Эффект: как доказать результат

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

Шаг 1. Метрика эффекта

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

Сила доказательства зависит от того, как цифру зафиксировали. В методологии это ступень подтверждённости — шкала от 2 («кто-то сказал») до 9 («работает в проде»).

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

У каждой цифры обязателен объём. «Время подключения снизилось с 9 до 2 дней» (пример условный) — факт, только если записано, на двух подключениях это измерено или на двадцати. Если продукт не монетизируется напрямую, вместо выручки берут метрику потребителя: долю подключившихся, время до интеграции, объём продаж через вашу возможность.

Кто что делает. PO просит у владельца метрики письмо или выгрузку вместо устного ответа. Агент кладёт артефакт в репозиторий и проверяет, что у цифры есть автор, дата и объём. Чужую метрику агент сам не считает и цифры из разговоров не переносит.

Результат. Метрика эффекта с артефактом и ступенью подтверждённости.

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

• Тема «Метрики продукта» — как выбрать одну метрику потребителя; статья «North Star».
• Тема «Эксперименты» — как проверить, что эффект дало именно изменение.

Шаг 2. Честная метрика выполнения

Главную метрику квартала — «полноту закрытия» — обычно считают против исходного плана. Рост объёма, который принёс бизнес, молча записывают команде в провал. Честная метрика раскладывает одно перверсное число на три.

Число	Что показывает
Выполнение против актуальной базовой линии	сделано против той версии объёма, что действует сейчас, а не против исходной фантазии
Рост объёма от первой версии	диагностика качества входа бизнеса, а не вина команды
Попадание в срок по Commitment	жёсткость меряют только на обещаниях уровня «обещаем», а не на Intent («хотим») и Target («целимся»)

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

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

Результат. Три числа выполнения с атрибуцией изменений.

Инструменты: тема «Обязательства» и модель честной метрики в Release Management.

Шаг 3. Управляемость и журнал решений

Если людей не прибавилось, рост выпуска обещать нельзя — это ловушка, в которую не стоит заходить с первого дня. Доказывается управляемость. Базовую линию для неё снимают в первый день квартала: потом её уже не восстановить.

Метрика	Замеряется в день 1	К концу квартала
Доля обещаний, выполненных в срок	по прошлому кварталу	не ниже прежней при большем объёме обязательств
За сколько недель до срока сообщали о риске	по прошлому кварталу	недели вместо дней
Часы в неделю на отчётность	по календарю и памяти	кратно меньше
Сюрпризы в конце квартала	сколько было	ноль
Потоки, где обещания стоят на письменном основании	обычно один из пяти	все

Журнал решений заводят в первый день и ведут весь квартал. Запись: что решили, на основании какого числа, за сколько недель до срока, чем закончилось. В него пишут и неудачи: дата, снятая за шесть недель с основанием и вариантами, доказывает управление лучше, чем героически вытянутый срок, о котором все узнали в последнюю неделю.

Кто что делает. PO согласует с руководителем три-четыре критерия письмом и пишет журнал. Агент переносит в журнал решения по отклонениям со стадии «Поставка» и сверяет метрики с базовой линией.

Результат. Таблица «было → стало» и три-четыре записи журнала — это и есть кейс квартала.

Инструменты: тема «Решения при неопределённости».

Шаг 4. Отчёт руководителю

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

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

В переходном формате про репозиторий и уверенность не упоминают: обсуждение съедет на инструмент вместо результата. Каждый спринт агент собирает «Факт спринта» — колоду от целей квартала: одна цель — один слайд, результат светофором, цифры из трекера, тексты пишет агент.

Кто что делает. Агент пишет итог, блокер и следующий шаг по каждому ключевому результату. PO правит слова и публикует. Замечания комитета агент сверяет с доской и предлагает правки, а в Jira они попадают только после ✅ PO.

Результат. Отчёт, в котором руководитель видит прогноз, а не только прошлое; в конце квартала — записка об итогах.

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

• Презентация «Бизнес-отчёт спринта: ценность от целей квартала» и навык poh-sprint-agents.
• Тема «Ритуалы для решений, а не для пересказа».

Шаг 5. Возврат знания в контекст

Калибровка — разбор в конце квартала: где были уверены, а не сработало. Полчаса перед ретро агент сопоставляет, что обещали и чем это было подтверждено, с тем, что вышло. В Product Architecture Framework (PAF) этот шаг называется Harvesting — сбор урожая: знание запуска возвращается в модель знания о продукте, а шкала подтверждённости калибруется.

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

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

Кто что делает. Агент сопоставляет обещания с исходами и предлагает правки узлов. Правила — шкалу, пороги, сроки годности — меняет только PO и только на калибровке. Агент правила не меняет: тот, кто их меняет, может получить любое число.

Результат. Обновлённые правила и узлы контекста; с ними следующий квартал начинается со стадии «Вход».

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

• Тема «Контекст в репозитории, а не в головах».
• Презентация «Второй мозг руководителя» и шаблон памяти poh-cortex.

Почему так, а не через рассказ о сделанном

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

Принцип стадии: доказанная управляемость вместо отчёта об объёме. Управляемость измерима с первого дня и проверяется открытием репозитория, а не честным словом. Руководитель получает прогноз, а неудача, снятая заранее с основанием, становится доказательством силы.

Артефакт: записка об итогах квартала и запись калибровки

Итоги квартала <Q> — <направление>
Критерии оценки согласованы: <дата письма руководителю>, <ссылка>

1. Управляемость (было в прошлом квартале → стало)
   Обещаний выполнено в срок:            <x из y> → <x из y>
   О риске сообщали за:                  <дней> → <недель>
   Часы в неделю на отчётность:          <ч> → <ч>
   Сюрпризов в конце квартала:           <n> → <n>
   Потоков с письменным основанием:      <n из N> → <n из N>

2. Выполнение
   Против актуального плана (версия <v>): <%>
   Рост объёма от первой версии:          <%>, авторы изменений: <кто>
   Жёсткие обязательства в срок:          <x из y>

3. Бизнес-эффект
   <метрика>: <было> → <стало>, объём: <на чём измерено>
   источник: <владелец, дата снятия, ссылка>, ступень: <2–9>

4. Журнал решений (3–4 записи)
   <дата> | решили: <что> | основание: <число, ссылка>
          | за <n> недель до срока | чем закончилось: <итог>

Калибровка <Q>
Что нашли: <переоценка | слепая зона | устаревание> — <обещание, ссылка>
Что меняем: <ступень шкалы | новый узел | срок годности знания>
Где записано: <файл правил или узла, коммит>
Что говорим на ретро: <формулировка без имён людей>

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

1. Снимите базовую линию по прошлому кварталу: часы на отчётность, сколько обещанных дат сдвинулось, за сколько дней до срока узнавали о проблемах.
2. Напишите руководителю письмо с тремя-четырьмя измеримыми критериями «стали управляемее» и попросите подтвердить.
3. Заведите журнал решений сегодня.
4. У каждого обещания заполните метрику эффекта и попросите у владельца цифры письмо или выгрузку.
5. В ближайший отчёт добавьте две строки про риск: причина и какое решение нужно к какой дате.

Источники

• PAF Product Ops для корпоративного PO, адаптация А. Ишманова: П7 «Что доказываем в конце квартала» и журнал решений, шаг 8 «Отчётность руководителю», шаг 9 «Калибровка и закрытие квартала», «Как доказать метрику, которая лежит в чужой системе».
• Модель честной метрики квартала и дрейфа объёма — Release Management в репозитории po-helper-org/docs.
• Product Architecture Framework Сергея Тихомирова — разбор итогов запуска (Harvesting) и монетизируемая North Star, CC BY-SA 4.0.