7.4 instruction — Цифровой профиль продукта (Нексус) вместо пакета требований¶

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

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

Классический «пакет требований v0.1» (User Stories / Use Cases / NFR / MoSCoW / DoD / Test Cases в Notion/Confluence) прекращает существовать как финальный артефакт [S2] III.5: документация исчезает, её заменяет цифровой профиль продукта (Нексус) — живой граф узлов, с которым работают агенты, аналог claude.md для продукта/процессов (единая точка информации). Методы сохраняются (User Stories, Use Cases, NFR, Screen Map, Test Cases, DoD) — но становятся типами узлов Нексуса.

Требования = точное описание того, что должен уметь продукт и как он должен себя вести; не как сделать технически (это задача разработчиков), а что произойдёт с точки зрения пользователя и системы. Чем точнее требования → тем меньше переделок → тем меньше технический долг (Technical Debt).

MoSCoW больше не объект управления (запрещённый синоним [naming_conventions]): MoSCoW → Банч фич под Карту Целей с лимитами Bunch Size/Window. Принцип 1 PAF [S1]: Беклог упразднён; объект управления PM — Нексусы, не поток задач. Принцип 5: скаутинг вместо приоритизации.

Цель 7.4 — построить спелый Нексус продукта (Context Ripeness ≥ порога), из которого Кортекс и вайбкодинг (7.5) генерируют инкремент. Чем точнее требования → тем меньше переделок → тем меньше технический долг. Каждое изменение требований после начала разработки стоит в 5–10 раз дороже, чем до неё — поэтому спелость контекста критична.

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

Product Engineer — проектирует «цифровой профиль продукта»: инженерия контекста (по Тоби Лютке [S2] III.6); определяет, какие узлы нужны; задаёт AI workflow (что делегировать агенту, что себе).
Discovery / Launcher PM — переводит финальное решение (из 7.3) в узлы Нексуса; вайбкодит спецификацию из цифрового профиля; minimизация time-to-market.
AI UX Designer — проектирует Screen Map (экраны, состояния загрузка/успех/пусто/ошибка, переходы) под ИИ-метафоры.
Technical / AI Product Manager — для AI-свойств: формирует NFR-узлы (точность, прецизионность, полнота, производительность модели) и COGS токенов как часть требований; сшивает агентов.
Product Ops — поддерживает структуру Нексуса продукта, метрику Context Ripeness (полнота × актуальность), флаги увядания узлов; миссия — рост ИИ-зрелости компании [S2] III.6.
Зона человека [S2] III.4: решение о составе Банча под Карту Целей — что входит в инкремент (Bunch Size), что вне окна (Bunch Window) [S1] VI.6. Стратегическое распределение ресурсов не делегируется.

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

Генератор User Stories / Use Cases — из final-solution (7.3) + user-flow генерирует:
User Stories в каноническом формате («Как [тип пользователя], я хочу [действие], чтобы [ценность]») с критериями приёмки; баланс размерности (не слишком большая — реализуема за итерацию; не слишком маленькая — приносит реальную ценность); приоритет, story points, зависимости;
Use Cases — для сложных многошаговых сценариев (≥5 шагов или ≥2 участников): цель, участники (actors), предусловия, триггер, основной поток, альтернативные потоки, постусловия.
NFR-агент — формирует нефункциональные требования по категориям:
производительность (время отклика);
масштабируемость (нагрузка);
надёжность (uptime/SLA);
безопасность (хэширование паролей, HTTPS);
доступность (WCAG, screen readers);
совместимость (браузеры/ОС);
портируемость;
для AI-продуктов — AI-COGS (cost-per-token × tokens-per-user) как отдельный модуль требований.
Screen Map-билдер — переносит экраны прототипа в карту экранов с переходами и состояниями (Загрузка/Skeleton, Успех, Пусто, Ошибка/Toast); для каждого экрана — элементы интерфейса и переходы (действие → куда ведёт).
Test Case-генератор — для каждой Must Have User Story генерирует Test Cases: наименование, связанная User Story, предусловия среды, тестовые данные, шаги (действие → ожидаемый результат → фактический → вердикт Pass/Fail).
Банч-архитектор — заменяет MoSCoW-приоритизацию: формирует Банч под Карту Целей с лимитами:
Bunch Size (скорость восприятия рынка);
Bunch Window (период ожидания бизнес-результата) [S1] VI.6;
три критерия: ① макс. mNSM; ② мин. рисков (CP); ③ эффект в окне → комплексный NPV;
Must Have ≤ 60% объёма (правило против перекладывания всего продукта в MVP).
DoD-агент — фиксирует Definition of Done трёх уровней (User Story DoD / Sprint DoD / Release DoD) как узлы-критерии приёмки.
Глоссарий-агент — формирует единый язык команды (термин → определение).
DoR-агент (Definition of Ready) — проверяет готовность User Story к разработке: есть ценность, критерии приёмки однозначны, нет противоречий с NFR, оценены story points, указаны зависимости.
Traceability-агент — строит цепочку User Story → User Flow → Final Solution → Solution Hypothesis → JTBD/боль/поведение; любая User Story без сквозной трассировки помечается CP = 0.

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

Валидация ИИ-генерации требований: каждая User Story проверяется на баланс размерности, однозначность критериев приёмки (без «быстро», «удобно», «правильно», «непрерывно» — описывают конкретное проверяемое поведение); правило «если можно представить два разных способа реализации — нужно уточнение».
Veto на противоречия: Product Engineer выявляет конфликты NFR (например, «работает оффлайн» + «данные всегда актуальны»; «мгновенно» + «тяжёлые вычисления»), расставляет приоритет, фиксирует решение в узле. Противоречивые требования выявить до разработки.
Решение о Банче: MoSCoW-категории (Must/Should/Could/Won't) — это вход, но объект управления — Банч в моменте под текущее состояние Нексуса. Тест «Что произойдёт, если этого не будет на запуске?»: «нельзя использовать по основному сценарию» → в Банч; «менее удобно, но можно» → вне окна.
Метапознание-фильтр: понимание каждого сгенерированного требования и способности его объяснить разработке/агентам. Change Request-процесс: любое изменение фиксируется, оценивается по влиянию (время/деньги), принимается осознанно. Правило «ничто не "очевидно" для разработчика, который не видел обсуждений».
Use Case vs User Story: User Stories достаточны для большинства фич; Use Cases добавляются, когда (1) в сценарии несколько типов пользователей или внешние системы; (2) сценарий >7 шагов; (3) важны альтернативные потоки/исключения. Типичный диапазон User Stories для первого MVP — 15–40.
NFR-конфликты как правило, не исключение: «мгновенный отклик» против «тяжёлых вычислений», «оффлайн» против «данных всегда актуальны» — выявляются на 7.4, до разработки, а не в коде.
Прозрачность до очевидности [S1] Принцип 1: цифровой профиль продукта — реализация этого принципа; рост доверия к решениям разработки требует роста прозрачности (полнота + непротиворечивость + доступ стейкхолдеров через Нексус, а не через разрозненные документы).
Совместная унификация контекста [S1] Принцип 2: все стейкхолдеры работают с единым Нексусом, а не с разрозненными документами — формализация контекста важнее повторяющейся коммуникации.

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

user-story — {роль, действие, ценность, критерии приёмки[], приоритет-в-банче, story points, зависимости}.
use-case — {цель, участники, предусловия, триггер, основной поток, альтернативные потоки, постусловия}.
nfr — {категория, требование, значение, источник}; включая ai-cogs-nfr для AI-продуктов.
screen-map — {экран, URL/route, триггер открытия, состояния (загрузка/успех/пусто/ошибка), элементы, переходы}.
test-case — {связанная User Story, предусловия, тестовые данные, шаги, ожидаемый результат}.
dod — {уровень (User Story/Sprint/Release), критерии[]}.
bunch — узел Банча под Карту Целей {фичи[], Bunch Size, Bunch Window, кандидат mNSM, NPV-оценка, CP-агрегат}.
glossary — узлы терминов продукта (единый язык команды).
Каждый узел: источник, CP, timestamp, статус увядания. Context Ripeness после 7.4 → ~70% стадии; порог для входа в execute-фазу (7.5).

🚦 Confidence Point-гейт¶

Gate 7.4 → 7.5 (CR ≥ порога): Context Ripeness Нексуса продукта ≥ порога:
все Must Have User Stories с критериями приёмки;
Use Cases для сложных сценариев;
NFR описаны по ключевым категориям;
Screen Map связан с User Stories;
Test Cases готовы для Must Have;
DoD согласован;
Банч сформирован с Size/Window и NPV-оценкой;
глоссарий един.
До порога — доработка узлов.
CP Банча = агрегированный CP входящих фич; падает при выявленных противоречиях NFR или отсутствии критериев приёмки.

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

Product Lens [S1] VI.1: Нексус продукта — основной объект управления; Банч формируется из текущего состояния Нексуса под Карту Целей.

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

Связь с Business Lens: кандидат mNSM Банча + NPV-оценка связывают требования с возвратом монетизируемой ценности (полное NPV замыкается в 7.6).

Связь со Strategy Lens: Банч под Карту Целей синхронизирует Pod с портфелем без прямого вмешательства [S1] III.2; синхронизация между командами — через Карту Целей.

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

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

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

Skill Map [S3] IV:
сектор 2 Value & Solution Design;
сектор 3 Development & Delivery (требования как вход в доставку).
Профстандарт 06.012 [S4] V: обобщённая функция B «Управление ИТ-продуктом», уровень 5 — B/02.5 «определение продукта/дизайн/требования» (каноническая трудовая функция требований в стандарте). Связка стандарт ↔ PAF интерпретативна (B≈Product Engineer) [S3]+[S4].

🔗 Связи¶

Назад: 7.3 instruction · Дальше: 7.5 instruction — Product Sprint execute-фаза + вайбкодинг MVP Связанные: reformation · index · naming_conventions