Одним из самых известных методов по адаптации бережливого производства к цифровой разработке можно считать бережливый стартап, описанный в одноименной книге Эриком Райсом. Он делится множеством зарекомендовавших себя на практике концепций, таких как минимально жизнеспособный продукт, которые стали неотъемлемой частью продуктовой разработки.
Рис. 2.2. Бережливый цикл
Одна из идей, описанных в книге, – цикл бережливого стартапа (Lean startup cycle) – идеального, максимально бережливого цикла для цифрового производства (рис. 2.2).
Суть идеи в том, чтобы максимально быстро с минимальными отходами пройти этапы формирования ценности, организации и обеспечения потока ценности, вытягивания (получения обратной связи от внешней среды) и внедрения улучшений на основе полученной обратной связи – на этом цикл замыкается, и этапы повторяются.
Цикл бережливого стартапа актуален не только для цифровых продуктов, запускаемых небольшими компаниями, но и для любых цифровых инициатив, включаемых в рамках уже зрелого продукта или внутрикорпоративных пилотных проектов.
2.3.1. Этапы цикла бережливого стартапа
Табл. 2.2. Этапы бережливого стартапа
* Гипотеза жизнеспособности инициативы – перечень метрик инициативы и их пороговые значения, при достижении которых инициатива признается потенциально (в отдаленной перспективе) жизнеспособной.
2.4. Циклы открытия и поставки
Прежде чем запустить продукт или другую инициативу важно определить образ того, что будет запускаться. Для этого необходимо:
➠ собрать идеи;
➠ оценить релевантность идеи потребностям пользователей;
➠ оценить рыночные условия;
➠ оценить идеи на предмет их инвестиционной привлекательности;
➠ определить объем работ и бюджет для запуска фазы MVP и фазы масштабирования.
Этап такого прояснения принято называть этапом открытия; также часто можно услышать «дискавери» (англ, discovery – открытие; рис. 2.3).
Рис. 2.3. Связь циклов открытия и циклов поставки
После того как объем работ определен и решение о старте работ принято, начинаются циклы поставки, итеративно улучшающие продукт от спринта к спринту.
Если цикл поставки – это интуитивно понятная составляющая производства цифрового продукта, то цикл открытия поэтапно появляется при достижении определенной зрелости компании. Например, сначала может появиться культура проведения исследований для оценки соответствия потребностям пользователя (CustDev, глубинные интервью), потом исследования рынка (конкурентный анализ, бенчмаркинг[18]), а потом оценка инвестиционной привлекательности. (Подробнее о бенчмаркинге см. в п. 4.3.3.4.)
Логично, что бережливый подход подходит для цикла открытия и к нему применим механизм бережливого цикла. Артефакты, необходимые для принятия решения о запуске разработки, проходят этапы цикла максимально быстро и с минимальными отходами. Затем артефакты цикла дискавери определяют дальнейшую разработку и, следовательно, должны быть эффективны как граничный объект[19].
При масштабировании производственного цикла, когда несколько продуктовых команд делают один продукт, как правило, приходят к тому, что цикл поставки (спринт) занимает две недели, а цикл открытия длится один квартал. Итого на один цикл открытия приходится шесть спринтов. Это позволяет выработать эффективный ритм согласования. Размеренность инициатив позволяет владельцу продукта согласовывать с внешними/ внутренними заказчиками (стейкхолдерами) крупные цели и не погружаться в мелкие задачи квартального цикла.
Табл. 2.3. Роли участников в разных циклах
Владелец продукта часто привлекает к работе в цикле открытия различных экспертов. Например, для декомпозиции и оценки объема работ инициативы – специалиста из команды разработки, для выравнивания видения образа результата – стейкхолдеров и внешних экспертов из других подразделений. Таким образом, можно говорить о виртуальной команде открытия, которая создается для проработки инициативы перед запуском. В этом случае владелец продукта, разработчики и стейкхолдеры постоянно могут сочетать в себе две роли – открытия и поставки (табл. 2.3).
Этап открытия не имеет жестких стопроцентных стандартов, меняется от компании к компании и часто имеет различные вариации в зависимости от бюджета. Во многих компаниях по той же причине многие этапы опускаются для повышения скорости течения инноваций.
Из хороших практик можно выделить трехэтапную модель цикла открытия:
1. Концепция. На этом этапе формируется краткое описание бизнес-идеи. Для эффективной генерации и обсуждения гипотез описание регламентируют, фиксируя его обязательные атрибуты, например: сегмент пользователей, проблема сегмента, возможные решения, поток доходов, поток расходов и прочее. За основу часто берется модель «бережливый холст» (Lean canvas) или ее предшественница «холст бизнес-модели» (Business model canvas) Александра Остервальдера. Описанные идеи обсуждаются со стейкхолдерами, и в случае веры в успех выделяются ресурсы для дальнейшей проработки концепции и превращения ее в гипотезу.
2. Гипотеза. На этом этапе производится анализ инвестиционной привлекательности инициативы – изучаются потенциальные конкуренты (конкурентный анализ) и их бизнес-показатели (бенчмаркинг). Определяются потенциальные бизнес-показатели инициативы – сроки прибыльности и окупаемости, потенциальная доходность. Для того чтобы уменьшить риск ошибки, в продуктовом подходе принято выделять пилотную фазу (MVP), которая позволяет, рискуя только частью бюджета, определить инвест-привлекательность. Для MVP также оцениваются бюджет и сроки и, главное, опережающие индикаторы, позволяющие как можно быстрее определить успех проекта. Формулируются гипотезы пилотного проекта – критерии, по которым принимаются решения о дальнейшем развитии или приостановке инициативы.
3. Пилотная фаза. На этом этапе производятся мероприятия для наиболее быстрой проверки гипотез. Как правило, это разработка MVP и минимальная маркетинговая кампания. В процессе сбора данных может понадобиться дополнительный бюджет на доработку и рекламу. После получения данных о подтвержденных гипотезах стейкхолдеры принимают решение о запуске следующих инициатив по развитию продукта или о приостановке.
Более подробно этапы цикла открытия будут рассмотрены в главе 4.
Так как сформированный осознанный цикл открытия появляется в компаниях при достижении определенной зрелости, то логичнее будет начать описание с цикла поставки.
Глава 3Цикл поставки
В классическом промышленном производстве и строительстве цена ошибки очень высока – крайне сложно «откатить» последствия неверного решения назад и все исправить. Отзыв партии авто или перестройка зданий критичны для бизнеса. В связи с этим требуется кропотливая длительная фаза проектирования, а внедрение инноваций подразумевает длительный этап исследований и тестов. В разработке программного обеспечения исправить продукт у всех пользователей можно практически в реальном времени. Это позволяет максимально быстро подстраиваться под желания пользователей, а также под действия конкурентов и регулятора.
На заре разработки ПО на рынке было множество больших компьютерных корпораций и академических институтов, где традиционно преобладал классический, глубоко регламентированный проектный подход. Со временем доступ к компьютерам демократизировался, и разработка стала доступна сначала студентам профильных вузов, а потом и большему кругу лиц.
Независимые компании-разработчики стали составлять весомую конкуренцию гигантам, обладая меньшей численностью, большей скоростью и зачастую не имея представления о том, «как правильно».
Начали появляться новые подходы к разработке, такие как Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и многие другие. Эти подходы, в свою очередь, черпали вдохновение в других быстрых практиках начиная от бережливого производства и заканчивая практиками армейской подготовки.
Общим для этих подходов была концепция гибкости, или часто можно услышать Agile (англ, гибкость[20]). Основная идея этой концепции – короткие циклы поставки. Важно обратить внимание, что ключевое слово здесь «поставки». Подразумевается, что не реже чем раз в месяц жизнь пользователей становится лучше.
Запуская Scrum в Альфа-банке, мы решили, что будем работать спринтами, но каждая роль будет эти две недели заниматься своим артефактом и передавать его на следующий – производственный – этап. Например, сначала аналитики две недели пишут ТЗ, затем дизайнеры две недели делают макеты по ТЗ, затем фронтенд-разработчики две недели верстают макеты, затем бэкенд-разработчики две недели делают серверную часть, потом тестировщики две недели ее тестируют…
Поначалу с вершин опыта проектного подхода все кажется очень логичным, но на самом деле такой подход приносит больше проблем, чем обычный водопад. Во-первых, цикл поставки от идеи до воплощения занимает несколько месяцев! Во-вторых, такой подход очень чувствителен к качеству артефактов, если на каком-то этапе обнаруживаются проблемы – ошибки в коде или невозможность сверстать макет, – то вся система рушится, нужно отправлять артефакт на доработку, и тогда сдвигаются сроки на всех этажах. В-третьих, такая система оказалась очень чувствительной к экстренным срочным доработкам – все уровни прерывали свои спринты и брались за новую срочную задачу. Это порождало великое множество промежуточных артефактов, многие из которых так и не пошли в производство.
Побочным эффектом становится необходимость отслеживания всех промежуточных артефактов. На инвентаризацию уходило очень много времени, при этом было очевидно, что половина артефактов безвозвратно утратила актуальность, но они все равно мешались в бесконечных колонках Trello. Позднее мы узнали, что такой подход называется Scrum-fall: Scrum + Waterfall, и обычно он порождает массу проблем с производством и культурой – команда разделяется на этажи, каждый занят своим артефактом и не ориентирован на заботу о результате и пр. Я помню это удивительное чувство освобождения, возникшее, когда мы перешли в режим, в котором все делают все в одном спринте. Артефакты порождались и утилизировались в спринте и их не нужно было учитывать. Команда работала сообща и принимала решение о необходимости артефакта и качестве его проработки, а самое главное, от идеи до релиза проходило две недели.