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

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

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

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

SPACE, представленная в марте 2021 года Николь Форсгрен вместе с Циммерманном, Хоуком и Батлером, раскладывает продуктивность на пять измерений: удовлетворённость и благополучие, результативность, активность, коммуникацию и взаимодействие, эффективность и поток — и каждое рассматривает на трёх уровнях: человек, команда, сквозной процесс. DevEx за авторством Форсгрен, Ноды, Стори и Грейлер сжимает картину до трёх областей: петли обратной связи, когнитивная нагрузка и состояние потока. QUANTS от Google собран командой инженеров и социальных учёных и опирается на метод GSM — от целей к сигналам и метрикам.

Часть сигналов принципиально достаётся только из опросов — авторы DevEx оговаривают это прямо, а продолжение фреймворка 2024 года построено на статистическом анализе опросов платформы getdx.com. Другая часть вытаскивается из рабочих систем, и на рынке обе школы представлены готовыми продуктами: 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-му. Автор дважды предупреждает: разметить модель статусов нетривиально, а если насаждать такие метрики сверху, мера превращается в цель и все начинают рисовать дашборды.