Зачем нужны flow-метрики

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

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

Пять основных показателей

Lead Time

Календарное время от выбранной точки начала до завершения. Границы должны соответствовать управленческому вопросу. Если CTO отвечает за путь от согласованной инициативы до выпуска, командный Cycle Time не заменит полный System Lead Time.

Throughput

Количество сопоставимых единиц результата, завершённых за период. Throughput помогает оценить фактическую мощность системы без пересчёта задач в часы или story points.

WIP

Количество начатой, но не завершённой работы. Рост WIP увеличивает очереди, переключения и срок обратной связи. Поэтому решение о старте новой инициативы одновременно является решением о сроке уже начатых работ.

Aging

Возраст текущей незавершённой работы. Aging позволяет увидеть риск до срыва даты: активная инициатива уже может выйти за диапазон, в котором обычно завершаются сопоставимые работы.

Перцентили срока

P50 описывает типичный сценарий, P85 — более осторожную границу длинного хвоста. В отличие от среднего, перцентили показывают распределение и помогают обсуждать риск обязательства.

Как превратить показатели в систему решений

Для каждой метрики заранее задаётся реакция:

  • Aging выше P85 — выяснить причину ожидания и владельца решения;
  • WIP растёт без роста Throughput — остановить новые старты;
  • увеличивается полный Lead Time — проверить очереди между командами;
  • падает Throughput — искать изменение системы, а не виноватого;
  • прогноз ухудшается — сократить объём, изменить порядок или снять зависимость.

Без этого метрики превращаются в отчётность. Система управления начинается там, где изменение сигнала приводит к понятному действию.

Как выбрать единицу измерения

Единица должна быть узнаваема и достаточно однородна. Для портфеля это может быть RFC или Epic, для продукта — клиентская функция. Нельзя смешивать мелкие исправления и крупные инициативы, а затем строить единый P85.

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

Что показывать руководителю

Управленческий экран не должен повторять Jira. Достаточно показать:

  • распределение полного срока;
  • текущий WIP и Aging;
  • Throughput по сопоставимым единицам;
  • повторяющиеся блокировки и зависимости;
  • инициативы, где требуется решение;
  • изменение прогноза после управленческого действия.

В кейсе про P85, Monte Carlo и дайджесты эти сигналы были встроены в регулярный контур решений для более чем 20 продуктовых команд. Следующий шаг после устойчивых данных — вероятностный прогноз сроков.

На delivery-диагностике можно определить минимальный набор метрик и проверить, какие из них действительно меняют решение в вашей системе.