3.bunch — BUNCH (Step 7: Solution & PMF) 🔴¶

Фаза ТЯЖЁЛАЯ · Линза: Product · Гипотезы решения как фичи Банча. MoSCoW не объект управления — Банч. Источник: 7.4 instruction (Банч-архитектор) + 7.1 instruction · [S1] VI.6, Принцип 1.

🎯 Цель фазы для Step 7¶

Сформировать Банч (Feature Bunch) из гипотез решения (кандидатов из SCOUT) под Карту Целей с лимитами Bunch Size/Window — связку фич в моменте, определяемую только текущим состоянием Нексуса. В PAF Беклог упразднён [S1] Принцип 1; MoSCoW — это лишь вход (Must/Should/Could/Won't), а объект управления — Банч в моменте.

Три критерия Банча [S1] VI.6: 1. максимальная mNSM — кандидат монетизируемой NSM; 2. минимум рисков (Confidence Point) — стоимость риска учтена; 3. эффект в окне (Bunch Window) → комплексный NPV.

Цель — поднять CP Банча до уровня, достаточного для входа в Pitching of Trust (7.3) и далее в вайбкодинг (7.5). Лимиты: Bunch Size (скорость восприятия рынка — баланс выращивания/потребления, без перепроизводства) и Bunch Window (период ожидания бизнес-результата).

Банч vs Беклог [S1] VI.6: Беклог утилизирует разработку (накопленный список); Банч — макс. финансовую и продуктовую ценность быстро, только в моменте, из анализа текущего состояния.

👤 Роль¶

Product Engineer — проектирует цифровой профиль; определяет AI workflow; решение о составе Банча (что входит в инкремент = Bunch Size, что вне окна = Bunch Window) — стратегический выбор. Discovery/Launcher PM — переводит финальное решение в узлы Нексуса; вайбкодит спецификацию; минимизация time-to-market. AI UX Designer — Screen Map под ИИ-метафоры. Technical/AI Product Manager — NFR-узлы (точность/прецизионность/полнота/COGS токенов). Product Ops — структура Нексуса, live-CR.

Зона человека [S2] III.4: решение о составе Банча под Карту Целей — стратегическое распределение ресурсов, не делегируется.

🤖 Кортекс-агент (из 7.1 + 7.4)¶

CP-скорер (колесо Гилада) [S1] VI.7 — агрегирует CP входящих фич-гипотез; ICE/RICE с оценкой стоимости риска: «сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?».
Банч-архитектор [7.4] — заменяет MoSCoW-приоритизацию: формирует Банч под Карту Целей с Size/Window; три критерия (mNSM, риски, эффект в окне → NPV); правило Must Have ≤ 60% объёма (против перекладывания всего продукта в MVP).
NPV/mNSM-скорер [7.3/7.4] — для каждого кандидата считает кандидат mNSM × вероятность (из CP) → вклад в NPV Банча; учитывает долгосрочный потенциал масштабирования и барьеры копирования.
Traceability-агент [7.4] — User Story → User Flow → Final Solution → Solution Hypothesis → JTBD/боль/поведение; любая User Story без сквозной трассировки → CP=0.

🧠 Человек (метапознание — конвергенция сигналов)¶

Решение о Банче: MoSCoW-категории — вход, но объект управления — Банч в моменте под текущее состояние Нексуса. Тест «Что произойдёт, если этого не будет на запуске?»: «нельзя использовать по основному сценарию» → в Банч; «менее удобно, но можно» → вне окна.
Решение при равных скорах: вопрос «если бы оба решения стоили одинаково — какое?»; посмотреть на масштабируемость и барьеры копирования; если всё равно ничья — выбрать то, что быстрее сделать.
Veto на противоречия NFR: выявляет конфликты (например, «работает оффлайн» + «данные всегда актуальны»; «мгновенно» + «тяжёлые вычисления») до разработки, расставляет приоритет.
MoSCoW-рефлексия как workslop-сигнал: «у нас 80% Must Have» = не сократили MVP, а переложили весь продукт; возвращаемся к Банчу с правилом Must Have ≤ 60%.

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

bunch — узел Банча под Карту Целей: {фичи[], Bunch Size, Bunch Window, кандидат mNSM, NPV-оценка, CP-агрегат, стоимость риска}.
solution-hypothesis (обновлённые CP после скоринга).
nfr — {категория, требование, значение, источник}; включая ai-cogs-nfr для AI-продуктов.
glossary — единый язык команды.
Каждый узел: источник, CP, timestamp, статус увядания. CR после формирования Банча → ~30–35%.

🚦 CP-гейт фазы¶

Gate Банч → Pitching (7.3): - Банч сформирован с Size/Window и NPV-оценкой; - три критерия (mNSM, риски, эффект в окне) посчитаны; - Must Have ≤ 60%; - стоимость риска оценена для каждой фичи; - трассировка User Story → гипотеза → JTBD жива. - CP Банча = агрегированный CP входящих фич; падает при выявленных противоречиях NFR или отсутствии трассировки.

Чем выше CP, тем выше шанс прохождения гейта или осознанного отказа [S1] VI.3. Слабые фичи (CP < gate) выкидываются в Pitching, сильные (CP ≥ gate) → в разработку.

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

Product Lens [S1] VI.1: Банч — основной артефакт Product Sprint; формируется из текущего состояния Нексуса под Карту Целей. Связь с Business Lens: кандидат mNSM Банча + NPV-оценка связывают фичи с возвратом монетизируемой ценности (полное NPV замыкается в 7.6 Harvesting). Связь со Strategy Lens: Банч под Карту Целей синхронизирует Pod с портфелем без прямого вмешательства [S1] III.2.

🛡️ Анти-workslop¶

Workslop в требованиях — неконкретные критерии приёмки («удобно», «быстро»), противоречивые NFR, User Stories без ценности, Use Cases для тривиальных сценариев.
Трассировка до Нексуса: каждая User Story → user-flow → final-solution → solution-hypothesis (цепочка до гипотезы из 7.1). Без трассировки — workslop, CP=0.
Сопротивление backlog → Банч: MoSCoW-рефлексия («80% Must Have») — признак, что не сократили MVP. Возвращаемся к Банчу под Карту Целей с правилом Must Have ≤ 60%.
Эффект асинхронности [S1] VI.2: при росте локальных скоростей (Кортекс генерирует требования быстрее, чем команда потребляет) каденции ломаются — Банч потребляется event-based, а не по спринт-плану.
Comb-shaped компетенции [S2]: Product Engineer замещает недостающие компетенции (системный аналитик, QA, архитектор) через Кортекс — гребёнка, не T-shaped.
Premature PMF-риск: «Банч сформирован» ≠ CP готов для PMF; до PMF ещё валидация прототипа (7.3), MVP (7.5), аналитика (7.6).

🧩 Skill Map / профстандарт¶

Skill Map [S3]: сектор 2 Value & Solution Design + сектор 3 Development & Delivery (требования как вход в доставку).
Профстандарт 06.012 [S4]: функция B, уровень 5, B/02.5 «определение продукта/дизайн/требования». Связка интерпретативна (B≈Product Engineer).

🔗 Дальше¶

→ 4.pitch (PITCH) — Pitching of Trust: юзабилити ≥5 + Red-Team Банча; скоринг через mNSM×CP→вклад в NPV; финальное решение.

Назад: 2.scout · Назад в хребет: overview.

Version: 1.0 · Last updated: 2026-06-20 · Maintained by: AI-KORTEX