Discovery и Delivery: как устроить продуктовый цикл
Если любая идея сразу превращается в задачу разработчикам, процесс напоминает трубу: сколько запросов поступило, столько предстоит реализовать. Воронка устроена иначе. На каждом этапе команда уточняет, какую проблему решает, каких доказательств не хватает и стоит ли тратить следующий объём ресурсов.
По авторскому фреймворку Евгения Мео, представленному на доске Discovery Process. Исходный гайд и рабочий шаблон.
Схема: шесть этапов и четыре точки решения
| Этап | Что происходит | Что остаётся после |
|---|---|---|
| 0. Идеи | Собираем сигналы пользователей, поддержки, продаж и аналитики | Открытый бэклог идей |
| 1. Отбор | Уточняем проблему, зависимости и предварительные затраты | Короткое описание инициативы и объяснение решения |
| 2. Discovery | Проводим исследования и проверяем экономику | Доказательства, ограничения, решение продолжать или остановиться |
| 3. Планирование | Формулируем результат и согласуем обязательства | OKR и план на квартал |
| 4. Delivery | Разрабатываем, проверяем и показываем результат | Рабочее изменение и обратная связь |
| 5. Метрики | Сравниваем ожидания с фактом | Решение масштабировать, изменить или остановить |
Бэклог идей: храните проблему, а не только просьбу о кнопке
В источнике идеи приходят из интервью, поддержки, продаж, анализа конкурентов и метрик. Превратите сообщение «добавьте экспорт» в короткое описание: кто просит, в какой ситуации, что не получается сейчас и как человек обходит ограничение. Ссылка на разговор ценнее уверенной формулировки без основания.
Бэклог должен быть доступен заинтересованным участникам. Это не обещание сделать всё: видимость запроса и обязательство реализовать его — разные вещи. Для каждой инициативы полезно хранить статус и причину решения.
Отбор: как объяснить, почему идея пока не идёт дальше
Сначала уточняются требования и зависимости, затем оцениваются ценность и усилия. На доске предложены ICE, RICE и WSJF. Не смешивайте их оценки в одну таблицу: выберите способ, чьи входные данные команда действительно может объяснить. Точная цифра, собранная из предположений, не делает решение точным.
После Gate 1 у стейкхолдера должен остаться ответ: почему берём, почему откладываем и какой сигнал может изменить решение. «Низкий приоритет» без аргумента провоцирует повторные переговоры. «Нет подтверждения проблемы у выбранного сегмента; вернёмся после интервью» задаёт проверяемый следующий шаг.
Что делают на Discovery
Интервью, опрос, проверка прототипа, модель привлечения и ROI-калькулятор нужны не для комплекта документов. Каждый инструмент закрывает конкретную неопределённость: существует ли проблема, работает ли решение, достижима ли экономика. Порядок зависит от наиболее рискованного предположения.
На Demo Day показывают не только удачные гипотезы. Отрицательный результат сохраняют в «архиве убитых гипотез»: что проверяли, на каких данных отказались и при каких изменениях стоит вернуться. Это защищает команду от повторного запуска той же идеи через полгода.
В исходной схеме Discovery-команда включает продакта, PMM, тимлида, аналитика и дизайнера. Delivery-команда собирается вокруг реализации. Это распределение ответственности, а не требование создать два изолированных отдела.
Как выводы превращаются в OKR
На планировании команда договаривается об изменении, которое хочет получить, и о способе его измерения. Выпустить функцию — ещё не доказать пользовательскую ценность. Пропишите ключевой результат, инициативы и ограничения мощности команды. Подробный алгоритм есть в гайде по постановке OKR.
После релиза: сравните факт с гипотезой
Смотрите не только основную метрику, но и защитные показатели: рост использования не должен скрывать ухудшение качества или нагрузки на поддержку. На этапе 5 результаты снова пополняют бэклог. Масштабирование — решение на основании эффекта, а не автоматическое продолжение уже сделанной разработки.
С чего начать небольшой команде
- Возьмите одну инициативу, а не перестраивайте сразу весь процесс.
- Запишите проблему, ожидаемый результат и самое рискованное предположение.
- Назначьте ответственного за проверку и дату обсуждения доказательств.
- Заранее определите условия остановки, чтобы не менять их после неудобного результата.
- После выпуска вернитесь к исходной гипотезе и зафиксируйте вывод.
