📊 🧑‍💻 ⚠️ «Худший программист, которого я знаю»: когда нулевая продуктивность оказывается бесценной

Руководители часто одержимы измерением продуктивности разработчиков. Но что если самый ценный член команды не оставляет никаких следов в метриках? Именно такую историю рассказал Дэнни Норт в своей статье о «худшем программисте, которого он когда-либо знал».

Нулевая продуктивность по метрикам

Все началось, когда крупный банк решил внедрить индивидуальные показатели эффективности «для целей оценки и личного развития». После тщательного обсуждения руководство решило измерять количество выполненных story points (SP), считая, что это отражает бизнес-ценность.

Система была простой: разработчики указывали свои имена напротив SP в Jira, что позволяло легко генерировать метрики продуктивности. И тут появляется Тим Маккиннон.

«Показатель Тима был стабильно равен нулю. Нулю! Не просто низкий или снижающийся, а буквально ноль. Неделя за неделей, итерация за итерацией. Ноль баллов для Тима», — пишет автор.

Руководитель пришел к очевидному выводу: Тима нужно уволить и заменить кем-то, кто действительно выполняет SP. Но автор статьи наотрез отказался это делать.

Невидимый вклад

«Причина, по которой показатель продуктивности Тима был равен нулю, заключалась в том, что он никогда не брал на себя никаких SP. Вместо этого он проводил свой день в парном программировании с разными членами команды», — объясняет автор.

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

С опытными разработчиками это больше напоминало совместное творчество или спарринг: объединение разных взглядов на проблему для создания решения лучше, чем каждый из них придумал бы в одиночку. «Тим — чертовски хороший программист, и ты всегда чему-то учишься, работая с ним в паре», — отмечает автор.

Создание команды, а не кода

«Тим в меньшей степени писал код; Тим создавал команду, которая создавала программное обеспечение. Вся команда становилась более эффективной, более продуктивной, более сплоченной, более веселой, потому что Тим был в команде», — пишет автор статьи.

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

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

Что говорит сообщество

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

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

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

«У меня был директор, одержимый статистикой GitHub Enterprise. Он запрещал объединять коммиты и говорил разрабам коммитить каждый день, даже если ты еще не закончил работу. Это было нужно, чтобы он мог видеть, кто пишет больше всего кода», — делится пользователь OnionBlender.

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

Пользователь suzzer99 сравнил измерение продуктивности разработчиков с квантовой механикой: «В тот момент, когда вы пытаетесь измерить ее, волновая функция схлопывается, и вы фундаментально изменяете то, что пытались измерить».

Выводы

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

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

💻 Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»