Самый плохой программист, которого я знаю

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

Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю ^[1], её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон ^[2]. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.

Прим. пер.: это перевод статьи The Worst Programmer I Know ^[3] Дэна Норта.

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

Вместо этого мы должны были измерять количество реализованных стори, или это могли быть сторипоинты (оказалось, что это неважно ^[4]), потому что они представляют ценность для бизнеса. Мы пользовались чем-то наподобие Jira: люди должны были указывать своё имя напротив стори, благодаря чему мы очень легко могли генерировать эти метрики продуктивности.

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

Было очевидно, что Тима нужно увольнять. К такому выводу пришёл менеджер, и он попросил произвести необходимые приготовления для увольнения Тима и замены его на того, кто сможет выполнять стори.

Я без лишних слов отказался. Это даже не было трудным решением для меня, я просто сказал «нет».

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

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

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

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

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

tl;dr

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

Просто не пытайтесь измерять личный вклад единицы в сложной адаптивной системе, потому что сама постановка вопроса ошибочна.

Например, метрики DORA связаны с тем, как работает система работы, будь то показатели культуры Вестрама или поток технических изменений в продакшене. Они измеряют показатели двигателя, а не вклад отдельных поршней, потому что это не имеет никакого смысла ^[5].

И ещё: если у вас появится шанс поработать с Тимом Маккинноном, сделайте это.