Блок 9. Создание и запуск

Цель

Довести MVP до использования ограниченной группой и организовать цикл обратной связи.

Маршрут

1. Короткие циклы разработки — превращают MVP Brief в малые сквозные поставки с явным outcome, качеством и решением.
2. Роли продуктовой команды — распределяют способности, решения, риск и право остановки независимо от размера команды.
3. Задачи и критерии приёмки — переводят сквозной срез в конкретные примеры поведения и отделяют их от общей Definition of Done.
4. Проверка ключевого сценария — сопоставляет фактический пользовательский путь, raw data, внешние зависимости и операции на одной сборке.
5. Альфа, бета и публичный запуск — разделяет deploy, release и launch и выбирает степень воздействия по риску, наблюдаемости и мощности команды.
6. Выбор первой группы пользователей — формирует воспроизводимую когорту под вопрос стадии, ограничения продукта и способность сопровождения.
7. Онбординг до первой ценности — сокращает путь от обещания к самостоятельному полезному результату, сохраняя помощь, восстановление и измеримость.
8. Обратная связь и roadmap — превращает просьбы, жалобы и наблюдения в проверенные проблемные паттерны и outcome-решения, не копируя запросы в backlog.
9. Ошибки, поддержка и инциденты — разделяет вопросы, затруднения, дефекты и критические события и задаёт полный контур от intake до learning.
10. Launch Checklist — объединяет аудиторию, обещание, версию, качество, данные, риск, поддержку и rollback в доказательный go/no-go gate.
11. Наблюдение за фактическим использованием — соединяет exposure, telemetry, прямое наблюдение, поддержку, ручные операции и outcomes, отделяя факт от интерпретации.
12. Post-Launch Review — проверяет исполнение и качество данных раньше результата и фиксирует обоснованное решение о следующей волне.

Итоговые артефакты

• Launch Decision Record — неизменяемый контракт одной волны: аудитория, версия, обещание, пороги, guardrails, владельцы, rollback и решение GO / CONDITIONAL GO / NO-GO.
• Журнал наблюдения за использованием — трассируемые факты о доступе, попытках, первой ценности, помощи, ошибках, операциях, результате и состоянии системы.
• Post-Launch Review — сопоставление исходного контракта с фактом, проверка валидности и решение EXPAND / HOLD & IMPROVE / REPEAT / NARROW / RETURN / STOP.

Сквозной кейс

«Маяк», эпизод 8 — ограниченный запуск и инцидент: выберите rollout после ошибки и разберите не только код, но и процессную причину.

Практика и контрольная точка

Запустите одну точную версию MVP для ограниченной и воспроизводимой группы. Одних заполненных документов недостаточно: покажите фактический exposure, работоспособность критического сценария, проверку качества данных, журнал поддержки и инцидентов, а также различие самостоятельного и сопровождаемого результата.

Контрольная точка пройдена, когда Post-Launch Review позволяет обосновать одно действие: EXPAND, HOLD & IMPROVE, REPEAT, NARROW, RETURN или STOP. Переход к коммерческому привлечению оправдан только тогда, когда следующая неопределённость действительно относится к каналу, предложению или готовности платить; слабая ценность возвращает к ближайшей контрольной точке проблемы или решения.

Следующий блок

Первые клиенты и Go-to-Market.