Команда считает срок задачи с момента перехода в «В работе», а заказчик — с момента отправки заявки. В результате одна и та же работа занимает семь дней по внутреннему расчёту и девять дней с точки зрения заказчика. Расхождение появляется не в арифметике, а в разных границах измерения.
Lead time, или полный срок прохождения, показывает время между заранее выбранной точкой входа и готовым результатом. Для ручного измерения нужны одинаковые границы, завершённые сопоставимые задачи и единая шкала времени. Разберём процесс на заявке на обновление страницы курса: запрос поступил 3 сентября, команда начала работу 5 сентября, готовый результат приняли 12 сентября.
Что такое lead time
Lead time — полный прошедший срок между заранее выбранным событием начала и событием готовности результата. В канбан-процессе границами служат, например, поступление запроса и принятие готовой работы.
Единой точки начала для всех процессов нет. Одна команда ведёт отсчёт с момента получения запроса, другая — с создания карточки, третья — с commitment point, или точки принятия обязательства выполнить работу. Ошибка возникает при смене правила между задачами одной выборки.
В нашем примере отсчёт начинается с получения заявки и заканчивается принятием результата:
Lead time = 12 сентября − 3 сентября = 9 календарных дней.
Полный срок включает очередь до старта, выполнение, проверку, согласование и другие периоды ожидания внутри выбранных границ.
Общий контекст помогает разобрать метрики потока, но для ручного расчёта lead time достаточно заранее закрепить начало и конец измерения.
Откуда вести отсчёт
Отсчёт ведут от события, которое команда заранее признала началом измеряемого пути.
Для входящих заявок встречаются три границы:
- запрос поступил от заказчика;
- карточка создана в рабочей системе;
- команда приняла обязательство выполнить работу.
Выбор зависит от вопроса. Срок с момента запроса показывает весь путь результата глазами заказчика. Срок от принятия обязательства исключает часть входящей очереди и отвечает уже на другой вопрос.
В учебном примере точкой входа остаётся 3 сентября — дата получения запроса. Заявка, которая лежит во входящих до начала работы, уже расходует время заказчика. При большом потоке полезно отделить очередь запросов от активной работы, но период ожидания всё равно остаётся внутри полного lead time.
Что считать концом отсчёта
Концом lead time служит событие, после которого результат соответствует согласованному критерию готовности.
Фраза «исполнитель закончил» не всегда обозначает конец процесса. Работа ещё способна находиться на ревью, согласовании или передаче заказчику. Внутреннее завершение исполнителя тогда наступает раньше готовности результата.
Для страницы курса финальной точкой станет 12 сентября — день принятия обновления после проверки.
Команде требуется заранее определить готовый результат. Иначе одна карточка завершится после черновика, другая — после ревью, третья — после публикации, а полученные сроки нельзя будет корректно сравнить.
Чем lead time отличается от cycle time
Lead time охватывает полный срок от выбранной точки входа до готовности, а cycle time, или время цикла, показывает более узкий отрезок после начала работы.
В учебном примере:
- запрос получен 3 сентября;
- работа началась 5 сентября;
- результат принят 12 сентября.
Расчёт выглядит так:
Lead time: 12 − 3 = 9 календарных дней.
Cycle time: 12 − 5 = 7 календарных дней.
Разница в два дня показывает очередь до начала работы. В другом процессе разрыв увеличится при длинном бэклоге или сократится при быстром старте.
Терминология различается между командами и инструментами. Одни процессы считают cycle time с первого активного статуса, другие используют точку принятия обязательства. Сравнение требует сначала уточнить время прохождения через конкретные события, а уже затем сопоставлять значения.
Что входит во время ожидания
В lead time входит всё время между выбранными границами, включая периоды без активной работы.
Например, девять дней заявки распределились так:
- два дня до начала;
- три дня активной работы;
- два дня ожидания ревью;
- один день исправлений;
- один день до окончательной приёмки.
Период ожидания нельзя вычитать только потому, что исполнитель в этот момент не работал над задачей. Результат ещё не готов, поэтому полный срок продолжает идти.
Отдельные состояния на доске помогают показать этапы ожидания и проверить, где карточки регулярно проводят время без движения к готовности.
Почему границы важнее названия
Письменно закреплённые границы делают задачи сопоставимыми независимо от принятой терминологии.
Две команды вправе называть lead time близкие, но не полностью одинаковые интервалы. Прямое сравнение таких цифр без проверки начала и окончания даст ложный вывод.
Внутри одной команды правило тоже должно оставаться постоянным. Первая карточка не должна считаться от входящего письма, вторая — от создания карточки, третья — от начала активной работы.
Правило измерения фиксируют одной строкой:
Lead time считаем в календарных днях от даты получения согласованной заявки до даты принятия готового результата.
Как измерить lead time вручную
Для ручного измерения запишите по каждой завершённой задаче дату входа, дату начала работы и дату готовности, затем рассчитайте разность дат в календарных днях.
Рабочая таблица выглядит так:
Таблица сохраняет события, по которым команда позже сравнит однотипные карточки. Поминутный учёт для такого расчёта не нужен.
В Канбано даты измерения фиксируют вручную в описании карточки или чек-листе, а итоговые значения переносят в отдельную рабочую таблицу. Автоматический расчёт lead time, timestamps переходов, процентили и аналитические отчёты в подтверждённый набор функций не входят.
Какие даты записывать
Для каждой карточки записывайте три события: вход, начало активной работы и готовность.
Дата входа нужна для lead time. Дата начала позволяет дополнительно посчитать cycle time и отделить очередь перед стартом. Дата готовности завершает обе шкалы.
Дополнительную дату стоит вводить только под конкретную гипотезу. Команда, которая подозревает задержку на ревью, отдельно фиксирует момент передачи карточки на проверку.
Большое количество ручных отметок увеличивает стоимость измерения. Первый замер лучше строить вокруг событий, которые помогают проверить предполагаемую задержку.
Как считать календарные дни
Календарные дни считайте как разность двух календарных дат без включения обеих границ одновременно.
Для учебной заявки:
12 сентября − 3 сентября = 9 дней.
Перечисление календарных дат «3, 4, 5 … 12» даст десять дат, но представляет другой принцип подсчёта. Два способа нельзя смешивать внутри одной выборки.
Рабочие дни подходят для отдельной шкалы, но тогда весь набор должен использовать именно рабочие дни. Сравнение одной карточки в календарных днях с другой в рабочих разрушает общую систему измерения.
Как собрать устойчивую выборку
Устойчивую выборку собирают из завершённых задач одного типа с одинаковыми точками входа, готовности и единицей времени.
Одна карточка показывает частный случай, а не поведение потока. Для первого ориентира соберите 15–20 завершённых однотипных задач. Диапазон служит практической отправной точкой, а не универсальным статистическим порогом. При меньшей истории выводы потребуют более осторожной интерпретации.
Разные классы работы разделяют:
- дефекты;
- контентные изменения;
- запросы поддержки;
- крупные проектные задачи.
Дефект на несколько часов и переработка большого раздела имеют разный естественный срок. Общая медиана по такому набору смешает два процесса вместо их описания.
Какие задачи сравнивать
Сравнивайте завершённые задачи, которые проходят близкий рабочий путь и сопоставимы по масштабу.
Для контентной команды в одной выборке останутся небольшие обновления существующих страниц. Создание нового раздела сайта относится к другому типу работы.
Отменённую работу не смешивают с завершённой. Карточку без известной даты входа тоже отделяют, поскольку полный lead time для неё нельзя восстановить по принятому правилу.
Размер выборки указывают рядом с результатом. Медиана по шести задачам и медиана по шестидесяти задачам требуют разной степени уверенности в выводах даже при одинаковом значении.
Как обработать выбросы
Выброс сначала разбирают по причине, а не удаляют из выборки из-за большой длительности.
Долгая карточка могла ждать согласования три недели, попасть на период отсутствия специалиста или оказаться существенно крупнее остальных. Причина определяет дальнейшее решение.
Результат проверяют в двух разрезах:
- со всеми завершёнными карточками;
- без несопоставимого случая с зафиксированной причиной исключения.
Сравнение двух разрезов сохраняет информацию о реальной задержке и показывает, насколько один случай изменяет общую картину.
Как читать результат измерения
Результат измерения читают по медиане, распределению сроков и длинному хвосту, а не по одной средней цифре.
Представим девять значений lead time:
3, 4, 4, 5, 5, 6, 7, 9, 24 дня.
Большинство задач проходит за несколько дней, но одна карточка заняла 24 дня. Среднее значение заметно увеличится из-за этой карточки. Медиана останется равной пяти дням и покажет середину фактического ряда.
Длинный хвост при этом сохраняет отдельный смысл. Значения 9 и 24 дня показывают задержки, которые центральная цифра не объясняет.
Почему медиана полезнее среднего
Медиана слабее среднего реагирует на единичную очень долгую задачу и показывает середину отсортированного набора.
Для ряда из девяти значений серединой становится пятое:
3, 4, 4, 5, 5, 6, 7, 9, 24 → медиана 5 дней.
Среднее тоже содержит полезную информацию и не требует исключения. Команда рассматривает его вместе с распределением, но не использует как единственную характеристику срока.
Большой разрыв между медианой и длинным хвостом даёт отдельный повод разобрать причины редких задержек.
Когда нужны процентили
Процентили нужны после накопления стабильной истории, когда команда хочет описать не только середину, но и верхнюю границу большей части завершённых задач.
P85 читается так: 85% сопоставимых завершённых задач прошли за этот срок или быстрее.
P85 описывает историческое распределение и не гарантирует срок следующей задачи. При смене типа работы или границ измерения значение требуется пересчитать на новой выборке.
SLE, или service level expectation — ожидаемый уровень обслуживания, — формируют на основе стабильной истории и явно указанной вероятности. Смешанный набор из дефектов, контента и крупных проектов для такого ориентира не подходит.
Как найти задержку на канбан-доске
Задержку ищут на повторяющемся участке, где однотипные карточки проводят заметную часть полного срока без движения к готовности.
Для каждой долгой карточки разложите lead time:
очередь до старта → активная работа → ревью → согласование → готовность.
Сравнение нескольких карточек показывает характер задержки. Один долгий этап остаётся частным случаем. Повторяющееся ожидание ревью у большинства задач уже даёт основание проверять сам процесс ревью.
Анализ направлен на механизм задержки, а не на поиск виноватого сотрудника. Причиной оказываются длинная очередь, неполные входящие данные, слишком крупные карточки или большой объём одновременно начатой работы.
Как найти очередь
Очередь находится на этапе, где карточки регулярно ждут следующего действия.
Авторы, например, завершают материалы за два дня, а проверка начинается только через четыре дня. Ускорение написания не затронет основной участок ожидания.
Команда фиксирует количество карточек перед ревью и длительность ожидания. Одновременный рост очереди и lead time даёт основание проверить пропускную способность следующего этапа.
WIP, или объём незавершённой работы, тоже связан с очередью. Большое количество одновременно начатых задач распределяет внимание между карточками и способно увеличить время до завершения.
Как проверить причину
Причину задержки проверяют на нескольких карточках, отделяя повторяющийся механизм от единичного события.
Четыре материала ждали ревью по три-четыре дня — процесс проверки требует отдельного анализа. Одна карточка простояла две недели из-за отсутствия специалиста — единичный случай ещё не подтверждает системное узкое место.
Рабочая гипотеза должна описывать наблюдаемый механизм:
«Основная часть длинного lead time возникает перед ревью: проверяющий получает больше карточек, чем успевает разбирать без очереди».
Следующий шаг — изменить одно правило и сравнить новый поток с исходным.
Как сократить lead time
Lead time сокращают через одно проверяемое изменение процесса и повторный замер на сопоставимых задачах. Само изменение не гарантирует сокращения срока: результат подтверждает следующая выборка.
Перед экспериментом команда фиксирует:
- границы измерения;
- тип работы;
- размер выборки;
- медиану;
- P85 при достаточной истории;
- основной участок ожидания.
Дальше выбирают один механизм. Материалы, например, регулярно ждут ревью. Команда сокращает число одновременно начатых материалов либо меняет порядок передачи работ на проверку.
Следующий набор собирают по тем же правилам и сравнивают с исходным.
Как поставить один эксперимент
Один эксперимент меняет одно правило, связанное с обнаруженной задержкой.
Одновременная перестройка колонок, сокращение WIP, смена ответственного и новый порядок ревью не даст понять, какое изменение повлияло на результат.
Рабочий эксперимент выглядит так:
Гипотеза: ожидание ревью занимает значительную часть полного срока.
Изменение: команда уменьшает число материалов, одновременно находящихся в активной работе.
Проверка: следующий набор однотипных задач сравнивается по медиане lead time и времени ожидания ревью.
Снижение медианы при сохранении длинного хвоста означает, что типичный путь изменился, но редкие задержки требуют отдельного разбора.
Когда повторять замер
Повторный замер проводят после накопления нового сопоставимого набора завершённых задач, прошедших по изменённому правилу.
Сравнение должно сохранять:
- одинаковые точки начала и окончания;
- одну единицу времени;
- тот же тип работы;
- сопоставимый размер задач;
- одинаковый принцип обработки выбросов.
Разница между периодами показывает изменение наблюдаемого потока, но сама по себе не доказывает причину. Внешние изменения — состав команды, объём входящих или недоступность участника — фиксируют рядом с результатом.
Lead time работает не как разовая цифра, а как повторяемый способ проверить путь задачи от заявки до готового результата. Для первого ручного эксперимента достаточно измерить первый поток, записать даты на нескольких карточках и повторить расчёт после одного изменения процесса.