Каждый десятый разработчик ничего не делает на работе. Пообщались с «охотником за привидениями» из Стэнфорда

Как проводилось исследование

Исследователи создали алгоритм для оценки эффективности работы софтверных инженеров и предложили компаниям предоставить доступ к их внутренним репозиториям. Таким образом они проанализировали коды более 50 тысяч разработчиков из нескольких сотен компаний (названия не разглашаются, участие для компаний бесплатно). Поддерживаемые языки: PHP, Python, JavaScript, Objective C, Swift, Go, Ruby, Java, .NET.

Что обнаружили

Больше всего «привидений» (термин автора) обнаружилось среди инженеров на удалёнке (14%), меньше всего — в офисах (6%). Среди тех разработчиков, которые трудятся в гибридном режиме, бездельников оказалось 9%. К числу «призраков» автор относит тех кодеров, чья производительность меньше 10% от медианных показателей. 

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

Оценить продуктивность «призраков» можно также с помощью подсчёта строчек кода. И хотя в целом это ошибочный способ, замечает Денисов-Бланч, он тоже выявляет бездельников: так, около 58% «привидений» делают <3 коммитов в месяц. Остальные 42% вносят лишь тривиальные изменения, такие как редактирование одной строки или символа, имитируя работу.

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

Применив процент «призраков» к числу сотрудников в 13 крупных компаниях (IBM, Microsoft, Oracle, Google, Amazon, Cisco, SAP и др.), Денисов-Бланч предположил, что увольнение нерадивых сотрудников позволило бы компаниям ежегодно экономить 11, 6 миллиарда долларов (при средней годовой зарплате в 150 тысяч долларов). При этом  совокупная рыночная капитализация 12 компаний могла бы вырасти на 465 миллиардов долларов.

А экстраполируя процент «привидений» на мир (для этого автор использует консервативную оценку в 6,5% инженеров-бездельников при средней годовой зп 50 тысяч долларов), Денисов-Бланч получает 90 миллиардов долларов, потраченных впустую.

«Текущие метрики продуктивности в ИТ искажают реальность»

Мы расспросили автора о методологии «охоты за привидениями» и том, откуда вообще они берутся.

Как вообще вам пришло в голову измерить продуктивность разработчиков и долго ли длилось исследование?

А велика ли исследовательская группа? Сколько авторов у алгоритма, с помощью которого определяли эффективность разработчиков? И насколько вы довольны этим алгоритмом?

У статьи, которая описывает концепцию алгоритмической модели, четыре автора: я, Игорь Чобану, Симон Обстбаум и Михал Косински. Это первая из серии статей по данной теме; следующая будет опубликована через несколько недель.

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

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

Расскажите об этом подробнее.

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

• Количество строк кода и коммитов — плохие метрики, так как не учитывают объём выполняемой задачи.
• Story points (методология, согласно которой работа программиста оценивается с помощью относительных параметров: объём усилий и ресурсов, техническая сложность, риски и пр. — Прим. ред.) — субъективны и не сопоставимы между командами.
• Опросы самооценки полезны для измерения опыта разработчиков, но не продуктивности.
• Метрики DORA (DevOps Research and Assessment) измеряют эффективность DevOps, но не продуктивность. Размеры деплоев варьируются, а самими метриками легко манипулировать.

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

Оба подхода снижают качество решений.

Наше исследование направлено на создание решения, которое позволит измерять результативность команд разработки ПО. Это шаг к более обоснованным и прозрачным решениям в ИТ-организациях.

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

«Если вы летом 2020 года ничего не делали, мы можем это увидеть»

Как ИТ-компании реагировали на предложение поучаствовать в исследовании? Легко ли давали доступ к репозиториям? 

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

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

Получить доступ к приватным Git-репозиториям всегда непросто, и, на мой взгляд, именно поэтому такие исследования ранее не проводились. Для крупных компаний мы разворачивали агент на их серверах. Для небольших компаний подключались к их Git через Personal Access Token.

Так как мы анализируем данные Git, а не поведение людей, это упростило исследование. Данные Git принадлежат компаниям, и мы никого не мониторим.

А самих разработчиков предупреждали, что их код будут проверять?

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

Мы также видим историю Git за прошлые годы. Это означает, что если вы летом 2020 года ничего не делали, мы это заметим, так как информация сохраняется в истории Git.

Кстати, это всё западные компании? Или компании из Китая, Японии, Южной Кореи, Индии там тоже были?

В исследовании участвуют компании со всего мира. Среди них много аутсорсинговых компаний, работающих в Восточной Европе и СНГ. Все упомянутые вами  страны страны тоже представлены.

Какие различия между Западом и Востоком? Неужели в «трудоголических» Японии и Корее тоже 10 процентов «призраков»?

Мы не проводили этот анализ, но планируем заняться этим в будущем.

«Это начинается с потери мотивации или с разочарования»

Почему вообще понадобилось исследование, чтобы вычислить «призраков»? Почему бездельников не обнаруживают тимлиды и другие руководители? 

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

Проблема была известна, но её нельзя было измерить.

Развитие AI и LLM (Large Language Models) изменило ситуацию: прозрачности в работе софтверных команд стало больше. Производительность инженеров растёт, и это позволяет компаниям развиваться при стабильном числе сотрудников.

У инженеров меньше вольницы, а компании смелее внедряют прозрачность и меритократию. Оценка эффективности — сложная проблема, и она не в тимлидах.

Индивидуальные разработчики

Многие «привидения» делились историями [как они стали «привидениями»]. Обычно это начинается с потери мотивации или с разочарования. Со временем такие сотрудники начинают проверять, насколько можно сократить усилия без последствий. Так что чаще всего тут нет злого умысла, это результат рабочей среды.

Менеджеры и тимлиды

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

Старшие руководители

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

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

«Один человек вносил изменения в Git-репозитории нескольких организаций»

Как ИТ-компании отреагировали на результаты? Не пытались ли узнать имена «привидений»? 

Компании остались очень довольны. Впрочем, в нашем наборе данных может присутствовать эффект самоселекции: компании, которые считают, что у них есть проблемы с продуктивностью, более склонны участвовать в исследовании, чем те, кто так не считает. Это как визит к доктору: 100% пациентов на что-то жалуются.

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

Каков портрет типичного «призрака»? Кто он — лентяй или лжеразработчик? А может, он просто левачит на четырёх работах?

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

У меня нет точных данных, кроме анекдотических свидетельств (из личных бесед с «привидениями» и изучения материалов в X, Blind, Reddit), но я думаю, что существует две категории «привидений».

В нашем датасете есть кейсы, когда один человек одновременно вносил изменения в Git-репозитории нескольких организаций.

А известно ли вам, что случилось с «призраками» из вашего исследования? Их уволили?

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

«Я за то, чтобы давать „привидениям“ второй шанс»

А какие меры кажутся правильными вам?

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

Какие ещё интересные результаты показало исследование?

Рекомендую подписаться на мой X и LinkedIn, где мы регулярно публикуем новые инсайты.

Какие выводы делают работодатели на основе вашего исследования? Что работа из офисов более эффективна, чем удалёнка? 

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

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

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

Как вы сами оцениваете влияние удаленки на работу ИТ-отрасли? Становится ли удаленка проблемой? Какие у нее перспективы?

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

Вы помните, как беларусское ИТ превратилось в феномен? Мы учились друг у друга, делились первыми успехами, вместе радовались, когда наши компании, продукты и команды получали мировое признание. Сегодня многие из нас — в разных странах, поэтому еще важнее сохранять связи и продолжить развитие. 16 лет dev.by — «дефолтный» источник информации о беларусском ИТ, площадка для общения и обмена опытом. Вместе мы преодолеваем кризисы, держим удары, радуемся успехам, надеемся. 

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

Если у вас есть возможность и вы считаете нашу работу важной, поддержите dev.by.