Escaping the Build Trap, глава 19: Разработка и оптимизация решения

Главная мысль: фича готова не тогда, когда её выпустили, а когда она достигла цели. Задайте критерии успеха до запуска и улучшайте продукт, пока не достигнете их.

Старое и настоящее Definition of Done: фича готова, когда достигнут outcome, а не когда код выпущен

Marquetly: от эксперимента к решению

Карен показывает руководству бизнес-кейс:

Strategic intent: удвоить рост выручки от индивидуальных пользователей за два года.
Проблема: только 25% учителей, которые начали курс, публикуют его. Второй курс публикуют только 10%.
Главная причина — монтаж видео.
Эксперименты подняли долю публикаций с 25% до 75%.

Почему не повторить эксперимент для всех:

Купить лицензии всем учителям слишком дорого. ROI не сходится.
Своя разработка займёт больше года до первой версии.
Предложение: купить компанию из Будапешта и встроить её технологию. Первая версия — через несколько месяцев.

Риски уже снижены. Эксперименты показали, что учителя сами монтируют видео, если есть удобный инструмент. CEO хочет решить эту проблему. Пока руководство решает, компания покупает пакет лицензий. Через три месяца сделка закрыта.

North Star и story mapping

Команда Кристы описала видение редактора и собрала документ North Star.

Инструмент	Что даёт
North Star	Общая картина для всей компании: проблема, решение, факторы успеха, ожидаемые outcomes
Story mapping	Разбивка работы по действиям пользователя. Помогает выбрать объём первой версии

North Star — не план работ. В нём нет ответа «как строить».
North Star меняется, когда команда узнаёт новое.
Story mapping придумал Джефф Паттон. Его цель — помочь команде говорить о работе и о ценности.
Сначала нужна большая картина. Без неё не на что опереться при сокращении объёма. И команда снова попадает в build trap.

Критерии успеха первой версии

Криста задала их до запуска:

75% учителей, которые создают или начинают курсы, начнут пользоваться редактором за месяц.
Доля опубликованных курсов вырастет с 25% минимум до 60%.
Время создания курса упадёт с трёх месяцев до меньше чем одного.

Рич отвечает за то, чтобы аналитика была готова к первому релизу.

Что получилось через месяц:

Редактор приняли 60% учителей. Это ниже цели.
Среди тех, кто принял, доля публикаций — 75%. Это выше прошлого уровня.
Следующий шаг: спросить тех, кто не стал пользоваться, почему.

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

Видение растёт из экспериментов

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

Приоритизация: Cost of Delay

Есть много фреймворков: benefits mapping, модель Кано и другие. Автор предпочитает Cost of Delay.

Дон Рейнертсен называет его «той единственной вещью», которую стоит измерять.
Cost of Delay — число, которое показывает, как время влияет на outcomes. Оно объединяет срочность и ценность.
Первая версия — это задача оптимизации: объём против времени.

Ошибка	Последствие
Слишком большой объём	Теряем деньги. Конкурент может занять рынок
Слишком слабая версия ради скорости	Теряем ранних пользователей. Вернуть их трудно

Качественная оценка. Ozlem Yuce и Joshua Arnold предложили оценивать каждую фичу по двум осям:

Срочность: каждый день без фичи мы теряем клиентов или выручку.
Ценность: фича решает самую сильную проблему клиента.

Пример Marquetly:

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

Настоящий Definition of Done

В Agile Definition of Done — это чеклист работ, чтобы выпустить ПО.
Проблема: он задаёт неверное ожидание. Выпустить — ещё не значит закончить.
Фича готова, когда достигла своей цели.
Частая ошибка: выпустить первую версию и перейти к следующей фиче, не измерив outcome.
Джефф Готельф: «Версия 2 — самая большая ложь в разработке ПО».

Как правильно:

Задать критерии успеха до запуска.
Считать Version 1 гипотезой.
Измерять и улучшать, пока цель не достигнута.
Если фича не работает, быть готовым откатить её и попробовать другое.

Критерии успеха становятся входом для Product Kata. Цикл тот же: направление, проблемы на пути, эксперименты. Для маленькой фичи шаги короче, но сам процесс не меняется.

Без среды процесс не работает

Команда Кристы смогла это сделать, потому что среда позволила. Она могла говорить с клиентами. Она была ориентирована на outcomes. Руководство дало ей свободу. Это признаки product-led компании. Культура, политики и структура — тема следующей части.

Ключевые термины

Термин	Значение
`North Star`	Документ с общей картиной продукта: проблема, решение, факторы успеха, outcomes
`Story mapping`	Разбивка работы по шагам пользователя, чтобы выбрать первую версию
`Version 1`	Первая версия. По автору — гипотеза, а не финал
`Cost of Delay`	Сколько ценности мы теряем, пока фича не выпущена. Срочность плюс ценность
`Definition of Done`	В Agile — чеклист для выпуска. По автору — фича достигла цели
`Success criteria`	Числовые цели фичи, заданные до запуска

Что это значит на практике

Метрики до релиза. Если PM задал критерии успеха, они должны считаться в день запуска. Договоритесь о событиях и витрине в dbt до начала разработки, а не после.
Наш Definition of Done. Модель в dbt не «готова», когда прошёл деплой. Она готова, когда дашборд на её основе используют для решения. Проверяйте это через usage-логи BI.
Cost of Delay в бэклоге данных. Спрашивайте про каждую задачу: что мы теряем каждую неделю, пока её нет? Если отчёт ждут для ежемесячного закрытия, срочность высокая.
Режем объём честно. Первая версия витрины может покрыть 2-3 главных разреза. Но данные в ней должны быть верными. Плохая первая версия подрывает доверие к данным.
North Star для платформы данных. Опишите на одной странице: какую проблему решает платформа, для кого и какие outcomes ждём. Это не план миграции.
Откат — это нормально. Если новый дашборд никто не открывает, уберите его. Не копите мёртвые модели и отчёты.

Вопросы для самопроверки

Почему Marquetly решила купить компанию, а не разработать редактор сама?
Чем North Star отличается от story map?
Что объединяет Cost of Delay? Почему сторонние видео не взяли в первую версию?
Чем «настоящий» Definition of Done отличается от Agile-версии?

Предыдущая: 18. Исследование решений. Следующая: 20. Коммуникация через результат.