Roadmap или дорожная карта продукта — это не только расписанный план деплоя фичей, это по сути стратегия и тактика на поле боя. Это огромная система фреймворков, методологий и артефактов, в конченом счете визуализированная в виде диаграммы Ганта, таблицы в конфлюенсе с эпик+релиз или ином виде.

Для эффективности планирование и построения дорожной карты продукта мы должны понимать несколько моментов. Первое — мы, как продуктовая команда, должны четко понимать ценность, которую хотим получить от продукта в заданный промежуток времени. И второе — в любой момент все может пойти через одного место.
Первый шаг — определение того, что мы в целом можем сделать
Для этого мы должны понимать что мы можем сделать физически (капаситет команды) и теоретически (наш бэклог).
С первым нет большой сложности. Используем стандартную формулу расчета: Рабочие дни в промежутке * рабочие часы в дне * кол‑во ресурса. Пример: у нас 2 GO Dev и нужно рассчитать капаситет на месяц. 20 дней * 8 часов * 2 dev. Как итог получаем 320 человеко‑часов. Более сложное упражнение — это расчет «очищенного» объема ресурсов или тот ресурс, который мы в действительности можем направить на тот или иной вид деятельности. Наличие 320 часов в месяц на разработку не равно разработке. Разработчику свойственно созваниваться, отвлекаться на код ревью, тестировать по на эмуляторе, рисовать архитектуру и фиксить баги. Необходимо точно понимать, сколько и каждого и членов команды уйдет времени на общение, проектирование, регресс, внештатные ситуации так далее
Критически важно планировать не весь объем ресурса, а лишь его 50–75%. Чтобы минимизировать риске не верных оценок, смены планов и тд
И второй шаг, зависит от практики декомпозиции, которая используется у вас продукте. В моем случаи это Эпик — Сторя — Таска. Необходимо выбрать сгруппированный объем задач (в моем случае Эпик) и сформировать список кандидатов на попадание в дорожную карту продукта.
DoD (Definition of Done) данного этапа будет являться:
-
Капаситет вашего продукта по всем производственным стримам (бекенд, френтенд, тестирование и т.д.)
-
Список кандидатов на попадание в дорожную карту продукта
Второй шаг — приоритизация
На данном этапе необходимо сопоставить несколько факторов — шаги для достижения стратегических и тактических целей. Мы формируем 4 графы для каждого кандидата.
Ваш приоритет — выставление приоритета на основе того что необходимо сделать для текущих рыночных реалий (закрыть обещание по контракту, рефакторинг, выпустить фичу обещанную CEO), и что нужно сделать для достижения стратегических долгосрочных целей (локализация в продукте для масштабирования бизнеса, старт разработки MVP)
Приоритет от C‑level. Здесь мы погружаем уровнь С в состояние продукта и синхронизируем с общей стратегией компании.
Приоритет от стейкхолдеров (в данном случае прямых заказчиков продукта). Удержание клиента, поддержание партнерских связей, новые условия по контракту, совместные проекты — именно для этого необходима данная приоритизация.
Итоговый приоритет — средневзвешенная оценка на основании 3-х предыдущих.
DoD данного этапа:
-
Собраны оценки от всех заинтересованных сторон
-
Получены финальный приоритет
Третий этап — ранжирование и определение реального объема задач
В текущем этапе важнейшей задачей соотнести тот объем ценности который мы объявили исходя из приоритета и тот капаситет которые мы очистили и выделили на производство данных кандидатов. Насыщение кандидатами капаситета происходить от высокого приоритета к низкому, пока не забьем его полностью. В данном случае если у нас ест low приоритет с крайне минимальной стоимостью реализации — он также можем попасть в RM на ряду с blocker.
Четвертый этап — формирование диаграммы Ганта
Конечно, визуализация дорожной карты продукта зависит от вашей культуры и набора практик. Но в Ганте, есть преимущества по отношению к другим инструментам:
-
Фактическая визуализация задействования всего объема ресурсов на каждом участке RM
-
Прозрачность в последовательности действий и понимании почему именно в тот, а не иной релиз войдет эпик
-
Простота в синхронизации с вашим релизным календарем (разработка‑регресс‑деплой и т. д.)
Пятый этап — подписание
Обязательный этап, которое многие пропускают по различным причинам — это подписание (согласование) вашего RM. Это избавит вас от притока лишних/срочных/важных/новых задач и проектов, которые необходимо реализовать. Подготовит вас к обоснованию в потребности в дополнительных ресурсах (если это необходимо). И сделаем процесс вашей работы более прозрачной для всех стейкхолдеров.
Автор: vaday01