Проблема: одна дата скрывала неопределённость

Руководители получали статусы из встреч, сообщений, Jira и отдельных таблиц. Дата инициативы выглядела определённой, пока очередная зависимость или длинное ожидание не делали перенос очевидным. К этому моменту уменьшить объём работ, изменить их порядок или снять ограничение было уже дорого.

Локальные метрики команд не отвечали на три управленческих вопроса:

  1. сколько времени проходит от идеи до результата;
  2. какая незавершённая работа уже находится в зоне риска;
  3. какой объём портфель способен завершить к дате с выбранной вероятностью.

Метод: одна единица потока и несколько разных сигналов

Мы выбрали RFC и Epic как единицы, которые распознают и бизнес, и ИТ. Для них разделили:

  • System Lead Time — полное календарное время от входа инициативы в анализ до результата;
  • Lead Time / Cycle Time — более узкие интервалы внутри delivery;
  • Throughput — сколько RFC или Epic завершается за период;
  • Aging — возраст текущей незавершённой работы;
  • P50 и P85 — типичный срок и граница длинного хвоста.

Сами числа не стали KPI людей. Для каждого сигнала определили решение: снять зависимость, уменьшить объём, изменить очередь, ограничить WIP или остановить инициативу.

Как использовали Monte Carlo

Вероятностная модель многократно проигрывает будущее по фактической истории сопоставимых работ. Она отвечает на два разных вопроса:

  • прогноз срока — с какой вероятностью заданный объём завершится к дате;
  • прогноз объёма — сколько единиц, вероятно, завершится к выбранной дате.

Прогноз строился как управленческий эксперимент, а не как новая форма обязательства. Мы фиксировали класс работ, исторический Throughput, границы System Lead Time и допущения о WIP и составе системы. P50 использовался как рабочий сценарий, P85 — как более осторожная граница риска.

От панели к управленческим решениям

Чтобы данные влияли на решения, одного экрана было недостаточно. Появился набор отчётов с разным ритмом.

Еженедельный дайджест рисков

Только инициативы, где Aging вышел за ожидаемый диапазон, появилась блокировка, изменилась вероятность завершения или требуется решение владельца.

Прогноз портфеля

Сравнение сценариев: текущий WIP, ограниченный WIP, другой порядок инициатив или снятая зависимость. Так цена параллельного старта выражается не числом карточек, а изменением вероятности достичь цели.

Отчёт о здоровье потока

System Lead Time, Throughput, WIP, Aging, блокировки и незапланированная работа помогают отличить симптом от ограничения. Падение выпуска может быть следствием очереди согласования, а не низкой скорости команды.

Digest качества RFC

Показывает отсутствие ожидаемого эффекта, критериев готовности и явных зависимостей до начала дорогой реализации. LLM может подготовить первичную проверку, но решение остаётся у владельца инициативы.

Ежемесячный обзор для руководителей

Связывает цепочку: цель компании → цель команды → RFC/Epic → метрика ожидаемого эффекта → delivery-сигнал. По каждой инициативе видно, движется ли работа, меняется ли ожидаемый результат и есть ли риск не получить его вовремя.

Что изменилось для бизнеса

Единый контур данных сократил время на получение общей картины до 1–2 часов вместо множества уточнений. RFC System Lead Time на P85 снизился с 295 до 106 дней, а выпуск Epic вырос с 16 до 54 в месяц.

Эти результаты нельзя приписать одной модели Monte Carlo или панели. Эффект дала система: общая единица потока, качество данных, видимость зависимостей и правило принятия решения по каждому сигналу.

Для бизнеса это означает более ранний выбор: что не начинать, где снять зависимость, когда сократить объём работ и какой риск по сроку принять осознанно.

Ограничения подхода

Monte Carlo не исправляет плохие данные и не делает нестабильную систему предсказуемой. Нельзя смешивать небольшие улучшения и крупные RFC, переносить P85 между несопоставимыми продуктами или превращать прогноз в оценку отдельного сотрудника.

Первый результат диагностики иногда не модель, а договорённость о единице потока, правилах начала и окончания и владельце решения.

Что проверять в похожей системе

  • распознаёт ли бизнес единицу, для которой измеряется срок;
  • видны ли Aging и зависимости до срыва обязательства;
  • разделены ли классы работ;
  • какое решение принимает руководитель при изменении прогноза;
  • связана ли скорость delivery с ожидаемым эффектом инициативы.

Delivery-диагностика помогает найти минимальный набор данных и управленческих правил, с которого имеет смысл начинать.