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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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