SPACE
В исследовании «SPACE of Developer Productivity» (2021) авторы определили методику SPACE (которую они предпочитают называть фреймворком) как систематический подход к измерению, осмыслению и оптимизации производительности инженеров-разработчиков. Методика, по заявлениям авторов, помогает менеджерам продуктов применять комплексный взгляд на производительность, эффективно передавая результаты оценки внутри компании, и увязывая текущие оценки с целями команды.
Описанные пять аспектов, классифицирующие производительность разработчиков, составляют суть Space Framework:
S: Satisfaction and Well-Being (Удовлетворенность)
Мы измеряем, насколько удовлетворены и счастливы члены нашей команды. Как правило, с помощью опросов. Почему мы это делаем? Потому что удовлетворенность
коррелирует с производительностью. Условно «несчастные» команды, которые работают продуктивно — выгорают раньше.
Р: Собственно Performance (Производительность)
Этот показатель трудно определить количественно, поскольку продуцирование большого количества кода за единицу времени не является надежной мерой качества кода или производительности труда разработчиков. Здесь мы можем измерить следующее: количество дефектов, или частоту неудачных изменений чего-то, например процент неудачных деплоев на проде. Каждая подобная ситуация свидетельствует о проблемах с продуктивностью команды. Также можно судить о продуктивности по количеству слитых пулл-реквестов за единицу времени, оно будет более-менее точно коррелировать с общей производительностью команды.
A: Activity (Активность)
Активность обычно видна. Здесь можно измерить количество коммитов в день или частоту деплоев, т.е. как часто доставляются новые функции на прод.
C: Collaboration and Communication (Сотрудничество и коммуникация)
Для создания продуктивной команды необходимо широкое и эффективное сотрудничество между отдельными сотрудниками и группами. Кроме того, продуктивные команды опираются на высокую прозрачность и осведомленность о работе других людей. Здесь мы можем измерить время ревью пулл-реквестов, качество митингов, и обмен знаниями.
E: Efficiency and Flow (Эффективность и поток)
Поток измеряет индивидуальную эффективность, позволяющую быстро и без перерывов выполнить определенную работу, в то время как эффективность означает то же самое, но на уровне команды. Цель — создать такую среду, в которой разработчики могли бы поддерживать свой поток как можно дольше каждый день; а также помогать им чувствовать себя удовлетворенными своей задачей.
Для реализации фреймворка SPACE авторы рекомендуют согласовать три области внимания с целями компании и приоритетами команды. Во-первых, когда команда выбирает показатель, это отражает ценности команды. Здесь мы хотим начать с показателей на уровне команды, а когда мы добьемся успеха, то сможем распространить показатели на всю организацию.
DORA
Еще одним способом измерения производительности команды являются метрики DORA. С помощью этих показателей мы оцениваем работу команды по следующим параметрам:
- Время подготовки изменений (Lead time for changes) — время между коммитом и поступлением в прод. Элитные команды справляются с этой задачей менее чем за час, в то время как средним командам требуется от одного дня до недели.
- Частота деплоя (Deployment frequency) — частота отправки изменений. Лучшие команды делают это несколько раз в день, средние — от одного раза в месяц до одного раза в полгода.
- Среднее время восстановления (Mean time to recovery) — среднее время, которое требуется команде для восстановления работоспособности при возникновении сбоев. Элитные команды делают это менее чем за час, средние — от одного дня до недели.
- Коэффициент отказов после изменений (Change failure rate) — процент релизов, которые приводят к простоям. У элитных команд этот показатель составляет 0-15%, а у средних — 16-30%.
Время подготовки изменений и частота развертывания показывают скорость работы команды и то, насколько быстро она реагирует на постоянно меняющиеся потребности клиентов. О стабильности обслуживания и о том, насколько оперативно группа реагирует на перебои и сбои в работе, говорят среднее время восстановления и частота отказов при изменениях.
Сравнивая все четыре основных критерия, можно оценить, насколько успешно компания балансирует скорость и стабильность.
GSM
Существуют и другие системы оценки продуктивности, например, подход Цели/Сигналы/Метрики (Goals/Signals/Metrics, GSM), принятая в Google. В этой методике сначала соглашаешься с тем, что есть проблема, которую нужно решить, затем ставишь цель, которую хочешь достичь, и решаешь, какие показатели будут свидетельствовать о том, что мы добились прогресса (сигналы). Наконец, мы приходим к метрикам, которые хотим измерить, но при этом больше внимания уделяем желаемому результату, а не только метрике. Например, цель может звучать так: «Убедиться, что у инженеров будет больше времени на концентрацию внимания», сигналы могут звучать так: «Инженеры сообщают о меньшем количестве случаев перегруженности совещаниями», а метрики могут звучать так: «Время концентрации внимания инженеров». Для метрик можно создать дашборд, который будет собирать все в одном месте, для наглядности и простоты анализа.
Источник. Это сокращенная версия статьи о том как строится правильная high-performing team.
Бонус: видеопрезентация Improving Engineering Productivity at Scale от Staff Software Engineer в Google Inc:
