Что такое Lead Time: простое объяснение с примерами
📝 Lead Time (с англ. «время выполнения») — это период от момента, когда команда коммитится (берёт обязательство) выполнить задачу, до её полного завершения.
Представь, что заказываешь пиццу. Как только нажимаешь кнопку «Оформить заказ» — запускается таймер. Курьер звонит в дверь — таймер останавливается. Это и есть Lead Time: от старта до финиша.
А теперь пример из рабочей жизни. В разработке ПО Lead Time отсчитывается
с момента, когда задача на Канбан-доске попадает в колонку В работе,
и заканчивается, когда задача оказывается в Готово и результаты уже можно отправлять пользователям или заказчику.
Lead Time помогает оценить скорость команды с точки зрения бизнеса
и понять, сколько на самом деле занимает полный цикл работы. Чем короче Lead Time — тем быстрее и гибче команда реагирует на изменения.
☝️ Важно
Отсчёт Lead Time начинается не в момент появления задачи в бэклоге, а когда команда закоммитилась её выполнить — то есть приняла обязательство взять в работу. Чаще всего это происходит после оценки задач, их приоритизации и уточнения требований.
Что такое Cycle Time: о том, что происходит внутри команды
📝 Cycle Time (с англ. «время цикла») — это время, которое сотрудники тратят на выполнение задачи. То есть с момента начала активной работы до полного завершения.
Вернёмся к вкусному примеру. Мы уже говорили, что Lead Time — это всё время
от момента, когда оператор принял заказ, до звонка курьера в дверь. Но есть ещё Cycle Time — он про другое.
Cycle Time — только то время, когда задача действительно в работе. То есть когда пицца не просто ждёт своей очереди, а активно готовится. Как это выглядит на кухне:
🧑🍳 Повар берёт тесто → 🍅 добавляет начинку → 🍕 собирает пиццу и отправляет её
в печь → 📦 потом в коробку → 🛵 передаёт курьеру → 🌪️ курьер мчится к клиенту.
А если заказ уже принят, но лежит в очереди из-за загруженности поваров — это входит в Lead Time, но не входит в Cycle Time, потому что работа ещё не началась.
Зачем оценивать Cycle Time? Чтобы понять, где тормозит процесс, оценить нагрузку команды и улучшить процессы.
В чём разница между Lead Time и Cycle Time
На первый взгляд Lead Time и Cycle Time — почти одно и то же. Оба про время, оба про задачи.
Если копнуть глубже, становится понятно: они смотрят на процесс с разных сторон. Один — глазами клиента, другой — глазами команды. Один считает всё с момента запроса, другой — только с начала работы.
Чтобы не путаться, разбираемся, чем они отличаются.
| Lead Time | Cycle Time | |
|---|---|---|
| Что измеряет | Весь период с момента договорённости о выполнении задачи до её завершения | Только время активной работы над задачей |
| Начало отсчёта | Когда команда получила запрос и взяла обязательство выполнить его | Когда команда начала активно работать над задачей |
| Конечная точка | Задача доставлена пользователю | Работа над задачей завершена |
| Что измеряет | Общую длительность «жизни» задачи | Время активной работы над задачей |
| Что оценивает | Скорость реакции на запросы | Эффективность рабочего процесса |
| Для кого | Для заказчиков, руководителей проектов | Для команды и оптимизации процессов |
| Когда применять | Для планирования будущих проектов и прогнозирования сроков | Чтобы анализировать производительность сотрудников и вовремя решать проблемы |
❗️ Учитывать эти метрики особенно важно, когда кто-то в команде берётся за несколько задач сразу. Время работы будет увеличиваться, потому что сотрудник переключается с одного на другое. Это ещё один камень в огород многозадачности. Лучше сосредоточиться на чём-то одном — тогда время выполнения будет стабильным и предсказуемым.
Теперь покажем, как пользоваться этими метриками.
Как посчитать Lead Time и Cycle Time в своей команде
Это можно делать вручную или в таск-менеджере. По очереди о том и другом.
Вручную
Lead Time. Зафиксируй дату и время, когда задачу переместили в колонку К работе на Канбан-доске. После отметь дату и время завершения работы, когда задача окажется в колонке Готово. Наконец, высчитай разницу в днях или часах между этими датами.
👀 Пример
Работа над задачей «Разработать новую форму регистрации» началась 10 мая в 14:00. Готова она была 15 мая в 18:00. Lead Time равно 5 дням и 4 часам, или 124 часам.
Cycle Time. Зафиксируй дату и время, когда задачу переместили в колонку
В работе на Канбан-доске. Потом отметь дату и время, когда она окажется в колонке Готово. И всё, можно считать разницу в днях или часах.
👀 Пример
Вновь разрабатываем новую форму регистрации. Эту задачу взяли в работу 12 мая в 10:00, а отдали 15 мая в 18:00. Cycle Time равно 3 дням и 8 часам (или 80 часам). Задача ждала, пока за неё возьмутся, 2 дня — с 10 по 12 мая. Эти 2 дня включаются в Lead Time, но не в Cycle Time.
В таск-менеджере
Отслеживать метрики Lead Time и Cycle Time удобнее и эффективнее в таск-менеджере. Например, в WEEEK можно автоматизировать этот процесс, чтобы не тратить времени на расчёты вручную.
Мы уже упоминали колонки К работе, В работе и Готово — это классика метода Канбан, где задачи двигаются по этапам с момента их постановки до полного завершения.
👉 Что такое методология Канбан
В колонке В работе можно настроить WIP-лимиты — это ограничение на количество задач, которые могут одновременно находиться в колонке, или ожидаемую временную нагрузку. Эти показатели будут видны всей команде.
В сервисе Аналитика можно выбрать любого из участников и посмотреть, в каких проектах они задействованы, сколько задач выполнили и за сколько времени
с ними справились.
При необходимости эти отчёты можно экспортировать, чтобы использовать для презентаций и дополнительного анализа.
Как понять, где старт, а где — финиш?
В метрике Lead Time стартом считается момент, когда задача уже прошла оценку и все уточнения и команда взяла её в работу. Финиш — когда задача готова и уже передана заказчику.
👀 Пример
Команда взялась за разработку лендинга для нового продукта. Приняли её 5 марта, а отдали 19 марта. Значит, Lead Time будет равно 14 дням. Этапы работы будут такими:
Ожидание: 3 дня (5–7 марта) → Дизайн: 4 дня (8–11 марта) → Вёрстка: 3 дня (12–14 марта) → Программирование: 2 дня (15–16 марта) → Тестирование: 1 день (17 марта) → Правки: 1 день (18 марта) → Публикация: 1 день (19 марта)
В Cycle Time старт — когда была начата активная работа над задачей, а финиш — когда работа полностью завершена.
👀 Пример
Продолжаем разрабатывать лендинг для продукта. Команда взялась за активную работу 8 марта, а закончили они 19 марта. Значит, Cycle Time равно 11 дням. Этапы работы:
Дизайн: 4 дня (8–11 марта) → Вёрстка: 3 дня (12–14 марта) → Программирование: 2 дня (15–16 марта) → Тестирование: 1 день (17 марта) → Правки: 1 день (18 марта) → Публикация: 1 день (19 марта).
Мы разобрались, что Lead Time составляет 14 дней, а Cycle Time — 11. Значит, задача по разработке лендинга провела в ожидании 3 дня, прежде чем за неё взялась команда. Похоже, где-то проседают процессы.
Почему важно знать время ожидания задачи?
⏱️ Управление приоритетами
Когда известно, сколько времени задача висит в воздухе, проще принять решение, что делать в первую очередь. Это особенно полезно, если задач много, а ресурсы ограничены.
📊 Прозрачность процессов
Если фиксировать время ожидания, видно, какие задачи простаивают, кто их задерживает и где нарушаются сроки. Это основа для улучшения процессов
и распределения ответственности.
⚖️ Баланс нагрузки
В одной команде задачи стоят неделями, а в другой — пролетают за день? Это повод пересмотреть загрузку людей.
🔧 Автоматизация и оптимизация
Если использовать Канбан-доски или WIP-лимиты, время ожидания — один из ключевых показателей, чтобы увидеть, где можно упростить или автоматизировать процессы.
Как сократить Lead Time и Cycle Time: советы из практики
Проводи постоянный обзор процессов и выявляй узкие места
Регулярный анализ Lead Time и Cycle Time помогает выявлять узкие места в работе команды на основе точных данных, а не догадок. Визуализируй эти метрики —
и слабые звенья в процессе станут очевидны для всех.
Так команде будет проще принимать решения о том, что именно стоит улучшить. Это не только ускорит выполнение задач, но и повысит предсказуемость сроков при планировании будущих проектов.
Приоритизируй задачи
В WEEEK в каждой задаче можно настроить приоритет так, чтобы каждый сотрудник в начале рабочего дня сразу понимал, за что браться.
Настрой напоминания о важных событиях
Используй напоминания для повторяющихся задач, чтобы никто ничего не забыл.
Стандартизируй повторяющиеся задачи
В Базе знаний WEEEK можно создавать шаблоны и чек-листы для повторяющихся задач. Сотрудники смогут в любое время свериться с ними, если что-то забыли, без необходимости дёргать коллег с вопросами.
Как внедрить метрики в команду
Подготовили пошаговый план, как помочь команде начать пользоваться Lead Time
и Cycle Time.
1. Расскажи команде, зачем это нужно
Объясни простыми словами: Lead Time показывает, сколько клиент ждёт задачу
с момента запроса, а Cycle Time — сколько времени команда реально тратит
на выполнение. Эти метрики нужны не для контроля сотрудников, а чтобы понять, где затыки и как сделать работу предсказуемее.
2. Определи правила учёта
Договоритесь, какие статусы задач будут стартом и финишем.
Например, Lead Time начинается, когда задача попала в колонку В работе
и заканчивается в Готово. Cycle Time — с момента, как разработчик начал работу
и включил таймер задачи, до окончания работы и таймера.
3. Зафиксируй текущие показатели
Замерь, сколько сейчас в среднем времени уходит на выполнение задач.
Например, ты посмотрел последние 15 задач и понял, что в среднем задача попадает в работу через 2 дня после запроса и команда выполняет её за 5 дней. Значит, средний Lead Time — 7 дней, а Cycle Time — 5. Это и станет точкой отсчёта для дальнейших улучшений.
4. Начни сбор данных
Запускай трекинг по всем задачам — вручную или через таск-менеджер. На этом этапе важно просто собирать статистику без резких изменений.
5. Визуализируй метрики
Показывай команде графики или диаграммы по Lead Time и Cycle Time. Так будет наглядно видно, где задачи застревают и какие этапы требуют внимания, а также изменения в метриках после нововведений.
6. Постепенно оптимизируй процессы
Если видишь, что задачи тормозят на тестировании, — выдели больше ресурсов на тестирование. Если проблемы на код-ревью — внедри парное программирование. Проверяй результат через месяц по метрикам.
7. Сделай это регулярной практикой
Можно проводить командные ретроспективы, где команда будет обсуждать Lead Time и Cycle Time и решать, что можно улучшить дальше. Так метрики станут частью культуры команды.
Отвечаем на популярные вопросы
Эти метрики подходят только для IT?
Нет. Lead Time и Cycle Time можно применять в любой команде и сфере — маркетинге, дизайне, продажах. В общем, везде, где есть поток задач и важно контролировать сроки.
Можно ли считать Lead Time и Cycle Time вручную?
Можно! Достаточно фиксировать даты начала и конца задачи в Excel или Google Таблице. Но удобнее использовать таск-менеджеры с автоматическим трекингом, например, WEEEK или Jira.
Как часто нужно анализировать метрики?
Лучше всего — раз в спринт или раз в месяц. Так будет проще замечать тренды
и оперативно улучшать процессы.
Что делать, если метрики не улучшаются?
Провести ретроспективу с командой, найти узкие места и попробовать другие подходы. Иногда помогает ограничение задач в работе или добавление людей
на перегруженные этапы.
Подписаться 
