Roadmap проекта из требований: как собрать этапы и проверить план

Roadmap проекта нужен, чтобы превратить список требований в последовательность этапов, решений и проверяемых результатов. Он не должен быть списком пожеланий или календарем без связки с объемом работ. Хороший roadmap показывает, что делаем сначала, что зависит от предыдущего шага, какие критерии подтверждают готовность и где остаются допущения.

• есть набор требований, идей или функций, но непонятен порядок реализации;
• нужно разделить MVP, следующий этап и будущие улучшения;
• важно оценить бюджет и сроки не всего продукта сразу, а управляемых этапов;
• есть зависимости между интеграциями, данными, интерфейсами и документами;
• нужно согласовать ожидания бизнеса, ИТ, закупки и команды разработки.

• требования еще не собраны даже на уровне исходных ожиданий;
• задача сводится к одной небольшой доработке;
• план используется как обещание дат без проверки объема;
• нет владельца продукта или лица, которое принимает приоритеты;
• не определено, какой результат должен завершать первый этап.

• реестр требований или список ожидаемых возможностей;
• группы пользователей и ключевые сценарии;
• обязательные ограничения: сроки, бюджет, нормативные требования, интеграции;
• зависимости между задачами и внешними системами;
• критерии MVP и критерии завершения каждого этапа;
• допущения, которые влияют на оценку;
• вопросы, которые требуют discovery или отдельной проработки.

1. Разделить требования по рабочим целям: запуск, интеграции, данные, интерфейс, администрирование, отчеты, эксплуатация.
2. Отметить обязательные и опциональные требования.
3. Найти зависимости: что нельзя сделать до доступа, API, миграции, согласования или проектного решения.
4. Собрать первый проверяемый этап, который дает полезный результат, а не только подготовку.
5. Для каждого этапа указать входные данные, результат и критерии приемки задач этапа.
6. Отдельно вынести риски и допущения, которые могут изменить оценку.

Когда roadmap уже показывает этапы и зависимости, его нужно разложить на управляемые задачи. Для этого смотрите, как декомпозировать roadmap в задачи, которые можно оценить, выполнить и принять.

• называть roadmap обычный список функций;
• обещать сроки без проверки зависимостей и внешних участников;
• смешивать MVP, технический долг и будущие идеи в одном этапе;
• не фиксировать, какие требования пока остаются гипотезами;
• не связывать roadmap с оценкой, договором и приемкой результата.

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

После согласования roadmap его не стоит превращать в длинный список мелких тикетов внутри самого документа. Для управляемой очереди работ лучше завести backlog задач и связать его с этапами, зависимостями и критериями готовности.