Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели - Эрик Рис

Программа QuickBooks много лет занимает ведущие позиции в своей категории. Поэтому у нее есть большая база лояльных клиентов, и она приносит компании Intuit существенную долю ее дохода. Команда разработчиков QuickBooks обычно выпускала новую версию ежегодно, одним большим пакетом. Так происходило и с другим программным обеспечением для ПК, созданным в последние два десятилетия. И так было еще три года назад, когда в команду пришел Грег Райт, новый директор по маркетингу QuickBooks. Существовало множество процессов, обеспечивавших целостность продукта и его своевременный выпуск. Перед выпуском новой версии команда тратила достаточно времени на то, чтобы выяснить, чего хотят пользователи.

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

Последовательность действий была такой: процесс начинался в сентябре, первая бета-версия была готова в июне, а вторая – в июле. Бета-версия, по сути, должна проверить, не уничтожит ли новый продукт компьютеры пользователей или их данные – на этой фазе процесса можно устранить только серьезные ошибки.

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

Год первый: вперед – к провалу

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

Первая бета-версия была выпущена в июне, и тут же стали поступать негативные отзывы. Пользователи жаловались, но достаточных оснований для того, чтобы приостановить выпуск новой версии, не было, потому что технически она отвечала всем требованиям – не уничтожала компьютеры. Грег оказался в безвыходном положении. Он никак не мог выяснить, как эта обратная связь повлияет на реальное поведение потребителей на рынке. Это просто отдельные жалобы? Или симптом общей проблемы? Одно он знал наверняка: его команда должна уложиться в срок.

Когда продукт наконец вышел на рынок, разразилась буря. Пользователям требовалось в четыре-пять раз больше времени, чтобы совершать свои банковские операции, чем в более ранней версии. Оказалось, команда Грега не смогла удовлетворить именно ту потребность клиентов, которую пыталась удовлетворить (несмотря на то, что продукт был создан в соответствии со спецификациями). Кроме того, следующая версия продукта также должна была пройти через тот же самый процесс водопадной разработки. Поэтому у команды ушло девять месяцев на то, чтобы устранить ошибки. Это классический случай успешного выполнения некорректного плана.

Чтобы оценить степень удовлетворенности пользователей ее продуктами, компания Intuit проводит маркетинговые исследования с использованием NPS (Net Promoter Score – чистый индекс поддержки). Это надежный способ установки действенных показателей, дающий объективное представление о том, что пользователи думают о продукте. Я использовал его и в IMVU. Одно из достоинств NPS заключается в том, что он очень стабилен. Он измеряет основной уровень удовлетворенности потребителей и не подвержен незначительным колебаниям, регистрируя только существенные изменения в настроениях пользователей. В тот год показатели QuickBooks упали на 20 пунктов, впервые с того времени, как в компании начали проводить подобные исследования. Такое падение привело к существенным убыткам для Intuit и стало очень неприятным сюрпризом, ведь обратная связь от потребителей пришла на слишком поздних стадиях процесса, и у компании уже не было времени на итерацию.

Руководство компании решило, что пора что-то менять. Управлять этими изменениями было поручено Грегу. Теперь у него была важная миссия: достичь при разработке и развертывании QuickBooks скорости стартапа.

Год второй: мышечная память

Следующая страница этой истории рассказывает о том, что создать адаптивную организацию очень непросто. Грег решил изменить процесс разработки в QuickBooks на основании четырех принципов:

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

2. Сократить время цикла.

3. Быстрее получать обратную связь от потребителей, тестировать, не повредит ли новая версия компьютеры пользователей, и выяснять, как влияют новые опции на качество обслуживания клиентов.

4. Дать командам полномочия принимать быстрые и смелые решения.

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

Фактически процесс разработки оставался почти таким же, как в прошлые годы. Как поясняет Грег: «У организации есть “мышечная память”, и людям трудно избавиться от старых привычек». Грег сражался с системой и проводил отдельные изменения, например переназначил дату выпуска, но старые привычки были еще сильны.

Год третий: прорыв

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

Грег и Химаншу не стали менять сроки выпуска новой версии. Вместо этого они сосредоточились на изменениях, связанных с процессами, продуктом и технологиями, которые позволяли работать с меньшими партиями. Эти технические инновации способствовали тому, что отзывы от клиентов стали поступать раньше. Грег начал новый год не с планирования действий на 12 месяцев вперед, а с того, что назвал «заторами» идеи/кода/решения. Инженеры, продукт-менеджеры и пользователи объединили усилия и создали «трубопровод идей». Грегу, как продукт-менеджеру, было страшно начинать год, не имея точного перечня опций новой версии продукта, но он был уверен в своей команде и в новом процессе. В третий год работы он ввел новые методы:

• команды активно участвовали в создании новых технологий, процессов и систем;

• кросс-функциональные команды были сформированы вокруг новых идей;

• контакт с пользователями поддерживался с самого начала разработки каждой опции.

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

Переход к кросс-функциональной модели работы был не слишком гладким. Члены команды были настроены скептически. Например, некоторые продукт-менеджеры считали общение разработчиков с клиентами пустой тратой времени. Ведь прежде это было задачей продукт-менеджеров – определить проблему пользователей и выяснить, какие опции нужно создать. Поэтому некоторые продукт-менеджеры стали спрашивать: «Что я теперь должен делать? В чем заключается моя работа?» Точно так же некоторых разработчиков вполне устраивало, что им просто говорят, что делать, и они не горели желанием общаться с пользователями. Как это обычно бывает при подходе больших партий, и менеджеры, и разработчики предпочитали пожертвовать обучением ради «эффективности».