Каждый третий корпоративный MVP проваливается не из-за плохого кода, а из-за хаотичного процесса. Продукт-менеджер получает бюджет, собирает требования в Google Doc на 40 страниц — и через три месяца обнаруживает, что команда сделала не то, не так и не в те сроки. Знакомая ситуация? Проблема не в людях, а в отсутствии чёткого roadmap. Этапы разработки MVP — это не абстрактная методология, а конкретная последовательность действий, которая отличает предсказуемый результат от лотереи.
По данным Standish Group, только 29% IT-проектов завершаются в срок и в бюджет. Однако среди проектов с формализованным roadmap этот показатель достигает 64%. Разница в два раза — и она объяснима: когда каждый участник знает, что делать на текущем этапе и чего ожидать от следующего, скорость и качество растут одновременно.
В этой статье я разберу этапы разработки MVP как пошаговый roadmap — от идеи до сдачи. Не теоретическую схему из учебника, а реальную последовательность, которую мы используем в IT Integration для корпоративных проектов с фиксированным сроком 22 рабочих дня.
Почему roadmap критичен именно для корпоративного MVP
В стартапе можно позволить себе хаос — основатель сам принимает решения и корректирует курс на лету. В корпорации всё иначе. У продукт-менеджера есть утверждённый бюджет, дедлайн перед руководством, требования от смежных подразделений и ожидания стейкхолдеров. Без чёткого roadmap каждый из этих факторов превращается в точку конфликта.
Типичные сценарии провала без roadmap:
- Scope creep: каждую неделю появляются «ещё одна важная фича» от разных стейкхолдеров, сроки ползут вправо
- Параллельная работа на разных этапах: дизайн ещё не утверждён, а разработчики уже пишут код — итог: двойная переработка
- Отсутствие чекпоинтов: руководство узнаёт о проблемах только при сдаче, когда исправлять уже поздно
- Размытая ответственность: никто не понимает, кто за что отвечает на каждом этапе
Формализованный roadmap решает все четыре проблемы. Каждый этап имеет вход, выход и критерии завершения. Продукт-менеджер контролирует процесс, а не тушит пожары.
Этапы разработки MVP: 5 фаз за 22 рабочих дня
Мы используем пятифазную модель, отработанную на десятках корпоративных проектов. Каждая фаза имеет фиксированную длительность, чёткие deliverables и gate review — точку принятия решения о переходе к следующему этапу.
| Фаза | Длительность | Результат (deliverable) | Кто участвует |
|---|---|---|---|
| 1. Discovery | 3 дня | Validated Brief + User Stories | PM + аналитик + заказчик |
| 2. Architecture | 2 дня | Tech Stack + API Design + DB Schema | Tech Lead + архитектор |
| 3. Development | 12 дней | Работающий продукт + API | 2-3 разработчика + QA |
| 4. QA & Polish | 3 дня | Протестированный продукт | QA + PM |
| 5. Delivery | 2 дня | Деплой + документация + демо | DevOps + PM + заказчик |
Суммарно: 22 рабочих дня. Рассмотрим каждую фазу подробно.
Фаза 1: Discovery — от идеи к валидированному брифу (дни 1-3)
Самая недооценённая фаза. Большинство проектов срывают сроки именно потому, что пропускают Discovery и сразу начинают писать код. Между тем три дня на старте экономят три недели на финише.
Что происходит:
- Problem Interview — 2-3 часовых сессии с конечными пользователями. Не «что бы вы хотели?», а «расскажите, как вы решаете задачу сейчас и где больно». Цель — убедиться, что мы решаем реальную проблему, а не воображаемую
- Prioritization Workshop — PM и заказчик расставляют User Stories по матрице MoSCoW: Must have, Should have, Could have, Won't have. Только Must have идут в MVP. Всё остальное — в бэклог версии 2.0
- Validated Brief — документ на 3-5 страниц: бизнес-цель, целевая аудитория, ключевые User Stories (5-8 штук), критерии приёмки, ограничения
Gate review: заказчик подписывает Validated Brief. После этого scope зафиксирован — любые изменения только через формальный change request.
Почему это важно для продукт-менеджера: вы получаете документ, который можно показать руководству. Не «мы начали что-то делать», а «вот конкретный план с критериями приёмки».
Фаза 2: Architecture — технический фундамент (дни 4-5)
Два дня на проектирование архитектуры кажутся избыточными для MVP. Однако именно эти два дня определяют, можно ли будет масштабировать продукт после успешного пилота или придётся переписывать с нуля.
Что происходит:
- Выбор Tech Stack — под конкретные требования, а не «на чём привыкли». Для корпоративного MVP критичны: безопасность, масштабируемость, возможность интеграции с существующими системами
- API Design — интеграция с корпоративными системами проектируется на этом этапе, а не дописывается в конце. API-first подход: сначала контракты, потом реализация
- Database Schema — структура данных с учётом будущего роста. Нормализация, индексы, миграции
- CI/CD Pipeline — автоматическое тестирование и деплой с первого дня. Не «настроим потом», а сразу
Gate review: Tech Lead представляет архитектуру заказчику. Обсуждаются риски, точки интеграции, ограничения.
Ключевой принцип: архитектура enterprise-уровня, но только для тех компонентов, которые войдут в MVP. Не проектируем то, что не будем строить.
Фаза 3: Development — основная разработка (дни 6-17)
12 рабочих дней — ядро процесса. Здесь код превращается в работающий продукт. Ключевое отличие от хаотичной разработки — жёсткая структура спринтов и ежедневный контроль прогресса.
Структура фазы:
| Период | Фокус | Демо для заказчика |
|---|---|---|
| Дни 6-9 (Sprint 1) | Backend: API, БД, бизнес-логика | Демо API через Postman |
| Дни 10-13 (Sprint 2) | Frontend: UI, интерфейс, интеграция с API | Демо работающего интерфейса |
| Дни 14-17 (Sprint 3) | Интеграции, аналитика, edge cases | Демо полного продукта |
Контрольные точки:
- Daily standup — 15 минут, три вопроса: что сделал, что буду делать, что блокирует. PM получает сводку ежедневно
- Sprint demo — каждые 4 дня заказчик видит работающий продукт. Не слайды, не макеты — живую систему
- Burndown chart — визуальный контроль: сколько User Stories закрыто, сколько осталось. Если кривая выше плана — сигнал тревоги
Три промежуточных демо за 12 дней — это три возможности скорректировать курс до финальной сдачи. Если что-то идёт не так, вы узнаете об этом на 9-й день, а не на 22-й.
Фаза 4: QA & Polish — тестирование и доводка (дни 18-20)
Тестирование — не «нажать все кнопки и посмотреть, что упадёт». Это систематическая проверка по заранее подготовленным сценариям. Три дня на QA — минимум для продукта, который увидят реальные пользователи и руководство.
Что тестируется:
- Функциональное тестирование — каждая User Story из Validated Brief проверяется по критериям приёмки
- Интеграционное тестирование — API-эндпоинты, взаимодействие с внешними системами, граничные случаи
- UX-тестирование — 3-5 реальных пользователей проходят ключевые сценарии. Фиксируются затруднения и баги
- Нагрузочное тестирование — продукт выдерживает ожидаемое количество одновременных пользователей
- Безопасность — базовый аудит: SQL-инъекции, XSS, OWASP Top 10
Критерий завершения: 0 критических багов, 0 блокирующих, не более 5 minor. Minor фиксируются в первую неделю гарантийной поддержки.
По моему опыту, именно на этом этапе продукт-менеджер получает наибольшую ценность. QA-отчёт — это объективный документ, который можно приложить к презентации для руководства: «продукт прошёл 87 тест-кейсов, 0 критических дефектов».
Фаза 5: Delivery — деплой и передача (дни 21-22)
Финальные два дня — не формальность, а критически важный этап. Продукт должен не просто «работать на ноутбуке разработчика», а быть развёрнут на production-сервере с документацией и аналитикой.
Deliverables:
- Production deployment — продукт развёрнут на сервере заказчика или в облаке, с SSL, мониторингом и бэкапами
- Техническая документация — API-спецификация, схема базы данных, инструкция по деплою. Достаточно, чтобы другая команда могла продолжить разработку
- Аналитический дашборд — ключевые метрики MVP подключены и работают с первого дня
- Финальная демонстрация — полная демо для заказчика и стейкхолдеров. Не только «что сделали», но и «как пользоваться» и «что измерять»
- Гарантийная поддержка — 2 недели на исправление багов после сдачи
Что получает продукт-менеджер: готовый продукт для пилотного тестирования + пакет документов для презентации руководству (ТЗ, архитектура, QA-отчёт, метрики).
Чек-лист: как контролировать этапы разработки MVP
Знание этапов разработки MVP бесполезно, если roadmap не контролировать. Вот практический чек-лист для продукт-менеджера — что проверять на каждом gate review:
| Gate | Вопрос | Red flag |
|---|---|---|
| После Discovery | Scope зафиксирован? User Stories с критериями приёмки? | «Мы потом уточним требования» |
| После Architecture | API спроектированы? CI/CD настроен? | «Архитектуру нарисуем по ходу» |
| Sprint 1 Demo | Основные API работают? Данные сохраняются? | «Покажем на следующей неделе» |
| Sprint 2 Demo | Интерфейс подключён к backend? Сценарии проходятся? | «Фронт пока на моках» |
| Sprint 3 Demo | Интеграции работают? Аналитика подключена? | «Интеграции подключим на деплое» |
| После QA | 0 критических багов? UX-тест пройден? | «Пользователи сами разберутся» |
| Delivery | Production работает? Документация готова? | «Задеплоим на следующей неделе» |
Если на любом gate вы слышите red flag из правой колонки — это сигнал, что roadmap нарушен. Не игнорируйте: лучше потерять день на корректировку, чем две недели на переделку.
Ошибки при планировании этапов: уроки из практики
За время работы с корпоративными клиентами мы выявили пять ошибок, которые повторяются чаще всего.
Ошибка 1: пропуск Discovery. «У нас уже есть ТЗ на 40 страниц». Длинное ТЗ — не замена Discovery. Validated Brief на 3-5 страниц с приоритизированными User Stories ценнее, чем 40 страниц непроверенных требований. Подробнее об ошибках IT-проектов — в отдельной статье.
Ошибка 2: отсутствие gate reviews. Без промежуточных демо продукт-менеджер теряет контроль. Три демо за 22 дня — это минимум. Если подрядчик отказывается показывать промежуточные результаты — серьёзный red flag.
Ошибка 3: scope creep через стейкхолдеров. Директор по маркетингу хочет «ещё одну интеграцию», IT-директор — «поддержку legacy-протокола», CEO — «чтобы как у конкурентов». Решение: любые изменения scope только через формальный change request с оценкой влияния на сроки и бюджет.
Ошибка 4: экономия на QA. «Мы потестируем сами». Самостоятельное тестирование заказчиком — это не QA. Профессиональное тестирование находит в 3-5 раз больше дефектов. Три дня QA окупаются двумя неделями без критических багов на production.
Ошибка 5: нет плана на «после MVP». MVP — не финал, а начало. Ещё до сдачи нужен план: как тестировать на пилотной группе, какие метрики измерять, при каких показателях масштабировать, при каких — менять направление.
Как адаптировать roadmap под корпоративные реалии
Стандартный roadmap из 22 дней работает для большинства корпоративных проектов. Однако есть нюансы, которые стоит учитывать.
Длинный цикл согласований. В крупных компаниях подписание Validated Brief может занять неделю вместо одного дня. Решение: параллельно с Discovery готовьте презентацию для стейкхолдеров. Чем раньше вовлечёте — тем быстрее подпишут.
Требования информационной безопасности. Корпоративный ИБ-отдел может добавить 2-3 дня на согласование архитектуры. Решение: привлеките ИБ-специалиста на фазу Architecture, а не на фазу Delivery.
Интеграция с legacy-системами. Корпоративная IT-инфраструктура часто включает системы 10-15-летней давности. Решение: на фазе Architecture определите точки интеграции и зафиксируйте API-контракты. Интеграция с legacy всегда сложнее, чем кажется — заложите буфер.
Множество стейкхолдеров. В стартапе один заказчик, в корпорации — пять. Решение: назначьте одного Product Owner с полномочиями принимать решения. Остальные стейкхолдеры участвуют в Sprint Demo, но не в ежедневных решениях.
FAQ о этапы разработки MVP
Сколько времени занимает разработка MVP?
При формализованном roadmap — 22 рабочих дня (чуть больше календарного месяца). Сроки фиксируются в договоре. Без roadmap типичный срок — 3-6 месяцев, при этом результат менее предсказуем. Ключевой фактор скорости — жёсткая фиксация scope на этапе Discovery.
Можно ли пропустить этап Discovery, если уже есть ТЗ?
Нет. Готовое ТЗ — не замена Discovery. Validated Brief содержит приоритизированные User Stories с критериями приёмки, а не описание «всего, что хочется». Discovery переводит размытые требования в конкретные задачи для разработчиков. Пропуск этого этапа — причина срыва сроков в 40% проектов.
Как контролировать разработку, если я не технический специалист?
Через gate reviews и Sprint Demo. Каждые 4 дня вы видите работающий продукт, а не слайды. Если на демо показывают моки вместо реальной системы или переносят показ — это красный флаг. Также следите за burndown chart: если скорость закрытия задач ниже плановой, узнайте причину.
Что делать, если после Discovery стало ясно, что 22 дней не хватит?
Пересмотреть scope, а не сроки. Вернитесь к матрице MoSCoW и переведите часть Should have в Won't have. MVP — это минимально жизнеспособный продукт, не версия 2.0. Если после урезания scope задача всё равно не укладывается в 22 дня — возможно, это не MVP, а полноценный продукт, и нужен другой формат работы.
Какой бюджет нужен для MVP с таким roadmap?
Стоимость MVP с формализованным roadmap из 5 фаз — до 900 000 рублей при фиксированной цене. В бюджет входят: Discovery, проектирование архитектуры, разработка, QA-тестирование, деплой и документация. Плюс 2 недели гарантийной поддержки после сдачи.
Итого
Пошаговый roadmap — это не бюрократия, а инструмент предсказуемости. Этапы разработки MVP — Discovery, Architecture, Development, QA, Delivery — превращают хаотичный процесс в управляемый конвейер с контрольными точками.
Главное, что нужно запомнить: три дня на Discovery экономят три недели на переделке. Три промежуточных демо дают три шанса скорректировать курс. А фиксированный scope после первого gate review защищает от scope creep.
Если вы планируете запуск MVP для корпоративного проекта и хотите обсудить roadmap под вашу конкретную задачу — запишитесь на бесплатный Zoom-колл. Разберём ваши требования, определим scope и покажем, как 22 рабочих дня превращаются в работающий продукт.