Понимание новой единицы прогресса: переход от вопроса к вопросу

 

Обучение, ведущее от сомнения к уверенности, зачастую является процессом проб и ошибок. Методом проб и ошибок мы учимся ходить, ездить на велосипеде, читать или играть на музыкальном инструменте. Другими словами, мы учимся посредством действий. Когда мы создаем команды для проектов, мы хотим, чтобы они могли действовать, и именно таким образом, чтобы это принесло им какие‑либо знания.

В рамках старой модели индустриальной эпохи мы, чтобы чему‑либо научиться, как правило, полагались на тщательное предварительное исследование. К тому времени, как мы приступали к действиям, мы считали, что изучение уже завершилось. Подход «почувствовать и отреагировать» – другой. Мы меньше уделяем внимания предварительному исследованию и больше концентрируемся на изучении посредством действия. Мы хотим, чтобы наши команды имели возможность попробовать что‑то новое и чтобы мы не винили их за «неудачные» попытки. Любой ответ команды (положительный или отрицательный) является единицей прогресса. Она приносит членам команды коллективные знания и позволяет им в следующий раз задать лучший вопрос (т. е. организовать лучший диалог с рынком).

На сегодняшний день команда Cooking Light Diet ответила на свои первые вопросы. Тестирования целевой страницы помогли членам команды найти идею, которая обладала достоинствами – она обещала вывести их к стратегической цели. Члены команды составили большой список клиентов, которые были готовы заплатить за сервис. Теперь группа была готова перейти к следующим вопросам. Пришло время более подробно выяснить, какой контент и функции будут важны для покупателей.

Члены команды знали, что исследование того, какие функции нужно создать, как должна работать система и как она должна выглядеть, могло занять недели. Вместо этого они снова выбрали оперативное изучение. Они решили запустить пилотную версию сервиса. В этом эксперименте они взяли первые 12 имен из списка ожидания и предоставили им доступ к сервису. Все это было необыкновенно интересно для участников, за исключением одной маленькой детали: сервиса как такового не было, по крайней мере в классическом понимании. В реальности команда запустила тестирование Волшебника страны Оз, называемое так потому, что система, по идее, управляемая программным обеспечением, на самом деле полностью функционировала благодаря усилиям человека «за кулисами», прямо как в фильме.

Команда Cooking Light Diet поддерживала диалог с первой группой участников нового проекта с помощью электронной почты и телефонных интервью. Работники использовали информацию, собранную во время этих бесед, чтобы «вручную» создать меню для каждого участника. Они еженедельно отправляли каждому покупателю меню на красиво оформленном шаблоне. В конце каждой недели члены команды проводили телефонные беседы со своими новыми клиентами, чтобы понять, какие элементы нового сервиса были ценными. Они опрашивали участников, по каким рецептам те готовили еду, какая дополнительная информация была им важна, интересовались процессом покупок и планирования. Они пытались понять, что сделает сервис более привлекательным. Команда не создавала веб‑страниц, почти не писала код и не потратила ни копейки на маркетинг. Тем не менее их клиенты опробовали новый сервис. Благодаря этим личным, нетехнологичным взаимодействиям, члены команды Cooking Light Diet продолжили разговор, который они начали с тестов целевой страницы. При этом они выстраивали алгоритм циклов обучения для проекта в целом.

Методы Волшебника страны Оз иногда называют услугами консьержа, потому что они основаны на личном взаимодействии между поставщиком услуг и покупателем. Такой непосредственный контакт с клиентами делает возможным ценный двусторонний разговор, который позволяет командам сосредоточить свои усилия на тех функциях, которые обеспечивают максимальную ценность для клиентов.

Затем команда Cooking Light Diet начала постепенный перевод сервиса – функцию за функцией – на автоматизацию. При этом они продолжали выполнять работу вручную до тех пор, пока у них не появилось четких доказательств необходимости автоматизации, а затем создали наименьшее число программ, которые удовлетворяли бы эту потребность. Иногда доказательства были качественными: они общались с несколькими клиентами и получали обратную связь. В других случаях, особенно по мере роста сервиса, доказательства были количественными. С помощью системных показателей команда определяла, что некоторые функции использовались не так часто, как ожидалось, и корректировала программу. Таким вот образом, внедряя по одной функции за раз, команда и запустила сервис. С каждым новым, немного более сложным его запуском члены команды все лучше понимали, что именно нужно рынку, а затем реагировали на это посредством постоянных обновлений.

Команда получила возможность постоянно проверять свои идеи и совершенствовать свое понимание благодаря тому, что группа управления создала обстановку, в которой команда могла экспериментировать, что сыграло решающую роль. В частности, политика менеджмента использовала следующую тактику:

• Позволяла команде совершать ошибки, пока те были относительно несерьезными, и команда на них училась.

• Обеспечила свободу в рамках четко заявленных границ для принятия собственных решений, так что время не было потрачено впустую из‑за ожидания обратной связи от руководителей.

• Оценивала поведение клиента как показатель прогресса, а не количество функций, которые запускала команда.

Это хороший пример механизма, используемого чуткими организациями. Это компании, которые ценят обучение, помогают командам с решением рабочих проблем, при этом четко ограничивая рамки, в которых те могут работать, и устанавливая точные показатели успеха. Команды выясняют, как лучше всего решить проблемы, переходя от вопроса к вопросу, а критерии успеха служат барометром прогресса.