Lead Time и Cycle Time: чем отличаются метрики и как улучшить поток задач

Lead Time показывает, сколько проходит от принятия командой обязательства выполнить задачу до готового результата. Cycle Time охватывает более узкий участок — период активной работы. Разница между ними раскрывает время ожидания: сколько задача уже находится в рабочем потоке, но фактически ещё не выполняется. Для отдельного разбора доли работы и ожидания пригодится эффективность потока в Канбане. Чтобы увидеть, где ожидание накапливается в масштабе всей команды, используйте накопительную диаграмму потока.

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

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

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

Cycle Time, или время цикла, начинается в момент фактического старта работы и завершается вместе с задачей. В примере с пиццей это время, когда заказ уже готовят: повар берёт тесто, добавляет начинку, выпекает и упаковывает заказ. Ожидание своей очереди до начала приготовления сюда не относится.

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

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

Метрики нельзя смешивать, иначе вывод будет ошибочным. Короткий Cycle Time не означает, что клиент получил результат быстро: задача могла долго лежать в очереди. И наоборот, рост Cycle Time может быть связан не с низкой продуктивностью, а с более сложным типом задач. Сравнивать стоит похожие работы и одинаковые правила учёта.

Для Lead Time зафиксируйте дату и время принятия обязательства, затем дату и время готовности. Разница между отметками и будет значением метрики. Если работу над формой регистрации приняли 10 мая в 14:00, а завершили 15 мая в 18:00, Lead Time составит 5 дней 4 часа, то есть 124 часа.

Для Cycle Time понадобятся момент начала активной работы и тот же финиш. Если форму начали делать 12 мая в 10:00 и закончили 15 мая в 18:00, время цикла равно 3 дням 8 часам, или 80 часам. Два дня между принятием задачи и началом работы входят в Lead Time, но не в Cycle Time.

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

Допустим, лендинг приняли 5 марта и отдали 19 марта. В ожидании задача провела 3 дня, дизайн занял 4 дня, вёрстка — 3, программирование — 2, тестирование — 1, правки — 1, публикация — ещё 1 день. Lead Time равен 14 дням. Активная работа началась 8 марта, поэтому Cycle Time составил 11 дней, а разница в 3 дня указывает на очередь перед стартом.

На канбан-доске удобно связать контрольные отметки со статусами. Колонки «К работе», «В работе» и «Готово» показывают движение задачи, а история перемещений сохраняет моменты переходов. В NUBL можно организовать такой поток, назначать исполнителей и сроки, а также видеть нагрузку команды.

WIP-лимиты ограничивают количество одновременных задач в работе. Когда колонка заполнена, команда не набирает новые карточки, а помогает завершить начатые. Это снижает многозадачность и делает задержки заметнее. Анализировать метрики полезно по группе похожих задач, а не по одному удачному или неудачному случаю.

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

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

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

Ожидание часто возникает на повторяющихся согласованиях, ручной передаче данных или ненужных переключениях. Карта потока, история карточек и WIP-лимиты подсказывают, где упростить правило, убрать лишний этап или автоматизировать рутинное действие.

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

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

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

Например, по последним 15 задачам команда увидела, что карточка в среднем ждёт старта 2 дня, а выполняется 5 дней. Базовый Lead Time равен 7 дням, Cycle Time — 5. После изменения правила приоритетов можно сравнить следующую выборку с этой точкой, не ожидая, что единичная задача докажет успех.

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

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

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

Подходящий ритм — раз в спринт или раз в месяц. Период должен давать достаточно завершённых задач для сравнения и при этом позволять вовремя замечать ухудшение.

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