Каждая компания в сфере разработки программного обеспечения имеет такого сотрудника. Вы знаете, о ком идёт речь. Они закрывают задачи за день, на выполнение которых обычным разработчикам потребуется неделя. Они как свои пять пальцев знают кодовую базу. Они могут отладить производственные инциденты, которые ставят в тупик целые команды. Руководство относится к ним как к уникумам. Инженеры избегают сидеть рядом с ними, потому что те заставляют всех остальных выглядеть плохо. И в глубине души вы задаётесь вопросом: не подхожу ли я для этой работы? Я просто средний?
Вот неприятная правда: миф о 10-кратном инженере в основном выдумка, и погоня за такими специалистами медленно отравляет вашу организацию. Более того, вы, возможно, уже поощряете поведение, которое создаёт иллюзию 10-кратного разработчика, систематически убивая долгосрочную производительность вашей команды.
Позвольте мне объяснить, почему это важно, и, что более важно, что вы на самом деле можете с этим сделать.
Миф о программисте «10х» и почему он существует
Концепция программиста «10х» предполагает, что некоторые разработчики в 10 раз продуктивнее своих компетентных коллег. Не в 10 раз лучше плохих разработчиков — в 10 раз лучше других хороших инженеров. Это идея о том, что один человек может сделать за день то, на что другому надёжному разработчику потребуется 10 дней.
Исследования, подтверждающие это утверждение, … ну, скажем так, «исторически оптимистичны». Исследования, поддерживающие миф о «10х», проводились десятилетия назад в совершенно иных условиях. Когда современные исследователи на самом деле изучили это в контролируемых условиях, они обнаружили совершенно другое: различия между большинством инженеров-программистов гораздо скромнее, чем предполагают популярные утверждения. Более того, один и тот же человек проявляет непостоянство в выполнении разных задач.
Тем не менее каким-то образом этот миф сохраняется с религиозной яростью. Почему? Потому что предвзятость подтверждения — это мощная вещь. Когда кто-то быстро завершает проект, мы создаём повествование вокруг их гениальности, вместо того чтобы изучить фактические переменные, играющие роль.
Архетипы, которые мы принимаем за сверхспособности
Вот где становится интересно. Люди, которых управленческие команды называют «инженерами 10х», обычно не являются воплощением сверхспособностей. Обычно они демонстрируют одно или несколько специфических поведений, которые кажутся очень продуктивными со стороны, в то время как фактические затраты остаются скрытыми. Позвольте мне рассказать вам о самых ярких примерах.
Накопитель очков: манипуляция метриками
Этот разработчик всегда выбирает задачи с низким приоритетом из доски Scrum. К концу спринта они закрывают десятки задач. Менеджеры поражены. «Как вам удаётся так много?» — спрашивают они, широко раскрыв глаза от удивления.
Что на самом деле происходит? Этот человек оптимизирует то, что измеряется, а не то, что важно. Они — эквивалент инженера-программиста студента, который отвечает на все простые вопросы с выбором ответа, но оставляет эссе пустым.
Фокусник: на самом деле просто умеет избегать отвлечений
Вот забавный момент: средний офисный работник проверяет электронную почту каждые 6 минут. Архетип «Фокусник» просто… не делает этого. Они защищают своё состояние потока, выделяют отрезки непрерывного времени и, возможно, иногда раздражают коллег, не отвечая немедленно на каждое сообщение в Slack.
У этого подхода действительно есть легитимные преимущества в плане продуктивности. Дело не в том, что они умнее — они просто не переключают контекст каждые 90 секунд. Вы можете повторить это сами, не будучи гением. Радикальная концепция, я знаю.
Профессор: узко, но глубоко
Профессор узко сосредоточен на определённой области проблем. Они потратили годы (или десятилетия) в одной конкретной области и знают о ней всё. В этой области они действительно превосходны.
Проблема? Они стали незаменимыми таким образом, который ужасен для организации. Они не будут работать в другом месте, знания не передаются, и когда они уходят или попадают под автобус, команда оказывается в серьёзной опасности.
Зацикленный: театр суеты
Некоторые разработчики просто оскорблены проблемами, которые они не могут решить. Они пропадают на часы или дни, работая одержимо, пока не одержат победу. Иногда они застревают на одной проблеме на несколько недель, постоянно думая о ней.
Это выглядит как преданность делу. Однако с точки зрения выгорания это выглядит неустойчиво. Вы не можете управлять компанией, в которой люди работают в режиме постоянного кризиса. И, что более важно, такая интенсивная концентрация на одной проблеме иногда означает, что они решают её наихудшим образом, просто чтобы закрыть задачу.
Субподрядчик: на самом деле умен в использовании рычагов
Этот человек ненавидит изобретать велосипед заново. Они неустанно ищут библиотеки, API и существующие решения. Если они не могут найти подходящее, они переформулируют проблему, чтобы она соответствовала существующему шаблону.
Вот в чём дело: это на самом деле здравая практика. Использование существующих, проверенных решений действительно более продуктивно и надёжно. Это больше касается здравого инженерного суждения, чем индивидуальной гениальности.
Упроститель: это действительно законно
Упроститель смотрит на вашу запутанную проблему, углубляется в неё, избавляется от отвлекающих элементов и переформулирует её таким образом, что она становится решаемой. Вы смотрите на их запрос на включение и думаете: «Это всё?» А затем: «О, вау. Да, это имеет смысл».
Это ближе всего к действительно исключительному таланту. Но вот в чём суть: упрощение — это навык, который можно развивать и обучать. Он не является чисто врождённым. Он приходит с опытом, пониманием шаблонов проектирования, ясным мышлением о пространстве проблем.
Как на самом деле выглядит реальная продуктивность
Позвольте мне отсеять шум. За 30 лет программирования люди, которые действительно работают на высоком уровне, имеют нечто общее: их сверхспособность заключается в уменьшении неоднозначности и быстром преодолении сложностей. Они читают чужой код лучше среднего. Они мгновенно находят дефекты и знают, как отлаживать чрезвычайно сложные проблемы.
Заметьте, чего нет в этом списке? Быстрая печать. Способность работать 80 часов в неделю. Специализированные знания в какой-либо малоизвестной технологии.
Лучшие разработчики — это мультипликаторы. Они не просто пишут лучший код — они делают лучше всю свою команду. Они прекрасно справляются с разблокировкой других людей. Они хорошо документируют. Они делятся знаниями. Они наставляют.
Как организации случайно создают токсичные структуры
Вот где происходит реальный ущерб. Когда руководство определяет кого-то как «инженера 10х», они часто совершают ряд предсказуемых ошибок:
- Они строят успех вокруг этого человека, а не вокруг процессов и систем.
- Они терпят плохое поведение, потому что результат, кажется, оправдывает это.
- Они создают двухуровневую систему, где с «Человеком 10х» обращаются иначе.
- Они дают понять всем остальным, что индивидуальные подвиги важнее командной работы.
- Они создают проблему удержания, когда другие хорошие разработчики в конце концов уходят, потому что устали быть в тени этого человека.
Я работал с одной компанией, у которой был «лучший разработчик». Этот человек разрабатывал одну и ту же систему в течение 15 лет, почти в одиночку первые пять лет. Они писали труднопонимаемый процедурный код с файлами длиной в 5000 строк. Они не делились знаниями с коллегами. Со временем способные разработчики приходили в компанию, смотрели вокруг и решали работать где-нибудь в менее душераздирающем месте. Те, кто остался, были довольны тем, что плывут по течению и позволяют этому человеку заниматься «подвигами».
Эта компания столкнулась с большими трудностями при масштабировании своих усилий в области разработки. Удивлён?
Настоящий разработчик «10х» не работает в одиночку
Если разработчики «10х» действительно существуют, вот что они делают: они делают лучше всю свою команду.
Это выглядит так:
- Чёткая документация о том, как работают системы.
- Наставничество других разработчиков как в технике, так и в мышлении.
- Рефакторинг для снижения сложности для всех.
- Обмен контекстом о том, почему были приняты те или иные решения.
- Создание процессов и инструментов, которые поднимают всю команду.
- Защита от технического долга, потому что они понимают долгосрочные затраты.
- Облегчение работы других людей, а не усложнение.
Парадокс заключается в следующем: разработчики, которых можно было бы назвать «10х», часто являются теми, кто больше всего привержен тому, чтобы сделать такой ярлык ненужным.
Что вам на самом деле следует делать вместо охоты на единорогов
Позвольте мне дать вам несколько конкретных практик, которые действительно работают:
1. Оптимизируйте командную скорость, а не индивидуальную производительность
Прекратите измерять продуктивность отдельных разработчиков. Это ненадёжно, поддаётся манипуляциям и стимулирует порочные стимулы. Вместо этого измеряйте:
- Время от задачи до развёртывания.
- Частоту развёртываний.
- Время подготовки изменений.
- Среднее время восстановления после инцидентов.
Это командные показатели, отражающие реальную ценность.
2. Инвестируйте в онбординг и передачу знаний
Если кто-то может добиться гораздо большего, чем другие, есть две возможности: они действительно исключительны (редко) или у них существенно больше контекста,