Roadmap требований — это “переводчик” между продуктовым roadmap и планом релизов: он раскладывает большие продуктовые намерения на проверяемые требования, которые реально уезжают в конкретные версии. Связать их можно за 2–6 недель через единую иерархию (Outcome → Epic → Feature → Story), но ключевой риск — «красивый roadmap без мощности команды и без критериев готовности».

Почему у BA это постоянно болит (и да, это нормально)

Боитесь потратить квартал на “стратегию”, а потом всё равно выпускать по принципу: «что успели — то в релиз»? Добро пожаловать в клуб. Между продуктовым roadmap (куда бизнес смотрит как на обещание рынку) и релиз-планом (куда delivery смотрит как на выживание) лежит пропасть из разночтений, зависимостей и оценок “на глаз”.

Я видел одно и то же в разных компаниях: roadmap рисуют в терминах “фичи”, релизы — в терминах “задач”, а требования вообще живут в Confluence как литературный жанр. И потом BA виноват, что «не связал». Хотя проблема обычно не в BA, а в отсутствии общей модели: что именно мы планируем и как это конвертируется в поставку.

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

1) Сначала договоритесь, что такое roadmap продукта (а не “список хотелок”)

Тезис: продуктовый roadmap должен быть про ценность и результаты (outcomes), а не про “сделаем кнопку”.

Обоснование: когда roadmap состоит из фич, он неизбежно конфликтует с релиз-планом: фича не равна поставке, у фичи есть зависимости, исследования, техдолг, дизайн, риски.

Практический вывод: на верхнем уровне фиксируйте цели/результаты (например, “снижение времени онбординга на 20%”), а не список экранов.

Подводный камень: «Outcome без метрики» — это тоже художественная литература. Если нельзя измерить — нельзя связать с релизами.

2) Введите иерархию артефактов: Outcome → Epic → Feature → Story → Release

Тезис: связь появляется не “из воздуха”, а через общую декомпозицию, где каждый уровень отвечает на свой вопрос.

Практический вывод: у каждого элемента в бэклоге появляется “родитель” и понятный маршрут до релиза. Если Feature не привязана к Epic/Outcome — это кандидат на вылет или на техдолг, но не на roadmap.

Подводный камень: «Epic на 6 месяцев» без разрезания на Feature — это скрытый водопад. Команда просто не сможет прогнозировать релизы.

3) Roadmap требований: что это и из чего он состоит

Тезис: roadmap требований — это не “второй roadmap”, а матрица связей между ценностью, требованиями и поставкой.

• Срез по времени: ближайшие 1–2 релиза детально, дальше — крупными блоками (rolling wave).
• Срез по ценности: каждый блок требований привязан к Outcome/OKR/KPI.
• Срез по рискам: что нужно исследовать (Discovery), что нужно согласовать (юридическое/безопасность), что зависит от других команд.
• Срез по готовности: Definition of Ready / критерии приемки / тестовые сценарии на ключевые потоки.

Практический вывод: BA становится “менеджером связности”: он держит трассировку от цели до релиза и обратно (что выкинули из релиза — какие outcomes пострадают).

Подводный камень: если трассировка живёт только в голове BA — при первом отпуске всё развалится. Нужен артефакт в Jira/Azure DevOps/Confluence.

4) Релиз-план строится от мощности (capacity), а не от мечты

Тезис: roadmap продукта обещает, релиз-план отвечает: “с нашей скоростью — вот что реально”.

Обоснование: если команда делает условно 30–50 сторипойнтов в спринт (или имеет стабильный throughput), то релиз-план — это упаковка Feature под эту мощность, а не список “важного”.

Практический вывод: вместе с delivery фиксируйте:

1. даты релиз-окон (например, раз в 2 недели/раз в месяц);
2. ограничения: freeze, регуляторика, маркетинговые даты;
3. буфер на bugfix/поддержку/инциденты (обычно 10–30% мощности);
4. правило: что входит в релиз (MVP), что — “если успеем”.

Подводный камень: “впихнуть всё” приводит к тому, что релиз становится помойкой и теряет смысл как единица ценности.

5) Два механизма, которые реально “сшивают” планы: трассировка и критерии готовности

Тезис: связь roadmap ↔ релиз работает, когда есть (1) трассировка и (2) одинаковые правила качества.

Коммерческие факторы (то, что обычно забывают посчитать)

Связка roadmap и релизов ломается не из-за “плохих требований”, а из-за стоимости изменений. Скрытая цена обычно такая:

• Переработка: требования переписывают 2–3 раза из-за отсутствия DoR.
• Зависимости: ожидание другой команды съедает релиз-окна.
• Контекст-свитч: 10 параллельных фич “в работе” замедляют каждую.
• Тестирование и релизные процедуры: их нет в roadmap, но они съедают сроки.

Если это не учитывать, продуктовый roadmap превращается в список обещаний, а релиз-план — в расписание разочарований.

Экспертный вердикт и инструмент: чек‑лист BA, чтобы связка не развалилась

• 1) У каждого пункта roadmap есть измеримый outcome? Если нет — это не roadmap, а wish-list.
• 2) У каждой Feature есть “родитель” (Epic/Outcome) и владелец? Иначе она будет вечным пассажиром бэклога.
• 3) Есть карта зависимостей? Хотя бы на уровне “кто от кого ждёт”.
• 4) DoR/DoD зафиксированы и реально используются? Не “для галочки”.
• 5) Релиз упакован как ценность, а не как набор задач? В релиз-ноутах должно быть понятно “что изменилось для пользователя”.
• 6) Планирование rolling wave: ближайшие 1–2 релиза — детально, дальше — грубо.
• 7) Есть правило резки scope: что выкидываем первым при сдвиге сроков (и какие outcomes пострадают).

Частые вопросы