День 2366. #ProjectManagement
Измеряем Продуктивность Разработчиков. Начало
В мире разработки ПО измерение продуктивности остаётся одним из самых сложных, но в то же время критически важных аспектов управления командами разработчиков. В то время как другие бизнес-функции часто можно оценить с помощью простых метрик, разработка ПО представляет собой уникальную задачу из-за своей командной, сложной и творческой природы.

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

Проблема измерения продуктивности
Измерение производительности труда разработчиков - сложная задача по нескольким причинам:
- Разработка ПО предполагает творческое решение задач, которое сложно выразить количественными показателями;
- Связь между входными и выходными данными значительно менее очевидна, чем в других бизнес-функциях;
- Разработка в значительной степени предполагает совместную работу, что затрудняет оценку индивидуального вклада;
- Различные уровни работы (системы, команды, отдельные лица) требуют разных подходов к измерению.

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

Однако по мере роста команд разработки и увеличения инвестиций организаций в инженерных специалистов подход «мы не можем это измерить» становится всё более несостоятельным.

Метрики, которые не работают (и почему)
Прежде чем углубляться в практические подходы к измерению, давайте рассмотрим некоторые распространённые, но проблемные метрики.

1. Строки кода (KLOC)
Хотя их легко измерить, строки кода — самый известный пример метрики тщеславия. Больше кода не обязательно означает лучше, и эта метрика может активно поощрять неэффективные практики:
- Поощряет многословный, неэффективный код;
- Игнорирует качество и поддерживаемость кода;
- Сильно варьируется в зависимости от языка программирования;
- Легко поддаётся манипуляциям.

2. Количество коммитов
Как и количество строк кода, измерение чистого количества коммитов мало что даёт знать о фактической производительности:
- Разработчики могут чаще вносить незначительные изменения, чтобы «обмануть» систему;
- Не отражает качество или ценность изменений;
- Игнорирует разницу в сложности между коммитами.

3. Отработанные часы
Время, затраченное на кодирование, не обязательно коррелирует с полученной ценностью:
- Поощряет презентеизм (видимость присутствия на работе), а не эффективность;
- Игнорирует качество выполненной работы;
- Может привести к выгоранию и снижению долгосрочной производительности.

Продолжение следует…

Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4