День 1690. #Карьера
Худший Программист, Которого Я Знаю
Самое замечательное в измерении продуктивности разработчиков заключается в том, что вы можете быстро выявить плохих программистов. Я хочу рассказать вам о худшем программисте, которого я знаю, и почему я боролся за то, чтобы удержать его в команде. Его зовут Тим Маккиннон, и я хочу, чтобы вы знали, насколько он непродуктивен.

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

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

Это подводит меня к Тиму. Оценка Тима стабильно была нулевой. Ноль! Не просто низкой или имеющей тенденцию к снижению, а буквально нулевой. Неделя за неделей, итерация за итерацией. Ноль очков у Тима.

Что ж, Тиму явно пора было уходить. Таков был вывод менеджера, и он попросил меня принять необходимые меры, чтобы Тима уволили и заменили кем-то, кто будет… творить истории. Но я наотрез отказался. Для меня это даже не было трудным решением, я просто сказал «нет».

Видите ли, причина того, что показатель продуктивности Тима был нулевым, заключалась в том, что он никогда не подписывался ни на какие истории. Вместо этого он проводил день в парах с разными товарищами по команде. Менее опытным разработчикам он терпеливо позволял писать код, планомерно подталкивая их к решению. Он не собирался давить на них или мешать им, а позволял им тратить время на обучение, тщательно создавая моменты озарения и обучения, часто в виде сократовских вопросов: а что, если?, а как ещё?

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

Тим не поставлял ПО; Тим руководил командой, которая поставляла ПО. Вся команда становилась более эффективной, более продуктивной, более слаженной и более веселой, потому что Тим был в команде.

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

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

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

Источник: https://dannorth.net/2023/09/02/the-worst-programmer/
Автор оригинала: Дэн Норт