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

7. Более дорогое решение. Если идея вашего продукта – удешевление уже существующего сервиса, то можно использовать более дорогой сервис под капотом для тестирования. Например, для тестирования приложения доставки персональной еды можно использовать существующие сервисы доставки и рестораны. Да, Юнит-экономика[40] не будет сходиться, но можно сделать выводы о востребованности продукта и готовности пользователей за него платить. С появлением больших лингвистических моделей типа ChatGPT появилась возможность использовать его для решения более простых задач, вроде проверки корректности вводимых данных. Например, указал ли клиент отчество ребенка и совпадает ли оно с именем отца. В случае удачного эксперимента можно начать использовать более дешевые специализированные алгоритмы.

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

Популярный слоган адептов – «Fake it till you make it» («Имитируй, пока не сделаешь»).

Например, прежде чем разработаешь продукт, можно организовать предзаказ или кампанию на Kickstarter и таким образом замерить интерес. Или сделать «Fake door» (фальшивую дверь) – одну или несколько рекламных кампаний, чтобы протестировать, какие свойства будущего продукта или стилистика оформления будут наиболее привлекательны.

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

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

Так как нет возможности заранее предсказать результат эксперимента, в компании должна быть развита культура совершения ошибок. Один из подходов, культивирующих культуру ошибки, – «Fail fast» (быстрый провал). Вместо того чтобы искать подтверждения жизнеспособности, возможно, более эффективным будет подтверждение того, что эксперимент провалится. Тогда, помимо продуктовых гипотез типа «мы идем на это, если…», формулируются контргипотезы «мы не идем на это, если…».

Табл. 3.2. Пример записи гипотез и контргипотез пилотного проекта

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

Рис. 3.7. Связь процессов из оперативных контекстов с циклами открытия и поставки

Как уже стало понятно, в компании может быть несколько типов процессов, для которых применимы разные подходы.

Например:

1. Проработка идей того, какие гипотезы стоит проверить, – это запутанный мир, где следует применять Kanban.

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

3. Превращение гипотезы в продукт для большого количества пользователей – комплексный мир, где зарекомендовал себя Scrum.

4. Если в процессе появляется ранее воспроизводимая операция, то максимальную эффективность показывает водопад.

Важно отметить, что предложенный каскад процессов – лишь общая практика, и многие процессы могут ситуативно меняться, например:

➠ На этапе стартапа, когда компания строится вокруг одного продукта, может быть рано применять конвейер открытий.

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

➠ Если внутри одной поставки недостаточно очевидно распределение ролей в команде, то не обязательно использовать водопад для планирования и действовать параллельно для достижения результата.

3.2. Scrum

Как стало понятно из предыдущих глав, Scrum – это один из ключевых процессных фреймворков в большинстве топовых IT-компаний. Де-факто Scrum – это промышленный стандарт продуктовой разработки. Даже если вы услышите, что в крупной компании применяется собственный Agile-фреймворк, то. скорее всего, это адаптированная версия Scrum.

Scrum в переводе с английского – схватка вокруг мяча. Термин, применяемый в регби, означает прием, когда команда объединяется и наваливается на противников. Смысл такой аналогии в том, что команда разработчиков «наваливается» на проблему для достижения цели спринта, в отличие от водопадного подхода, где каждый в рамках своей выделенной роли выполняет определенный этап обработки артефакта.