Lead Time метрика в DORA: формула, бенчмарки и отличие от Cycle Time
Примерно 80% инженерных команд, которые я смотрел за последний год, репортят «Lead Time», который DORA не признала бы. Они меряют «от создания тикета до релиза». DORA меряет другое и более узкое: от первого commit'а до production. Разница между этими двумя определениями — обычно 5–10 дней. И это разница между честной метрикой доставки и дашбордом, который льстит не тем людям.
В этом гайде — строгое DORA-определение, формула, чем Lead Time отличается от Cycle Time (это не синонимы), и бенчмарки elite/high/medium/low на 2026 год, по которым можно сравнить свою команду.
{/* truncate */}
Lead Time for Changes — определение DORA
Программа DORA (Forsgren, Humble, Kim — кодифицировано в Accelerate, 2018) определяет Lead Time for Changes так:
Время, которое нужно изменению кода, чтобы пройти путь от первого commit'а на feature-ветке до работы в production.
Всё. Не создание тикета. Не сбор требований. Не одобрение релизного окна. Часы стартуют на первом git commit'е и останавливаются, когда код этого commit'а обслуживает реальный трафик.
Из этого определения следуют две вещи:
- Lead Time — это метрика доставки, а не продуктовая метрика. Она измеряет инженерный throughput, а не время от идеи до пользовательской ценности. Продуктовый аналог («от идеи до результата») иногда называют Concept Lead Time или Time to Market — другая метрика, другая аудитория.
- Включает всё, что происходит с commit'ом после его создания. Очередь на код-ревью, время CI, ручной QA, deploy-gate'ы, батчинг релиз-поезда — всё это считается. Если разработчик закоммитил в понедельник, а в prod ушло в пятницу — ваш Lead Time 4 дня, независимо от того, насколько код был «готов» в понедельник.
В 2023 State of DevOps Report (последний крупный релиз до момента написания) Lead Time — одна из четырёх core DORA-метрик, наряду с Deployment Frequency, Change Failure Rate и MTTR. Все четыре спроектированы для совместного чтения — и к этому противоречию мы вернёмся в конце.
Формула Lead Time
В виде псевдокода:
lead_time(change) = production_deploy_timestamp(change)
- first_commit_timestamp(change)
Для team-level значения агрегируйте по окну (обычно 30 или 90 дней) и отчитывайтесь перцентилем, не средним:
lead_time_p50 = медиана lead_time(c) по c из deployed_changes(last_90d)
lead_time_p75 = 75-й перцентиль (это то, что репортит DORA)
lead_time_p95 = хвост — ловит outlier-PR'ы, которые блокируют релиз
DORA по умолчанию использует p75. Средние обманывают: распределение почти всегда правоскошенное — 80% PR'ов уходят быстро, 20% тянутся, среднее садится в бессмысленную середину.
Несколько тонкостей, на которых команды спотыкаются:
- «Первый commit» — это первый commit на ветке, которая в итоге смерджилась. Squash-merge выбрасывает эту информацию: придётся брать pre-squash историю, иначе вам покажется, что каждое изменение заняло 5 минут.
- «Production deploy» — это реально обслуживающий трафик код. Если вы деплоите в staging или pre-prod и сидите там 2 дня — эти 2 дня часть Lead Time.
- Реверченые изменения тоже считаются. Если commit задеплоился и его откатили, Lead Time меряется до timestamp'а исходного деплоя. Сам откат становится отдельным сигналом (он всплывёт в Change Failure Rate).
Часы DORA идут end-to-end по всем шести стадиям — не только по той, где активно пишется код.
Lead Time vs Cycle Time
Эти два термина используют как синонимы. Не надо. Самый короткий точный ответ: Cycle Time — подмножество Lead Time.
| Параметр | Lead Time (DORA) | Cycle Time (lean / Kanban) |
|---|---|---|
| Старт | Первый commit | Задача официально стартовала (статус → «In Progress») |
| Стоп | Код в production | Задача официально закрыта (статус → «Done» или merge) |
| Что меряет | End-to-end throughput доставки | Активное время работы |
| Включает deploy? | Да | Обычно нет |
| Включает очередь на ревью? | Да | Да |
| Происхождение | DORA / Accelerate | Lean-производство → Kanban |
| Типичный p75 | 1 день – 1 месяц | Часы – дни |
У команды может быть Cycle Time 2 дня и Lead Time 14 дней, если merge-to-deploy управляется недельным релиз-поездом. Cycle Time выглядит здоровым. Lead Time говорит, что клиенты ждут фикса две недели.
Именно поэтому DORA выбрал такое определение — это то, что реально чувствуют клиенты.
Бенчмарки 2026: elite / high / medium / low
Бэнды ниже — из DORA State of DevOps Reports (2019–2023), которые мы в 2026 считаем всё ещё авторитетными в отсутствие нового крупного релиза. Сравните свой p75 с релевантной строкой.
| Уровень | Lead Time (p75) | Как это обычно выглядит |
|---|---|---|
| Elite | Менее 1 часа | Trunk-based development, полный CI/CD, feature flags вместо релиз-веток |
| High | От 1 дня до 1 недели | Feature-ветки с same-day ревью, автоматические деплои, лёгкий ручной QA |
| Medium | От 1 недели до 1 месяца | Очереди PR с задержкой в несколько дней, батчевые релизы, ручные gate'ы |
| Low | Более 1 месяца | Долгоживущие ветки, релизные окна, тяжёлые цепочки ручных согласований |
Несколько честных оговорок к этим бэндам:
- Уровень «Elite» нереалистичен для regulated industries. Fintech, healthcare и govtech-команды часто гоняют жёсткие manual-compliance gate'ы, которые ставят floor в 1–3 дня на любой деплой. Они могут попасть в «High» — не в «Elite» — и это нормально.
- Распределение важнее, чем бэнд. Команда с p50 в 6 часов и p95 в 11 дней имеет проблему хвоста, которую стоит фиксить, а не проблему «среднего».
- Цифры отчёта 2023 года агрегированы по тысячам компаний. Ваша индустрия, возраст кодовой базы и размер команды смещают реалистичный таргет.
Где Lead Time идёт хуже всего (карта боттлнеков)
Когда Lead Time в 12 дней падает на стол CTO, естественный вопрос — куда ушли эти 12 дней. Пять мест, примерно в порядке появления в реальных данных:
1. Очередь на PR-ревью (тихий убийца). По B2B инженерным командам, которые мы смотрели, разрыв между «PR открыт» и «первое ревью» — устойчиво самый крупный единичный кусок Lead Time, часто 2–4 дня. PR готов. Ревьюеры заняты. С кодом ничего не так. Часы просто идут.
2. Merge-конфликты на долгоживущих ветках. Ветка, которая живёт 5 дней, накапливает 5 дней конфликтов. Их разрешение добавляет часы и часто триггерит повторное ревью.
3. Flaky CI. 30-минутный пайплайн, который падает в 20% случаев на flaky-тестах, по факту имеет эффективную длительность ~45–60 минут на merge, а не 30. Умножьте на команду и неделю — и вот вы потеряли дни.
4. Ручные QA-gate'ы. Шаг «QA должна подписать» добавляет 4–48 часов на каждый деплой в зависимости от глубины очереди QA. Для regulated industries это неизбежно; для большинства продуктовых команд — привычка, а не требование.
5. Production deploy-gate'ы. Релизные окна («мы деплоим только во вторник»), change advisory boards, freeze-периоды могут добавлять 1–7 дней. Они существуют по причинам, которые часто не пересматривались с тех пор, как компания была в 10 раз меньше.
Полный разбор по стадиям (Coding / Pickup / Review / Deploy) — в нашем предыдущем разборе Lead Time: декомпозиция на 4 стадии. 4-stage view — диагностический слой поверх headline-числа.
Как сократить Lead Time на 50% (реалистичный плейбук)
Это не теория — это рычаги, которые двигают цифру, по убыванию impact-to-effort.
- Поставить SLA на ревьюера в 4 бизнес-часа. Одно правило: на каждый PR при создании назначается ревьюер, и этот ревьюер обязуется дать первый ответ за 4 бизнес-часа. На наших клиентских данных одно это правило стабильно режет p75 Lead Time на 30–50%.
- Ограничить размер PR 400 строк diff'а. Большие PR дольше ревьюятся и дольше возвращаются к ним после первого круга. Маленькие PR уходят циклами, а не батчами.
- Сделать CI зелёным за 15 минут. Параллелить, кэшировать, убивать flaky-тесты. 45-минутный пайплайн — это 45-минутная заложническая ситуация.
- Заменить релиз-поезда на feature flags. Расцепить деплой (технический событие) и релиз (продуктовое событие). Деплойте непрерывно, релизьте по расписанию. Lead Time падает до того, сколько занимает CI.
- Провести аудит ручных gate'ов. По каждому спросить: какой failure mode это ловит? Сколько раз поймало за последние 12 месяцев? Если ответ «мы не знаем» — кандидат на удаление.
Прямолинейный contrarian-тезис: команды, которые оптимизируют Lead Time без слежения за Change Failure Rate, кончают с быстрыми деплоями плохого кода. 4 DORA-метрики спроектированы для парного чтения — throughput (Deployment Frequency, Lead Time) против стабильности (Change Failure Rate, MTTR). Срежете Lead Time с 10 дней до 1 — и увидите, как CFR ползёт с 8% до 25% — значит, систему вы сделали хуже, не лучше. Этот trade-off мы разбирали в Change Failure Rate: 15% — это нормально?.
Честное ограничение
Lead Time геймится. Самый распространённый способ — делать PR'ы искусственно маленькими. Косметический PR на одну строку имеет Lead Time в час, и если ваша команда начинает ранжироваться по метрике — вы внезапно увидите эпидемию микро-коммитов. Метрика улучшается; доставка — нет.
Поэтому DORA настаивает на чтении Lead Time вместе с Deployment Frequency (объём) и Change Failure Rate (качество). Команда, которая шипит в 5 раз больше изменений с 2× более коротким Lead Time и тем же CFR — реально улучшилась. Команда, которая шипит в 5 раз больше крошечных изменений с тем же общим throughput'ом — загеймила дашборд.
Стоит сказать честно: размер PR и архитектура команды тоже влияют. Команда, которая только что распилила монолит на микросервисы, увидит падение Lead Time почти мгновенно — не потому что стала быстрее, а потому что у каждого сервиса меньше deploy-поверхность. Метрика не врёт. Она просто меряет другую систему.
FAQ
Lead Time это что? Lead Time for Changes — это DORA-метрика, измеряющая интервал от первого commit'а на ветке до момента, когда этот код работает в production. Чистая инженерная метрика throughput.
Lead Time и Cycle Time — одно и то же? Нет. Cycle Time — подмножество Lead Time. Cycle Time стартует, когда задача переходит в «In Progress» (lean / Kanban), Lead Time — с первого commit'а. Lead Time всегда включает merge-to-deploy stretch, Cycle Time — обычно нет.
Какой нормальный lead time? По 2023 State of DevOps Report: Elite — менее часа (p75), High — от 1 дня до 1 недели, Medium — от 1 недели до 1 месяца, Low — больше месяца. Для regulated industries (fintech, healthcare) реалистичный таргет — High, не Elite.
Как измерять lead time без специальных инструментов?
Минимум: Git API (или git log) для timestamp'а первого commit'а на ветке + CI/CD-логи для timestamp'а deploy'а в prod. Рассчитайте deploy_ts - first_commit_ts для каждого merge'нутого PR, агрегируйте за 90 дней, возьмите p75. Это работает для разового аудита. Не масштабируется, потому что edge-кейсы (squash-merge, force-push, reverted PR'ы) ломают наивную формулу.
Что входит в lead time для DORA? Всё, что происходит с commit'ом после его создания: код-ревью, merge, CI, staging, manual QA, deploy в production. Не входит: время на формулирование задачи, оценку, спецификацию и любая работа до первого commit'а — это product-side метрики.
По теме
- DORA Metrics 2026: полный гайд — все четыре метрики в одном месте
- Lead Time: декомпозиция на 4 стадии — диагностика по стадиям Coding / Pickup / Review / Deploy
- Deployment Frequency: с месяца на день — почему частые деплои меняют Lead Time
- Change Failure Rate: 15% — это нормально? — стабильность как контрагент throughput'а
- DORA vs SPACE vs DevEx (2026) — куда Lead Time вписывается в более широкие фреймворки
Одно замечание по реализации. PanDev Metrics считает Lead Time напрямую из вашей Git-истории и событий CI/CD: timestamp первого commit'а на merge'нутой ветке плюс timestamp деплоя из пайплайна. Без ручной разметки тикетов, без поддерживания таблиц, без бухгалтерии по edge-кейсам. Декомпозиция на 4 стадии (Coding / Pickup / Review / Deploy) — автоматически для GitHub, GitLab, Bitbucket и Azure DevOps. Единственное workflow-правило, которое мы просим от клиентов — именовать ветки с task ID (feature/PROJ-324) — нужно, чтобы соединить Git-сторону данных с task-трекером. Всё остальное выводится из commit'ов.