Ник Ходжес решил порассуждать на тему KPI для разработчиков. Около 10 лет назад я написал сообщение в блоге под названием “Можем ли мы измерить производительность разработчиков?” В нем я обсудил множество объективных попыток, которые были предприняты для этого — строки кода, функциональные точки и т.д. Я также предложил некоторые субъективные меры. Тем не менее, вывод заключался в том, что, несмотря на желания менеджеров, любящих ключевые показатели эффективности, не существовало жизнеспособного способа измерить производительность отдельного разработчика программного обеспечения.

Я упоминаю об этой статье, опубликованной 10 лет назад, потому что с тех пор многое значительно изменилось. Когда я писал это, Git и Mercurial были известными и популярными системами управления версиями программного обеспечения. В то время я был менеджером по программному обеспечению, переводя свою команду с Visual Source Safe из Microsoft, и мы решили использовать Mercurial, потому что он был гораздо более удобен для Windows. Мы выбрали не ту лошадь, потому что в ближайшие годы Git станет стандартом де-факто для контроля версий. В результате вокруг репозиториев Git возникла кустарная индустрия. GitHub - это огромный бизнес, за который Microsoft заплатила 7,5 миллиарда долларов. Многие компании теперь предоставляют метрики для вашего кода в Git. И многие из этих компаний претендуют на то, чтобы измерять производительность разработчиков программного обеспечения.

Дай мне метрики

Если мы признаем, что можно измерить производительность разработчиков (предложение, с которым я не полностью согласен), мы должны спросить, следует ли нам это делать. Желание сделать это, безусловно, сильно. Менеджеры хотят знать, кто их лучшие разработчики, и им нужны показатели, которые помогут им во время оценки производительности. Отдел кадров хочет иметь возможность документировать проблемы с производительностью. Руководители компаний хотят знать, что деньги, которые они тратят, используются эффективно.

Даже если вы используете новые инструменты для измерения производительности отдельных разработчиков, эти показатели, скорее всего, будут искажены. Количество строк кода в наши дни считается показателем шутки. “Вам нужны строки кода? Я дам тебе строки кода!” Отличается ли количество коммитов в день или среднее время для первого PR-комментария? Если вы будете оценивать отдельных разработчиков по этим показателям, они, безусловно, улучшат их. Но какой ценой? Вероятно, за счет производительности команды.

Один мой бывший генеральный директор говорил, что разработка программного обеспечения - это командный вид спорта. Если сравнивать отдельных разработчиков друг с другом по какому-либо показателю, они начнут конкурировать друг с другом, особенно если на кону деньги и рекламные акции. А группа людей, соревнующихся друг с другом, - это не команда. Именно команды, а не отдельные разработчики, добиваются успеха в бизнесе программного обеспечения. Разработка программного обеспечения интересна в этом отношении. Фактическое кодирование часто лучше всего выполняется людьми, глубоко задумавшимися, но работа, которая происходит до и после написания кода, в значительной степени способствует успеху.

Измерьте команду

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

Тренер НБА Фил Джексон говорил: «Сила команды - в каждом отдельном члене. Сила каждого члена - это команда!. Это справедливо и для разработчиков: Сила команды разработчиков программного обеспечения заключается в каждом отдельном разработчике. Сила каждого разработчика - это команда. Вот почему вместо измерения производительности отдельного разработчика следует измерять производительность команды. Разработчики, работающие вместе как команда, стремящиеся к общей цели, - это то, чего действительно хотят менеджеры.

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

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