SPACE Framework

Почему DORA оказалось мало

После того как DORA-метрики стали индустриальным стандартом, довольно быстро стало понятно, что четыре метрики delivery pipeline — это хорошо, но недостаточно для полной картины продуктивности разработчиков. Николь Форсгрен, которая была одним из авторов оригинального исследования DORA, вместе с коллегами из Microsoft Research в 2021 году опубликовала статью “The SPACE of Developer Productivity”, в которой предложила принципиально другой подход: вместо того чтобы пытаться свести продуктивность к нескольким числам, нужно рассматривать её как многомерное явление и сознательно выбирать метрики из разных измерений, чтобы избежать слепых пятен.

Ключевая идея SPACE состоит в том, что ни одна метрика или даже группа метрик из одного измерения не может адекватно описать продуктивность разработчика, и любая попытка свести всё к одному числу неизбежно приведёт к искажениям и перекосам. Именно поэтому фреймворк предлагает пять измерений, из которых нужно выбирать метрики осознанно, покрывая как минимум три из пяти.

Пять измерений

Satisfaction & Well-being — удовлетворённость и благополучие

Это измерение, которое до SPACE почти никто не измерял системно в контексте продуктивности разработчиков. Речь идёт о том, насколько разработчик доволен своими инструментами, процессами, командой, и не выгорает ли он. Измеряется в основном через опросы: eNPS (employee Net Promoter Score), вопросы о выгорании, удовлетворённости инструментами, и так далее. Это перцептивная метрика — она основана на ощущениях людей, а не на данных из систем, и это совершенно нормально. Исследования показывают, что удовлетворённость разработчиков сильно коррелирует с их продуктивностью и удержанием, так что измерять её не менее важно, чем считать время сборки.

Performance — производительность

Здесь речь про результаты работы разработчика или команды с точки зрения качества и влияния на бизнес. Это не про количество строк кода или закрытых тикетов — скорее про надёжность сервисов, отсутствие регрессий, удовлетворённость конечных пользователей. Метрики: Change Failure Rate (да, DORA-метрика сюда тоже входит), customer satisfaction, availability. Это измерение сложнее всего операционализировать, потому что связь между работой конкретного разработчика и бизнес-результатом часто неочевидна и опосредована множеством факторов.

Activity — активность

Количественные метрики того, что разработчик делает: количество PR-ов, коммитов, code review, деплоев, закрытых тикетов. Это самое опасное измерение, потому что его проще всего измерить и проще всего неправильно интерпретировать. Авторы SPACE особо подчёркивают, что метрики активности никогда нельзя использовать изолированно — десять PR-ов в день могут означать как гиперпродуктивность, так и декомпозицию одного нормального PR-а на десять бессмысленных, чтобы хорошо выглядеть в дашборде. Activity-метрики работают только в связке с другими измерениями.

Communication & Collaboration — коммуникация и сотрудничество

Как хорошо команда общается и работает вместе: скорость code review, качество обратной связи, участие в обсуждениях, доступность документации, время ответа на вопросы. Это измерение особенно важно для распределённых команд, где проблемы коммуникации могут быть невидимы менеджменту. Метрики: время первого ответа на PR, количество итераций code review, результаты опросов о качестве взаимодействия в команде, network analysis коммуникаций (кто с кем взаимодействует и есть ли изолированные участки).

Efficiency & Flow — эффективность и поток

Способность разработчика выполнять работу без прерываний и лишних препятствий: время на глубокую работу без прерываний, количество контекст-свитчей, время ожидания в процессах (ожидание code review, ожидание CI, ожидание доступов). Это измерение ближе всего к тому, что разработчики на самом деле чувствуют каждый день — раздражение от медленного CI, фрустрацию от бесконечных митингов, которые разрывают рабочий день на куски, удовлетворение от продуктивного дня, когда всё шло гладко.

Перцептивные vs поведенческие метрики

Одна из самых ценных идей SPACE — это чёткое разделение метрик на перцептивные (основанные на ощущениях людей, собираются через опросы) и поведенческие (основанные на данных из систем, собираются автоматически). Авторы настаивают, что обе категории одинаково важны, и что попытка свести всё к «объективным» поведенческим метрикам — это ошибка. Разработчик может объективно иметь быстрый CI, но субъективно чувствовать, что всё тормозит, потому что его рабочий день устроен так, что он постоянно переключается между задачами и никогда не видит результат своей работы целиком. Без перцептивных метрик вы это не увидите.

Опыт Microsoft

Microsoft — одна из немногих компаний, которая открыто делится опытом применения SPACE внутри организации. В блоге Microsoft Research и докладах на ICSE команда описывает, как они проводят регулярные опросы разработчиков, комбинируют их с данными из Azure DevOps и GitHub, и используют результаты для принятия решений о приоритетах платформенной команды. Важный урок, который они вынесли: метрики нужно обсуждать с командами, а не спускать сверху, и никогда не использовать для сравнения людей между собой. SPACE — это инструмент для команды, чтобы понять, что улучшить, а не инструмент для менеджера, чтобы ранжировать разработчиков.

Как начать применять

Для команд в российских компаниях стоит начинать с двух шагов. Первый — запустите простой опрос удовлетворённости (Satisfaction). Пять-семь вопросов раз в две недели или раз в месяц: насколько вы довольны инструментами, процессами, скоростью получения обратной связи, возможностью делать глубокую работу. Это даст вам перцептивные метрики с минимальными усилиями. Второй — начните собирать базовые Activity-метрики из вашего CI/CD и системы управления задачами: время прохождения pipeline, время жизни PR, количество деплоев. Не для оценки людей — для понимания трендов и выявления узких мест. А когда у вас будут данные из хотя бы двух измерений, вы сможете увидеть интересные паттерны: например, команда говорит в опросе, что всё медленно, а данные показывают, что CI проходит за три минуты — значит, проблема не в CI, а в чём-то другом, и стоит копнуть глубже. Для ещё более сфокусированного взгляда на повседневный опыт разработчиков стоит также рассмотреть DevEx Framework, который выделяет три конкретных измерения: feedback loops, когнитивную нагрузку и состояние потока.