Обязательства: сроки, которые можно держать

Обещать бизнесу срок можно ровно настолько жёстко, насколько позволяет подтверждённое знание. Поэтому у обещания три уровня — «хотим», «целимся», «обещаем», — и переход между ними даёт артефакт, а не настойчивость заказчика. Каждый сдвиг срока потом раскладывается на два источника: бизнес поменял требования или сработали риски поставки.

Шаг 1. Что должно быть правдой

Обещание формулируют не списком работ, а условием: что должно быть правдой одновременно, чтобы цель потока считалась достигнутой? На поток выходит два-четыре таких условия. По каждому сразу помечают владельца — внутри вашей зоны или снаружи — и какое подтверждение уже существует.

Это два-три часа в одиночку, до разговоров с командами.

Кто что делает. PO отвечает на вопросы и вычёркивает лишнее. Агент раскладывает ответы на условия и выдаёт черновик; владельцев и подтверждения он не придумывает — неизвестное помечает для уточнения.

Результат. Список условий цели, у каждого — владелец и существующее подтверждение или пометка «подтверждения нет».

Инструменты:

• Шаблон ставки в poh-cortex: обещание с порогом, датой, зависимостями и разделом «Что должно быть правдой»; артефакты лежат рядом и не переписываются.
• Команда /okr-scope из презентации «Планирование квартала за час разговора с ИИ» — цели и инициативы из рассказа PO голосом или текстом.

Шаг 2. Разговор про даты

Уверенность здесь — не ощущение техлида, а ступень доказательства. В PAF (Product Architecture Framework) она называется Confidence Point: число считывают со шкалы по одному вопросу — какой самый сильный артефакт уже существует и открывается по ссылке? Нет ссылки — нет ступени.

Ступень	Что за ней стоит
2	Устное: созвон, личные сообщения. От такого можно отказаться
3–4	Письменное или показанное: письмо, тикет с датой, демо
5–6	Проверенное: прогон на заглушках, тест против реальной системы
7–9	Работающее: ограниченный объём, пилот, полный прод

Три ограничителя не дают число раздуть: сверка на 50 транзакциях ничего не говорит о 50 000; повышать уверенность может только владелец объекта; устное слово и личка дают не выше ступени 3.

Ступень добывают десятиминутным разговором рядом с демо, без терминов: вы просите защитить вас от обещания, которое команде потом исполнять.

Что спрашиваете	Что этим измеряете
«Что мы уже видели своими глазами, а что пока на словах?»	Отделяет обещания (2–3) от проверенного (5 и выше)
«Гоняли на заглушках или против их реальной системы?»	Разделяет ступени 5 и 6 — самая частая переоценка
«Если я назову дату и что-то поедет — где вероятнее всего?»	Вытаскивает слабое звено
«Готов, чтобы я на QBR сказал: готово?»	Переводит уверенность в личную ответственность

Каждое «не знаем» становится задачей на выяснение в первый спринт: на это отдают 15–20% его ёмкости, а не «если останется время». Вы не пытаетесь узнать всё до планирования — вы планируете узнавание.

Кто что делает. Техлид отвечает на вопросы. PO назначает ступень по сильнейшему выжившему доказательству — не голосованием и не средним мнением. Агент собирает ссылки на письма, тикеты и прогоны и показывает, где ссылки нет; ступень по пересказу он не повышает.

Результат. Ступень по каждому условию со ссылкой на артефакт и список задач на выяснение в первый спринт.

Инструменты: правило слабого звена — уверенность в цели равна минимуму по её критическим зависимостям; смежнику, который не пишет писем, заменяет подпись ваш тест против его системы — ступень 6.

Шаг 3. Уровень и форма

Уровень обещания выбирают по ступени, а не по желанию заказчика.

Уровень	Уверенность	Предусловие	Что обещаем
Intent — «хотим»	низкая	требований нет	дату, к которой закончим исследование, а не поставку
Target — «целимся»	средняя	черновик требований	диапазон: реалистичный и осторожный срок
Commitment — «обещаем»	высокая	объём заморожен	жёсткую дату и объём; любое изменение — новая базовая линия

Формулировка Target: «основание проверяем к такой-то дате, после этого фиксируем срок запуска» — обязательство другого типа, проверяемое в срок. При новых потоках почти всё уедет в Target, и для первого квартала это честно.

Форму выбирают каждый раз: какая сторона треугольника «срок — объём — ресурс» жёсткая. Дата фиксирована — режем объём; объём фиксирован — двигаем дату. Бизнес хочет зафиксировать и то и другое — это некоммитбельно, и команда отвечает встречным предложением, а не «да».

Кто что делает. PO выбирает уровень и форму и следит, чтобы Commitment занимал не больше 70% реальной ёмкости; команда без процессов получает одно обещание, а не три. Агент ловит «всё фиксировано» и готовит встречное предложение, но сам на дату не соглашается.

Результат. У каждого обещания — уровень и форма.

Инструменты:

• Release Management в po-helper-org/docs — лестница обязательств и форма обязательства.
• Презентация «БФТ под управлением руководителя»: агент собирает черновик требований, без которого обещание не поднимается выше Intent.

Шаг 4. Базовая линия

Базовая линия — нулевая точка, от которой потом меряют сдвиг: что в объёме, что вне объёма, буфер под известные риски и порог алерта (по умолчанию два спринта). Сдвиг считают в спринтах по двум дорожкам.

Дорожка	Источник	Куда идёт
Спрос	бизнес меняет требования	журнал изменений с автором
Поставка, известные риски	сработали заложенные риски	буфер базовой линии
Поставка, неизвестное	баги, блокеры, новые обстоятельства	в дрейф, когда буфер исчерпан

общий дрейф = дрейф спроса + max(0, дрейф поставки − буфер)

В корпоративные артефакты обещание ложится один к одному: условие — эпик в Jira, дата гейта — срок эпика, задачи на выяснение — тикеты первого спринта. В описание эпика добавляют четыре строки из карточки ниже.

Кто что делает. Агент собирает базовую линию и переносит план в Jira: эпики и истории создаёт только после «да» PO, существующие задачи не меняет. Техлиды расписывают подзадачи и исполнителей сами. PO утверждает буфер и порог.

Результат. Базовая линия v1 и эпики с четырьмя строками условия.

Инструменты: команды /okr-teamplanner и /okr-jira из презентации о планировании квартала и агент poh-okr-agent.

Шаг 5. Обещание наружу

Наружу обещание проходит через гейт — порог уверенности плюс дату. Исходов три: снять обещание, добыть недостающее доказательство или дать дату. На защите плана неизвестное называют прямо: часть обязательств стоит как Target с датой проверки, и к ней по каждому будет либо твёрдый срок, либо пересмотр объёма.

После гейта ступень меняется по событиям, а не по расписанию. Падение — хороший сигнал: риск был и раньше, система его заметила. Плохо, когда число стоит четыре недели.

Кто что делает. PO даёт обещание и защищает план. Агент по расписанию считает дрейф от базовой линии и при срабатывании порога поднимает алерт; обещание он не пересогласует. Эскалацию начинают на экваторе: тогда она — управление, через месяц та же эскалация — оправдание.

Результат. Обещание дано, у каждого есть уровень, форма, основание и дата пересмотра. Работа уходит на стадию «Поставка».

Инструменты: тема «Ритуалы для решений, а не для пересказа»; статья «Премортем» — где поедет срок.

Почему так, а не датой от бизнеса

Бизнес называет дату без требований и продавливает её в команды, после согласования задача на два-три дня превращается в пачку работ на три-пять месяцев, а то, что результат нельзя выкатить, выясняется в конце квартала. Корень один: обязательство фиксируют в момент минимальной уверенности и потом не пересматривают.

Платят дважды: в декабре руководитель объясняет отклонения вместо того, чтобы управлять, а метрика «полнота закрытия» наказывает команду за рост объёма, который принёс сам бизнес. Её заменяют тремя числами — полнота по актуальной базовой линии, дрейф объёма и попадание в Commitment; подробнее — на стадии «Эффект».

Принцип стадии: обещание по уверенности вместо обещания по надежде. Спорят не о том, «успеем ли», а о том, какого документа или теста не хватает. Такой спор решается за спринт, а не за квартал.

Артефакт: карточка обязательства

Её кладут в описание эпика в Jira — четыре строки из середины уже работают как контракт.

Обязательство: <что должно быть правдой к концу квартала>
Уровень: <Intent | Target | Commitment>
Форма: <дата фиксирована — режем объём | объём фиксирован — двигаем дату | всё фиксировано — встречное предложение>
Заказчик: <кто просит, ФИО>

Владелец зависимости: <команда (ФИО)>
Основание на сегодня: <самый сильный артефакт, ссылка> → ступень <2–9>
Что подтверждаем и к какой дате: <письмо, тест, прогон> — к <дд.мм>
Условие: нет подтверждения к <дд.мм> — <срок пересматривается | объём режется>

Базовая линия v<N>: в объёме <…>; вне объёма <…>; буфер <N> спринтов; порог алерта <2> спринта
Изменения: <дата> · <автор> · <что изменилось> · <+N спринтов> · <спрос | поставка>

С чего начать завтра

• Разложите обещания квартала по трём уровням: без требований — в Intent с датой, к которой назовёте дату; с черновиком — в Target с диапазоном.
• Добавьте в описание каждого эпика четыре строки условия из карточки.
• Отдайте 15–20% ёмкости первого спринта на выяснение — это переводит Target в Commitment.
• На ближайшем демо спросите техлида: «Готов, чтобы я на QBR сказал, что это готово?» Если он молча соглашается, механизм не работает — скажите ему это прямо.
• Ведите обещания лично только по одному потоку, остальные — через артефакты: иначе к третьей неделе ежедневная проверка перестаёт открываться.

Источники

• PAF Product Ops для корпоративного PO, адаптация А. Ишманова: разделы 9 «Откуда берётся число CP», 12 «Жизненный цикл риска», П3-бис «Квартальный план за три дня», П8 «Три точки, где это ломается», шаги 4, 6 и 7.
• Release Management — управление релизами и дрейфом объёма: лестница обязательств, форма обязательства, модель дрейфа и честная метрика квартала.
• Презентация «Планирование квартала за час разговора с ИИ», агент poh-okr-agent и шаблон памяти poh-cortex.
• Product Architecture Framework, Сергей Тихомиров: Confidence Point, гейты, спелость контекста. CC BY-SA 4.0.
• Confidence Meter, Итамар Гилад: шкала силы доказательств, на которой построена лестница.