Всем привет
перехожу к следующей метрике.
Кстати, в эпоху ИИ метрики уже есть новые, как разберусь в них получше, тоже опишу, а пока продолжаем по известным и хорошо опробованным
Lead time и Lead time distribution
Время от создания тикета до его завершения. От cycle time отличается тем, что включает время ожидания в беклоге.
График распределения показывает категории сколько тикетов в какой отрезок попадает (см скриншот)
Что мы видим на скрине:
- половина тикетов делается за 20 дней,
- 85% тикетов делается за 43 дня
- 95% тикетов делается аж за 67 дней
Как это интерпретировать, то есть что это может значить.
Опять предостерегу от быстрых выводов по одной метрике - это слишком мало информации чтобы делать выводы, это всего лишь указатель куда посмотреть поглубже
Само по себе такое время - это очень долго, а в текущих реалиях непростительно долго. Это признак нестабильного деливери процесса. Здесь прямо сильно обязательно разбираться глубже в чем может быть проблема.
Потенциальные проблемы исходя из такого графика (одна или несколько сразу):
- команда не успевает брать задачи в работу, не хватает капасити
- новых тикетов появляется больше, чем выполняется, некоторые тикеты ждут своей очереди очень долго (системная проблема)
- нет SLA (то есть какого то лимита на ожидание)
- есть маленькие тикеты, закрываются быстрее, в первую неделю и есть тикеты побольше, которые ждут дольше, чтобы их взяли в работу
- Тикеты закрываются пачками к концу спринта или релиза независимо от того, когда реально закончена работа — отсюда пик около 12-18 дней и провалы между корзинами.
- Смешение разных типов задач в одной метрике (баги vs фичи vs технический долг). У них разная естественная длительность, и сложенные вместе они дают бимодальное распределение.
- Хвост — это тикеты, заблокированные внешними зависимостями (ответ клиента, доступ, стороннее API), низкоприоритетные задачи, которые постоянно отодвигают, или тикеты с расползающимся скоупом без переоценки.
- Отсутствие WIP-лимитов — если в работе одновременно слишком много тикетов, они физически не могут двигаться быстро, отсюда растянутый хвост.
Что делать дальше:
- Разбить lead time по типу тикета (баг/фича/техдолг) — вероятно, увидите два четких распределения вместо одного смешанного
- Разбить lead time на wait time (до старта) и cycle time (от старта до завершения)
- Посмотреть отдельно на тикеты из хвоста (48+ дней) — обычно там небольшая группа с общей причиной (один блокер, одна команда, один клиент)
Отдельно стоит упомянуть что если новых тикетов появляется больше, чем завершается, то график распределения не будет отражать реальность, получится что тикеты стоят в очереди почти столько же времени, сколько работаются.
Тут стоит посмотреть график возраста тасок в беклоге и кумулятивную диаграмму потока.
ну и график в динамике - он будет растягиваться все больше со временем.
Растягивающийся хвост как на графике в скрине - как раз симптом такой проблемы.
По закону Литтла: Lead Time = WIP / Throughput. Если входящий поток (arrival rate) стабильно превышает throughput команды, WIP растёт без остановки. А раз WIP растёт, растёт и lead time — причём не линейно, а ускоряясь, потому что каждый новый тикет попадает в очередь, которая уже длиннее, чем была у предыдущего.
В заключение - lead time метрика не является основой для каких либо выводов, но помогает как дополнительная информация в наборе метрик, чтобы сделать верные выводы.
Всем отличной недели!
8July 17, 2026 177 1
