Можно ли измерять продуктивность инженеров?

DORA, SPACE и ловушки метрик

1 июня 2024

Справочник

Инженерные метрики помогают увидеть задержки, качество изменений и условия работы команды. Чтобы пользоваться ими, нужно понимать, что измеряет каждый показатель, на каком уровне он полезен и как его интерпретировать. В статье разбираю DORA и SPACE, примеры применения и ситуации, когда улучшение цифр расходится с улучшением работы.

Закон Гудхарта и почему метрики ломаются Цепочка: Effort → Output → Outcome → Impact Подгонка работы под метрики Почему индивидуальные показатели не дают полной картины Кейс: переход от output к outcome на примере одной команды DORA и SPACE: история фреймворков и что они измеряют Как использовать метрики в работе команды Ошибки при использовании метрик Практические рекомендации Источники и смежные статьи

Закон Гудхарта и почему метрики ломаются

В 1975 году британский экономист Чарльз Гудхарт, советник Банка Англии по денежно-кредитной политике, опубликовал заметку о том, что любой статистический показатель, выбранный регулятором как цель, в течение нескольких лет перестает отражать ту реальность, ради которой его выбрали. Поведение участников рынка адаптируется к самому показателю, а не к тому, что он раньше измерял. Антрополог Мэрилин Стратерн в 1997 году переформулировала эту идею в виде, который чаще всего цитируют сегодня: «when a measure becomes a target, it ceases to be a good measure» («когда мера становится целью, она перестает быть хорошей мерой»).

В инженерной среде закон Гудхарта работает буквально. Вы поставили команде KPI «закрывать не менее 30 тикетов в спринт» - через два спринта тикеты дробятся на более мелкие, чтобы счет сходился. Вы привязали бонус к количеству строк кода - в кодовой базе появляются раздутые конструкции и копипаста. Вы хвалите за «pull request в день» - команда начинает создавать формальные PR, которые ничего не меняют по существу. Сама метрика не виновата: проблема в том, что ее превратили из сигнала в цель.

Метрику полезно обсуждать вместе с другими показателями и конкретными примерами работы. Нужно проверить, можно ли улучшить цифру без полезного результата и не мешает ли индивидуальная цель совместной работе. Если метрика влияет на бонусы или оценку сотрудника, риск подгонки становится особенно важен. Ни один набор показателей не устраняет этот риск полностью.

Статья опирается на четыре источника. «Accelerate» (2018) Николь Форсгрен, Джеза Хамбла и Джина Кима - книга, в которой обоснована DORA-четверка, основанная на State of DevOps Report 2014-2018. Статья «The SPACE of Developer Productivity» Форсгрен, Стори, Маддилы, Циммермана, Хоука и Батлер (ACM Queue, март-апрель 2021) - формальное введение SPACE-фреймворка. Заметка McKinsey «Yes, you can measure software developer productivity» (август 2023) - попытка свести DORA, SPACE и продуктовые метрики в единую систему. И длинная серия публикаций Гергей Орос в The Pragmatic Engineer о том, как инженерные руководители реально применяют эти фреймворки в продуктовых компаниях.

Цепочка: Effort → Output → Outcome → Impact

Любую работу можно разложить на четыре уровня:

Уровень Что это Пример (разработчик) Пример (sales)
Effort Затраченные усилия Часы работы, коммиты Количество звонков
Output Произведенный результат Закрытые тикеты, PR Отправленные предложения
Outcome Достигнутый результат Фича в production Подписанный контракт
Impact Влияние на бизнес Рост retention пользователей Выручка
Ключевая проблема: У sales outcome индивидуален (подписанный контракт). У разработчиков outcome - на уровне команды. Индивидуальный вклад в командный результат взвесить сложно.

Подгонка работы под метрики

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

Если измерять... Люди будут...
Effort (часы, коммиты) Создавать busywork - много усилий с сомнительной ценностью
Output (тикеты, PR) Увеличивать количество через то, что проще сделать. Не факт, что это поможет outcome
Outcome (фичи в prod) Бить таргеты любой ценой, даже через shortcuts
Impact (бизнес-метрики) Креативно достигать impact с меньшим effort и output (иногда это хорошо!)

Нельзя измерять что-то одно изолированно. Нужны checks and balances - система сдержек, которая гарантирует, что outcome достигается правильным путем.

Почему индивидуальные показатели не дают полной картины

Оценка людей по отдельным показателям активности может поощрять конкуренцию в ущерб совместной работе.

Возможные последствия такой оценки:

В Project Aristotle Google изучил 180 команд: 115 инженерных и 65 команд продаж. В этой выборке эффективность была связана прежде всего с тем, как люди работали вместе. Исследователи выделили психологическую безопасность, надежность, ясность ролей и целей, смысл работы и ощущение ее влияния.

Индивидуальная результативность участников не показала значимой связи с эффективностью команды в этом исследовании. Это не означает, что индивидуальный вклад не важен: Google отдельно предупреждает, что результаты могут отличаться в других организациях. Для оценки совместной работы стоит учитывать и результат команды, и условия, в которых люди его достигают.

Антипаттерн: Измерять разработчиков как sales - по индивидуальному output. Это создаст серьезные проблемы для командной динамики: вы измеряете не outcomes или impact, а output.

Кейс: переход от output к outcome на примере одной команды

Чтобы увидеть, как переключение метрик меняет поведение, удобно посмотреть на одну команду, прошедшую такой переход. Ниже - стилизованный пример на основе типичных паттернов, которые я видел в B2B SaaS-компаниях на 200-500 инженеров и которые повторяются в публичных рассказах GitLab, Atlassian и Etsy. Имена и числа собирательные; механика - реальная.

До. Платформенная команда из 9 человек измерялась двумя метриками: количество закрытых тикетов в спринт и SLA на ответ в support-канале. Обе считались еженедельно, отображались на дашборде в офисе и обсуждались на one-to-one с менеджером. За три квартала команда стала рекордсменом по обеим: 70+ тикетов в спринт, среднее время ответа меньше 5 минут. Параллельно происходило странное: продуктовые команды жаловались на «непредсказуемость» платформы, retro регулярно упирались в инциденты на проде, а MTTR за тот же период вырос с 22 минут до часа с лишним. Показатели улучшались, хотя продуктовые команды отмечали проблемы с платформой.

Что именно сломалось. Тикет проще закрыть быстро, чем разобраться в его причине, поэтому команда стихийно научилась резать симптомы: добавить ретрай, поднять таймаут, рестартнуть Pod. Реальная причина оставалась в системе и через неделю всплывала в виде нового тикета. Среднее время ответа в чате тоже легко «разогнать»: достаточно дежурному отвечать «смотрим» в течение 30 секунд, чтобы метрика SLA закрылась, дальше можно копаться сколько угодно. Обе метрики измеряли output (закрыто) и effort (время реакции), но никак не outcome (стабильность платформы для ее клиентов).

Переход. Новый Engineering Manager заменил два индикатора на четыре: две метрики надежности платформы и два показателя взаимодействия с продуктовыми командами:

Что важно - старые метрики не выкинули, а перевели в категорию «локальная диагностика». Количество закрытых тикетов и время ответа продолжали считать, но они перестали быть KPI. Они оставались полезными как диагностический сигнал: если вдруг закрытых тикетов резко стало меньше, это повод задать вопрос, не более того.

Через два квартала. Количество закрытых тикетов упало примерно на 35%. Это вызывало нервный разговор с CTO в первом квартале (выглядело как «команда работает хуже»), но к концу второго стало ясно, почему: incoming tickets per team снизился еще сильнее, потому что команда занялась устранением причин проблем и вычистила несколько хронических источников шума. MTTR вернулся к 25 минутам. Change Failure Rate стабилизировался около 8% - не elite, но в зоне приемлемого. Quarterly platform NPS, который в первом замере был отрицательным, во втором замере стал нейтральным; в третьем - положительным.

Что сделало переход возможным. Три вещи. Первая - поддержка CTO, который выдержал квартал «плохих» цифр на старых метриках. Вторая - перевод старых метрик в роль диагностики, а не их полное удаление; команда не чувствовала, что ее обесценили. Третья - новый набор метрик включал и outcome (CFR, MTTR), и client-satisfaction (NPS, incoming tickets), и leading indicator (incoming tickets - снижение этой цифры предшествовало улучшению NPS). Это и есть checks and balances в действии.

Похожие истории описаны в публичных материалах GitLab DORA in the handbook (2023) и Atlassian про DORA. У Etsy еще в 2010-е Эрик Кастнер и Джон Олспоу описывали культуру deployment-velocity как сознательный отказ от output-метрик в пользу частоты релизов и MTTR - см. посты в Code as Craft.

DORA и SPACE: история фреймворков и что они измеряют

DORA и SPACE возникли с разницей примерно в десять лет и из очень разных мотиваций. DORA родилась как эмпирический проект Николь Форсгрен, исследователя организационного поведения с PhD в IT-менеджменте. С 2014 по 2018 годы она вместе с командой DevOps Research and Assessment проводила ежегодный State of DevOps Report - анкетирование 30 000+ инженеров и руководителей по всему миру. К 2018 году у них накопилось достаточно данных, чтобы сформулировать главный вывод книги «Accelerate» (Форсгрен, Хамбл, Ким, IT Revolution Press, 2018): четыре конкретные метрики статистически отличают «elite» команды от средних, и эти же метрики коррелируют с финансовыми результатами компании в целом.

Важно, что Хамбл и Ким принесли в эту работу собственные книги. Джез Хамбл вместе с Дэвидом Фарли написал «Continuous Delivery» (Addison-Wesley, 2010), задавшую язык для описания deployment pipeline и rolling release. Джин Ким - автор «The Phoenix Project» (2013) и «The DevOps Handbook» (IT Revolution, 2016). DORA-четверка опирается на их предыдущие работы как на фундамент: Continuous Delivery дал определения lead time и deployment frequency, DevOps Handbook - связь между технической практикой и организационным результатом. «Accelerate» добавил статистическую базу.

DORA (DevOps Research and Assessment)

DORA оценивает процесс доставки изменений для отдельного приложения или сервиса. Эти показатели помогают обсуждать скорость и стабильность разработки, но сами по себе не измеряют пользу продукта для клиента.

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

Метрика Что показывает
Deployment frequency Частоту деплоев в production или время между ними
Change lead time Время от коммита изменения до его деплоя в production
Failed deployment recovery time Время восстановления после неудачного деплоя, требующего немедленного вмешательства
Change fail rate Долю деплоев, после которых требуется немедленное вмешательство, например hotfix или rollback
Deployment rework rate Долю внеплановых деплоев, вызванных инцидентами в production

Failed deployment recovery time относится к сбоям после изменения системы. Это более узкий показатель, чем время восстановления после любых инцидентов, включая отказ внешней инфраструктуры.

Метрики стоит смотреть вместе и сравнивать во времени для одного приложения или сервиса. Если сделать их самостоятельными целями, люди могут улучшать цифры без улучшения процесса. Например, требование деплоить несколько раз в день само по себе не гарантирует полезных изменений для пользователей.

SPACE

SPACE появился в марте-апреле 2021 года в виде статьи «The SPACE of Developer Productivity: There's More to It Than You Think», опубликованной в журнале ACM Queue. Авторы - Николь Форсгрен (та же, что в DORA), Маргарет-Энн Стори (профессор University of Victoria, два десятка лет занимающаяся developer experience), Чандра Маддила, Томас Циммерман, Брайан Хоук и Дженна Батлер (все - Microsoft Research). Мотивация авторов прямо названа в первой же странице: за пандемию COVID-19 руководители массово начали внедрять «productivity tracking» с акцентом на индивидуальные показатели, и многие из этих внедрений ломали команды быстрее, чем приносили пользу. SPACE - это попытка дать руководителям альтернативный, многомерный язык.

Фреймворк предлагает измерять продуктивность по пяти осям:

SPACE рекомендует выбирать метрики из минимум трех категорий, чтобы избежать однобокости. Например: Satisfaction (опросы) + Performance (change failure rate) + Efficiency (lead time). SPACE рассматривает продуктивность на уровне человека, команды и системы. Индивидуальные показатели могут помочь инженеру разобраться в своей работе - например, заметить частые переключения контекста или периоды сосредоточенной работы. Для отчетности команды и организации авторы рекомендуют использовать обезличенные агрегированные данные.

Критика SPACE (The Pragmatic Engineer): эти метрики могут быть полезны для внутренней рефлексии, но их связь с реальным impact на клиентов не всегда очевидна. SPACE лучше всего работает в сочетании с DORA: DORA показывает «что происходит» с поставкой ценности, SPACE помогает понять «почему» (морально-устойчива ли команда, насколько хорошо она коммуницирует, не выгорает ли).

Как использовать метрики в работе команды

Знать DORA и SPACE - не то же, что внедрить их. Большинство компаний, которые «внедрили DORA», поставили дашборд - и на этом остановились. Нужно определить, кто обсуждает показатели и какие решения принимает на их основе. Ниже - последовательность шагов, которая в моей практике работает; она собрана из публичных материалов GitLab, Atlassian и Stripe и из нескольких внутренних кейсов в B2B SaaS.

Шаг 1. Собрать данные о доставке изменений. Коммиты и деплои можно связать по данным Git и CI/CD. Change lead time измеряется от коммита до production. Для change fail rate и failed deployment recovery time нужны связи между деплоями и вызванными ими инцидентами. Для deployment rework rate нужно отмечать внеплановые деплои, сделанные из-за инцидентов. На сбор данных обычно уходит 2-4 недели и обнаруживается, что половина данных не собирается чисто, а часть инцидентов вообще не размечается. Это нормальный первый этап: нужно разобраться, какие события регистрируются и достаточно ли данных для расчета показателей.

Шаг 2. Добавить минимум один satisfaction-сигнал. Без «S» из SPACE команда измеряет только то, что видно снаружи. Простейшая форма - короткий ежеквартальный опрос на 4-6 вопросов: «насколько ты доволен инструментами», «насколько часто ты испытываешь flow», «есть ли у тебя достаточно автономии», «как ты оцениваешь нагрузку 1-10». Сложнее, но сильнее - DevEx survey по методике Microsoft Research или GitHub (см. доклады DX team). Данные обрабатывает не менеджер команды, а кто-то на стороне (HR, People Ops), чтобы анонимность реально работала.

Шаг 3. Регулярно обсуждать метрики. Метрики, которые никто не обсуждает, перестают что-либо менять через два-три месяца. Минимальный ритуал - ежемесячное обсуждение работы разработки на 60 минут, на котором команда смотрит на показатели DORA и satisfaction-сигнал, и каждое отклонение разбирается: что произошло, что мы делаем дальше, нужно ли что-то менять в процессе. Правило обсуждения - не наказывать за плохие цифры. Цифры - это сигнал для разговора, а не основание для PIP.

Шаг 4. Добавить один outcome-показатель снаружи. DORA описывает доставку изменений, а SPACE помогает рассматривать несколько сторон работы инженеров. Нужен еще один сигнал: что от этой доставки реально происходит у клиента. У Pragmatic Engineer есть две хорошие формулировки - «customer-facing thing per team per week» (минимум одно изменение, видимое клиенту) и «business impact committed by team» (команда сама коммитится на бизнес-результат и отвечает за него). У Amazon роль такого индикатора играет процедура Working Backwards - PR/FAQ-документ перед началом работ описывает, что именно увидит клиент в момент запуска. Этот документ помогает команде заранее описать результат для клиента и оценивать технические решения относительно него.

Шаг 5. Различать leading и lagging indicators. Lead time - lagging: вы видите его уже после факта. PR review time, время в статусе «in review», количество PR в очереди - leading: они меняются раньше и предсказывают рост lead time. Change Failure Rate - lagging; покрытие тестами по новым PR и доля смерженных PR без CI-флапов - leading. Полезно сочетать показатели доставки изменений с более ранними сигналами, например временем ревью и очередью PR. Их роль зависит от того, какой результат мы пытаемся предсказать. Без leading-индикаторов команде нечего обсуждать, кроме «вот, опять цифра уехала».

Шаг 6. Не сравнивать команды между собой. Самая частая ошибка - усреднять DORA по всем командам компании и сравнивать одну команду с другой. Маленькая инфраструктурная команда из 4 человек, которая релизит платформу раз в день, и продуктовая команда из 12 человек, которая релизит фичу в SPA-приложение каждый час - работают в разных условиях; сравнение одного показателя без учета этих различий мало что объясняет. Каждая команда сравнивается со своей траекторией во времени, а не с соседом.

Stripe в публичных материалах Брэндура Лича и команды (см. блог Stripe Engineering) описывает культуру zero-downtime деплоев как продолжение этой модели: deploy frequency на платформенных сервисах достигает десятков релизов в день, но change failure rate отслеживается жестче, чем deploy frequency, потому что один плохой релиз стоит больше, чем сто хороших. Это пример совместного использования метрик: одна метрика не может вырасти без второй; обе измеряют один процесс с разных сторон.

Ошибки при использовании метрик

Опытные инженерные руководители видят одни и те же провалы внедрения метрик снова и снова. Ниже - восемь паттернов, каждый из которых ломает либо саму метрику, либо команду вокруг нее. Большинство легко поймать, если знать, что искать.

1. Оценка по строкам кода и коммитам на разработчика

Количество строк кода показывает объем текста, но не его пользу. Бонус за этот показатель может поощрять раздувание реализации. С AI сгенерировать много кода еще проще, поэтому для оценки результата нужны проверки поведения, качества и решения исходной задачи.

2. Оценка по одному показателю

Частоту деплоя нужно сопоставлять со стабильностью изменений, а покрытие тестами с тем, какое поведение проверяется. Если один показатель улучшается, а другой ухудшается, это повод разобраться в причинах. Сам по себе рост числа деплоев, тестов или закрытых задач не доказывает улучшения работы.

3. Подгонка работы под целевой показатель

Сама по себе метрика - сигнал; цель - объяснить отклонения и подкорректировать процесс. Превращение метрики в KPI с привязкой к бонусу или к performance review запускает закон Гудхарта в полную силу. Признак, что вы попали в ловушку: за две недели до конца квартала разработчики начинают «фиксить» цифры на дашборде вместо обычной работы.

4. Игнорирование «S» в SPACE

Самый частый способ внедрить SPACE - выкинуть satisfaction. Activity, Performance, Communication, Efficiency легко вытаскиваются из инструментов; satisfaction требует опроса людей и обработки качественных ответов. В итоге фреймворк, придуманный как противовес дегуманизации метрик, превращается в набор показателей, который не учитывает опыт сотрудников. Если из SPACE убрать «S», получается «PACE» - и теряется смысл всего фреймворка.

5. Инструменты без обсуждения результатов

Поставили DataDog DORA dashboard или LinearB - и решили, что внедрили DORA. Дашборд показывает deployment frequency 2.3 в день, lead time 6 часов, все зеленое. Что дальше? Если вокруг дашборда не выстроен ритуал обсуждения, retro-разговор, разбор отклонений - метрики не меняют поведение. Через полгода дашборд перестают открывать.

6. Усреднение по разнородным командам

Усреднили показатели DORA по 30 командам, получили «у нас компания high performers», отчитались наверх. Внутри: одна платформенная команда тянет deployment frequency вверх, шесть продуктовых лежат внизу, трое вообще релизят раз в две недели и в среднем уходят в шум. Метрики имеют смысл только в разрезе команд, и тот же разрез должен быть у всех ритуалов обсуждения. Усреднение по компании - это управленческая отчетность для C-level, а не инженерная метрика.

7. Путаница leading и lagging

Lead time - lagging: вы можете воздействовать на него только косвенно. Если ставите команде цель «сократить lead time на 30% за квартал», но не даете ей рычагов на leading-индикаторы (PR review time, размер PR, частота merge-конфликтов), команда либо не сделает ничего, либо начнет хитрить с замером. Хороший паттерн - таргет на leading, мониторинг на lagging.

8. SPACE-опросник «в режиме паники»

Команда полгода жалуется на нагрузку, менеджер игнорирует, потом по фидбеку HR-Performance заказывает «срочный SPACE-замер» с 40 вопросами на одного человека. Опрос приходит после двух недель аврала, проводится один раз, никто не объясняет, что будет с результатами. Команда отвечает либо дежурно, либо враждебно; данные оказываются бесполезны; доверие к опросам падает на год вперед. SPACE-опрос работает только как регулярный ритуал на короткой анкете, а не как разовое спасение в момент кризиса.

Как заметить gaming-у вовремя. Раз в квартал садитесь с командой и задавайте вопрос: «Что мы делаем сейчас, что мы бы не делали, если бы не существовало этой метрики?» Если ответ есть - метрика сместила поведение нездоровым образом. Если ответ «ничего» - метрика честная. Этот вопрос сильнее любого аудита, потому что команда честнее всех знает, как именно она «обыгрывает» свои показатели.

Практические рекомендации

Что измерять кроме DORA

The Pragmatic Engineer предлагает два дополнительных outcome-oriented показателя:

Customer-facing thing per team per week Минимум одна штука, видимая клиенту, от каждой команды каждую неделю
Business impact committed by team Команда сама коммитится на бизнес-impact и отвечает за его достижение

Принципы измерения

  1. Оценивайте командный результат. Индивидуальные показатели не дают полной картины совместной работы.
  2. Фокус на outcomes и impact, не на effort и output. DORA - хороший выбор.
  3. Используйте checks and balances. Одна метрика - это ловушка.
  4. Метрики - для разговора, не для KPI. «Почему lead time вырос?» - хороший вопрос для ретро.
  5. Клиент-ориентированность. Если метрика не связана с клиентом - зачем она?
  6. Различайте leading и lagging. Таргет ставится на leading, мониторинг - на lagging.
  7. Не сравнивайте команды между собой. Каждая сравнивается со своей траекторией.

Резюме

Измерять продуктивность можно, но осторожно:

Измерять outcomes и impact нужно, но без системы сдержек люди будут достигать целей обходными путями. Метрики работают, когда их используют для разговора, а не для наказания.

Источники и смежные статьи

Книги и первоисточники

Реальные кейсы и публичные практики

Аналитика и обзоры