Как измерять эффективность разработчиков: DORA, GSM, SPACE, DevEx, McKinsey

DORA — DevOps Research and Assessment

Методика DORA (DevOps Research and Assessment — 2014), авторами которой являются Николь Форсгрен, Джез Хамбл и Джин Ким, включает в себя набор показателей эффективности, известных как «Четыре ключевые метрики«. Эти метрики помогают компаниям оценивать успешность их DevOps-процессов. 

  1. Время выполнения изменений (Lead time for changes) — это время между коммитом и продакшеном. Элитные разработчики делают это менее чем за час, а средним требуется от одного дня до недели. 
  2. Частота развертывания (Deployment frequency) — это частота отправки изменений. Элитные разработчики делают это несколько раз в день, а средние — от одного раза в месяц до одного раза в полгода. 
  3. Среднее время восстановления (Mean time to recovery) — это среднее время, которое требуется команде для восстановления сервиса при сбоях. Элитные команды делают это менее чем за час, а средние — от одного дня до недели. 
  4. Коэффициент отказов изменений (Change failure rate) — это процент релизов, которые привели к даунтайму. У элитных исполнителей этот показатель составляет 0-15 %, а у средних — 16-30 %.

Время подготовки к внесению изменений и частота развертывания показывают скорость работы команды и то, насколько быстро она реагирует на постоянно меняющиеся потребности клиентов. Стабильность обслуживания и то, насколько оперативно группа реагирует на перебои в работе, показывают среднее время восстановления и частота отказов при изменениях. Сравнивая все четыре основных критерия, можно оценить, насколько успешно компания балансирует между скоростью и стабильностью.

GSM — Цели/сигналы/метрики

Фреймворк «Цели/сигналы/метрики» (GSM — 2018.) В Google используют метрику «Цели/сигналы/метрики (GSM)». В этой методике: 

  1. Сначала вы соглашаетесь с тем, что есть проблема, которую нужно решить. 
  2. Затем вы ставите цель, которой хотите достичь, и решаем, какие сигналы, если они актуальны, будут свидетельствовать о том, что мы добились прогресса.
  3. Наконец, мы приходим к метрикам, которые хотим измерить — но больше фокусируемся на желаемом результате, а не только на метрике.

Например, цель может звучать так: «Убедиться, что у инженеров будет больше времени на концентрацию усилий», сигналы могут быть такими: «Инженеры сообщают о меньшем количестве случаев перегруженности совещаниями», а метрики — «Время концентрации инженеров». 

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

Можете посмотреть это видео от Google, если хотите узнать больше об этой методике.

Данная методика также применяется, например, в Linkedin.

SPACE (SPACE of Developer Productivity — 2021) 

В недавнем исследовании Николь Форсгрен и ее коллег «The SPACE of Developer Productivity» авторы определяют свой фреймворк как «систематический подход к измерению, пониманию и оптимизации продуктивности инженеров». Он побуждает руководителей применять комплексный подход к эффективности, передавая метрики друг другу и увязывая их с целями команды. 

Пять аспектов Space Framework классифицируют производительность труда инженеров:

  • S — Удовлетворенность и благополучие. Здесь мы измеряем, насколько члены нашей команды удовлетворены и счастливы, с помощью опросов. Почему мы это делаем? Потому что удовлетворенность коррелирует с производительностью. Несчастные команды, которые работают продуктивно, перегорают раньше. 
  • P — Производительность. Этот показатель также сложно определить количественно, поскольку производство большего количества кода в единицу времени не является показателем качественного кода или эффективности. Здесь мы можем измерить уровень дефектов или уровень отказов изменений, что означает процент развертываний, приводящих к отказу в производстве. Каждая потеря производительности вредит продуктивности команды. Кроме того, если мы подсчитаем количество слитых PR со временем, это будет коррелировать с производительностью. 
  • A — Деятельность. Деятельность (активность) обычно заметна. Здесь мы можем измерить количество коммитов в день или частоту развертывания, то есть как часто мы отправляем новые функции в прод.
  • С — Сотрудничество и общение. Для создания продуктивной команды необходимо широкое и эффективное сотрудничество между отдельными людьми и командами. Кроме того, продуктивные команды обычно опираются на высокую прозрачность и осведомленность о работе других людей. Здесь мы можем измерить время рассмотрения пулл реквестов, качество митингов, и обмен знаниями. 
  • E — Эффективность и поток. С помощью рабочего потока мы измеряем индивидуальную эффективность, позволяющую быстро и без перерывов завершить определенную работу, а эффективность означает то же самое, но на уровне команды. Цель — создать среду, в которой разработчики смогут ощущать и поддерживать поток в течение как можно более длительного периода времени каждый день, при этом помогая им чувствовать себя довольными своей рутиной.

Авторы методики рекомендуют согласовывать эти аспекты с целями компании и приоритетами команды. Во-первых, когда команда выбирает метрику, это отражает ценности команды. Мы начинаем с показателей на уровне команды, а когда добьемся успеха, сможем распространить их на всю организацию.

DevEx (Developer Experience, 2023) 

В последней статье Аби Нода, Маргарет-Энн Сторей, Николь Форсгрен и Микаэлы Герилер для ACM Queue под названием «DevEx: что на самом деле способствует продуктивности» авторы представили фреймворк для измерения и улучшения опыта разработчиков (DevEx). 

Они обнаружили, что разработчики счастливы, когда чувствуют себя продуктивными. Таким образом, они могут обеспечить максимальную ценность только при наличии препятствий. Плохой developer experience вызывают такие вещи: прерывания, плохой инструментарий, нереальные сроки, работа над малозначимыми задачами и т. д. 

Авторы выделили три основных измерения опыта разработчиков, которые оказывают непосредственное влияние:

  • Петли обратной связи (Feedback loops) — скорость и качество реакции на выполненные действия.
  • Когнитивная нагрузка (Cognitive load) — объем умственной обработки, необходимый разработчику для выполнения задачи 
  • Состояние потока (Flow state) — психическое состояние, при котором человек, выполняющий какую-либо деятельность, полностью погружен в ощущение энергичной сосредоточенности, полной вовлеченности и удовольствия.

Итак, чтобы создать метрики DevEx, мы можем использовать три их основных измерения с помощью двух методов:

  • Восприятие (Perceptions) — Собирается с помощью опросов. Можем спросить, насколько сложна кодовая база, или насколько легко понять документацию.
  • Рабочие процессы (Workflows) — Собираются из систем. Здесь мы можем проверить время, необходимое для получения ответов на технические вопросы, или частоту улучшения документации. 

В DevEx мы должны фиксировать восприятие разработчиков и их рабочие процессы. Выбор правильных KPI важен для отслеживания общей эффективности.

Методика измерения производительности разработчиков от McKinsey 

А как же спорный текст о производительности разработчиков от McKinsey, вызвавший множество дискуссий и реплик? 

Они разработали метод, который основывается на существующих показателях производительности и направлен на выявление возможностей для повышения эффективности работы. Внедрение этого подхода привело к значительным улучшениям, включая сокращение количества дефектов в продуктах, улучшение опыта сотрудников и повышение удовлетворенности клиентов. 

Для измерения производительности разработчиков необходима тонко настроенная система. Существует три основных типа показателей, которые необходимо учитывать:

  • Метрики уровня системы: Это широкие метрики (например частота развертывания), которые дают представление о производительности системы.
  • Метрики уровня команды: Учитывая коллаборативную природу разработки ПО, командные метрики фокусируются на коллективных достижениях. Например, если частота развертывания может быть хорошей метрикой для систем или команд, то для отслеживания индивидуальной производительности она не подходит. 
  • Метрики индивидуального уровня: Эти метрики нацелены на производительность отдельных разработчиков.

Два набора отраслевых метрик стали основополагающими в этой области. Первый — это метрики DORA, а второй — метрики SPACE, о которых говорится выше. Подход McKinsey дополняет их, вводя метрики, ориентированные на возможности, которые дают комплексное представление о производительности разработчиков. 

Эти метрики включают в себя следующее: 

  • Затраты времени во внутреннем/внешнем контуре (Inner/outer loop time spent): деятельность по разработке ПО распределяется по внутреннему и внешнему контуру. Внутренний контур включает в себя такие виды деятельности, как кодирование, сборку и тестирование, в то время как внешний включает в себя задачи, которые разработчики должны выполнить, чтобы пушить свой код в прод: интеграция, релиз и развертывание. Мы должны максимально увеличить время, которое разработчики проводят во внутреннем контуре. Лучшие технологические компании стремятся к тому, чтобы разработчики тратили до 70 % своего времени на создание внутренних контуров.
  • Индекс скорости разработчиков (Developer Velocity Index): Это исследование измеряет технологию, практику работы и организационные возможности компании и сравнивает их с аналогами. 
  • Анализ вклада (Contribution analysis): предполагает оценку вклада отдельных сотрудников в бэклог команды. С помощью такого анализа тимлиды могут установить четкие ожидания от результатов, что повысит эффективность работы. 
  • Возможности талантов (Talent capability): Этот показатель описывает уникальные знания, навыки и способности организации, основанные на стандартных картах возможностей (capability maps). Распределение навыков в виде «бриллианта», когда большинство разработчиков находятся в среднем диапазоне компетенций — это то, к чему в идеале должны стремиться компании.

Techworld with Milan


Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас