В начале 2021 года в профессиональном журнале ACM Queue был представлен
фреймворк SPACE для анализа продуктивности разработчиков, созданный авторами Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck и Jenna Butler.
Авторы разработали фреймворк SPACE, чтобы охватить разные измерения продуктивности разработчиков (
Developer Productivity). Фреймворк предоставляет способ логично и системно осмыслять продуктивность в широком контексте, выбирать сбалансированные метрики исходя из целей, выявлять компромиссы, а также понимать ограничения метрик при изолированном использовании или в неподходящем контексте.
Фреймворк SPACE выделяет пять основных измерений (
Dimensions) продуктивности разработчиков:
- Удовлетворенность и благополучие (Satisfaction and well-being);
- Результативность (Performance);
- Активность (Activity);
- Коммуникацию и сотрудничество (Communication and collaboration);
- Эффективность и поток (Efficiency and flow).
Эти измерения рассматриваются на трех уровнях: индивидуальном (
Individual), командном (
Team or Group) и системном (
System).
Удовлетворенность и благополучие (Satisfaction and well-being)- Удовлетворенность (Satisfaction) — насколько разработчики чувствуют себя реализованными в своей работе, команде, инструментах или культуре;
- Благополучие (Well-being) — насколько разработчики здоровы и счастливы, как работа влияет на эти состояния.
Это измерение чаще всего оценивается с помощью опросов, поскольку отражает личное восприятие и не может быть получено из телеметрии. Примеры метрик:
- Удовлетворенность сотрудников (Employee satisfaction). Насколько сотрудники удовлетворены и готовы рекомендовать свою команду другим.
- Эффективность разработчиков (Developer efficacy). Есть ли у разработчиков необходимые инструменты и ресурсы для выполнения работы.
- Выгорание (Burnout). Истощение, возникающее из-за длительного и чрезмерного рабочего стресса.
Результативность (Performance)Результативность — итог работы системы или процесса. Это измерение рекомендуется оценивать через результаты (
Outcomes), а не через объем выполненной работы (
Output). Примеры метрик:
- Качество (Quality). Надежность, отсутствие ошибок, стабильность работы сервиса (Reliability, absence of bugs, ongoing service health).
- Влияние (Impact). Удовлетворенность клиентов, новый функционал, удержание клиентов, снижение затрат (Customer satisfaction, customer adoption and retention, feature usage, cost reduction).
Активность (Activity)Активность — количество действий или результатов работы, выполняемых в процессе выполнения задач. Примеры метрик:
- Проектирование и разработка (Design and coding). Объем или количество проектных документов и спецификаций, рабочих элементов, пул-реквестов, коммитов и код-ревью (Volume or count of design documents and specs, work items, pull requests, commits, and code reviews);
- Непрерывная интеграция и развертывание (Continuous integration and deployment). Количество сборок, тестов, деплоев и использование инфраструктуры (Count of build, test, deployment/release, and infrastructure utilization);
- Операционная деятельность (Operational activity). Количество или объем инцидентов и проблем, распределение по их критичности, участие в дежурствах, устранение инцидентов (Count or volume of incidents/issues and distribution based on their severities, on-call participation, and incident mitigation).
Коммуникация и сотрудничество (Communication and collaboration)Коммуникация и сотрудничество отражают то, как люди и команды взаимодействуют и работают вместе. Эта деятельность включает коммуникацию, координацию и взаимодействие (
Communication, coordination, and collaboration) внутри команд и между ними. Часть деятельности в этом измерении трудно поддается количественной оценке, включая невидимую работу (
Invisible work) и деятельность (
Articulation work), связанную с планированием и распределением задач. Примеры метрик:
- Находимость документации и экспертизы (Discoverability of documentation and expertise);
- Насколько быстро работа интегрируется;
- Качество ревью (Quality of reviews), выполняемых членами команды;
- Сетевые метрики (Network metrics), отражающие взаимодействие между участниками;
- Время адаптации (Onboarding time) и улучшение опыта новых сотрудников.
Эффективность и поток (Efficiency and flow)Эффективность и поток отражают способность выполнять работу или продвигаться в ней с минимальными прерываниями или задержками — как на индивидуальном уровне, так и на уровне системы. Это измерение описывает, насколько согласованы и связаны виды деятельности внутри команды и между командами. Индивидуальная эффективность обычно оценивается количеством непрерывного времени фокусировки или временем, проведенным в приложениях, создающих ценность (например, временем работы в IDE). На уровне команды и системы эффективность связана с потоком создания ценности (
Value-stream mapping), который отражает путь от появления идеи до поставки пользователю. В этом контексте также используются метрики
Deployment frequency и
Lead time for changes из
модели DORA. Примеры метрик:
- Количество передач задач (Number of handoffs) внутри команды или между командами;
- Насколько разработчики могут оставаться в состоянии потока (Stay in flow) и завершать работу;
- Прерывания (Interruptions): количество, время, интервалы и влияние на работу и поток;
- Временные показатели движения работы через систему: общее время (Total time), время, создающее ценность (Value-added time), время ожидания (Wait time).
Рекомендации авторов по применению фреймворка SPACE:
- Используйте несколько метрик из разных измерений. Команды, руководители и отдельные разработчики должны смотреть не на одну метрику, а на набор показателей из разных измерений SPACE. Практический минимум — три метрики из разных измерений;
- Обязательно включайте метрики по данным опросов. Хотя бы одна из метрик должна опираться на данные опросов или самооценку разработчиков. Такие данные помогают увидеть то, что не видно в телеметрии и метриках активности;
- Сохраняйте баланс и не перегружайте систему метриками. Метрики из разных измерений могут находиться в напряжении друг с другом, и это нормально: это дает более честную картинку. Но слишком большое количество метрик приводит к путанице и снижает мотивацию. Лучше небольшой набор показателей из нескольких измерений, чем длинный перечень целей;
- Метрики определяют поведение. Измеряемые показатели воспринимаются как значимые и задают фокус для команд. Поэтому выбор метрик должен быть осознанным и соответствовать целям организации;
- Учитывайте конфиденциальность и смещения в данных. Результаты стоит публиковать только в анонимизированном и агрегированном виде, на уровне команды или группы. Индивидуальный анализ возможен как инструмент для самого разработчика. При работе с данными нужно учитывать возможные смещения и внешние факторы, которые могут влиять на метрики.
Пример от авторов по применению фреймворка SPACE для практики Code Review:
- Удовлетворенность. Метрики, связанные с процессом код-ревью, могут показывать, насколько разработчики воспринимают эту работу как положительную или отрицательную — например, создаются ли условия для обучения, наставничества или участия в развитии и улучшении кодовой базы;
- Результативность. Скорость выполнения ревью (Code-review velocity) может показывать как индивидуальную скорость выполнения ревью, так и ограничения команды, эта метрика относится одновременно к индивидуальному и командному уровням;
- Активность. Количество завершенных код-ревью — индивидуальная метрика, показывающая, сколько ревью выполнено за определенный период и как это вносит вклад в итоговый продукт;
- Коммуникация и сотрудничество. Код-ревью является формой сотрудничества через код, и оценка качества или глубины ревью может использоваться как качественная метрика взаимодействия и коммуникации;
- Эффективность и поток. Код-ревью — важная часть процесса, но может создавать проблемы, если прерывает рабочий поток или если задержки ограничивают движение задач в системе. Аналогично, ожидание ревью может замедлять возможность разработчика продолжать работу.
Ниже приведена примерная таблица от авторов, показывающая, как метрики могут распределяться по измерениям фреймворка SPACE. Таблица не является исчерпывающей: она иллюстрирует подход к выбору и группировке метрик на индивидуальном, командном и системном уровнях. Конкретный набор метрик должен определяться контекстом и целями: