Фредерик Брукс опубликовал «Мифический человеко-месяц» в 1975 году. Его главный тезис — «добавление людей в опоздавший проект делает его ещё более опоздавшим» — пережил пять десятилетий методологической моды: водопад, agile, DevOps. В 2026 году AI-ассистенты подняли индивидуальную продуктивность инженера на 30-55% в контролируемых исследованиях (GitHub/Microsoft Research, 2024-2025). Естественный вопрос: AI наконец сломал закон Брукса?

Короткий ответ: нет. Чуть менее короткий: AI ускорил именно ту часть инженерной работы, которая никогда не была узким местом, и почти не затронул ту, которая им является.

DORA метрики — это 4 показателя, которые предсказывают, насколько хорошо ваша команда поставляет ПО. Не опросы, не самоотчёты — четыре жёстких сигнала: как часто вы деплоите, сколько времени изменение идёт до прода, как часто деплой ломает прод и как быстро вы восстанавливаетесь. Отчёт DORA 2023 от Google Cloud, построенный на 10 годах исследований и 36 000+ респондентах, — самая большая когда-либо собранная база данных по доставке ПО. И из года в год она показывает один и тот же паттерн.

Этот глоссарий объясняет каждую метрику простыми словами — с формулами и бенчмарками, которые отделяют elite-команды от low performers. Прочитайте один раз, держите как справочник.

Самый живучий миф в индустрии: Engineering Manager — это senior-разработчик, которому дали права админа в GitHub и разрешили одобрять pull requests по пятницам. Миф ошибочный по двум причинам. Первая: медианный EM в 100+ B2B-командах, которые мы измеряем, пишет код примерно 18 минут в день, и это здоровая цифра. Вторая: самое ценное, что делает EM, к IDE отношения не имеет. Это разговор, который удержал senior'а от ухода. Переписанная спека, которая спасла квартал. Нанятый инженер на уровень выше, чем команда считала возможным. Will Larson, который строил инженерию в Stripe, Calm и Carta, в An Elegant Puzzle формулирует прямо: задача EM — сделать так, чтобы команда выдавала больше суммы своих частей. Руками на клавиатуре этого не сделать.

Эта статья — простое определение роли. Кто такой EM, что он делает в течение недели, чем отличается от Tech Lead, как попасть туда из senior engineer и по каким метрикам понять, что человек справляется.

Команда из 8 инженеров отлогировала 1 280 часов в марте 2026 — ровно столько, сколько даёт месяц при 160 часах на FTE. На таблице всё выглядело чисто. Двое инженеров были в трёх неделях от увольнения. Цифра часов это полностью скрыла; FTE utilization показала на пятый день.

Это разрыв между метрикой посещаемости и метрикой вовлечённости относительно базовой нагрузки. Исследование Microsoft Research WorkLab 2022 года про «triple peak workday» задокументировало третий вечерний пик продуктивности у knowledge workers — невидимый, если считать только сумму часов. Часы не говорят, кто спринтует, а кто плывёт. FTE utilization — говорит.

Средний engineering manager тратит 4 часа в неделю на перетаскивание тикетов в Jira. Не планирование, не 1:1 — сортировку, напоминания, закрытие stale и гонки за полями, которые забыли заполнить. Мы опросили 31 EM у B2B-клиентов; 27 назвали Jira главной временной дырой после встреч.

Atlassian поставляет довольно мощный engine автоматизации в каждом плане Jira (да, даже в Standard). Команды его игнорируют. Или, что хуже, используют для одного правила — auto-close на "Done" — и упускают 11, которые имеют значение. Ниже — набор 12 правил, которые вместе сокращают admin-нагрузку EM с 4 ч/нед до ~40 минут. Мы используем варианты у себя в PanDev Metrics и у трёх on-prem клиентов.

Примерно 80% инженерных команд, которые я смотрел за последний год, репортят «Lead Time», который DORA не признала бы. Они меряют «от создания тикета до релиза». DORA меряет другое и более узкое: от первого commit'а до production. Разница между этими двумя определениями — обычно 5–10 дней. И это разница между честной метрикой доставки и дашбордом, который льстит не тем людям.

В этом гайде — строгое DORA-определение, формула, чем Lead Time отличается от Cycle Time (это не синонимы), и бенчмарки elite/high/medium/low на 2026 год, по которым можно сравнить свою команду.

Два production-инцидента, одна и та же причина — плохой конфиг положил платёжный сервис. Команда A восстановила сервис за 2 часа 14 минут. Команда B — за 6 минут. У команды B MTTR ниже не потому что инженеры умнее. У них была одна команда rollback, отрепетированная раз в месяц, runbook закреплён в on-call канале, и доступ на запись в прод выдан дежурному заранее. Разрыв — 134 минуты против 6 — это именно то, что измеряет MTTR. И это же отделяет elite-кластер из DORA 2023 State of DevOps Report от всех остальных.

В 2024 году Forrester впервые выделил «Engineering Intelligence» (EI) в отдельную категорию ПО. Спустя полтора года мы насчитываем минимум 40 вендоров, борющихся за один и тот же закупочный комитет — VP Engineering, CTO, CFO, иногда Chief of Staff. Питч у всех одинаковый. Качество данных, модель развёртывания и прозрачность ценообразования — нет.

Мы протестировали 15 из них. Часть — отличные. Часть — дорогие обёртки вокруг git log. Это buyer's guide, который мы хотели бы иметь, когда строили свою платформу.

14-минутный CI-пайплайн — это не просто 14 минут ожидания. GitHub Octoverse 2024 отчитался: медианный enterprise-репозиторий прогоняет pull request через CI 4.2 раза перед merge — ретраи, пуши после ревью, починка flaky-тестов. Это почти час компьюта на один PR. В команде, шипящей 200 PR в неделю, CI-бюджет вам ничего не приносит, а context-switch налог стоит вам четверга senior-разработчика.

Это how-to. Шесть шагов, которые стабильно режут время GitHub Actions CI на 50%+ на реальных репо, которые мы помогали оптимизировать. Без теории; у каждого шага есть патч, который можно адаптировать.

В инженерной организации на 50 человек, которую мы инструментировали в феврале 2026 года, месячный overhead-коэффициент составил K = 0.37. То есть на каждый $1 прямой разработческой работы приходилось 37 центов косвенных расходов: митинги, code review, ramp-up и доля зарплаты CTO/EM/DevOps, размазанная по команде. CFO три года использовал плоский коэффициент 30% для loaded cost. Реальное число было на 23% выше, и почти никто в компании об этом не знал.

Главная проблема была не в самом разрыве. Главная проблема: 30% — это один бакет, и даже после того, как разрыв обнаружен, внутри ничего нельзя оптимизировать. Отчёт Boston Consulting Group 2024 года про распределение G&A в софтверных компаниях фиксирует ту же картину на масштабе индустрии: компании, которые показывают overhead одной строкой, не могут его сократить, а компании, которые декомпозируют его на три компоненты, режут его на 8–15% за два квартала.