Команда из восьми инженеров, которую я консультировал в прошлом году, держала правило: любой тикет больше 3 story points требует design doc. Получалось около четырёх документов в неделю, по полдня на написание и ещё полдня на циклы ревью. Итого 32 инженерных часа в неделю — четыре полных рабочих дня на документы, которые большинство людей пробегало глазами один раз и больше не открывало. CTO считал, что у них высокая дисциплина. Данные говорили, что у них перегруз документации и провал по velocity.

Обратная крайность ещё хуже. Stack Overflow Developer Survey 2019 года назвал «плохую документацию внутренних систем» блокером продуктивности №2 — сразу после технического долга. Полностью отказаться от design docs значит, что каждый рефакторинг через полгода превращается в археологические раскопки.

Это фреймворк, которым я пользуюсь, чтобы решить: какие изменения заслуживают документа, какие — комментария на 3 предложения в RFC, а какие — ничего.

Среднее инженерное ретро длится 60 минут, рождает пять стикеров и ноль действий, которые доедут до следующего спринта. В опросе Scrum Alliance 2023 года жалоба №1 от senior-разработчиков звучала так: «ретро ощущается как спектакль». Это не проблема митинга — это проблема измерений. Команда обсуждает ощущения, потому что никто не вытащил цифры до звонка.

В этой статье — 30-минутное ретро, которое начинается с данных, заканчивается именами и сроками, и работает на командах от 5 до 25 инженеров.

Два разработчика на одну задачу. Удвоенная стоимость труда, вдвое меньше багов, и никто не может договориться, окупается ли это. Самое цитируемое исследование на эту тему — Cockburn & Williams, The Costs and Benefits of Pair Programming (2000) — показало +15% времени при парной работе и −15% дефектов. На бумаге это ничья. В реальности — нет. Математика "баг пойман рано" выводит ROI примерно к 2×, если учесть сэкономленный rework и предотвращённые production-инциденты.

В этой статье мы скрестили академические данные Cockburn-Williams с нашим IDE heartbeat датасетом по 100+ B2B-компаниям — включая команды, которые практикуют pair programming ежедневно, и те, что не используют его вовсе. Не "хорош ли pair programming?", а "когда он окупается, а когда это театр?".

Прямо сейчас у вашей команды несколько 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+ опрошенных данные однозначны: более частый деплой не означает больше поломок. Тем не менее большинство команд застряли в ежемесячных релизных циклах, воспринимая частоту как риск вместо митигации риска. Вот практический план, как это изменить.