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

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

1 июня 2024

McKinsey считает, что да - можно измерять продуктивность разработчиков. Но дьявол в деталях: что именно измерять, на каком уровне, и как избежать gaming'а метрик. Главная ловушка сформулирована ещё в 1975 году британским экономистом Чарльзом Гудхартом: «когда мера становится целью, она перестаёт быть хорошей мерой». Эта статья разбирает, почему инженерные метрики так часто проваливаются, как два самых популярных фреймворка - DORA и SPACE - возникли как ответ на эту проблему, как одна команда выстраивает систему сдержек на практике и какие конкретные паттерны gaming-а ловят опытные руководители.

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

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

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

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

Хорошая инженерная метрика устойчива к этому превращению, если выполнено три условия. Во-первых, её сложно «обыграть» без реального улучшения процесса или продукта - то есть короткий путь к её росту совпадает с длинным. Во-вторых, она измеряется на уровне, где её улучшение требует кооперации, а не индивидуальной оптимизации. В-третьих, она используется как тема для разговора в ретро, а не как основание для бонуса или PIP. Все три условия одновременно выполнены у очень небольшого числа метрик; ниже мы увидим, что именно они и попали в DORA-четвёрку.

Эта статья опирается на четыре опорных источника. «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 - на уровне команды. Индивидуальный вклад в командный результат взвесить сложно.

Проблема gaming'а на каждом уровне

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

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

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

Почему нельзя измерять индивидуально

Даже если можно взвесить индивидуальный вклад - нельзя концентрироваться на индивидуальных метриках.

Последствия:

Это не абстрактное опасение. В 2012-2016 годах внутри Google шёл проект под кодовым названием Project Aristotle, который пытался ответить на вопрос: что отличает высокоэффективные команды от низкоэффективных? Исследователи проанализировали данные по 180 командам и не нашли никакой корреляции между составом команды по индивидуальным показателям и её результатами. Зато нашли, что главный предиктор результата - психологическая безопасность: насколько люди в команде готовы признавать ошибки, задавать вопросы и помогать друг другу. Любая система индивидуальных метрик подрывает именно это качество, потому что превращает коллег в конкурентов за рейтинг.

Антипаттерн: Измерять разработчиков как 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. Реальная причина оставалась в системе и через неделю всплывала в виде нового тикета. Среднее время ответа в чате тоже легко «разогнать»: достаточно дежурному отвечать «smотрим» в течение 30 секунд, чтобы метрика SLA закрылась, дальше можно копаться сколько угодно. Обе метрики измеряли output (закрыто) и effort (время реакции), но никак не outcome (стабильность платформы для её клиентов).

Переход. Новый Engineering Manager заменил два индикатора на четыре, явно опираясь на DORA-четвёрку и одно outcome-добавление от продуктовых команд:

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

Через два квартала. Количество закрытых тикетов упало примерно на 35%. Это вызывало нервный разговор с CTO в первом квартале (выглядело как «команда работает хуже»), но к концу второго стало ясно, почему: incoming tickets per team снизился ещё сильнее, потому что команда занялась root-cause фиксами и вычистила несколько хронических источников шума. 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 измеряет outcomes и impact на уровне команды/системы:

Метрика Что показывает Elite benchmark
Deployment Frequency Как часто доставляем ценность Несколько раз в день
Lead Time for Changes Как быстро от коммита до production < 1 часа
Change Failure Rate % деплоев, вызывающих сбои 0-5%
Mean Time to Recovery Как быстро восстанавливаемся < 1 часа
Почему DORA работает: Эти метрики коррелируют с бизнес-результатами (исследование Google и State of DevOps Report за 6 лет). Их сложно «обыграть» без реального улучшения процессов: чтобы поднять deployment frequency без обвала change failure rate, нужно реально починить тестирование и pipeline, а не просто пересчитать что-то на дашборде.

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 помогает понять «почему» (морально-устойчива ли команда, насколько хорошо она коммуницирует, не выгорает ли).

Как одна команда выстраивает checks-and-balances

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

Шаг 1. Собрать DORA-четвёрку из существующих систем. Деплои - из CI/CD (GitLab, Argo, Spinnaker, GitHub Actions). Lead time - из связки Jira/Linear и Git: время от первого коммита PR до merge + время от merge до production. Change failure rate - из инцидент-трекера (PagerDuty, Opsgenie) с тегом «вызвано релизом». MTTR - оттуда же. На сборе всех четырёх обычно уходит 2-4 недели и обнаруживается, что половина данных не собирается чисто, а часть инцидентов вообще не размечается. Это нормальный первый этап: вы не строите аналитику, вы строите измерительный аппарат.

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

Шаг 3. Привязать метрики к ритуалу обсуждения. Метрики, которые никто не обсуждает, перестают что-либо менять через два-три месяца. Минимальный ритуал - ежемесячный engineering review на 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-документ перед началом работ описывает, что именно увидит клиент в момент запуска. Это не метрика в привычном смысле, но это outcome-якорь: команда обязана начать с того, что увидит клиент, а не с того, что технически удобно.

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

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

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

Антипаттерны и реальные сценарии gaming-а

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

1. Vanity metrics: lines of code и коммиты на разработчика

Классика, которую критикуют со времён Билла Гейтса («measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs»). Любая метрика, которая растёт от добавления текста, поощряет добавление текста. В современных AI-инструментах эта проблема обострилась: автогенерация может за минуту создать сотни строк, формально засчитываемых как «production code». Если бонус привязан к LOC, экономика гарантированно поломается.

2. Single-metric tunnel vision

Команда смотрит только на deployment frequency и игнорирует change failure rate - получает 30 деплоев в день и 40% инцидентов после релиза. Команда смотрит только на code coverage и пишет тесты, дублирующие очевидное. Команда смотрит только на ticket throughput и режет тикеты, чтобы счёт сходился. Лекарство - всегда минимум две метрики, которые двигаются в разные стороны: рост одной без удержания второй должен быть невозможен.

3. Метрика-как-таргет (Goodhart triggered)

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

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

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

5. Tooling без процесса

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

Резюме

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

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

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

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

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

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