Расчёт Lead Time (LT)

Команда гордится тем, что фактическая обработка заказа занимает всего два часа работы — но клиент ждёт результат три недели, потому что заказ две недели лежал в очереди перед тем, как кто-то начал над ним работать. Метрика "время обработки" (processing time) скрывает главное: реальное время ожидания клиента определяется не скоростью работы, а тем, сколько времени задача провела в системе целиком. Именно эту разницу измеряет Lead Time, а не touch time.

Клиента не волнует, сколько именно времени вы работали над его заказом — его волнует, сколько времени он вообще ждал результат. Часы ожидания и часы работы для него неразличимы.

Самый известный документированный пример радикального сокращения Lead Time именно через управление WIP — подразделение Microsoft XIT Sustained Engineering (техподдержка внутренних приложений компании, инженерная команда в Хайдарабаде, Индия). В 2005 году это подразделение считалось худшим в своём бизнес-юните: очередь запросов превышала допустимый объём более чем в 5 раз, а среднее время обработки одного запроса (Lead Time) составляло около 5,5 месяца. Консультант Дэвид Андерсон внедрил в команде вытягивающую систему (pull system) с ограничением незавершённой работы — без дополнительных ресурсов и без изменения самого процесса разработки (дизайн, кодирование, тестирование остались прежними). За 9 месяцев результат: Lead Time упал с 5–5,5 месяца примерно до двух недель, доля выполненных в срок задач поднялась до 98%, а общая производительность команды выросла на 155% — без единого дополнительного найма, только за счёт изменения того, как работа ставится в очередь и ограничивается по объёму одновременно выполняемых задач.

Происхождение и исследовательская база

Понятие Lead Time происходит из производственного менеджмента и Производственной системы Toyota (Toyota Production System) как одна из ключевых метрик потока — в отличие от времени обработки (touch time, cycle time на отдельной операции), Lead Time измеряет полное время прохождения единицы работы через всю систему от момента запроса до момента доставки результата, включая все периоды ожидания в очередях между этапами. Позже понятие было перенесено из физического производства в управление потоком знаний (knowledge work) — прежде всего усилиями Дэвида Андерсона, адаптировавшего принципы TPS для IT и разработки ПО в методологии Kanban, где Lead Time стал одной из двух центральных метрик потока наравне с Cycle Time.

Ключевые идеи и принципы

1. Принцип: Lead Time = время ожидания + время обработки

   Полное время прохождения задачи через систему складывается из активного времени работы над ней и времени, когда задача просто ждёт своей очереди на каждом этапе — в большинстве реальных процессов время ожидания составляет значительно бóльшую долю Lead Time, чем время активной обработки. В кейсе Microsoft XIT именно эта пропорция была радикально изменена — задачи стали проводить в очереди на порядок меньше времени, а не работать над ними стали быстрее.

2. Принцип: Точки отсчёта должны быть явно определены

   Lead Time измеряется от чётко зафиксированной точки старта (например, момента поступления заявки клиента) до чётко зафиксированной точки завершения (момента доставки готового результата) — без явного определения этих границ метрика становится несопоставимой между разными измерениями. Клиент, отправивший заявку, отсчитывает время именно с момента отправки, а не с момента, когда команда официально «взяла задачу в спринт».

3. Принцип: Lead Time связан с WIP через закон Литтла

   В соответствии с законом Литтла, Lead Time прямо пропорционален количеству задач в работе (WIP) при заданной скорости их завершения — снижение WIP является одним из самых надёжных способов сократить Lead Time без изменения скорости работы каждого отдельного исполнителя.

   Точная атрибуция закона имеет нюанс: соотношение L = λW (WIP равен произведению темпа поступления задач на среднее время их пребывания в системе) первым сформулировал и предложил как гипотезу Филип Морс в 1954 году, не доказав его строго и предложив читателям найти контрпример. Джон Литтл, профессор MIT, в 1961 году опубликовал статью «A Proof for the Queuing Formula: L = λW», строго доказав, что соотношение справедливо для любой стабильной системы массового обслуживания независимо от распределения времени поступления или обработки задач, — с этого момента соотношение и получило имя закона Литтла.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: Lead Time подменяется временем обработки (touch time).

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

   Как избежать

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

2. Ошибка 2: границы измерения меняются от периода к периоду.

   Точка старта или завершения измерения Lead Time определяется по-разному в разные периоды или разными командами, что делает динамику показателя несопоставимой. Формально «улучшившийся» показатель может означать не реальное ускорение процесса, а просто изменение методики его расчёта.

   Как избежать

   Один раз чётко зафиксировать точки отсчёта и завершения и не менять их без явного пересмотра всей методики измерения.

3. Ошибка 3: время ожидания не декомпозируется по этапам процесса.

   Измеряется только суммарный Lead Time целиком, без разбивки на то, сколько времени задача простаивает на каждом конкретном этапе — непонятно, куда направить усилия по сокращению. В кейсе Microsoft XIT именно детальная декомпозиция очереди по этапам позволила Андерсону точно определить, где именно накапливается основная задержка, прежде чем вводить ограничение WIP.

   Как избежать

   измерять время ожидания отдельно на каждом этапе процесса, а не только суммарный Lead Time целиком.

4. Ошибка 4: Lead Time сокращают за счёт увеличения WIP.

   Чтобы «не простаивать», в работу параллельно берут больше задач одновременно — по закону Литтла это лишь маскирует проблему: реальное время выполнения отдельной задачи не уменьшается, а часто растёт.

   Как избежать

   сокращать Lead Time через снижение WIP и устранение узких мест, а не через наращивание параллельной загрузки.

5. Ошибка 5: Lead Time сравнивается между принципиально разными типами задач.

   Крупная фича и мелкий баг-фикс усредняются в одну общую метрику Lead Time — сравнение и выводы получаются некорректными, потому что у задач изначально разный объём работы. Средний Lead Time по такой смешанной выборке не описывает реалистичного ожидания ни для одного из двух классов задач в отдельности.

   Как избежать

   измерять и сравнивать Lead Time отдельно по классам задач сопоставимого размера и сложности (class of service).

6. Ошибка 6: сокращение Lead Time воспринимается как требующее новых ресурсов или изменения самого процесса работы.

   Как показал кейс Microsoft XIT, драматическое сокращение Lead Time (с 5–5,5 месяца примерно до двух недель) было достигнуто БЕЗ дополнительных сотрудников и без изменения того, как именно инженеры проектируют, пишут и тестируют код — единственным рычагом было изменение способа постановки работы в очередь и явное ограничение объёма одновременно выполняемых задач.

   Как избежать

   перед тем как запрашивать дополнительные ресурсы для сокращения Lead Time, сначала проверить, не является ли реальной причиной задержек избыточный WIP и отсутствие явного ограничения на количество одновременно выполняемых задач — этот рычаг часто даёт кратный эффект без единого нового найма.

План внедрения

1. Неделя 1: фиксация границ измерения

   явно зафиксировать точки старта и завершения для измерения Lead Time — точка старта должна совпадать с реальным моментом обращения клиента, а не с моментом, когда команда официально начала работу (см. Ошибку 2).

2. Неделя 2: сбор данных

   наладить систематический сбор данных о полном времени прохождения задач, включая моменты фактической постановки в очередь, а не только моменты начала и завершения активной работы (см. Ошибку 1).

3. Неделя 3: анализ разброса

   проанализировать разброс значений, а не только среднее Lead Time, и по возможности разбить задачи по классам сопоставимой сложности (class of service, см. Ошибку 5) прежде чем сравнивать показатели между собой.

4. Неделя 4: поиск узкого места

   определить, где именно накапливается наибольшее время ожидания в процессе, и в первую очередь проверить уровень WIP на этом участке — по образцу кейса Microsoft XIT, ограничение WIP часто даёт больший эффект, чем найм дополнительных людей (см. Ошибку 6).

5. Далее: регулярный мониторинг

   Далее: регулярно отслеживать Lead Time и связывать его изменения с уровнем WIP, ориентируясь на реальный результат Microsoft XIT как ориентир масштаба возможного улучшения, а не как гарантированную норму для любой команды.

Как реализовать этот план с помощью фрейма «Расчёт Lead Time (LT)» в OrgDevTools

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

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

Книги по теме

Андерсон Д. — «Kanban: Successful Evolutionary Change for Your Technology Business» (2010). Практическое измерение и управление Lead Time в потоковых системах.

Little J.D.C. — «A Proof for the Queuing Formula: L = λW» (Operations Research, 1961). Строгое доказательство закона, связывающего WIP и Lead Time, изначально предложенного как гипотеза Филипом Морсом в 1954 году.