Менеджмент цифрового продукта. От идеи до идеала

«Давайте сначала все по договору закроем, а потом начнем вносить правки», – именно так я отвечал клиенту, управляя небольшой компанией заказной разработки. Планы разработки шли тогда 3 4 квартала и уже на 1-2-м квартале накапливалось смещение сроков, и изменения в процессе – даже очевидные и существенные – были подобны смерти.

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

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

3.1.2. Пример гибкого подхода

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

➠ Проектирование, в результате которого мы получаем проект отеля на 20 номеров разной комфортности и вместимости, с открытым бассейном.

➠ Вырываем котлованы под основное здание и под бассейн.

➠ Возводим стены этаж за этажом.

➠ Ставим крышу.

➠ Проводим отделку.

➠ Строим бассейн.

➠ Запускаем постояльцев.

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

Гибкий подход позволяет возвращать инвестиции как можно раньше, постепенно наращивая объем входящего денежного потока.

Рассмотрим строительство отеля с активным применением гибкого подхода:

➠ Привозим на участок жилой блок-контейнер.

➠ Делаем рекламу и запускаем жильцов.

➠ Собираем обратную связь об их предпочтениях: например их полностью устраивает уровень комфорта блок-контейнера.

➠ Входящий денежный поток позволяет закупить в сезон еще несколько контейнеров.

➠ По обратной связи мы понимаем, что вместо открытого бассейна постояльцам не хватает теннисного корта.

➠ Возводим теннисный корт.

➠ Собираем статистику по составу отдыхающих семей, что позволяет скорректировать проекты блок-контейнеров по наиболее востребованным сценариям; это позволило увеличить наполняемость и снизить расходы на рекламу

➠ Полученные данные о финансовой модели привлекли инвестора, который вложил деньги в еще несколько контейнеров и расширение участка.

Рис. 3.1. Сравнение водопадного и итеративного подходов

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

Разумеется, гибкий подход не всегда и не везде показывает максимальную эффективность. Давайте рассмотрим области применимости разных типов подходов.

3.1.3. Область применения гибких подходов

После знакомства с гибким подходом возникают две радикально противоположные идеи. Одни считают, что Agile нужно использовать повсеместно, другие, что в их случае (госзаказ, корпоративные закупки и т. и.) этот подход неприменим. Рассмотрим, в каких же случаях какие типы процессов уместно применять.

В 1999 году Дэйв Сноуден из IBM Global Services предложил свою модель классификации «миров», в которых приходится действовать. Модель называется Cynefin (среда обитания, пристанище), и в ней определены четыре операционных контекста:

➠ Simple (понятный или очевидный) – мы находимся в предсказуемой среде, все объекты и процессы знакомы и можно применять сложившиеся лучшие практики для достижения результата.

➠ Complex (комплексный, сложный в значении многосоставный) – в этом операционном поле причинно-следственные связи можно получить ретроспективно, в результате совершенного действия. Тут работает цикл «исследуй-восприни-май-реагируй».