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

Ваш сениор-разработчик назначен на три проекта. Вы полагаете, что он отдаёт каждому проекту треть времени. Джеральд Вайнберг посчитал реальную математику в Quality Software Management (1992): при трёх параллельных проектах каждый получает около 20% времени разработчика — а оставшиеся 40% испаряются в виде накладных расходов на переключение контекста.

Это не предположение. Это хорошо задокументированный когнитивный феномен, подтверждённый данными нашей платформы по B2B-инженерным командам и согласующийся с исследованиями Глории Марк из UC Irvine, показавшими 23 минуты восстановления после каждого прерывания. Переключение контекста — одна из самых дорогих невидимых затрат в разработке ПО.

Согласно исследованиям McKinsey о продуктивности разработчиков, инженеры тратят лишь 25–30% времени на написание кода. Поэтому то, где работают разработчики, должно значить куда меньше, чем как структурировано их время. Тем не менее спор «удалёнка или офис» длится уже шесть лет: CEO ссылаются на «коллаборацию», разработчики — на «фокус», и обе стороны аргументируют убеждениями, а не доказательствами.

У нас есть тысячи часов отслеженной IDE-активности по 100+ B2B-компаниям. Данные рисуют более нюансированную картину, чем хотелось бы любой из сторон.

Исследования Gallup неизменно показывают, что качество менеджера — главный фактор вовлечённости сотрудников, и всё же большинство инженерных менеджеров проводят 1:1 одинаково: «Как дела?», за чем следует неловкая тишина, а потом разговор сползает в обновление статуса по проекту. Это не 1:1 — это стендап с лишними шагами. Настоящие 1:1 должны быть самыми ценными 30 минутами в неделе вашего разработчика, и данные делают их кратно лучше.

Анализ Harvard Business Review показал, что более 90% менеджеров признают: процесс performance review в их компании не даёт точных результатов. В инженерии проблема ещё хуже: менеджеры пишут размытые абзацы на основе того, что помнят за последние две недели. Тихие высокоэффективные сотрудники остаются незамеченными. Громкие слабые — получают оценки выше заслуженного. И все уходят с ощущением, что процесс был произвольным. Данные это исправляют — но только если использовать их правильно.