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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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