Подход к повышению эффективности разработчиков

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

Как улучшить то, что так сложно измерить? И как оценить эффективность ваших усилий, когда нет четкого стандарта для сравнения?

Недавно активизировались дискуссии о различных методиках измерения производительности разработчиков, таких как DORA и SPACE. Некоторые из этих методик подверглись критике за чрезмерное внимание к измерению выходных показателей разработчиков. Метрики вроде написанных строк кода, слияний коммитов или закрытых задач — плохой показатель производительности. Более того, отслеживание этих мер приводит к манипуляции системой и может демотивировать лучших исполнителей — во многих случаях написание меньшего количества кода или даже его удаление может быть самым продуктивным действием!

Так что же делать дальше?

Переосмысление проблемы: Акцент на опыт разработчика

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

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

Решение этой задачи требует другого подхода — фокусирования на улучшении опыта разработчика. Этот подход направлен на понимание повседневного опыта разработчиков и различных трудностей, с которыми они могут столкнуться на работе.

Хорошая новость в том, что измерение опыта разработчика — задача гораздо более управляемая, чем это может показаться. Можно просто спросить людей, каково им работать в их команде и чувствуют ли они, что могут работать на полную производительность. Затем нужно работать над пониманием основных причин их отзывов.

Измерение опыта разработчика: три основные составляющие

В начале этого года Николь Форгенсен и другие авторы опубликовали фантастические исследования об измерении опыта разработчиков и его влиянии как на вовлеченность разработчиков, так и на их производительность.

Эта методика сводит опыт разработчика к трем основным составляющим: обратная связь, когнитивная нагрузка и состояние потока.

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

1. Состояние потока

Решение сложных технических задач требует глубокой концентрации или нахождения в состоянии потока на длительные периоды. К сожалению, во многих организациях найти время для концентрации сложно. Перерывы из-за совещаний, сообщений в Slack/Teams и электронной почты вызывают переключение контекста и нарушают поток. К счастью, измерение этих перерывов — решаемая задача.

Ниже представлена картина типичного дня разработчика программного обеспечения и перерывов в его потоке работы:

И если мы сочетаем это с данными о самооценке производительности разработчиков, мы видим, что количество времени, отведенное на концентрацию/поток, действительно кажется значимым фактором.

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

2. Когнитивная нагрузка

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

Мы отслеживаем различные метрики, которые являются косвенными показателями когнитивной нагрузки, с которой сталкиваются разработчики. Один из таких показателей — количество сотрудников, участвующих в совместной работе, который часто влияет на воспринимаемую производительность. Он дает представление о том, сколько людей необходимо привлечь для выполнения работы? Если разработчикам нужно сотрудничать более чем с 7 или 8 людьми для завершения своей работы, они часто сообщают о трудностях в поддержании продуктивности.

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

Для того чтобы сделать эту информацию применимой на практике, полезно понимать, какие команды занимают время разработчиков. Анализируя, какой процент их рабочей недели уходит на межфункциональное сотрудничество, можно выявить, откуда исходит дополнительная когнитивная нагрузка, чтобы «защитить» разработчиков от чрезмерного сотрудничества.

3. Каналы обратной связи

Обратные связи относятся к скорости и качеству ответов на выполненную работу разработчика. Представьте типичный день в жизни разработчика — это пестрое полотно итеративных задач, тесно переплетенных с обратной связью от различных источников. Разработчики получают спецификации от продуктовых команд, запрашивают уточнения, а затем оказываются в ожидании обратной связи. Они могут отправить свой код на ревью, но затем приходится остановиться, ожидая одобрения или запросов на изменения, которые временно замедляют их прогресс. И, пожалуй, самое важное — это петля обратной связи, которая соединяет их с пульсом их работы: отзывы клиентов. Как быстро идея может превратиться в ощутимую функцию в руках клиента? Исследования подчеркивают, что сокращение этих циклов обратной связи имеет ключевое значение для повышения производительности разработчиков.

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

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

‍Циклы ревью кода и обратной связи также измеримы и могут предоставить полезную информацию о трениях в процессе разработки.

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

Измерение опыта разработчика

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

Раздел опыта разработчика	Метрики для отслеживания
Состояние потока	Время потока (блоки по 2 часа и более непрерывной работы) Время фокусировки (блоки по 1 часу непрерывной работы) Потерянное время (блоки, если < 1 час) Переключения контекста (количество смены типа работы)
Когнитивная нагрузка	Количество переключений контекстов (типа работы) Количество основных сотрудников (Количество сотрудников, с которыми проводится более 2+ часов в неделю) Взаимодействие между командами (Количество времени, затраченное на сотрудничество с другими командами) Сотрудничество вне технической сферы (Сотрудничество с членами команды вне технической области) Накладные расходы Scrum (Время, выделенное на процессы, связанные со Scrum, например, стендапы и ретроспективы)
Обратная связь	Время ответа на тикеты JIRA/Asana Длительность цикла ревью PR (PR review Cycle Length) Сделанные коммиты в репозиторий Количество комментариев в репозитории (объем комментариев) Время ответа разработчика на входящее сообщение Время ответа менеджера (время ответа на личные сообщения менеджера в Slack) Частота личных встреч один на один
Прочие метрики благополучия	Количество сообщений, полученных после рабочего времени Продолжительность рабочего дня (оценка длительности рабочего дня / сверхурочные)

Попробуйте собрать эти метрики в своих системах, чтобы оценивать благополучие разработчиков.

Перевод статьи Developer Experience: A Developer-Centric Approach to Productivity из блога Worklytics.