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

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

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

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

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

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

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

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

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

* * *

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

Мало изменить культуру — основные изменения, необходимые для создания адаптивной организации, должны произойти в мышлении ее сотрудников. Как мы видели в главе 9, метод бережливого производства требует, чтобы все действия компании воспринимались системно. А затем нужно сокращать размеры партий и время прохождения цикла всего процесса. Таким образом, для достижения долгосрочных изменений команде QuickBooks нужно было создать новые инструменты и изменить платформы, чтобы начать работать быстрее и по-новому.

Например, одной из основных проблем в процессе выпуска первой альфа-версии в прошлом году было то, что QuickBooks — очень важный продукт с точки зрения миссии компании. Для множества небольших фирм он является основным инструментом работы с важными финансовыми данными. Поэтому команда очень боялась, что альфа-версия, этот первый минимально рабочий продукт, может повредить базы данных клиентов. И хотя разработчики были объединены в небольшие команды, этот страх мешал им следовать подходу небольших партий.

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

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

* * *

Работая по системе «экономичный стартап», команда может использовать адаптивные методы для разработки более сложных процессов, не отказываясь при этом от основного преимущества: быстро проходить цикл обратной связи «создать — оценить — научиться». Одно из основных преимуществ использования методов из арсенала бережливого производства заключается в том, что в процессе развития компания может в соответствии с ними совершенствовать свои операции. Команды уже знают, как следовать дисциплине, разрабатывать процессы с учетом своей индивидуальной ситуации, и используют такие методы бережливого производства, как «Пять “Почему?”» и работу небольшими партиями. И когда успешный стартап превращается в стабильную компанию, в нем уже есть культура, основанная на строгих экспериментах и дисциплине, характерная для лучших компаний мира, таких как Toyota.

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