Как измерять Lead Time for Changes: 4-стадийная декомпозиция, выявляющая реальные узкие места

Исследование Stripe «Developer Coefficient» (2018) оценило, что $300 миллиардов ежегодно теряется глобально из-за неэффективности разработчиков. Значительная доля этих потерь скрыта внутри одной метрики: Lead Time. Lead Time в 5 дней не говорит вам ничего. Это 4 дня кодинга и 1 день ревью? Или 1 день кодинга и 4 дня ожидания, пока кто-то откроет ваш merge request? Решение для каждого сценария совершенно разное — и если вы воспринимаете Lead Time как одно число, вы решаете не ту проблему.

{/* truncate */}

Почему одно число Lead Time бесполезно

Исследовательская программа DORA определяет Lead Time for Changes как время от первого коммита до запуска кода в продакшене. State of DevOps Report 2023 устанавливает бенчмарки:

Уровень производительности	Lead Time
Elite	Менее 1 часа
High	От 1 дня до 1 недели
Medium	От 1 недели до 1 месяца
Low	Более 1 месяца

Эти бенчмарки полезны для позиционирования команды на отраслевой кривой. Они бесполезны для понимания того, что именно исправлять. Если ваш Lead Time — 12 дней, агрегированное число не подскажет, стоит ли инвестировать в автоматизацию CI/CD, процессы код-ревью или инструменты для разработчиков.

Нужна декомпозиция.

4 стадии Lead Time

В PanDev Metrics мы разбиваем Lead Time на четыре последовательные стадии. Каждая стадия — это отдельная фаза с отдельными ответственными, отдельными причинами задержек и отдельными способами решения.

Стадия 1: Coding Time

Определение: От первого коммита в ветке до момента создания merge request (или pull request).

Что отражает: Время, которое разработчик тратит на написание кода, локальное тестирование и подготовку изменения к ревью. Включает время в IDE, локальную отладку и написание тестов.

Здоровый диапазон: 1–3 дня для типичной фичи. Всё, что больше 5 дней, часто сигнализирует о расползании скоупа, нечётких требованиях или разработчике, застрявшем без помощи.

Частые антипаттерны:

• Разработчики собирают несколько несвязанных изменений в один MR, потому что процесс ревью — мучение
• Нет лимитов на work-in-progress, разработчики переключаются между 3–4 фичами
• Требования размытые, что ведёт к переделкам ещё до открытия MR

Что исправить:

• Разбивайте работу на меньшие задачи (стремитесь к MR менее 400 строк diff)
• Отслеживайте активность IDE через heartbeat-данные, чтобы отличить «активно кодирует» от «ветка простаивает»
• Дополняйте нечёткие задачи коротким дизайн-ревью перед началом кодинга

Стадия 2: Pickup Time

Определение: От момента создания merge request до первого значимого ревью-действия (комментарий, апрув или запрос изменений).

Что отражает: Сколько код лежит в ожидании начала ревью. Это чистое время ожидания в очереди — никакой ценности не создаётся.

Здоровый диапазон: Менее 4 часов в рабочее время. Более 24 часов — тревожный сигнал.

Почему эта стадия важнее всего: Наши данные по B2B-инженерным командам стабильно показывают Pickup Time как скрытое узкое место номер один — паттерн, который отражает выводы отчётов GitHub Octoverse, где время ожидания pull request'ов является ведущим индикатором трения в доставке. Команды часто считают, что проблема в медленных ревью. На деле само ревью занимает 30 минут — но MR пролежал в очереди 2 дня, прежде чем кто-то его открыл.

Частые антипаттерны:

• Нет чёткого назначения ревьюера — MR висят в общей очереди, которую все игнорируют
• Ревьюеры перегружены (у каждого 8+ открытых MR)
• Команды работают в разных часовых поясах без учёта передачи ревью
• Уведомления об MR тонут в шуме Slack

Что исправить:

• Назначайте ревьюеров явно при создании MR (используйте CODEOWNERS или round-robin)
• Установите командное SLA: «Каждый MR получает первый ревью в течение 4 рабочих часов»
• Создайте выделенный канал или дашборд для ревью — не Slack-тред
• Отслеживайте Pickup Time как командную метрику, а не индивидуальную

Стадия 3: Review Time

Определение: От первого ревью-действия до момента, когда merge request одобрен и готов к мёрджу.

Что отражает: Обмен замечаниями в код-ревью — комментарии, обсуждения, запросы изменений, дополнительные коммиты.

Здоровый диапазон: 4–24 часа для большинства изменений. Многодневные ревью обычно сигнализируют о крупных MR или архитектурных разногласиях, которые следовало решить раньше.

Частые антипаттерны:

• Большие MR (1000+ строк), требующие нескольких раундов ревью
• «Gatekeeping апрува» — только один сеньор может апрувить, а он весь день на митингах
• Придирки к стилю, которые должны ловиться автоматическими линтерами
• Пинг-понг ревью: ревьюер запрашивает изменения → разработчик пушит фикс через 2 дня → ревьюер ре-ревьюит ещё через день

Что исправить:

• Введите лимиты на размер MR (оптимальная пропускная способность у большинства команд — 200–400 строк)
• Автоматизируйте проверки стиля и форматирования (линтеры, форматтеры в CI)
• Расширьте пул ревьюеров — вложитесь в обучение мидлов ревью
• Установите ожидания по срокам повторного ревью (в тот же день)

Стадия 4: Deploy Time

Определение: От апрува merge request до запуска кода в продакшене.

Что отражает: Выполнение CI/CD-пайплайна, валидация на стейджинге, ручные гейты апрува и собственно процесс деплоя.

Здоровый диапазон: Менее 1 часа для Elite-команд. Менее 1 дня для High.

Частые антипаттерны:

• Ручные окна деплоя («мы деплоим по вторникам»)
• Медленные CI-пайплайны (45+ минут), блокирующие очередь мёрджей
• Ручные QA-гейты, требующие подписи конкретного человека
• Заморозки деплоев, накапливающие изменения и увеличивающие risk батча

Что исправить:

• Инвестируйте в скорость CI: параллелизуйте тесты, кэшируйте зависимости, используйте более быстрые раннеры
• Перейдите на continuous deployment с feature flags вместо релизных поездов
• Замените ручные QA-гейты автоматическими smoke-тестами и canary-деплоями
• Отслеживайте длину очереди деплоя — если 10 MR ждут деплоя, это проблема

Бенчмарк: где команды реально теряют время

На основе DORA State of DevOps Reports и отраслевых исследований (согласуется с паттернами, описанными в Accelerate Forsgren, Humble и Kim, 2018), вот как обычно распределяется время для команды с Lead Time в 10 дней:

Стадия	Типичная доля Lead Time	Типичная длительность	Самый мощный рычаг
Coding	30–40%	3–4 дня	Меньшие задачи, чёткие спеки
Pickup	25–35%	2,5–3,5 дня	Назначение ревьюеров, SLA
Review	15–25%	1,5–2,5 дня	Меньшие MR, автоматизация
Deploy	10–15%	1–1,5 дня	Скорость CI/CD, убрать гейты

Ключевой вывод: Pickup и Review вместе поглощают 40–60% Lead Time в большинстве организаций. Это процессные проблемы, а не технические. Они не требуют новой инфраструктуры — они требуют новых привычек.

Как измерять каждую стадию

Вариант 1: Ручной трекинг (не рекомендуется на постоянной основе)

Можно рассчитать стадии из git и вашей платформы хостинга кода:

• Coding Time: Таймстамп первого коммита → таймстамп создания MR
• Pickup Time: Таймстамп создания MR → таймстамп первого комментария/апрува
• Review Time: Первое ревью-действие → таймстамп финального апрува
• Deploy Time: Финальный апрув → таймстамп деплоя (из логов CI/CD)

Это работает для разового аудита. На масштабе ломается, потому что таймстампы живут в разных системах, граничные случаи запутанные (драфт MR, force-push, повторные ревью), и никто не хочет вести таблицу.

Вариант 2: Автоматизированная платформа

Инструменты вроде PanDev Metrics подключаются к вашему Git-провайдеру (GitLab, GitHub, Bitbucket, Azure DevOps) и рассчитывают все четыре стадии автоматически. Преимущество — не только автоматизация, но и консистентность. Каждая команда использует одни определения, одну обработку граничных случаев и одни бенчмарки.

PanDev также коррелирует стадии Lead Time с данными IDE heartbeats. Это значит, что можно отличить «Coding Time, когда разработчик активно пишет код» от «Coding Time, когда ветка простаивает 3 дня, потому что разработчика дёрнули на реагирование по инциденту».

Дашборд команды PanDev Metrics — активность, онлайн-статус и таймлайн событий для корреляции улучшений Lead Time с поведением команды.

Реальный план улучшения

Вот пошаговый подход, работающий для большинства команд с Lead Time более 7 дней:

Неделя 1: Измерение и базовые показатели

• Настройте отслеживание по стадиям для всех MR, смёрдженных за последние 90 дней
• Определите, какая стадия поглощает больше всего времени
• Представьте результаты команде без обвинений — формулировка: «где наш процесс создаёт время ожидания?»

Неделя 2: Исправляем Pickup Time (обычно самый большой выигрыш)

• Внедрите явное назначение ревьюеров
• Установите командное SLA (например, первый ревью в течение 4 рабочих часов)
• Создайте видимость: дашборд «MR, ожидающие ревью» с возрастом

Недели 3–4: Исправляем Review Time

• Введите ограничения на размер MR (менее 400 строк)
• Добавьте линтеры и форматтеры в CI для устранения стилевых замечаний при ревью
• Расширьте пул ревьюеров

Недели 5–6: Исправляем Deploy Time

• Аудит длительности CI-пайплайна — цель менее 15 минут
• Удалите или автоматизируйте ручные гейты апрува
• Двигайтесь к деплою каждого MR независимо

Ожидаемые результаты: Команды, следующие этому плану, обычно сокращают Lead Time на 40–60% за 6 недель — что согласуется с темпами улучшения, наблюдаемыми в исследованиях DORA. Наибольший выигрыш — от Pickup Time: часто удаётся сократить с 3 дней до 4 часов просто за счёт назначения ревьюеров и отслеживания SLA.

А что с Coding Time?

Coding Time — самая сложная стадия для сжатия, потому что она зависит от сложности работы. Однако два вмешательства стабильно помогают:

1. Меньше скоупа на задачу. Если медианный MR — 800 строк, Coding Time отражает большой скоуп. Разбиение задач на более мелкие поставки (200–400 строк) сокращает каждый цикл.

2. Отслеживание активности IDE. Инструменты, фиксирующие heartbeats разработчика (нажатия клавиш, сохранения файлов, триггеры сборки), позволяют отличить «активно кодирует» от «заблокирован». Если ветка разработчика показывает нулевую активность 2 дня в середине кодинга, что-то не так — и это, скорее всего, не лень. Это блокер, переключение контекста или недостающая зависимость.

PanDev Metrics собирает IDE heartbeats из 10+ плагинов (VS Code, JetBrains, Eclipse, Xcode, Visual Studio и других) именно для обеспечения этой видимости — не для слежки, а для выявления системных блокеров.

Типичные ошибки при измерении Lead Time

Ошибка 1: Измерение от создания задачи, а не от первого коммита. Создание задачи отражает время планирования — это метрика продуктового менеджмента, а не доставки. Lead Time по DORA начинается с первого коммита.

Ошибка 2: Исключение выходных и праздников. Для клиентов, ждущих фикса, часы не останавливаются. Измеряйте календарное время. Если выходные искажают цифры, это говорит что-то полезное о вашем процессе деплоя.

Ошибка 3: Измерение только MR с «happy path». Исключите откатившиеся MR или хотфиксы — и потеряете самые информативные точки данных. Измеряйте всё, затем сегментируйте.

Ошибка 4: Среднее вместо перцентилей. Средний Lead Time в 3 дня может скрывать бимодальное распределение: 50% MR мёрджатся за 1 день, 50% — за 5. Используйте p50, p75 и p95 для понимания реального распределения.

Ошибка 5: Трактовка Lead Time как индивидуальной метрики. Lead Time — это командная метрика. Использование её для оценки отдельных разработчиков создаёт стимулы к накрутке (мелкие косметические MR, пропуск тестов, избегание сложной работы).

От измерения к улучшению

Цель измерения Lead Time по стадиям — не создание дашбордов. Это принятие лучших решений о том, куда инвестировать инженерные усилия в улучшение процессов. Когда вы видите, что 35% Lead Time — это Pickup Time, вы перестаёте спорить о переписывании CI-пайплайна и начинаете исправлять назначение ревьюеров.

Измерение без действия — это оверхед. Действие без измерения — это гадание. 4-стадийная декомпозиция даёт вам разрешение для обоих подходов.

---

Бенчмарки из DORA State of DevOps Reports (2019–2023), опубликованных Google Cloud / DORA team.

Хотите увидеть, куда на самом деле уходит ваш Lead Time? PanDev Metrics разбивает Lead Time на стадии Coding, Pickup, Review и Deploy автоматически — для GitLab, GitHub, Bitbucket и Azure DevOps. Начните измерять то, что важно →