Всех приветствую, зовут меня Николай и теперь я Delivery manager из компании 05.ru

В этой статье я делюсь своим личным «набором приборов»: какие метрики для меня приоритетные, а какие служат дополнительной поддержкой, и как я интерпретирую их показания. Расскажу, какие сигналы считаю тревожными, как нахожу закономерности в данных и использую их для более точного управления процессом.

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

Опережающие метрики

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

Blockers — количество и длительность задач-блокеров;
WIP Age — средний возраст задач в системе;
WIP Rate — отношение количества задач в работе к количеству завершённых задач за период.

Запаздывающие метрики

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

Lead Time — время от постановки задачи в разработку до релиза;
Cycle Time — время выполнения задачи с момента начала разработки;
T2M (Time to Market) — время от идеи до выхода фичи или исправления в проде, включая Discovery и Delivery;
Пропускная способность (Throughput) — количество задач, завершённых за период;
Flow efficiency — эффективность потока с измерением блокирующего времени.

Анализ T2M и Lead Time на уровне координаций

Важно не только знать средние числа, но и понимать, как они распределяются по типам задач и платформам. Поэтому я сначала смотрю на «Мультимодальную модель», а затем спускаюсь на уровень отдельных моделей, чтобы выявить отклонения и аномалии.

В моей системе есть два уровня визуализаций:

Координационный уровень. Здесь находятся команды, которые объединяют разные платформы. Этот уровень нужен для оперативного управления процессом и координации между командами. Если запрос буксует, то именно здесь проще всего заметить проблему и вовремя подключить ресурсы.
Операционный уровень. Это взгляд на отдельные платформы. Каждая из них может закрывать один и тот же запрос за разное время, поэтому важно смотреть вглубь, чтобы выявлять локальные узкие места и причины задержек.

Есть ещё уровень стратегии, но это выходит за рамки статьи.

Мультимодальная модель (Multimodal). Все типы рабочих элементов. Смотрим на систему целиком, чтобы увидеть общую динамику и первичные аномалии. Вопрос, на который отвечает уровень Multimodal:
«Есть ли системные проблемы в потоке задач, или изменения происходят локально?»
Отдельная модель (Single Model). Конкретный тип задач. Переходим к одному типу, чтобы исключить искажения. Если встречается высокий WIP Age, то агрегированная метрика будет смещена.
Разрез по платформам (iOS, Android, Web, Backend). Если в Single Model есть аномалии, то спускаемся на уровень платформ, чтобы найти узкие места.

Пропускная способность (Throughput)

Это ключевой показатель скорости работы, который напрямую влияет на Lead Time и T2M. Но сам по себе он мало что говорит — важно смотреть, из каких типов задач складывается поток и сколько в нём блокировок.

На метрику воздействуют:

количество закрытых задач за период;
процентное соотношение типов рабочих элементов;
время, потраченное из-за блокировок и буферов.

Интерпретация:

Если Throughput снизился, а Lead Time вырос, то, вероятно, были блокировки или объёмные задачи.
Если Throughput вырос, а Lead Time снизился, то, возможно, было много мелких задач (доработок, багов).
Для детального разбора обратитесь к метрике эффективности потока.

Анализ Cycle Time разработки и тестирования

После того, как мы посмотрели на T2M и Lead Time, важно углубиться в Cycle Time и понять, какие этапы занимают больше всего времени.

Я делю Cycle Time на два ключевых участка:

разработка: написание кода и проверка кода;
тестирование: начинается с перехода задачи в статус «готово к тестированию» и заканчивается статусом «готово к релизу».

Такое разделение помогает увидеть, где именно «застревают» задачи. В моей практике часто бывает ситуация, когда разработка занимает меньше времени, чем тестирование. Например, средний Cycle Time разработки — 3 дня, а средний Cycle Time тестирования: 5 дней

Зачем сравнивать?

Если тестирование стабильно занимает больше времени, то это сигнал о том, что команда QA перегружена или нехватает автотестов.
Баланс важен: если разработка ускоряется (с помощью распараллеливания задач или упрощений), а тестирование остаётся «бутылочным горлышком», то LeadTime держится на том же уровне.
Здесь мы можем внимательнее изучить конкретные этапы: дашборд с временем задач в определённых статусах позволяет увидеть, где именно возникает задержка — на проверке кода, в очереди на тестирование или в самом тестировании.

Визуализация

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

Диаграмма соотношения (bar chart) показывает, какую долю Cycle Time занимает разработка, а какую — тестирование.

Динамика по времени (line chart) позволяет отследить, меняется ли баланс между разработкой и тестированием от месяца к месяцу.

Stacked bar chart он показывает распределение длительности задач по статусам для каждого месяца.

Взаимосвязь WIP Rate и Lead Time

Если WIP Rate растёт, а Throughput остаётся прежним или снижается, то Lead Time почти наверняка вырастет в следующем месяце.

Можно сравнить это с автомобильной пробкой: если на дорогу выезжает больше машин (рост WIP), а ширина и скоростной режим остаются прежними (стабильный Throughput), то время в пути (Lead Time) увеличивается. Задачи скапливаются, создавая очереди на разных этапах.

Таким образом, для сохранения предсказуемости сроков критически важно ограничивать количество одновременной работы (WIP), чтобы оно соответствовало реальной пропускной способности системы.

Эффективность потока и причины низкой эффективности

Flow efficiency отвечает на вопрос: «Сколько времени задача реально работала, а сколько — просто ждала?» Это помогает понять, где теряется энергия команды: в блокировках, ожидании проверки кода или тестирования. Чем выше эффективность потока, тем быстрее и предсказуемее результат.

Подходы для анализа низкой эффективности:

WIP Rate показывает, какие типы рабочих элементов были в этом месяце, их долю в техдолге, доработках и фичах.
Анализируем Throughput и список закрытых задач, выявляем блокировки, их причины и длительность.
Буферное время и блокировки можно детализировать по сырым данным в BI-системе или выгрузить в Excel.

Практика применения

Все примеры взяты из практики.

Первый пример. Снижение Lead Time и увеличение пропускной способности не всегда говорит об ускорении разработки 🙂

На графиках видно, что улучшение произошло за счёт уменьшения LT по закрытию багов и общего снижения количества багов за месяц по отношению к фичам. Первый график показывает ускорение Leadtime: в динамике было 10, стало 8.

Второй график показывает пропускную способность и соотношение типов рабочих элементов:

А здесь мы видим, за счёт какого типа ускорился LeadTime:

Второй пример. Flow efficiency показала резкое падение из-за очереди на проверку кода. Решением стало введение WIP-лимитов на проверку и кросс-проверки в команде разработки. Этот пример показывает, что метрики могут сигнализировать о конкретных узких местах в процессе, а не просто демонстрировать общую эффективность.

Вывод: одна метрика без контекста мало что говори�� о реальной работе команды.

Низкий Lead Time может быть достигнут ценой качества.
Высокий Throughput не всегда отражает положительный результат.
Flow efficiency может быть высокой, но если команда работает только над багами, то ценность для бизнеса будет низкой.

Работа с «толстыми хвостами»

Толстые хвосты — далекие от среднего. Они встречаются чаще, чем ожидалось бы при нормальном распределении, что делает систему менее предсказуемой и требует особого подхода к планированию. На графике распределения они выглядят как длинная «полка», или хвост вправо.

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

Что делаем:

Измеряем WIP Age и проводим аудит долгоживущих задач.
Анализируем Control Chart и Lead Time Distribution, чтобы найти аномально длительные работы.

Критерий стабильности: если (98-й перцентиль Lead Time) / (50-й перцентиль Lead Time) > 3,14, то система нестабильна и требует внимания.

Предсказуемость через распределение Lead Time

Полезная идея Павла Ахметчанова: смотреть на компактность распределения Lead Time как на индикатор предсказуемости.

50-й перцентиль (медиана) — «оптимистичный» срок выполнения задачи.
98-й перцентиль — «пессимистичный» срок, при котором почти гарантированно (в 98 % случаев) задача завершится.

Если соотношение 98 %/50 % близко к 1, то система работает предсказуемо. Если оно велико, то есть «толстые хвосты» и высокие риски срыва сроков.

В классических моделях предсказуемость оценивается через константу 5,6, полученную из распределения Вэйбулла. Но для ИТ-практики удобно использовать более понятный ориентир — π (3,14). Почему? Потому что многие команды и так «умножали сроки на 3» для подстраховки. Поэтому использование числа, близкого к 3, как критерия предсказуемости, оказалось практичным решением.

Подсказка: если 98 %/50 % ≤ π, то систему можно считать предсказуемой.

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

Метрики помогают не только анализировать прошлое, но и планировать будущее. Для этого используются Lead Time и Throughput в разных разрезах (по платформам и типам задач). Перцентили Lead Time помогают определять сроки коммитов, а Throughput показывает прогнозируемый объём задач в релизах.

Подход к анализу:

для оперативной корректировки — данные за три месяца;
для стратегического прогноза — данные за шесть месяцев.

Разрезы обязательны по платформам (iOS, Android, Web, Backend) и по типам задач (фичи, баги, улучшения).

Ключевые метрики:

Lead Time — медиана в динамике за последние три месяца (с шагом анализа в две недели, фильтр по типам задач);
Throughput — в разрезе типов задач для прогноза объёма.

Практическое применение:

Для сроков коммита используем перцентили Lead Time (обычно 50 % и 85 %).
Для прогноза объёма релиза берём средний Throughput за выбранный период (например, три месяца в разрезе двух недель).

Насколько часто измерять метрики

Частота измерений зависит от объёма данных: чем больше задач проходит через систему, тем устойчивее статистика. Если данных мало, то важно подбирать правильный период анализа и не делать поспешных выводов.

1. Зависимость от объёма данных

Если за неделю < 11 точек, то метрика неустойчива.
85-й перцентиль требует минимум 11 значений для статистической устойчивости.
Определяем период, за который накапливается ≥ 11 точек, и используем его как минимальный для анализа. Обычно это совпадает с регулярным релизом.

2. Подход при малом объёме данных

Если 5–10 точек, то мы избегаем жёстких выводов и ищем выбросы.
Сосредоточены на аномалиях и качестве процессов, а не на средних значениях.
Инструменты: гистограмма, контрольная карта (Control Chart).

3. Минимальный объём данных для анализа

Показатель	Минимум значений	Граница надёжности	Применение
Медиана	5	≥10	Оценка текущих процессов, выявление выбросов.
85-й перцентиль	11	≥20–30	Анализ крайних значений и целевых сроков.
Корректный прогноз	30+	50+	Прогнозирование времени выполнения и планирование релизов.

Работа с малым количеством данных и шумами

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

≥ 11 измерений — уже можно построить математическую модель для интерпретации.
≈ 30 измерений — модель устойчива, ошибки минимальны, форма кривой предсказуема.
< 11 измерений + редкие значения → применяем усечённую медиану:
- убираем по 5–10 % крайних значений;
- пересчитываем медиану на очищенных данных.

Пример усечённой медианы: выборка Lead Time: 1, 2, 2, 3, 4, 5, 6, 7, 20, 25. Убираем 1 и 25 → медиана = 4,5. Без очистки медиана = 4,5, но выбросы искажают распределение.

Итог

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

Начинать стоит с простого: Lead Time, Cycle Time и пропускная способность. Эти базовые метрики уже дают много информации и позволяют увидеть закономерности. Но помните — это, в основном, «ретроспектива». Они показывают то, что уже случилось.

Более интересная метрика — T2M (time-to-market). Но тут всё сложнее: очень часто реальный upstream-процесс даже не зафиксирован в системе, и тогда статистика может вводить в заблуждение.

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

Полезные ссылки

Летим или падаем? Метрики как приборная панель команд