Roadmap продукта — это публичный договор о том, зачем и в каком порядке вы делаете изменения в продукте, с понятными приоритетами, зависимостями и критериями успеха; хороший roadmap разработки продукта одновременно читается бизнесом (ценность и сроки) и командой (объём, риски, техдолг), не превращаясь в «график хотелок».

Самая частая боль: стейкхолдеры (продажи, маркетинг, руководители) хотят «когда будет фича X», а разработка слышит «нас снова пытаются привязать к датам без ТЗ и без ресурсов». Итог — вечная война: бизнес считает, что IT тормозит, а IT считает, что бизнес фантазирует. Ирония в том, что нормальный roadmap продукта как раз и нужен, чтобы обе стороны перестали угадывать мысли друг друга.

В российской реальности к этому добавляется классика жанра: импортозамещение, интеграции с 1С, СБИС, Госуслугами, платёжками, плюс зоопарк легаси-систем. Любой «план на год» без явных зависимостей — это не стратегия, а фанфик. Дальше — как составить roadmap так, чтобы он пережил первый же квартальный пересмотр бюджетов.

Что такое roadmap продукта (и чем он не является)

Roadmap ≠ Gantt на 12 месяцев.

Полезная ИНФОГРАФИКА в конце статьи.

Тезис: roadmap продукта — это карта намерений и приоритетов, а не обещание, что «15 мая в 18:00 всё будет готово».

Обоснование: в разработке неопределённость — норма: меняются вводные, появляется техдолг, прилетают регуляторные требования, «внезапно» нужен рефакторинг. Поэтому roadmap разработки продукта должен быть устойчив к изменениям: чем дальше горизонт, тем крупнее зерно планирования.

Практический вывод: фиксируйте цели и результаты (outcomes), а не только список фич (outputs). Фича — средство, не цель.

Подводный камень: называть «roadmap» список задач из Jira. Это бэклог, только распечатанный.

Три языка одного плана: бизнес, продукт, разработка

Чтобы один документ был понятен всем, в нём должны одновременно жить три слоя:

• Бизнес-слой: зачем, какой эффект в деньгах/рисках/пользователях (например: снизить отток на 10%, увеличить конверсию оплаты, пройти 152-ФЗ/PCI DSS, снизить стоимость поддержки).
• Продуктовый слой: что именно меняем в пользовательском опыте, какие метрики проверяем, какие гипотезы тестируем (A/B, пилот, фича-флаг).
• Технический слой: как меняется архитектура, где зависимости (1С, шины, DWH, Kafka, очереди), что с техдолгом, какие риски по срокам.

Как составить roadmap: пошаговая схема без магии

Шаг 1. Сформулируйте «северную звезду» и 3–5 целей на период

Тезис: без измеримых целей roadmap — это «сделаем много полезного».

Как делать: выберите 1 North Star Metric (NSM — метрика, которая лучше всего отражает ценность продукта) и 3–5 supporting metrics.

• Для маркетплейса: доля успешных заказов / GMV.
• Для B2B-сервиса: активные компании, удержание, время до value.
• Для внутренней системы на 1С: скорость обработки, % ручных операций, количество инцидентов.

Подводный камень: ставить цели вида «выпустить редизайн». Цель — эффект: «снизить время оформления на 20%».

Шаг 2. Переведите цели в инициативы (themes) и гипотезы

Инициатива (theme) — крупный смысловой блок: «Онбординг», «Платежи», «Стабильность», «Интеграции с 1С», «Личный кабинет».

Дальше — гипотезы: “Если упростим KYC/подтверждение данных, конверсия в первую оплату вырастет на X%”. Это уже честнее, чем «сделаем кнопку зеленее».

Шаг 3. Оцените объём и неопределённость (не только “стори-пойнты”)

Тезис: стейкхолдерам важны сроки, разработке — риски. Вам — и то, и другое.

Простой способ договориться: оценивать задачи по двум осям — объём и неопределённость.

Подводный камень: обещать дату по задачам из правого нижнего квадранта. Там дата — это ставка в казино, только без бесплатных напитков.

Шаг 4. Сделайте «двухконтурный roadmap»: Discovery и Delivery

Discovery — выясняем, что делать и зачем: интервью, аналитика, прототип, проверка данных, тех-спайки (исследовательские задачи).

Delivery — строим и выкатываем: разработка, тестирование, релиз, мониторинг, поддержка.

В roadmap разработки продукта это выглядит просто: отдельные инициативы помечаются как “Discovery” до момента, пока вы не сняли ключевые неопределённости.

Шаг 5. Встройте техдолг и устойчивость как «первый класс»

Техдолг — не «хотелка разработчиков», а будущие деньги на поддержку и простои. Если его не видно в roadmap продукта, он всё равно будет делаться — только в виде аварий и ночных релизов.

• Явная квота: например, 20–30% мощности команды на стабильность/рефакторинг/инфраструктуру.
• Привязка к риску: “снижаем количество P1-инцидентов”, “сокращаем время восстановления (MTTR)”.
• Связь с бизнесом: меньше простоя = меньше потерь выручки/репутации.

Шаг 6. Определите формат и горизонты (иначе вас съедят уточняющими вопросами)

Подводный камень: один и тот же уровень детализации на год вперёд. Это гибрид плохого прогноза и лишней работы.

Шаблон структуры roadmap, который понимают стейкхолдеры

Если хочется «скелет», вот минимальный набор колонок, который закрывает 80% вопросов:

Коммерческие факторы: где roadmap чаще всего ломается

Ресурсы и «скрытая цена» изменений

Даже если вы не продаёте курс и не нанимаете подрядчика, «цена» roadmap — это мощность команды и потери от переключений.

• Контекст-свитчинг: 3 параллельных инициативы в одной команде легко съедают 20–40% производительности на переключениях, созвонах и согласованиях.
• Интеграции: любая внешняя система (1С, СБИС, банк, ЕГАИС и т.д.) = зависимость по срокам, доступам, тестовым стендам.
• Поддержка: если продукт живой, заложите мощность на инциденты и саппорт, иначе roadmap будет «вечно сорванным».

Подводный камень: планировать 100% времени команды на фичи. Это как составить семейный бюджет без еды — вроде красиво, но недолго.

Экспертный вердикт и инструмент: чек‑лист «понятного roadmap»

• 1) Есть ли в roadmap продукта цели в метриках? Если нет — это список задач, а не план продукта.
• 2) Понятны ли зависимости? Включая внешние системы (1С, банки, госинтеграции) и внутренние команды.
• 3) Разделены ли Discovery и Delivery? Если всё “в разработке” — вы просто не видите неопределённость.
• 4) Есть ли место техдолгу и стабильности? Если нет — он придёт инцидентами.
• 5) Есть ли «окна», а не фальшивые даты? Чем дальше горизонт, тем шире окно — иначе вы обещаете то, что не контролируете.
• 6) Есть ли критерии готовности и успеха? “Сделано” = выкатили + измерили + приняли решение, что дальше.

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