Как продакту эффективно построить RoadMap. Пошаговая инструкция

в 11:16, , рубрики: roadmap, дорожная карта

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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js