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

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

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

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

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

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

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

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

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

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

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

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

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

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

tl;dr

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

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

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

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