Перейти к содержанию

4.3 instruction — Обновление CP как цикл Product Sprint

Этап RB-STEP-1 — BIG IDEA (прелюдия) · Линза: над 3PL (цикл замыкается через все Нексусы) · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-1-IDEA/4.3 Обновление CP.md — правила обновления CP по результатам валидации (smoke 1–3 → pass = 4–5; prototype 4–6 → pass = 6–7; customer 7–8 → pass = 8–9), опции при fail (refine/pivot/drop), Bunch v2.0 (Confirmed/Needs-More/Dropped). Эта инструкция: переопределяет обновление CP как цикл Product Sprint [S1] VI.4 — авто-коммит learnings в Нексус (Harvesting-микро), триггер переоценки Банча (Банч меняется при изменении состояния Нексуса [S1] базовая логика).

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

Обновление CP — не отдельный шаг, а цикл Product Sprint в миниатюре [S1] VI.4: learnings из валидации (4.2) коммитятся в Нексус (увеличивая Context Ripeness), что меняет текущее состояние → Банч переоценивается (Банч определяется только текущим состоянием [S1] базовая логика).

Это Harvesting-микро цикла: импакт → фиксация → инкремент контекста → цикл заново [S1] VI.4. Результат — Bunch v2.0 (Confirmed/Needs-More/Dropped, из исходника 4.3) как живой артефакт, не статичная таблица.

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

  • Product Engineer — принимает решение о fate фичи (Confirmed/Needs-More/Dropped); инициирует переоценку Банча; veto на фичи, чей CP не вырос от evidence.
  • Product Ops — обеспечивает событийный авто-коммит learnings в Нексус (event-based, не ручное редактирование [S1] VI.2).
  • Portfolio Manager — сверяет Bunch v2.0 с Картой Целей (если Банч сильно изменился — конфликт с Ставками?).
  • Зона человека: решение о судьбе фичи (drop/pivot/keep) — за человеком; Кортекс рекомендует, человек решает.

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

CP-Update Agent (режим Validation Agent [reformation] §1.5) + Nexus-Commit:

  • Применяет правила обновления CP (из исходника 4.3: smoke→4–5, prototype→6–7, customer→8–9 при pass).
  • Авто-коммит learnings в Нексус: каждый Validation-Result (4.2) → обновление Узлов-источников (JTBD-Opportunity, mNSM-numeric), пересчёт CR.
  • Триггер переоценки Банча: если CP фичи изменился → Bunch Architect Agent (3.3) переcчитывает комплексный NPV Банча; фичи с CP<порога → отсев; новые opportunity (из learnings) → кандидаты.
  • Генерация Bunch v2.0 (Confirmed/Needs-More/Dropped, из исходника 4.3).

  • Вход: Validation-Result-узлы (4.2) + Bunch-v1 (3.3).

  • Выход: обновлённые CP фич, Bunch-v2, пересчитанный CR Нексусов, Learning-узлы.

Правила обновления CP (преемственность из исходника 4.3): - smoke pass (CP 1–3) → 4–5; - prototype pass (CP 4–6) → 6–7; - customer validation pass (CP 7–8) → 8–9; - fail → refine / pivot / drop.

Промпт-идея:

«Обнови CP по результатам валидации. Закоммить learnings в Узлы Нексуса (пересчитай CR). Если CP фичи изменился — триггер Bunch Architect на переоценку NPV Банча. Сгенерируй Bunch v2.0 (Confirmed/Needs-More/Dropped). CP растёт только от evidence, не от возбуждения.»

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

  • Чекпоинт: Банч должен меняться от изменения состояния Нексуса, а не от каприза. Инженер проверяет: каждое изменение Банча связано с конкретным learning-узлом?
  • Veto-право: фича, чей CP «вырос» без нового evidence (самоубеждение) → откат CP. CP — потенциальная vanity [reformation] §4.9.
  • Вопрос:
  • «Какой learning вызвал drop этой фичи? Bunch v2.0 всё ещё максимизирует NPV при текущем состоянии Нексуса?»

📦 Артефакт = узлы Нексуса

  • Создаются/обновляются: Learning-узлы (коммит в Нексус), обновлённые CP фич, Bunch-v2-мета-узел (Confirmed/Needs-More/Dropped + пересчитанный NPV), пересчитанный CR.
  • Метаданные: источник (Validation-Result), delta-CP, learning, timestamp, trigger=re-evaluation, статус увядания.
  • Прирост Context Ripeness: +5–10% (learnings — ядро созревания; это микро-Harvesting [S1] VI.4).

🚦 Confidence Point-гейт

  • Критерий перехода к 5.1: Bunch-v2 существует с Confirmed фичами (CP≥порога после валидации); каждая Confirmed фича имеет ≥1 Learning-узел; CR Нексусов вырос.
  • Стоимость риска: «Какой NPV мы теряем, держа в Банче фичу, чья валидация failed?» — drop по NPV-логике.

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

  • Над 3PL: цикл замыкается через все Нексусы (learnings затрагивают рынок/продукт/рост).
  • Связь: Bunch v2.0 → BIG Idea Statement (5.1); Confirmed фичи → Pitching of Trust (6.1).

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

  • Workslop-риск: CP растёт от самоубеждения (новая vanity); learnings не коммитятся (остаются в голове/чате); Банч не переоценивается (стареет).
  • Признак: изменение CP без Learning-узла; Bunch v2.0 = Bunch v1.0 после валидации (не изменился — подозрительно).
  • Правило верификации: каждое изменение CP — Learning-узел с источником; Банч переоценивается при изменении состояния; CP растёт только от evidence.

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

  • Skill Map [S3]: сектор 4 Growth & Experiments (анализ результатов, итерация). Уровень — средний круг (middle/senior): анализ, обоснованные выводы.
  • Профстандарт 06.012 [S4]: функция B (B/08.5 показатели успешности), уровень 5.

🔗 Связи

Назад: 4.2 instruction · Дальше: 5.1 instruction Связанные: reformation · index · [[naming_conventions]