Когда 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 — каждый заявляет, что измеряет «продуктивность разработчиков». Ни один из них не измеряет одно и то же.

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

Большинство попыток внедрения DORA проваливаются не из-за инструментов или данных — а потому что превращаются в 6-месячные проекты, умирающие в комитетах. Исследование Accelerate (Forsgren, Humble, Kim, 2018) показало, что организации с видимыми метриками доставки улучшаются быстрее. Ключевое слово — видимыми: дашборд, на который никто не смотрит, хуже, чем отсутствие дашборда, потому что создаёт иллюзию измерения. Вот пошаговый план: от нуля до рабочих DORA-дашбордов за две недели — достаточно быстро, чтобы инерция не рассеялась.

Регуляция — не враг скорости; отсутствие измерений — вот настоящий враг. State of DevOps Report (2023) показывает, что финансовые организации из верхнего квартиля деплоят ежедневно, поддерживая при этом более строгий контроль изменений, чем их медленные коллеги. Когда аудитор спрашивает «как вы обеспечиваете контролируемость и надёжность процесса деплоя?», нужен ответ лучше, чем «у нас есть код-ревью». DORA-метрики дают такой ответ — с количественными доказательствами, которые аудиторы и комитеты по рискам могут реально проверить.

Исследование Глории Марк из UC Irvine показало, что после одного прерывания требуется в среднем 23 минуты 15 секунд, чтобы вернуться к задаче. А теперь представьте типичное утро разработчика: в 9:07 пришло сообщение в Slack, в 9:15 — напоминание о стендапе, в 9:45 — «быстрый вопрос» от PM. К 10:30 он «работал» 90 минут, но написал ровно 11 строк кода. Три прерывания съели примерно 70 минут когнитивного восстановления.

Это не проблема продуктивности. Это проблема Focus Time. И данные показывают, что она обходится вашей команде гораздо дороже, чем вы думаете.

Фред Брукс предупреждал в Мифическом человеко-месяце (1975), что измерять продуктивность программистов объёмом кода — ловушка: больше кода не значит больше ценности. Пятьдесят лет спустя некоторые организации всё ещё приравнивают написанные строки к выполненной работе. Фреймворк SPACE (Forsgren et al., 2021) прямо предостерегает от одномерных метрик активности — и всё же потребность, которую они адресуют, реальна: как понять, что ваша инженерная команда доставляет результат?

Ответ — не очередная vanity-метрика. Это составной сигнал, который мы называем Delivery Index.

«Это должно занять два дня.» Три недели спустя фича всё ещё в работе.

Стив Макконнелл в книге Software Estimation: Demystifying the Black Art обнаружил, что программные проекты обычно превышают первоначальные оценки на 28–85%. Закон Брукса из Мифического человеко-месяца объясняет часть причины: сложность растёт нелинейно с объёмом, а добавление людей в опаздывающий проект делает его ещё более опаздывающим. PM расстроен. Разработчик чувствует вину. Дорожная карта — фикция. И вся организация молчаливо приняла, что инженерные оценки ненадёжны.

Это не проблема людей. Это проблема измерения. И она решаема.

Никто не увольняется в понедельник. Заявление об увольнении, которое вы получите в случайный четверг, было написано — эмоционально — шесть недель назад. Отстранение началось три месяца назад. И данные видели это всё время.

Опрос Stack Overflow Developer Survey 2023 показал, что более 70% разработчиков отметили те или иные симптомы выгорания. Замена среднего разработчика обходится примерно в 50–200% его годовой зарплаты, если учесть рекрутинг, онбординг и потерю институциональных знаний. Фреймворк SPACE (Forsgren et al., 2021) прямо включает «Удовлетворённость и благополучие» как ключевое измерение продуктивности — признавая, что выгоревшие разработчики не просто несчастны, они существенно менее продуктивны. Но сигналы видны в данных активности задолго до заявления об увольнении.

Вот пять паттернов, которые проявляются в данных активности IDE за недели — иногда месяцы — до того, как разработчик выгорит или уволится.

«10x-разработчик» — один из самых устойчивых мифов нашей индустрии и один из самых разрушительных. Фред Брукс отмечал в Мифическом человеко-месяце (1975), что продуктивность отдельных программистов сильно варьируется, но при этом предупреждал: не стоит делать вывод, что найм решает системные проблемы. Фреймворк SPACE (Forsgren et al., 2021) идёт дальше: измерять «продуктивность» отдельного разработчика одной метрикой не просто неточно — это контрпродуктивно.

У нас есть данные B2B-инженерных команд и тысячи часов отслеженного кодирования. Вот что они на самом деле говорят о разбросе производительности разработчиков — и почему ответ значит меньше, чем вы думаете.