В управлении проектами есть два вопроса, которые пугают менеджеров больше всего: «Когда это будет готово?» и «Почему так долго?». Чтобы отвечать на них не наугад, а с цифрами в руках, нужно понимать разницу между ожиданием и работой.
Cycle Time — это метрика, которая показывает чистую производительность вашей команды. Если Lead Time измеряет путь задачи от идеи до клиента (включая лежание в бэклоге), то Cycle Time включается только тогда, когда разработчик фактически взял задачу в работу. Это спидометр вашего процесса разработки.
В чем суть: Разница между Lead Time и Cycle Time
Путаница между этими понятиями — главная причина сорванных дедлайнов. Давайте разберем на простом примере кофейни.
- Lead Time (Время выполнения заказа): Вы оплатили кофе на кассе в 08:00. Получили стаканчик в 08:10. Ваш Lead Time — 10 минут. Вам как клиенту важно именно это время.
- Cycle Time (Время производства): Бариста увидел ваш чек, болтал с коллегой, протирал стол и только в 08:08 начал готовить кофе. Закончил в 08:10. Cycle Time — 2 минуты. Это показатель эффективности самого бариста.
Для команды разработки Cycle Time начинается в момент перетаскивания задачи в колонку В работе и заканчивается в момент перехода в Готово.
Сравнение метрик
| Характеристика | Cycle Time | Lead Time |
| Точка старта | Когда команда начала работу (In Progress) | Когда заказчик создал запрос (Backlog) |
| Точка финиша | Задача готова (Done) | Задача готова (Done) |
| Что показывает | Техническую скорость команды | Скорость сервиса для клиента |
| Что влияет | WIP, сложность задачи, блокеры | Очередь в бэклоге, приоритеты |
Почему среднее значение врет
Главная ошибка новичков, считать средний Cycle Time. Например: одну задачу мы сделали за 1 день, а вторую мучили 19 дней. Среднее время — 10 дней. Но если вы пообещаете заказчику сделать следующую задачу за 10 дней, вы почти наверняка ошибетесь.
Профессионалы используют процентили.
Вместо среднего значения мы смотрим на 85-й процентиль. Это число говорит нам: «85% наших задач мы закрываем за X дней или быстрее». Это называется Service Level Expectation (SLE).
Если ваш 85-й процентиль равен 7 дням, вы можете с уверенностью сказать бизнесу: «Мы сделаем эту фичу за неделю». И в 85 случаях из 100 вы будете правы.
Как уменьшить Cycle Time
Если ваша скорость вас не устраивает, не нужно заставлять людей печатать быстрее. Проблема почти всегда в процессе.
1. Ограничьте WIP (Work In Progress)
Это закон Литтла: чем больше задач одновременно находится в работе, тем медленнее делается каждая из них. Заставьте команду доделывать начатое, прежде чем брать новое, и Cycle Time упадет автоматически.
2. Уменьшите размер задач
Огромные задачи (слоны) застревают в трубе разработки. Дробите истории так, чтобы каждая из них могла пройти через процесс за 2–3 дня.
3. Борьба с блокерами
Если задача висит в статусе «В работе», но никто ей не занимается, потому что «ждем доступы», Cycle Time продолжает тикать. Скрам-мастер должен атаковать такие простои немедленно.
Резюме: Предсказуемость важнее скорости
Многие думают, что цель измерения Cycle Time — заставить команду работать быстрее. Это миф. Главная цель сделать команду предсказуемой.
Бизнесу не так важно, сделаете вы задачу за 3 дня или за 5. Бизнесу важно знать, что если вы пообещали 5 дней, то это будут именно 5 дней, а не 15. Стабильный Cycle Time — это признак зрелой, профессиональной команды, которой можно доверять сложные проекты.
Часто задаваемые вопросы (FAQ)
Лучшая практика — считать календарные дни, включая выходные. Клиенту все равно, был у вас выходной или праздник, он ждет результат. Кроме того, это стимулирует не оставлять задачи почти готовыми на пятницу, а закрывать их до выходных.
Нет. С точки зрения процесса и клиента время продолжает идти. Если вы будете останавливать таймер на время блокеров, вы получите красивые, но бесполезные цифры. Вам нужно видеть реальную боль, чтобы иметь мотивацию её устранить.
Velocity показывает объем работы (сколько стори поинтов мы сожгли). Cycle Time показывает скорость потока (как быстро одна задача пролетает сквозь доску). Можно иметь высокую Velocity, но ужасный Cycle Time, если вы закрываете много мелких задач, а важные крупные висят месяцами.
Да. Cycle Time охватывает весь процесс производства. Если задача написана за час, но ждет ревью три дня — ваш процесс медленный, и метрика должна это показать.
Тот, который стабилен. Если в одном спринте задачи делаются за 2 дня, а в другом за 12 — у вас проблема. Стремитесь к тому, чтобы разброс значений сужался.