Как и зачем измерять инженерную продуктивность

В крупной технологической компании эффективность инженеров вносит большой вклад в эффективность бизнеса, но привычные общие показатели описывают ситуацию целиком, и понять по ним вклад отдельных частей организации не получается. Автор раскладывает процессы на Run, Change и Disrupt — операционную работу, создание и развитие продуктов, внутренние стартапы и смену бизнес-моделей — и договаривается, что дальше речь пойдёт про поставку внутри Change. Это сразу отсекает и часть отраслей: рамки выросли в продуктовых компаниях и не рассчитаны на консалтинг и аутсорсинг.

Претензия к старым способам измерения формулируется отдельно: они считали произведённый объём вместо достигнутого результата и оценивали отдельного человека вместо системы в целом, а значит подталкивали к локальной оптимизации, когда один участок разгоняется, а общий результат не меняется.

DORA собрана вокруг четырёх метрик: частота развёртываний и время прохождения изменения отвечают за темп поставки, доля неудачных изменений и время восстановления сервиса — за стабильность. За моделью стоят исследования Форсгрен, Хамбла и Кима, книга «Accelerate» 2018 года и позже переход направления к Google; массив опросов и их анализ подтвердили положительную корреляцию между темпом поставки и стабильностью сервисов. SPACE, вышедшая в марте 2021 года, добавляет удовлетворённость и благополучие, результативность, активность, коммуникацию и взаимодействие, эффективность и поток, читая каждое измерение на уровне человека, команды и сквозного процесса, и сочетает опросы с процессными показателями.

DevEx сводит картину к трём областям — петли обратной связи, когнитивная нагрузка и состояние потока — и внутри каждой разделяет восприятие, рабочие процессы и показатели; авторы сами отмечают, что восприятие достаётся только из опросов, а статья 2024 года подкрепляет фреймворк статистикой с платформы getdx.com. QUANTS от Google собран командой из инженеров и социальных учёных, опирается на метод GSM и на отдельную процедуру триажа: прежде чем начинать исследование, команду спрашивают, стоит ли это вообще измерять.

Продукты на рынке распределяются по тем же школам: Cortex строит командные оценочные карточки поверх DORA, SPACE и DevEx, DevEx 360 работает как опросная платформа, Code Climate опирается на метрики DORA и отчётность по целям, Pluralsight Flow считает время цикла и активность в пул-реквестах; среди пользователей DevEx названы Etsy, Dropbox, eBay, Amplitude, Monzo, P&G и DHL. Внутренний T-Meter, продуктом которого занимался Павел Ахметчанов, относится к школе данных из рабочих систем: шаблонные вики-пространства и панели поверх Jira, от простых конфигураций для небольшой команды до сложных для крупной организации.

Командная панель показывает скорость поставки, время задач в статусах для поиска узких мест, динамику бэклога и время цикла разработки — от старта работ до попадания в релизный буфер. У руководителя та же картина сворачивается в таблицу по командам: время поставки по 85-му перцентилю, текущий бэклог, отношения бэклога и незавершённой работы к скорости поставки, предсказуемость как отношение 85-го перцентиля к 50-му и баланс типов задач по месяцам. Автор предупреждает, что разметка модели статусов нетривиальна, а метрики, спущенные сверху как KPI, превращают меру в цель. Сам он верит в подход снизу вверх, если удаётся вовлечь людей на местах.