Команда гордится тем, что фактическая обработка заказа занимает всего два часа работы — но клиент ждёт результат три недели, потому что заказ две недели лежал в очереди перед тем, как кто-то начал над ним работать. Метрика "время обработки" (processing time) скрывает главное: реальное время ожидания клиента определяется не скоростью работы, а тем, сколько времени задача провела в системе целиком.
Клиента не волнует, сколько именно времени вы работали над его заказом — его волнует, сколько времени он вообще ждал результат.
Происхождение и исследовательская база
Понятие Lead Time происходит из производственного менеджмента и Производственной системы Toyota (Toyota Production System) как одна из ключевых метрик потока — в отличие от времени обработки (touch time, cycle time на отдельной операции), Lead Time измеряет полное время прохождения единицы работы через всю систему от момента запроса до момента доставки результата, включая все периоды ожидания в очередях между этапами.
Ключевые идеи и принципы
Принцип: Lead Time = время ожидания + время обработки
Полное время прохождения задачи через систему складывается из активного времени работы над ней и времени, когда задача просто ждёт своей очереди на каждом этапе — в большинстве реальных процессов время ожидания составляет значительно бóльшую долю Lead Time, чем время активной обработки.
Принцип: Точки отсчёта должны быть явно определены
Lead Time измеряется от чётко зафиксированной точки старта (например, момента поступления заявки клиента) до чётко зафиксированной точки завершения (момента доставки готового результата) — без явного определения этих границ метрика становится несопоставимой между разными измерениями.
Принцип: Lead Time связан с WIP через закон Литтла
В соответствии с законом Литтла, Lead Time прямо пропорционален количеству задач в работе (WIP) при заданной скорости их завершения — снижение WIP является одним из самых надёжных способов сократить Lead Time без изменения скорости работы каждого отдельного исполнителя.
Ограничения, слепые зоны и критика
Lead Time как единственная агрегированная метрика скрывает разброс: среднее значение может быть приемлемым, а отдельные заказы — ждать неприемлемо долго, что критично для клиентского опыта. Показатель также легко исказить, если границы измерения определены нечётко или непоследовательно — сравнение Lead Time между командами, использующими разные точки отсчёта, вводит в заблуждение. Улучшение Lead Time исключительно за счёт сокращения времени ожидания без внимания к качеству результата может привести к росту доли переделок, которые в итоге снова увеличивают полное время до приемлемого результата.
Типовые ошибки
Ошибка 1: Lead Time подменяется временем обработки (touch time).
Команда отчитывается о времени, реально потраченном на работу над задачей, игнорируя время, которое задача провела в ожидании — это создаёт ложное впечатление о скорости обслуживания клиента.
Как избежать: Всегда измерять полное время от заявки до результата, включая все периоды ожидания, а не только активную работу.
Ошибка 2: границы измерения меняются от периода к периоду.
Точка старта или завершения измерения Lead Time определяется по-разному в разные периоды или разными командами, что делает динамику показателя несопоставимой.
Как избежать: Один раз чётко зафиксировать точки отсчёта и завершения и не менять их без явного пересмотра всей методики измерения.
Ошибка 3: время ожидания не декомпозируется по этапам процесса.
Измеряется только суммарный Lead Time целиком, без разбивки на то, сколько времени задача простаивает на каждом конкретном этапе — непонятно, куда направить усилия по сокращению.
Как избежать: измерять время ожидания отдельно на каждом этапе процесса, а не только суммарный Lead Time целиком.
Ошибка 4: Lead Time сокращают за счёт увеличения WIP.
Чтобы «не простаивать», в работу параллельно берут больше задач одновременно — по закону Литтла это лишь маскирует проблему: реальное время выполнения отдельной задачи не уменьшается, а часто растёт.
Как избежать: сокращать Lead Time через снижение WIP и устранение узких мест, а не через наращивание параллельной загрузки.
Ошибка 5: Lead Time сравнивается между принципиально разными типами задач.
Крупная фича и мелкий баг-фикс усредняются в одну общую метрику Lead Time — сравнение и выводы получаются некорректными, потому что у задач изначально разный объём работы.
Как избежать: измерять и сравнивать Lead Time отдельно по классам задач сопоставимого размера и сложности (class of service).
Главное, что нужно знать
Lead Time измеряет полное время прохождения задачи от заявки до результата, включая всё время ожидания, а не только время активной работы. Показатель напрямую связан с количеством задач в работе (WIP) через закон Литтла — сокращение WIP обычно эффективнее для снижения Lead Time, чем попытка ускорить саму работу.
План внедрения
Неделя 1: фиксация границ измерения
Неделя 1: явно зафиксировать точки старта и завершения для измерения Lead Time.
Неделя 2: сбор данных
Неделя 2: наладить систематический сбор данных о полном времени прохождения задач.
Неделя 3: анализ разброса
Неделя 3: проанализировать разброс значений, а не только среднее Lead Time.
Неделя 4: поиск узкого места
Неделя 4: определить, где именно накапливается наибольшее время ожидания в процессе.
Далее: регулярный мониторинг
Далее: регулярно отслеживать Lead Time и связывать его изменения с уровнем WIP.
Как реализовать этот план с помощью фрейма «Расчёт Lead Time (LT)» в OrgDevTools
Фрейм устроен как четыре карточки со свободным списком записей на каждой — Границы измерения, Время ожидания, Время обработки, Действия по сокращению — прямо соответствующие последовательности плана внедрения.
Неделя 1 — карточка «Границы измерения». Первая в сетке — фрейм физически задаёт фиксацию точек старта и завершения как отправную точку, не позволяя начать сбор данных с плавающими границами (защита от ошибки 2).
Карточки «Время ожидания» и «Время обработки». Разделены физически — фрейм не даёт свести Lead Time к одной цифре touch time, требуя явно зафиксировать именно простои между этапами (защита от ошибки 1 и 3).
Неделя 4 — карточка «Действия по сокращению». Отдельная от измерений карточка — требует конкретных шагов по снижению Lead Time без потери качества, не давая спутать сокращение показателя с ростом параллельной загрузки (защита от ошибки 4).