Нулевая продуктивность по метрикам
Все началось, когда крупный банк решил внедрить индивидуальные показатели эффективности «для целей оценки и личного развития». После тщательного обсуждения руководство решило измерять количество выполненных story points (SP), считая, что это отражает бизнес-ценность.
Система была простой: разработчики указывали свои имена напротив SP в Jira, что позволяло легко генерировать метрики продуктивности. И тут появляется Тим Маккиннон.
«Показатель Тима был стабильно равен нулю. Нулю! Не просто низкий или снижающийся, а буквально ноль. Неделя за неделей, итерация за итерацией. Ноль баллов для Тима», — пишет автор.
Руководитель пришел к очевидному выводу: Тима нужно уволить и заменить кем-то, кто действительно выполняет SP. Но автор статьи наотрез отказался это делать.
Невидимый вклад
«Причина, по которой показатель продуктивности Тима был равен нулю, заключалась в том, что он никогда не брал на себя никаких SP. Вместо этого он проводил свой день в парном программировании с разными членами команды», — объясняет автор.
С менее опытными разработчиками Тим терпеливо позволял им вести процесс, аккуратно направляя их к решению. Он не давил на них и не подавлял их инициативу, а создавал моменты озарения, часто используя сократические вопросы, предлагая альтернативные подходы и варианты решения проблем.
С опытными разработчиками это больше напоминало совместное творчество или спарринг: объединение разных взглядов на проблему для создания решения лучше, чем каждый из них придумал бы в одиночку. «Тим — чертовски хороший программист, и ты всегда чему-то учишься, работая с ним в паре», — отмечает автор.
Создание команды, а не кода
«Тим в меньшей степени писал код; Тим создавал команду, которая создавала программное обеспечение. Вся команда становилась более эффективной, более продуктивной, более сплоченной, более веселой, потому что Тим был в команде», — пишет автор статьи.
Когда руководитель заходил в офис, он всегда видел Тима, сидящего с кем-то другим, работающего над «их» задачей. И можно было быть уверенным, что качество этой работы будет значительно выше, а время до получения ценности значительно ниже, чем когда Тим не работал с людьми в паре.
В итоге Тима оставили в команде, а индивидуальные метрики продуктивности тихо заменили на командную ответственность. Команда начала отслеживать и отмечать бизнес-влияние, которое они, как высокоэффективное подразделение, оказывали на организацию.
Что говорит сообщество
Многие разработчики в комментариях к оригинальному посту поделились похожими мыслями о проблемах измерения продуктивности разработчиков.
«Идея измерения индивидуальной продуктивности разработчика кажется мне абсурдной. Я не говорю, что то, что мы делаем — это магия, просто существует слишком много переменных», — отмечает пользователь morsecodist.
Другие разработчики рассказали о своем опыте работы с руководителями, одержимыми метриками:
«У меня был директор, одержимый статистикой GitHub Enterprise. Он запрещал объединять коммиты и говорил разрабам коммитить каждый день, даже если ты еще не закончил работу. Это было нужно, чтобы он мог видеть, кто пишет больше всего кода», — делится пользователь OnionBlender.
Многие согласились, что количество кода отрицательно коррелирует с ценностью: «Измерение продуктивности по написанным строкам кода активно препятствует написанию чистого, поддерживаемого кода без ошибок», — пишет lisper.
Пользователь suzzer99 сравнил измерение продуктивности разработчиков с квантовой механикой: «В тот момент, когда вы пытаетесь измерить ее, волновая функция схлопывается, и вы фундаментально изменяете то, что пытались измерить».
Выводы
История Тима Маккиннона показывает, что настоящая ценность разработчика не всегда может быть измерена стандартными метриками. Иногда самый ценный вклад — это то, как человек влияет на всю команду, повышая ее общую эффективность и качество работы.
Как отмечает автор статьи: «Измеряйте продуктивность, если хотите — я полностью за ответственность — в идеале как ощутимое бизнес-влияние, выраженное в сэкономленных, заработанных или защищенных долларах. Это обычно сложно, поэтому прокси-метрики бизнеса тоже подойдут. Просто не пытайтесь измерить индивидуальный вклад единицы в сложной адаптивной системе, потому что предпосылка вопроса ошибочна».
💻 Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»
А вы сталкивались с ситуациями, когда формальные метрики не отражали реальную ценность сотрудника? Как в вашей команде оценивают эффективность разработчиков?