7.5 instruction — Product Sprint execute-фаза + вайбкодинг MVP¶

Этап RB-STEP-7 — SOLUTION VALIDATION (Stage 6) · Линза: Product · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-7-SOLUTION-VALIDATION/7.5 Бизнес-логика и разработка MVP.md.

🎯 Цель в PAF-оптике¶

Стадия 7.5 переходит в execute-фазу Und-Id-Ex и Build-фазу цикла Product Sprint [S1] VI.4: Discovery / Launcher PM строит инкремент через Кортекс (вайбкодинг), проектирование бизнес-логики (Entity Model, Sequence Diagrams, State Modelling) становится узлами Нексуса, а MVP понимается как стратегия разработки (научная теория диверсификации рисков по Фрэнку Робинсону / Уильяму Шарпу — параллельная/синхронная разработка и верификация), а не «минимум фич».

MVP — НЕ «продукт с минимальным набором функций». Это концепция разработки на ранних этапах жизни компании, основанная на теории Шарпа: - диверсифицированный портфель даёт лучший ROI при меньшем риске, чем ставка на одну акцию; - Робинсон применил это к продукту — вместо большого продукта (= один большой риск) разрабатывай и верифицируй параллельно и синхронно; - Бланк/Дорф: стартап — временная организация для поиска масштабируемой бизнес-модели; MVP — способ разработки до момента, пока модель не найдена.

Каденции (PI-планирование, фиксированные спринты) заменяются асинхронным Kanban / event-based [S1] VI.2: при росте локальных скоростей компания в целом рассинхронизируется, каденции ломаются. Параллельная верификация сохраняется — это ядро MVP. Цикл Build → Change Log.

👤 Роль и ответственность¶

Product Engineer — управляет инкрементом через Кортекс; определяет AI workflow (что делегировать агенту, что себе); стратегическое решение об уровне MVP (не «скейтборд вместо машины», а баланс под гипотезы; иногда для верификации нужен «автомобиль»).
Discovery / Launcher PM — вайбкодинг MVP как ключевая компетенция [S2] III.6: продуктовые знания + генерация кода; минимизация time-to-market/time-to-PMF; человек-команда, full-stack (весь цикл: исследование → проектирование → производство → запуск → развитие [S1] III.2).
AI UX Designer — проектирует дизайн-систему и состояния интерфейса под ИИ-метафоры; онбординг вокруг Aha Moment.
Technical / AI Product Manager — проектирует бизнес-логику AI-свойств: сшивает агентов, оценивает качество моделей, KPI точность/прецизионность/полнота/производительность; контроль COGS токенов [S2] III.6.
Product Ops — поддерживает Нексус продукта, цикл Build → Change Log, асинхронный Kanban; модель зрелости Кортекса [S1] Часть VII; миссия — рост ИИ-зрелости.
Зона человека [S2] III.4: стратегическое решение об уровне MVP (что входит в инкремент для проверки гипотез) — не агентное; синхронизация команды (агенты делают прозрачным, но не преодолевают корпоративные интриги).

🤖 Что делает Кортекс-агент¶

Вайбкодинг-агент / MVP-builder — из узлов user-story, use-case, nfr, screen-map генерирует код инкремента; rapid-итерации Build → Change Log; практики:
feature flags — включать/выключать фичи без деплоя;
CI/CD pipeline — автоматический деплой каждого коммита на staging;
готовые компоненты (UI-библиотеки, платёжные SDK) — не изобретать колесо;
согласованный DoD — нет споров «готово или нет»;
timeboxing.
Entity Model-агент — из User Stories / Use Cases извлекает сущности (существительные-объекты), атрибуты, связи и кратность:
ассоциация (объекты связаны, но не зависят жёстко);
генерализация/наследование (частный случай);
композиция (часть не существует без целого);
агрегация (часть существует независимо);
кратность 1:1 / 1:N / N:M.
Строит ERD (Entity Relationship Diagram). Сущность = «существительное» продукта (Пользователь, Урок, Платёж).
Sequence-агент — для каждого ключевого Use Case рисует Sequence Diagram (временная шкала сверху вниз: Пользователь → Frontend → Backend API → БД → внешние сервисы → Email-сервис).
State-агент — для сущностей с жизненным циклом строит State Diagrams (состояния + разрешённые переходы + триггеры; например Lesson: Draft → Reserved → Scheduled → InProgress → Completed/Cancelled/CancelledLate/Interrupted).
Дизайн-система-агент — формирует минимальный стек v0.1 из узлов ai-metaphor:
цветовая палитра с ролями Primary/Secondary/Success/Error/Neutral;
типографика H1/H2/Body/Caption;
компоненты; сетка мобильная/десктоп.
Верификация-агент — поддерживает параллельную верификацию: после каждого блока инкремента запускает проверку на пользователях по плану верификации (Sprint → что разрабатываем → что верифицируем → метод → кто участвует → метрика успеха); обновляет CP.
Product Ops-агент — ведёт асинхронный Kanban, event-based триггеры (событие «CP вырос» → следующий шаг); следит за техническим долгом (15–20% capacity на рефакторинг); MVP Decision Log (дата/решение/альтернатива/обоснование/кто принял).
Time-to-market-агент — практики снижения time-to-market; контроль NPV-эффекта от ускорения.

🧠 Что делает человек (метапознание)¶

Валидация ИИ-генерации кода/бизнес-логики (критический фильтр [S2] III.4): Launcher PM обязан понимать сгенерированный код и Entity Model, быть способным объяснить разработке/команде. Entity Model — всегда гипотеза; спорные связи (1:N vs N:M) разрешаются через реальные сценарии («может ли один ученик иметь несколько активных репетиторов?» → N:M). Planning Poker для калибровки Story Points (baseline «добавить поле в форму» = 1 SP).
Veto на workslop-код: сгенерированный код, который выглядит работающим, но не проверяет гипотезы MVP — отбраковка; спагетти-логика, технический долг, неотслеживаемые зависимости.
Решение об уровне MVP: 5 вопросов диагностики:
(1) core user flow?
(2) без чего flow невозможен?
(3) что верифицируем в первую очередь?
(4) какой функционал ускорит верификацию?
(5) что блокирует принятие продукта, если отсутствует?
Это стратегический выбор.
Параллельная верификация: Product Engineer тратит 2–3 часа в неделю на звонки с 2–3 пользователями по текущему staging — это снижает риск «не то рынку». Выделяется минимальный ресурс.
Синхронизация команды — зона человека [S2] III.4; агенты делают прозрачным, но не преодолевают кросс-проектные конфликты и корпоративные интриги.
MVP ≠ «скейтборд вместо машины»: знаменитая картинка — иллюстрация принципа итеративности (каждая версия рабочая и используемая), но не означает «всегда делай самое минимальное». Иногда для верификации нужен «автомобиль». MVP с базовым функционалом и MVP с расширенным — оба корректны [Бланк/Дорф].

📦 Артефакт = узлы Нексуса продукта¶

entity — узел сущности {название, описание, атрибуты[] (тип, обязательность), связи[] (тип, кратность)}.
erd — узел Entity Relationship Diagram.
sequence-diagram — узел диаграммы последовательности ключевого сценария.
state-diagram — узел диаграммы состояний сущности с жизненным циклом {состояние, описание, разрешённые переходы}.
increment — узел инкремента {фичи из Банча[], статус Build, связь с гипотезами, Change Log-версия}.
change-log — узел цикла Build → Change Log {что добавлено/изменено, CP-дельта, версия}.
design-system — узел дизайн-системы v0.1 {палитра, типографика, компоненты, сетка}.
verification-result — узел результата параллельной верификации {sprint, что проверяли, метод, метрика факт vs цель}.
mvp-decision-log — узел ключевых решений по MVP {дата, решение, альтернатива, обоснование, кто принял}.
Каждый узел: источник, CP, timestamp, статус увядания. Context Ripeness после 7.5 → ~75% стадии; инкремент готов к аналитике и PMF-детекции (7.6).

🚦 Confidence Point-гейт¶

Gate 7.5 → 7.6 (Change Log):
инкремент собран по Банчу;
Entity/Sequence/State Diagrams согласованы с командой;
MVP Decision Log ведётся;
Change Log цикла Build работает;
параллельная верификация идёт по плану (метрики sprint-верификации в норме);
дизайн-система v0.1 готова;
асинхронный Kanban работает;
глоссарий един.
CP инкремента растёт от результатов параллельной верификации (реальные транзакции, первые уроки, UX-фидбек); CP не поднимается без реальных данных пользователей.

🔭 Связь с Тремя Линзами (3PL)¶

Product Lens [S1] VI.1: execute-фаза Und-Id-Ex в Product Sprint; MVP как стратегия разработки (диверсификация рисков по Шарпу/Робинсону).

Связь с Business Lens: MVP проверяет гипотезу mNSM → NPV (полностью замыкается в 7.6 Harvesting); для AI-продуктов COGS токенов как рычаг (cost-per-token × tokens-per-user) [S2] III.6.

Связь со Strategy Lens: MVP — поиск масштабируемой бизнес-модели (по Бланку/Дорфу) до точки масштабируемости; когда модель найдена — переход к Product Growth.

🛡️ Анти-workslop чекпоинт¶

Workslop в коде (вайбкодинг ~15,4%) [S2] III.7 — сгенерированный код, который выглядит убедительно, но содержит спагетти-логику, технический долг, неотслеживаемые зависимости, «убедительные, но неверные» результаты (Harvard × BCG).
Метапознание-фильтр: Launcher PM проходит code review сгенерированного, объясняет Entity Model; Planning Poker для калибровки; 15–20% capacity на рефакторинг.
Трассировка до Нексуса: каждый increment → user-story → solution-hypothesis; инкремент без связи с гипотезой — workslop.
Ложное ощущение готовности: «инкремент работает» ≠ гипотезы подтверждены; параллельная верификация обязательна; MVP — не «сырой» продукт, а полностью покрывающий core user flow, надёжный и качественный, без вторичного функционала.
Эффект асинхронности: при росте локальных скоростей каденции ломаются → event-based Kanban с событийными триггерами, а не Scrum-спринты фиксированной длины [S1] VI.2.
Утрата стратегического контроля: NPV-моделирование и фиксация уровня MVP — зона человека; агенты = инструменты, не акторы [S2] III.4.
Длительность MVP: типичные сроки — команда 3–5 человек (2 backend, 1 frontend, 1 дизайнер, PM) за 2–4 месяца; команда 1–2 fullstack за 4–8 месяцев. Признак неправильного MVP: оценка >6 месяцев — значит, в него попало слишком много.

🧩 Маппинг к Skill Map / профстандарту 06.012¶

Skill Map [S3] IV:
сектор 3 Development & Delivery (управление разработкой и поставкой) — средний круг, middle/senior;
вайбкодинг как новая компетенция AI-эпохи.
Профстандарт 06.012 [S4] V: обобщённая функция B «Управление ИТ-продуктом», уровень 5 — B/04.5 «заказ разработки/контроль/приёмка». PAF: Launcher PM как full-stack продукт+код [S2]. Связка стандарт ↔ PAF интерпретативна [S3]+[S4].

🔗 Связи¶

Назад: 7.4 instruction · Дальше: 7.6 instruction — Harvesting и PMF-точка Связанные: reformation · index · naming_conventions