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

1 июня 2024

McKinsey считает, что да - можно измерять продуктивность разработчиков. Но дьявол в деталях: что именно измерять, на каком уровне, и как избежать gaming'а метрик.

На основе исследований DORA (книга "Accelerate" — Nicole Forsgren, Jez Humble, Gene Kim), фреймворка SPACE (Forsgren et al., ACM Queue 2021) и McKinsey.

Цепочка: Effort → Output → Outcome → Impact Проблема gaming'а на каждом уровне Почему нельзя измерять индивидуально DORA и SPACE: что измеряют Практические рекомендации

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

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

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

Ключевая проблема: У sales outcome индивидуален (подписанный контракт). У разработчиков outcome - на уровне команды. Индивидуальный вклад в командный результат взвесить сложно.

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

Любую метрику можно "обыграть". Это описывает закон Гудхарта (Charles Goodhart, 1975): когда мера становится целью, она перестаёт быть хорошей мерой. Изначально сформулированный для экономической политики, этот принцип точно описывает проблему инженерных метрик: люди оптимизируют именно то, что измеряется, даже если это не совпадает с тем, что вы хотели улучшить.

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

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

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

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

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

Разрушается команда и совместный результат
Люди оптимизируют личные метрики в ущерб командным
Code review становится "не моя работа" (не считается в метрики)
Помощь коллегам - потеря времени
Knowledge sharing исчезает

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

DORA и SPACE: что измеряют

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). Их сложно "обыграть" без реального улучшения процессов.

SPACE

SPACE (разработан в Microsoft Research, 2021) добавляет человеческое измерение к инженерным метрикам. Фреймворк предлагает измерять продуктивность по пяти осям:

Satisfaction - удовлетворённость работой и инструментами. Измеряется опросами. Низкая удовлетворённость коррелирует с текучкой и снижением качества.
Performance - достижение результатов. Качество кода, надёжность, отсутствие инцидентов.
Activity - объём работы. Количество коммитов, PR, code reviews. Наиболее подвержена gaming'у.
Communication - коллаборация. Скорость code review, качество документации, доступность знаний.
Efficiency - эффективность процессов. Время от идеи до production, количество переключений контекста.

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

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

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

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

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

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

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

Измеряйте команды, не индивидов. Outcome - командный результат.
Фокус на outcomes и impact, не на effort и output. DORA - хороший выбор.
Используйте checks and balances. Одна метрика - это ловушка.
Метрики - для разговора, не для KPI. "Почему lead time вырос?" - хороший вопрос для ретро.
Клиент-ориентированность. Если метрика не связана с клиентом - зачем она?

Резюме

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

Effort и Output легко измерить, но легко gaming'ить
Outcome и Impact сложнее, но ценнее
Индивидуальные метрики разрушают команду
DORA измеряет outcomes - это работает
SPACE добавляет человеческое измерение, но клиентам всё равно
Лучшая метрика: customer-facing результат каждую неделю

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