Интервью с Егором Денисовым-Бланчем: кто такие «инженеры-призраки» и как с ними бороться

В конце ноября 2024 года на Хабре вышла новость о том, что 9,5% программистов в IT-компаниях ничего не делают. Они как мёртвые души или призраки — числятся в штате, ходят на созвоны, но не выполняют рабочие задачи. Поводом для новости стало исследование Егора Денисова-Бланча (Yegor Denisov-Blanch) из Стэнфордского университета.

Мы связались с автором исследования, чтобы больше узнать о методологии исследования и мотивации. А ещё попытались выяснить, можно ли уволить разом всех «инженеров-призраков» и сработает ли такая тактика.

Расскажите немного о себе. Чем занимаетесь, как попали в Стэнфорд и чем там занимаетесь?

Я родился в Барселоне. Моя мама — испанка, а папа — русский. В 12 лет я начал изучать программирование и пишу код уже 20 лет. Когда мне было 14, я бросил школу, чтобы сконцентрироваться на запуске собственной компании в сфере электронной коммерции для корпоративных клиентов. Это было в 2006 году, а в 2010 я открыл компанию в области рекламных технологий. Я самостоятельно разработал код продукта, а в 17 лет зарабатывал больше, чем сейчас в 32.

Пять лет школьного образования я пропустил и сразу поступил в Индианский университет в Блумингтоне (Indiana University Bloomington), в котором изучал бизнес с упором на «технологии принятия решений». Обучение закончил с отличием (summa cum laude) и был первым в своём выпуске из 4 тыс. студентов. Также продолжал заниматься программированием, увлекся тяжёлой атлетикой и пауэрлифтингом. Даже выступал на соревнованиях.

После этого пять лет проработал в DHL последние три из которых — в роли главы аппарата генерального директора региона EMEA (Европа, Ближний Восток, Африка). Возглавлял множество проектов по цифровой трансформации для более чем 6 тыс. инженеров. Именно в этот период я начал думать над тем, как можно справедливо оценивать продуктивность разработчиков.

Для магистратуры я подал документы в шесть университетов (Стэнфорд, Гарвард, MIT, Уортон, Колумбия, Дартмут) и прошёл во все. В Стэнфорде и Гарварде мне предложили полное покрытие обучения. В 2022 году я начал обучение в Стэнфорде и с тех пор исследую продуктивность в области разработки ПО.

Кто работает в вашей команде? Есть ли в ней инженеры-программисты? Какой у вас рабочий график и режим работы?

В нашу основную исследовательскую команду входят:

• Саймон Обстбаум — бывший технический директор Crunchyroll, который продал компанию за $1,2 млрд.

• Михал Косиньски — профессор Стэнфорда и разоблачитель Cambridge Analytica.

Мы все пишем код, но также нас поддерживают инженеры-программисты уровня senior/lead. Они обычно отвечают за техническую часть исследований.

Я не сторонник романтизации сверхурочной работы, но сам посвящаю примерно 80–90 часов в неделю работе, совмещая академическую деятельность и исследования. Работаю 7 дней в неделю, но другие члены команды менее загружены. Мы работаем на удалёнке, но часто встречаемся в Стэнфорде, чтобы обсудить вопросы лично.

Про исследование

Как, по вашему, менялась жизнь программистов в Кремниевой долине в последнее время?

На протяжении этого столетия программисты, особенно в Кремниевой долине, пользовались огромным спросом и имели высокую мобильность на рынке труда.

Моя гипотеза такова: раньше компании боялись терять инженеров в пользу конкурентов, поэтому не внедряли прозрачность и подотчётность в процессах. Считалось, что из-за этого инженеры начнут увольняться и переходить к другим работодателям. Это привело к тому, что часть инженеров в компаниях либо фактически перестала работать («тихое увольнение»), либо неэффективна. Долгое время руководители компании воспринимали это как издержки бизнеса. Все знали о проблеме, но никто не мог её оценить.

С появлением искусственного интеллекта и больших языковых моделей произошли два изменения:

1. Стало легче контролировать прозрачность в командах инженеров.

2. Производительность инженеров увеличилась. Если этого и не произошло  сейчас, то в ближайшем будущем точно.

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

Главное отличие Кремниевой долины от остального мира — плотность талантов. Здесь концентрация профессионалов чрезвычайно высока, что создаёт более благоприятную среду для развития и генерации идей. Это место, где легче расти как специалисту, ведь доступно больше ресурсов и возможностей для обмена даже самыми безумными идеями.

Из результатов вашего исследования следует, что 9,5% разработчиков в IT-компаниях ничего не делают. Как пришли к такому результату? В чём заключается методология исследования?

На протяжении 1,5 лет мы сотрудничали с частными компаниями, которые предоставили доступ к своим git-репозиториям с помощью персонального токена или локального развёртывания. Мы использовали эти данные для обучения нейросети, которая оценивает деятельность разработчиков. Учитывается код, созданный в рамках коммитов. Наша модель машинного обучения анализирует изменения в коде, используя более 30 параметров.

В основе модели лежит следующая структура: мы привлекли независимую группу экспертов, которые оценивали код по ряду критериев. Удивительно, но они продемонстрировали высокий уровень согласованности между собой, даже не зная, какие оценки ставят другие. Коэффициент внутриклассовой корреляции (ICC2k) составил более 0,80 — это очень высокий показатель. Анализ мощности выборки показал, что вероятность получить иные результаты составляет менее 0,00001.

Наибольшее согласие экспертов наблюдалось в следующих аспектах:

• время написания кода;

• время полного цикла реализации, включая тестирование и отладку.

Затем мы соотнесли оценки экспертов с реальными данными о времени выполнения коммитов по рабочим журналам. Результаты коррелировали настолько сильно, что мы смогли построить модель, которая согласуется как с оценками экспертов, так и с реальностью. 

Модель также анализирует такие аспекты, как:

• Поддерживаемость кода — насколько легко код можно модифицировать или расширять в будущем.

• Сложность решаемой задачи — насколько трудной была проблема, которую код решает.

Эти факторы помогают более точно оценить вклад разработчика, выходя за рамки простых метрик вроде количества строк кода или числа коммитов. Процесс измерения коммита выглядит следующим образом:

1. Коммит проходит через нашу модель.

2. Модель оценивает его по ряду параметров (30-40 параметров в зависимости от языка).

3. Результаты комбинируются с метаданными Git (автор, дата, репозиторий, SHA коммита и т. д.).

4. Сумма «оценок» (output units) коммитов человека за определённый период формирует его общий показатель продуктивности.

Разумеется, такие факторы, как парное программирование или squash merges, влияют на распределение авторства. Наша модель далека от идеала, но она предоставляет достаточно точные оценки для анализа.

Используя эту модель, мы проанализировали миллионы коммитов и миллиарды строк кода из сотен организаций-участников. Всего исследование охватило более 50 000 инженеров. Мы плотно сотрудничали с компаниями, чтобы понять роли участников (должности и обязанности). На основе данных мы составили список «инженеров-призраков» (ghost engineers).

Этот список проверили представители компаний-участников исследования. Они подтвердили, что люди, которых мы обнаружили, на самом деле «призраки». Они практически не вносят вклад в кодовую базу. Наша модель оказалась весьма точной, хотя в ней, конечно, присутствуют ошибки.

Особенности и оговорки:

1. Мы не считаем коммиты или строки кода. Модель анализирует изменения в исходном коде каждого коммита и оценивает их на основе множества параметров.

2. Наши результаты необходимо рассматривать в контексте. Решения нельзя принимать только на основании модели.

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

4. Инженеров, которые не вносили вклад в код, но выполняли значимую работу в других областях, мы не включили в 9,5%.

5. Мы признаём наличие ложноположительных и ложноотрицательных результатов.

6. Возможен систематический сдвиг выборки: компании, где ощущались проблемы, вероятнее соглашались участвовать в исследовании. Однако среди участников было и много высокоэффективных организаций.

7. Даже если ошибка составляет 50%, и «призраков» всего 5%, их существование общеизвестно. Это обсуждается в сообществах вроде Blind или Reddit.

8. Наша цель — сделать разработку более прозрачной и основанной на данных, а не на интуиции или политике.

9. Мы надеемся, что компании будут использовать наше исследование для повышения эффективности своих команд.

Какие данные вы использовали для исследования?

Исследование построено на базе истории коммитов из git-репозиториев сотен IT-компаний по всему миру. Кроме этого, нам предоставили данные о сотрудниках компаний, включая должности, локации и тип занятости (полная, частичная или сдельная). После обнаружения «программистов-призраков» компании подтверждали или опровергали наши догадки. Всего набор данных включает в себя миллионы коммитов и миллиарды строк кода от более чем 50 тыс. программистов.

Более 77 тыс. разработчиков в крупных IT-компаниях ничего не делают. Значит, их можно просто уволить, чтобы сохранить бюджет?

Это просто наша забавная гипотеза. Мы прикинули, что так можно сократить расходы компаний. Судя по тому, что пишут в интернете и говорят в Кремниевой долине, можно без ущерба уволить 5% разработчиков в любой крупной технологической компании. В некоторых случаях это может даже повысить продуктивность. Но отмечу, что это только предположения без опоры на научные данные.

Почему «инженеры-призраки» (Ghost Engineers) продолжают работать в компаниях?

Им за это платят, поэтому они даже не думают уходить. Разве кто-то откажется от возможности ничего не делать и хорошо зарабатывать? Кроме того, некоторые инженеры работают одновременно в нескольких компаниях. Это явление называется overemployed. Я планирую написать тред в Twitter на эту тему.

Какие сотрудники более продуктивны: удалённые или офисные?

Кто красивее: блондинки или брюнетки? Смысл в том, что всё зависит от компании и конкретной ситуации. Мы видели успешные компании как с удалёнными, так и с офисными сотрудниками. Если говорить о средних показателях, то офисные инженеры оказываются более продуктивными. Но это усреднённое значение и данные могут отличаться в каждой компании.

Как справедливо измерять продуктивность инженеров? Разработчик может быть ценным источником опыта и при этом писать очень мало кода?

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

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

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

Можно ли вообще измерить продуктивность разработчика? Программирование чаще похоже на искусство, а не на работу у станка. 

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

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

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

На базовом уровне код — это математика, а математику мы всегда можем измерить. Даже если представить, что программирование на 100% искусство, то всё равно можно будет обучить модель для оценки всего этого.

Если инженеры будут работать ради соблюдения KPI и метрик, не приведёт ли это к выгоранию и творческому кризису?

Да, скорее всего так и будет, поэтому наши данные и модель машинного обучения надо использовать с осторожностью. Люди — не роботы. У нас случаются неудачные дни, недели и даже месяцы, что снижает нашу продуктивность и это нормально. Нельзя ожидать, что процесс разработки ПО всегда будет идти в стабильном и ровном темпе.

Наша модель даёт ориентир для оценки работы команды. Как менеджеру или техническому директору, вам важно понимать, когда нужно поднажать, а когда, наоборот, дать команде передышку. Если давить слишком сильно, люди уйдут или выгорят. Я рекомендую использовать опросы для оценки морального состояния команды. Но они тоже часто оказываются ложными из-за того, что сотрудники отвечают на вопросы просто для галочки.

Наша модель помогает принимать более правильные решения, не полагаясь на интуицию. Кроме того, с её помощью можно отказаться от устаревших метрик вроде количества строк кода, частоты развёртываний или числа коммитов. Эти метрики не всегда дают справедливую оценку.

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

Заметна ли корреляция между количеством строк кода или закрытыми тикетами с качеством кода?

Наш инструмент не оценивает качество кода, поэтому я не могу ответить на этот вопрос с научной точки зрения. Термин «качество» многозначный, и мы предпочитаем сосредотачиваться на поддерживаемости кода. Если вы создаёте код, который сложно поддерживать, то наша модель замечает это.

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

• Они анализировали файлы вместо коммитов.

• Рассматривали команды, а не индивидуальных разработчиков.

• Их метрика была сосредоточена на оценке качества и поддерживаемости.

Это подтверждает, что мы правильно выбрали направление исследования.

Есть ли заметные различия в продуктивности программистов в зависимости от опыта, команды и проекта?

Разумеется, различия могут быть огромными. Мы видели, как невероятно талантливые программисты демонстрировали низкие результаты из-за проблем, связанных с некомпетентными коллегами, руководством или другими внешними факторами.

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

Если инженер весь день думал над архитектурой проекта или решением конкретной задачи, но не писал код, то его можно назвать продуктивным?

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

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

Есть ли конкретные практики, которые вы рекомендуете для улучшения продуктивности программистов?

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

Многие разработчики считают, что измерение продуктивности — попытка контролировать сотрудников. Что вы думаете на этот счёт?

Я понимаю, почему люди так думают, но на самом деле измерение продуктивности делает разработку программного обеспечения более прозрачной, меритократичной и справедливой.

Вам нравится, когда решения в компании принимают коллективно, а продвижение по должности получает приятель начальника? Мне — нет, и я хочу положить этому конец. Я не утверждаю, что наше исследование полностью устранит эти проблемы (наша метрика не универсальная), но она как минимум привнесёт объективные данные в процесс принятия решений.

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

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

Продуктивность зависит не от разработчика, а от процессов, которые выстраивают менеджеры. Согласны ли вы с этим суждением?

Продуктивность зависит от обоих факторов: и разработчика, и процессов. Можно быть плохим инженером, работая в среде с отличными процессами, и всё равно показывать низкую производительность. Можно быть выдающимся инженером, но в плохой среде работать неэффективно. Мы видим оба эти сценария.

Сводить продуктивность инженера исключительно к его личным действиям — это ошибка. На неё влияет множество факторов, и низкая производительность инженера часто также связана с его окружением. Это не научный вывод, а скорее наблюдение.

В комментариях к новости разработчики говорят, что эффективность неоднородна: если сейчас есть задачи и/или проекты, будет и бурная деятельность. Какова вероятность, что «призраки» — просто те разработчики, у которых на момент исследования не было задач?

Мы подключаемся к Git и видим полную историю изменений. Например, мы можем посмотреть, что люди делали в марте 2020 года, когда началась пандемия COVID-19.

Чтобы стать «инженером-призраком», нужно долгое время практически ничего не делать. Я не буду раскрывать детали методологии, но подумайте об этом так: если за период в 6–12 месяцев вы сделали очень мало работы, значит, что-то явно не так.

Если уволить всех «призраков» — через какое время их популяция в компаниях восстановится? Что с этим делать?

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

Как огласка в СМИ и комментарии сторонних инженеров повлияли на исследование?

Мы наблюдаем три типа реакций:

1. Продуктивные разработчики, которые переживают, что их будут оценивать несправедливо. У многих из них травматичный опыт из-за использования неадекватных метрик, таких как количество строк кода или коммитов.

2. «Инженеры-призраки», которые боятся, что их разоблачат.

3. Люди, которые ждут, когда такая система оценки появится в их компаниях.

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

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

Какие есть планы на новые исследования? 

В данный момент мы работаем над статьёй, где сравниваем крупные языковые модели (OpenAI, Anthropic, Google, Llama) с нашей моделью в контексте измерения продуктивности разработчиков.

Мы также планируем выпустить больше научных материалов об «инженерах-призраках». Кроме того, мы всегда рады новым участникам исследований и приглашаем оставить заявку на нашем сайте.

---

Ниже принципы и законы, которые относятся к исследованию:

Принцип Парето (80/20)

Принцип: 80% результата достигается за счёт 20% усилий, а оставшиеся 20% результата требуют 80% усилий.
В разработке ПО: Обычно 20% разработчиков создают 80% ценного кода, а 20% функционала продукта удовлетворяют 80% потребностей пользователей. Этот принцип помогает менеджерам сосредоточиться на ключевых приоритетах, не растрачивая ресурсы на малозначительные задачи.

Закон Прайса

Принцип: Половину работы выполняет квадратный корень из общего числа сотрудников.
В разработке ПО: Если в команде 100 человек, половина ценного вклада исходит всего от ~10 разработчиков. Это подчёркивает важность правильного подбора ключевых сотрудников и риска увеличения команды без роста производительности.

Закон Брукса

Принцип: Добавление новых людей в проект, который уже задерживается, только увеличивает задержку.
Причина: Новым участникам нужно время на обучение, что нагружает команду.
В разработке ПО: Если проект отстаёт, лучше пересмотреть задачи, сократить объём работы или улучшить процессы, чем расширять команду.