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

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

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

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

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

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

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

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

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