Шаг 9. Калибровка и закрытие квартала

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

Стадия 1. Как проходит сейчас

Ретро и QBR обсуждают, что не успели и кто виноват. Вывод формулируется как «в следующий раз начнём раньше». Через квартал повторяется то же самое, потому что причина не зафиксирована, а память о ней ушла вместе с людьми.

Стадия 2. Что делаете лично вы

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

Что нашли	Вывод для правил	Что говорите на ретро
Из пяти обещаний с высокой уверенностью сорвались два, оба на демо-подтверждении	Демо больше не считается сильным доказательством	«Демо оказалось слабее, чем мы думали. В следующем квартале дату даём после теста против реальной системы»
Сорвался стык, которого не было ни в одном списке	Появляется новый узел: фискальные основания	«Мы не смотрели в эту сторону вообще. Теперь смотрим»
Знание об API считалось свежим, а схема менялась дважды	Срок годности этого знания сокращается до трёх недель	«Договорились: сверяем схему каждые три недели, а не раз в квартал»

Заметьте формулировки: ни одна не про людей. Вы обсуждаете качество своих оснований, и это единственная версия ретро, после которой что-то меняется.

Стадия 3. Когда так работает департамент

Калибровка становится общей: лестница одна на департамент, и после квартала видно, чьи обещания какого уровня стоят, у каких систем знание протухает быстрее всего и какие узлы отсутствуют у всех команд сразу. Это уже разговор CPO и CTO о структуре, а не PO о своём квартале.

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

Ниже — что именно ищет агент при разборе.

Как доказать метрику, которая лежит в чужой системе

Ставка несёт поле impact_metric: что именно должно измениться и на чём это измеряется. Агенту не нужен доступ к дашборду — нужен артефакт с цифрой, автором, датой снятия и ссылкой на источник для человека.

Способ фиксации	Ступень
Владелец метрики назвал цифру на созвоне	2
Письмо владельца с цифрой и датой снятия	3
Экспорт или скриншот дашборда с датой, положенный в evidence/	5–6
Регулярная выгрузка в репозиторий, например CSV раз в неделю	7

Про scope у метрики: «time-to-integrate снизился с 9 до 2 дней» — факт со scope. Обязательно фиксируйте, на каком числе подключений измерено: на двух или на двадцати. Без этого цифра выглядит сильнее, чем есть.

Что ищем	Признак	Что правим
Переоценка	Из ставок с CP 8 доехала половина	Сдвинуть ступени вниз
Слепая зона	Инцидент, который никто не предсказал	Завести отсутствующий узел
Неверный распад	Узел считался свежим, знание не соответствовало	Поднять change_rate