🚦 Release Management — управление релизами и дрейфом объёма¶

Нормативное описание процесса, который реализует навык release-guard. Достраивает недостающее звено опер.модели: CP-гейтинг обязательств по поставке, а не только дискавери. Терминология — по operating-model и fit-points.

🎯 Проблема¶

Главная метрика — полнота закрытия бизнес-квартала. Патология:

Квартал стартует при минимальном объёме требований — оценивать нечем.
Бизнес/продакты придумывают сроки без БФТ и продавливают их в техкоманды.
После согласования требования разрастаются: задача на 2-3 дня → пачка на 3-5 месяцев.
«Не можем выкатить» — отгружаемость обнаруживается в конце.

Корень один: обязательство по дате и объёму фиксируется в момент минимального Confidence Point — и потом никогда не пере-гейтится.

🧭 Управляющий принцип¶

CP управляет обязательством по поставке. Обязательство нельзя давать жёстче, чем позволяет текущий Confidence Point.

Это перенос Stage-Gate с продуктовых fit-точек (fit-points) на релизные. Обязательство рождается в фазе PITCH спринт-цикла (operating-model), а не в переговорной с бизнесом «до всего».

🪜 Лестница обязательств¶

Уровень	CP	Предусловие	Что обещаем
Intent	низкий	БФТ нет	дату гейта дискавери, не поставки
Target	средний	БФТ-черновик	диапазон P50/P80
Commitment	высокий	объём заморожен	жёсткую дату/объём; изменение = ре-baseline

Форма обязательства (какая вершина iron triangle жёсткая) выбирается каждый раз: date_fixed (режем объём) · scope_fixed (двигаем дату) · both_fixed (некоммитбельно — выдаётся встречка).

📊 Модель дрейфа¶

Дрейф измеряется в спринтах относительно зафиксированного baseline (нуля). Две дорожки:

Дорожка	Источник	Куда закладывается
demand	продакт меняет требования	change-log + атрибуция автору
supply (known)	заложенные риски сработали	контингенс-буфер baseline
supply (🦢 unknown)	баги/блокеры/найденные обстоятельства	overflow в дрейф после буфера

total_drift = demand_drift + max(0, supply_drift − buffer)

Светофор: 🟢 дрейф 0 и нет увядания · 🟡 0<дрейф<порог или буфер исчерпан · 🔴 дрейф ≥ порог (деф. 2 спринта) → алерт + ре-baseline.

Staleness = Context Ripeness decay. Автор не актуализировал статус требования ≥ N синков (деф. 2) → требование в зоне риска: скрытый дрейф. Самостоятельный триггер алерта.

🔄 Процесс (навык release-guard)¶

ФАЗА SETUP (один раз, ДО bft-writer, STOP-паузы)
  /release-frame    → форма обязательства + CP + заказчик (ловит both_fixed → встречка)
  /release-baseline → нуль: scope in/out, DoR, буфер, порог → handoff в bft-writer

ФАЗА RUN (фоновая)
  /release-sync  ⏰  → cron: расчёт дрейфа, при триггере → алерт в release-alerts/
  /release-change   → change request с атрибуцией автору
  /release-gate     → ре-baseline: cut / move-date / refuse (+ кто утвердил)
  /release-status   → 3 честные метрики квартала + атрибуция

Точка входа — prerequest бизнеса, ворота перед БФТ. Это перехватывает продавливание в корне: дата на пустом месте фиксируется как Intent, а не Commitment.

📐 Честная метрика квартала¶

«Полнота закрытия» раскладывается на три числа вместо одного перверсного:

Метрика	Смысл
Baseline-полнота	выполнено против актуальной версии baseline, не против исходной фантазии
Scope drift	рост объёма от v1 = диагностика качества входа бизнеса, не вина команды
Commitment hit-rate	жёсткость меряем только на обязательствах уровня `Commitment`

Каждое — с атрибуцией по авторам change requests. Это доказательная база PO в защите объёма перед CPO/бизнесом.

🔗 Связи¶

Вход обязательства: фаза PITCH operating-model.
Гейтинг по CP: fit-points (Stage-Gate).
Требования эпика после baseline: навык bft-writer (/bft-context-gen …).
Квартальные KR, к которым привязан релиз: навык okr-planner.