Продакт приходит к команде с идеей. Разработчики кивают, открывают таск-трекер, начинают писать код. Через две недели выясняется: продакт имел в виду одно, команда поняла другое, а пользователь не просил ни того, ни другого.

Знакомая картина. И причина не в плохой разработке — причина в том, что между “я думаю, нам нужно это” и “мы начали это строить” не было ни одного шага проверки.

Маршрут из трёх фаз закрывает именно этот разрыв. Идея, PRD, Dev Kickoff — три этапа, после которых продакт и разработчики выходят на старт с одинаковым пониманием задачи.

Это не бюрократия ради бюрократии. Это минимальная структура, которая помогает не строить не то.

Что это

Три последовательных шага, которые превращают сырую гипотезу в задачу, которую можно разработать. Центральный элемент маршрута — PRD (Product Requirements Document, документ с продуктовыми требованиями).

PRD — это контракт между продактом и командой. Не API-контракт с жёсткой схемой запросов и ответов, а продуктовый контракт: что строим, зачем и где проходит граница. Технические детали — зона команды, продуктовый смысл — зона продакта.

Идея — входная точка. PRD — рабочий документ. Dev Kickoff — переход к коду. Каждый шаг имеет чёткий выход: что должно быть на руках, прежде чем переходить дальше.

Зачем нужно

Разрыв между идеей и кодом стоит дороже, чем плохой код. Плохой код можно переписать. Не ту фичу — можно потратить недели на разработку, которую никто не ждал.

Проблема, которую закрывает маршрут: разработчик решает не ту проблему. Не потому что плохо работает — потому что у него не было достаточного контекста. Продакт держал картинку в голове, команда получила задачу в таск-трекере, и между этими двумя состояниями — пропасть.

Инсайт: фичи застревают не в разработке. Они застревают раньше — когда никто не уточнил, что именно строим.

Как устроено

Маршрут состоит из трёх фаз. Каждая отвечает на свой вопрос и имеет свой выход. Скипнуть любую — значит передать непроверенные допущения дальше по цепочке.

Фаза 1. Идея

Идея — не задача, а гипотеза. Предположение, что определённое изменение уменьшит конкретную проблему. Без проверки это предположение превращается в фичу, которая решает несуществующую боль.

Чтобы идея стала задачей, нужно ответить на четыре вопроса:

  • Какая проблема? — с цифрой в руках. Не размытое “пользователям неудобно”, а “по понедельникам 40% попыток входа заканчиваются неудачей с первого раза”.
  • Кому эта проблема? — портрет аудитории с конкретным примером.
  • Почему это важно сейчас? — привязка к текущим приоритетам бизнеса.
  • Как выглядит успех? — что изменится, если всё сработает.

Выход фазы — opportunity brief на полстраницы. Короткий документ, который фиксирует гипотезу и проверяет, стоит ли тратить время на следующий шаг.

Фаза 2. PRD

Если идея прошла проверку, следующим шагом становится PRD. Это продуктовый артефакт: фиксирует суть решения и его обоснование, не вдаваясь в техническую реализацию.

Минимальная структура:

  • Context — суть проблемы, портрет пользователя, привязка к бизнес-метрике.
  • Goals & Success Metrics — по каким критериям поймём, что фича сработала.
  • Non-Goals — чего принципиально не будет в продукте.
  • User Stories — пользовательские сценарии: роль, потребность, ожидаемый результат.
  • Requirements — функциональные требования (поведение системы) и нефункциональные (производительность, безопасность, надёжность).
  • Out of Scope — границы текущей версии: что не трогаем сейчас.
  • Open Questions — нерешённые вопросы, требующие разбора на kickoff.

Важно: Non-Goals и Out of Scope — не одно и то же. Non-Goals — что принципиально не входит в продуктовый замысел. Out of Scope — что не делаем в этой версии, но может войти в следующую.

Фаза 3. Dev Kickoff

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

Пять составляющих, без которых kickoff не состоялся:

  • Walk-through PRD — продакт проходит по документу вместе с командой, разбирает непонятные места.
  • Техническое обсуждение — архитектурные решения, спорные моменты, вопросы, всплывшие при чтении.
  • Оценка — сроки с учётом выявленных рисков и допущений.
  • План — распределение задач по людям, даты промежуточных результатов.
  • Definition of Done — критерии, по которым поймём, что работа завершена.

Инсайт: Definition of Done — не формальность. Если команда не договорилась, что считать “готовым”, каждый будет мерить по своей линейке.

Когда использовать

Не все проекты идут одинаково. Размер команды определяет, сколько структуры нужно.

  • Маленькая команда (1–3 человека): краткий PRD на страницу, kickoff в чате. Формальные ритуалы здесь только тормозят.
  • Средняя команда (3–10 человек): полный PRD со ссылками на дизайн, аналитику, данные о пользователях. Kickoff — встреча с техническим обсуждением.

Большая команда (10+ человек): полноценное kickoff-мероприятие с повесткой, фиксацией решений и блоком вопросов-ответов. PRD здесь — точка опоры: без общего документа десяток людей расходится в разных направлениях.

Пример

Вернёмся к примеру с понедельничным входом: 40% неудачных попыток с первого раза. Проблема оцифрована, время зафиксировано, масштаб виден. Не абстрактное описание, а конкретика.

  • На фазе 1 команда отвечает: кто эти 40%, почему именно в понедельник, что считать успехом. Выход — opportunity brief.
  • На фазе 2 продакт пишет PRD: контекст проблемы, метрики успеха, что не делаем, сценарии пользователя. Разработчики дополняют техническую часть.
  • На фазе 3 — kickoff: продакт проходит по PRD, команда обсуждает архитектуру, даёт оценку, договаривается о плане и критериях завершения.

Без этого маршрута задача “починить вход” уходит в разработку как есть. Разработчик додумывает детали сам. Иногда угадывает. Часто — нет.

Фичи, которые прошли три фазы, редко возвращаются на доработку с формулировкой “мы не то имели в виду”.

Ограничения

Ограничения

PRD — продуктовый, не технический документ — PRD отвечает на “что и зачем”, не на “как”.

Технические детали — зона команды: продакт пишет продуктовую часть, разработчики дополняют свою. Если продакт лезет в архитектуру, а разработчик — в продуктовый смысл, документ теряет фокус и перестаёт быть рабочим контрактом.

Процесс масштабируется под команду — Полный маршрут с PRD и формальным kickoff в команде из двух человек — избыточность.

Бюрократия замедляет больше, чем помогает. Для 1–3 человек достаточно PRD на страницу и обсуждения в переписке. Для 10+ — наоборот, формальная структура становится необходимостью.

У каждой фазы — свой артефакт на выходе — Фаза 1 даёт opportunity brief.

Фаза 2 — PRD. Фаза 3 — план и Definition of Done. Без предыдущего артефакта следующий шаг строится на допущениях, а не на проверенных фактах. Скипнуть фазу — значит передать непроверенные гипотезы дальше.

Антипаттерны

Антипаттерны

Пропустить фазу идеи — Пользователь попросил фичу — она сразу ушла в таск-трекер, никто не спросил “зачем”.

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

PRD пишет разработчик — Технические детали — зона команды, но продуктовый документ — зона продакта.

Если разработчик пишет PRD, он додумывает продуктовый смысл вместо того, чтобы получать его готовым. Результат: технически точный документ, который решает не ту проблему.

Kickoff без разбора открытых вопросов — вопросы, оставшиеся без ответа, нужно вынести на встречу и закрыть до старта разработки.

Находить их в середине спринта — дороже. Секция Open Questions в PRD собирает все неизвестности в одном месте, чтобы не пропустить ни одно.

PRD на 30 страниц — Документ, который никто не дочитает.

Цель PRD — общее понимание, а не энциклопедия. Если команда не может уложиться в рабочий объём, проблема не в детализации — проблема в том, что объём задачи не помещается в один PRD.

Чеклист

Чеклист

Четыре вопроса фазы “Идея” отвечены — Проверьте: проблема сформулирована конкретно (не “неудобно”, а с цифрой), аудитория определена, есть связь с бизнес-целью, критерий успеха измерим.

Если хотя бы один ответ — “ну, примерно” — фаза не закончена.

PRD содержит семь обязательных секций — Context, Goals & Success Metrics, Non-Goals, User Stories, Requirements, Out of Scope, Open Questions.

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

Dev Kickoff закрыл пять пунктов — Walk-through PRD, техническое обсуждение, оценка, план, Definition of Done.

Если после kickoff нет плана с ответственностями и критериями завершения — встреча была, а kickoff не состоялся.

Ссылки

Ссылки

По теме

По теме