Тема: Часть 12. MVP
Уровень сложности: Средний
Расчётное время изучения: 4-6 часов (теория: 1.5 часа, практика: 2.5-4.5 часа)
Предварительные требования: Прохождение минимум двух малых фаз фич (из предыдущих частей курса)
Понимание структуры проектных документов: mission.md, tech-stack.md, roadmap.md
Опыт работы с системой контроля версий Git
Базовые знания тестирования и CI-проверок
Знакомство с работой агентов кода (Qwen Code или аналогичных)
Цели обучения: Определять готовность проекта к MVP-фазе по чек-листу из 6 критериев
Формулировать чёткие границы MVP, отделяя 'внутри' от 'за границами', с минимум 5 пунктов в каждой категории
Применять технику группированной реализации MVP с созданием 'зелёных точек' отката через git-теги
Проводить проверку отклонений MVP с автоматическими и ручными проверками
Использовать пост-MVP-анализ для выявления пробелов в спецификациях и обновления проектных правил
Обзор: MVP-фаза — это критический этап разработки с участием агента кода, когда вместо пошаговой реализации отдельных фич происходит сборка оставшейся части минимально жизнеспособного продукта целиком. В отличие от обычных фаз фич, MVP представляет повышенный риск: агент обрабатывает большой объём спецификаций одновременно, что делает эту фазу мощным стресс-тестом зрелости проектной документации. Учебный материал охватывает критерии готовности к MVP, техники управления рисками, структурирование MVP-спецификаций, группированную реализацию с контрольными точками, таймбоксинг и пост-анализ для улучшения проектных правил.
Ключевые концепции: Mvp как стресс-тест спецификаций: Если агент, прочитав все проектные документы, строит не то, что ожидается — проблема не в агенте, а в недостаточной детализации спецификаций, избыточной свободе или непонятной дорожной карте. MVP выявляет эти проблемы раньше, чем они станут критическими в продакшене.
Критерии готовности к mvp: Минимум две фичи прошли полный цикл; mission.md, tech-stack.md, roadmap.md актуальны; существует политика тестирования; ведётся журнал изменений; команда готова к проверке большого объёма изменений; дорожная карта содержит чёткие границы MVP.
Границы mvp: Чёткое разделение на то, что входит в MVP (главная страница, ключевые функции, тесты критичных маршрутов) и то, что остаётся за границами (аутентификация, оплата, внешние сервисы, админ-интерфейс). Границы предотвращают разрастание scope.
Группированная реализация: Даже единая спецификация MVP реализуется по частям — группам задач. После каждой группы: остановка, проверка, коммит, тег 'зелёной точки'. Следующая группа не должна редактировать файлы предыдущей без необходимости.
Зелёные точки отката: Git-теги (например, mvp-green-1), проставляемые после успешного прохождения typecheck и тестов. При поломке следующей группы — жёсткий откат к последней зелёной точке, а не отладка в 'грязном' состоянии.
Таймбоксинг mvp-сессии: Фиксированный бюджет времени (2–4 часа для учебного MVP). По истечении — остановка, оценка, сознательное решение, а не 'ещё одна группа'.
Проверка отклонений: Жёсткая проверка, что за границы MVP не вышли: аутентификация не добавлена, клиентский фреймворк не внедрён, внешние сервисы не требуются. Предотвращает 'ползучее разрастание' функциональности.
Пост-mvp анализ пробелов: Вопрос к агенту: 'Что тебе пришлось вывести самому, потому что не было явно задано?' Честный ответ — подарок для улучшения спецификаций, а не повод для наказания.
Практические упражнения: Название: Аудит готовности к MVP
Проблема: Вам предоставлен описание проекта 'EcoTracker' — приложения для отслеживания экологических привычек. Проект имеет: roadmap.md (последнее обновление 3 месяца назад), одну реализованную фичу (регистрация пользователя), тесты только для этой фичи, отсутствующий journal.md. Оцените по чек-листу из материала, готов ли проект к MVP-фазе. Если не готов — составьте план действий до достижения готовности с приоритетами и сроками.
Решение: 1. Проверяем критерий 'минимум две фичи прошли полный цикл' — НЕТ, только одна фича. 2. Проверяем актуальность roadmap.md — НЕТ, обновлён 3 месяца назад. 3. Проверяем политику тестирования — ЧАСТИЧНО, тесты только для одной фичи. 4. Проверяем журнал изменений — НЕТ, journal.md отсутствует. 5. Проверяем готовность к проверке большого объёма — НЕОПРЕДЕЛЁННО. 6. Проверяем чёткие границы в roadmap — НЕВОЗМОЖНО ПРОВЕРИТЬ из-за устаревания. ВЕРДИКТ: не готов. ПЛАН: (1) Реализовать вторую фичу полным циклом (1-2 недели); (2) Обновить roadmap.md с чёткими границами MVP (2-3 дня); (3) Расширить тесты до политики покрытия всех критичных путей (1 неделя); (4) Создать и наполнить journal.md (1 день); (5) Повторный аудит готовности.
Сложность: intermediate
Название: Формулирование границ MVP
Проблема: Разработайте документ 'Требования — MVP' для сервиса онлайн-бронирования коворкингов 'DeskShare'. Сервис должен демонстрировать: просмотр доступных мест, фильтрация по локациям, карточка места с фото и удобствами, форма бронирования с выбором даты/времени, подтверждение бронирования. За границами остаются: оплата, интеграция с календарями, личный кабинет пользователя, рейтинги и отзывы, мобильное приложение. Сформулируйте также 3 технических решения и 5 пунктов проверки отклонений.
Решение: ГРАНИЦЫ ВНУТРИ: каталог мест с поиском; фильтры по городам и удобствам; карточка места с галереей; форма бронирования (дата, время, контакты); страница подтверждения; адаптивная вёрстка; тесты маршрутов каталога и бронирования. ЗА ГРАНИЦАМИ: оплата (бронирование без оплаты); интеграции с Google/Apple Calendar; личный кабинет (бронирование по email); рейтинги и отзывы; нативное мобильное приложение; уведомления по SMS. РЕШЕНИЯ: (1) Хранение бронирований в SQLite с email как идентификатором; (2) Серверный рендеринг всех страниц, без React/Vue; (3) Загрузка фото через статические файлы, без CDN. ПРОВЕРКА ОТКЛОНЕНИЙ: Stripe/PayPal не подключён; OAuth-авторизация не добавлена; React/Vue/Angular не внедрён; Firebase/AWS Lambda не используется; SMS-шлюз не интегрирован; клиентская маршрутизация не применяется.
Сложность: intermediate
Название: Сценарий отката к зелёной точке
Проблема: Вы реализуете MVP в 3 группах. После группы 1 (агенты и недуги) вы создали коммит и тег mvp-green-1, typecheck проходит. При реализации группы 2 (терапии и форма записи) агент 'по ходу' изменил файлы группы 1, и теперь: (а) тесты группы 1 падают; (б) git diff --stat показывает изменения в 12 файлах, из которых 4 не входят ни в одну группу плана; (в) агент предлагает 'заодно' добавить кэширование. Опишите ваши действия пошагово, включая git-команды и решение о продолжении/откате.
Решение: 1. НЕМЕДЛЕННАЯ ОСТАНОВКА: не соглашаться на 'заодно' кэширование — это признак размывания границ. 2. ОЦЕНКА: признаки критичные — тесты группы 1 падают, файлы вне плана изменены, агент предлагает выход за границы. 3. ПРОВЕРКА ВРЕМЕНИ: если потрачено <50% таймбокса и проблема локализуема — можно попробовать откатить только изменения группы 1; иначе — полный откат. 4. ПОЛНЫЙ ОТКАТ: git log --oneline для проверки коммитов; git reset --hard mvp-green-1; git clean -fd если агент создавал новые файлы; проверка: npm run typecheck должен пройти. 5. АНАЛИЗ ПРИЧИНЫ: спецификация группы 2 была недостаточно детальной и не запрещала изменять группу 1. 6. ДЕЙСТВИЕ: создать отдельную фичу 'Уточнение изоляции групп MVP', доработать plan.md с явным запретом на редактирование файлов предыдущих групп. 7. ПОВТОРНАЯ ПОПЫТКА: начать группу 2 с обновлённой спецификацией.
Сложность: advanced
Название: Пост-MVP опрос агента
Проблема: Составьте промпт для Qwen Code на русском языке, который после завершения MVP выявит неявные выводы агента. Затем проанализируйте гипотетический ответ агента: 'Я сам решил использовать localStorage для сохранения черновиков формы, потому что в спецификации не было указано, как обрабатывать прерванное заполнение. Также я добавил debounce на поиск — это казалось очевидным для UX, хотя в требованиях не упоминалось.' Сформулируйте, какие обновления в какие документы внести.
Решение: ПРОМПТ: 'По реализации MVP скажи, что тебе пришлось вывести самому, потому что это не было явно задано. Перечисли пробелы в спецификациях и предложи обновления для mission.md, tech-stack.md, roadmap.md или спецификации MVP. Файлы не изменяй.' АНАЛИЗ ОТВЕТА: (1) localStorage для черновиков — архитектурное решение без одобрения; влияет на приватность данных, работу в приватном режиме, синхронизацию между устройствами. (2) debounce на поиск — UX-решение с техническими последствиями (задержка, частота запросов). ОБНОВЛЕНИЯ: В specs/mission.md — добавить принцип 'Все решения по сохранению состояния пользователя согласовываются явно'; в specs/tech-stack.md — указать допустимые механизмы клиентского хранения (или их отсутствие); в specs/YYYY-MM-DD-mvp/requirements.md — явно описать поведение при прерванном заполнении ('черновики не сохраняются, форма сбрасывается'); в validation.md — добавить проверку отклонения 'localStorage не используется'; в tech-stack.md или roadmap.md — вынести debounce в отдельную UX-фичу с измеримыми параметрами (задержка в мс).
Сложность: intermediate
Кейсы: Название: AgentClinic: от провала первого MVP к контролируемой реализации
Сценарий: Стартап разрабатывает демонстрационное приложение AgentClinic — симулятор медицинской клиники с ИИ-агентами. После двух успешных малых фаз (страница агента, страница недуга) команда решает ускориться и реализовать оставшийся функционал одним запросом к Qwen Code.
Задача: Первый MVP-запрос без подготовки привёл к: (1) добавлению аутентификации 'заодно', хотя она была за границами; (2) внедрению React на клиенте, несмотря на серверный рендеринг в tech-stack; (3) 47 изменённых файлов без понимания, что к какой фиче относится; (4) падению тестов, которые проходили до MVP; (5) 6 часов отладки без результата — команда потеряла ориентиры.
Решение: Команда применила методологию из Части 12: (1) откат к последнему стабильному коммиту перед MVP; (2) создание полной спецификации MVP с явными границами; (3) разбиение на 4 группы: главная+навигация, терапии, форма записи, панель управления; (4) таймбокс 3 часа на группу; (5) git-теги mvp-green-1, mvp-green-2 и т.д. после каждой группы; (6) жёсткая проверка отклонений после каждой группы.
Результат: Второй MVP прошёл за 10 часов (4 группы × 2.5 часа среднее). Все тесты проходили. Аутентификация и клиентские фреймворки не проникли в код. Журнал изменений содержал чёткую историю. Пост-анализ выявил 7 неявных решений агента, которые были формализованы в обновлённых спецификациях.
Извлечённые уроки: Первый 'быстрый' MVP без спецификации занял 6 часов и привёл к откату; второй, методичный — 10 часов с рабочим результатом. Экономия времени на подготовке — иллюзия.
Git-теги 'зелёных точек' спасли 2 раза: при поломке группы 3 откат к mvp-green-2 занял 30 секунд вместо часов отладки.
Проверка отклонений после группы 2 поймала попытку агента добавить кэширование — раннее обнаружение предотвратило накопление технического долга.
Пост-MVP опрос выявил, что агент 'сам решил' использовать определённый шаблонизатор — это привело к уточнению tech-stack.md, которое предотвратило аналогичные проблемы в следующих проектах.
Связанные концепции: MVP как стресс-тест спецификаций
Группированная реализация
Зелёные точки отката
Таймбоксинг MVP-сессии
Проверка отклонений
Пост-MVP анализ пробелов
Название: EduPlatform: когда отказ от MVP оказался правильным решением
Сценарий: Образовательный проект разрабатывает платформу для онлайн-курсов. После одной реализованной фичи (просмотр каталога курсов) product owner настаивает на 'ускорении через MVP' для демонстрации инвесторам через неделю.
Задача: Анализ готовности показал: roadmap.md отсутствует (есть только 'видение' в голове основателя); тесты написаны только для каталога; нет журнала изменений; агент в предыдущей фиче дважды 'добавлял полезности' вне спецификации. Классические признаки неготовности к MVP.
Решение: Команда отказалась от MVP в пользу двух дополнительных малых фаз: (1) система регистрации пользователя с полным циклом тестирования; (2) проигрыватель видео с прогрессом обучения. Параллельно: формализация roadmap.md с чёткими границами будущего MVP, создание journal.md, внедрение политики тестирования (покрытие >80% критичных путей).
Результат: Инвесторская демонстрация состоялась через 3 недели вместо 1, но показала стабильный, предсказуемый продукт. MVP-фаза, когда она наконец была запущена, прошла без откатов и за 2 часа меньше запланированного таймбокса. Инвесторы отметили 'профессиональный подход к разработке' как фактор доверия.
Извлечённые уроки: Давление сроков — худший повод для преждевременного MVP; неготовый MVP рискует показать хаос вместо продукта.
Две дополнительные малые фазы (2 недели) сэкономили потенциальные 1-2 недели отладки после провального MVP.
Формализация документов в процессе малых фаз оказалась более эффективной, чем попытка написать всё 'под MVP' — документы проверялись на практике.
Агент, склонный к 'полезностям', требует особенно жёстких границ MVP; ранняя фиксация этого поведения в правилах проекта предотвратила проблемы в дальнейшем.
Связанные концепции: Критерии готовности к MVP
Таймбоксинг MVP-сессии
MVP как стресс-тест спецификаций
Советы по изучению: Пройдите чек-лист готовности к MVP на бумаге или в таблице — не из памяти. Физическое отмечание каждого пункта снижает соблазн 'ну, почти готовы'.
Практикуйте написание промпта для Qwen Code в точности по шаблону из материала, включая /clear и структуру 'сначала анализ, потом план, потом код'. Отклонения от шаблона — частая причина непредсказуемого поведения агента.
Создайте личную 'карту отката' — шпаргалку с git-командами: git commit -m '...', npm run typecheck, git tag mvp-green-N, git reset --hard mvp-green-N. В стрессовой ситуации готовая шпаргалка ценнее памяти.
Для визуального восприятия: нарисуйте диаграмму групп MVP с 'зелёными точками' как светофор. Красный — текущая работа, жёлтый — на проверке, зелёный — тегировано. Обновляйте статус в реальном времени.
Ролевая практика: попросите коллегу или используйте 'двойной контроль' — один играет роль агента, предлагающего 'заодно улучшить', другой должен устоять и применить проверку отклонений.
Ведите 'журнал MVP' параллельно официальному: фиксируйте эмоциональное состояние, моменты искушения 'ещё одна группа', фактическое время vs таймбокс. Это данные для улучшения вашей оценки собственной готовности.
После каждого упражнения проводите '5 почему' анализа: почему агент сделал X? Почему спецификация этого не предотвратила? Почему проверка не поймала? И так до корневой причины.
Дополнительные ресурсы: Оригинальный материал курса — часть 12: Полный текст с примерами промптов и шаблонами документов MVP
Git документация по тегам: https://git-scm.com/book/en/v2/Git-Basics-Tagging — для углублённого понимания аннотированных и лёгких тегов
Статья 'the lean startup' эрика риса (глава о mvp): Классическая база концепции минимально жизнеспособного продукта, адаптированная для контекста агентной разработки
Документация qwen code: Официальные рекомендации по работе с контекстом и файловыми ссылками (@файл)
Шаблоны проектных документов (mission, tech-stack, roadmap): Примеры из предыдущих частей курса для сравнения зрелости документации
Интерактивный тренажёр git: https://learngitbranching.js.org/?locale=ru_RU — для отработки сценариев отката и тегирования
Резюме: MVP-фаза с агентом кода — это не ускорение за счёт масштаба, а управляемый риск, требующий зрелости проектной документации. Ключевые принципы: (1) не начинать без двух пройденных малых фаз и актуальных документов; (2) формализовать границы MVP как явное включение и явное исключение; (3) реализовывать группами с 'зелёными точками' отката; (4) применять таймбокс и жёсткий откат при нарушениях; (5) проверять отклонения — что НЕ добавлено; (6) после MVP извлекать неявные решения агента для улучшения спецификаций. MVP — стресс-тест вашей дисциплины проектирования, не только кода агента.