Прямо сейчас у вашей команды несколько pull request'ов застряли в ревью. Скорее всего, три или больше. Один из них провисел пять дней. Исследование Google 2018 года (Sadowski et al., Modern Code Review: A Case Study at Google) показало: медианный review в Google закрывается за менее чем 4 часа. В большинстве команд, которые мы наблюдаем, этот показатель — 4 дня. Разница в 24 раза, и она почти полностью объясняется процессом, а не уровнем разработчиков.

Это чеклист из 11 правил, которые режут время ревью вдвое без потери качества. Каждое правило подкреплено внешним исследованием, проверено на реальных данных инженерных команд и разнесено по трём фазам: дисциплина автора, дисциплина ревьюера, дисциплина команды.

Каждый руководитель разработки задаёт один и тот же вопрос: сколько времени разработчики реально тратят на написание кода?

Microsoft Research выяснили, что разработчики тратят на код всего 30-40% рабочего времени. Исследование Haystack Analytics 2019 года показало ближе к 2 часам. Наши собственные данные IDE heartbeats по B2B-командам подтверждают медиану в 78 минут в день.

Вот что реально показывают данные и почему это важно.

В апрельском номере Forbes Kazakhstan за 2026 год (страницы 104–107) вышла статья «Доверься «большому брату»», посвящённая инженерной аналитике и PanDev Metrics. Материал рассматривает, как подход к управлению разработкой на основе данных набирает обороты в Центральной Азии и за её пределами.

Вместо перепечатки мы хотим выделить главное: что говорят наши клиенты, что показывают цифры и куда движется индустрия.

Согласно отчёту McKinsey о продуктивности разработчиков (2023), инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, ожидании и процессном оверхеде. DORA-метрики существуют, чтобы сделать эту невидимую трату видимой — и исправимой.

Если вы CTO, VP of Engineering или Engineering Manager, который ещё не внедрил DORA — вы управляете по интуиции в эпоху, которая требует доказательств. Это руководство охватывает всё: что измеряет каждая метрика, как сравнить свою команду с бенчмарками, как внедрить отслеживание и какие ошибки превращают данные DORA в бесполезный мусор.

Отчёт McKinsey о продуктивности разработчиков (2023) показал, что инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, переключении контекста и ожидании. Если вы Engineering Manager и полагаетесь на интуицию — вы не видите, куда уходит 70% мощности вашей команды.

Вот 10 метрик, которые заточат ваши решения. Без воды и совета «отслеживайте всё» — только то, что отличает управление на основе данных от гадания.

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

Accelerate State of DevOps Report (2023) показал, что элитные команды деплоят по запросу, несколько раз в день — и при этом у них меньше инцидентов в продакшене, чем у команд с ежемесячным циклом. За десять лет исследований и 36 000+ опрошенных данные однозначны: более частый деплой не означает больше поломок. Тем не менее большинство команд застряли в ежемесячных релизных циклах, воспринимая частоту как риск вместо митигации риска. Вот практический план, как это изменить.

Когда VP of Engineering говорит мне, что их Change Failure Rate — 0%, я не поздравляю. Я спрашиваю, что они не учитывают. Исследование Stripe «Developer Coefficient» (2018) оценило, что $300 миллиардов ежегодно теряется глобально из-за плохого кода и неэффективных процессов — и значительная часть этих потерь скрывается за нереалистичными метриками качества. 0% CFR почти всегда означает, что команда либо деплоит так редко, что каждый релиз тестируется до состояния паралича, либо — что чаще — определение «сбоя» настолько узкое, что реальные инциденты в него не попадают.

Книга Google Site Reliability Engineering (2016) популяризировала контринтуитивный принцип: примите неизбежность сбоев и инвестируйте в скорость восстановления. Исследования DORA подтвердили это данными — разница между элитными и отстающими командами не в том, что у элитных меньше инцидентов, а в том, что они восстанавливаются менее чем за час вместо недели. Каждая инженерная организация инвестирует в предотвращение сбоев. Немногие инвестируют в быстрое восстановление после них. Данные говорят, что приоритеты расставлены наоборот.

Stack Overflow Developer Survey (2023) показал, что удовлетворённость разработчиков напрямую предсказывает удержание и качество результата. Одновременно DORA-метрики предсказывают эффективность организации. Тем не менее многие инженерные лидеры рассматривают эти подходы как конкурирующие, а не как взаимодополняющие линзы. В 2026 году проблема не в нехватке фреймворков — а в выборе правильной комбинации. DORA, SPACE и DevEx — каждый заявляет, что измеряет «продуктивность разработчиков». Ни один из них не измеряет одно и то же.

Вот как разобраться в этом шуме.