Как правило, первые три-четыре месяца ежегодного цикла создания новой версии занимали разработка стратегии и планирование, при этом новые опции не создавались. После разработки плана и установки промежуточных этапов команда тратила следующие шесть-девять месяцев на создание опции. Этот процесс достигал кульминации в торжественный момент выпуска новой версии, а затем, в самом конце, команда получала первую обратную связь о том, удалось ли ей удовлетворить потребности клиентов.
Последовательность действий была такой: процесс начинался в сентябре, первая бета-версия была готова в июне, а вторая — в июле. Бета-версия, по сути, должна проверить, не уничтожит ли новый продукт компьютеры пользователей или их данные — на этой фазе процесса можно устранить только серьезные ошибки.
Это метод водопадной разработки, который разработчики программного обеспечения используют уже много лет, — линейная система, основанная на подходе больших партий, успех которой зависит от правильности прогнозирования и планирования. Другими словами, она совершенно не соответствует современной быстро меняющейся среде бизнеса.
В 2009-м, в первый год своей работы в команде QuickBooks, Грег столкнулся с серьезной проблемой. Компания представила совершенно новую систему для онлайн-банкинга. Это была одна из самых важных опций новой версии QuickBooks. Команда провела несколько раундов тестирования удобства и простоты использования, применяя макеты и теоретические модели, а затем провела бета-тестирование на основании типовых данных о пользователях. В момент запуска все выглядело хорошо.
Первая бета-версия была выпущена в июне, и тут же стали поступать негативные отзывы. Пользователи жаловались, но достаточных оснований для того, чтобы приостановить выпуск новой версии, не было, потому что технически она отвечала всем требованиям — не уничтожала компьютеры. Грег оказался в безвыходном положении. Он никак не мог выяснить, как эта обратная связь повлияет на реальное поведение потребителей на рынке. Это просто отдельные жалобы? Или симптом общей проблемы? Одно он знал наверняка: его команда должна уложиться в срок.
Когда продукт наконец вышел на рынок, разразилась буря. Пользователям требовалось в четыре-пять раз больше времени, чтобы совершать свои банковские операции, чем в более ранней версии. Оказалось, команда Грега не смогла удовлетворить именно ту потребность клиентов, которую пыталась удовлетворить (несмотря на то, что продукт был создан в соответствии со спецификациями). Кроме того, следующая версия продукта также должна была пройти через тот же самый процесс водопадной разработки. Поэтому у команды ушло девять месяцев на то, чтобы устранить ошибки. Это классический случай успешного выполнения некорректного плана.
Чтобы оценить степень удовлетворенности пользователей ее продуктами, компания Intuit проводит маркетинговые исследования с использованием NPS (Net Promoter Score — чистый индекс поддержки). Это надежный способ установки действенных показателей, дающий объективное представление о том, что пользователи думают о продукте. Я использовал его и в IMVU. Одно из достоинств NPS заключается в том, что он очень стабилен. Он измеряет основной уровень удовлетворенности потребителей и не подвержен незначительным колебаниям, регистрируя только существенные изменения в настроениях пользователей. В тот год показатели QuickBooks упали на 20 пунктов, впервые с того времени, как в компании начали проводить подобные исследования. Такое падение привело к существенным убыткам для Intuit и стало очень неприятным сюрпризом, ведь обратная связь от потребителей пришла на слишком поздних стадиях процесса, и у компании уже не было времени на итерацию.
Руководство компании решило, что пора что-то менять. Управлять этими изменениями было поручено Грегу. Теперь у него была важная миссия: достичь при разработке и развертывании QuickBooks скорости стартапа.
Следующая страница этой истории рассказывает о том, что создать адаптивную организацию очень непросто. Грег решил изменить процесс разработки в QuickBooks на основании четырех принципов: