Support us

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

Стэнфордский университет провёл исследование продуктивности разработчиков ПО. И сделал впечатляющие выводы: почти каждый десятый разработчик (9,5%) — «привидение».  Его производительность меньше 10% от медианных показателей, он практически не работает или работает на нескольких работах одновременно. Всмотрелись в результаты исследования и пообщались с одним из его авторов — Егором Денисовым-Бланчем.

Падтрымайце нашую беларускую версiю: перайсцi

15 комментариев

Стэнфордский университет провёл исследование продуктивности разработчиков ПО. И сделал впечатляющие выводы: почти каждый десятый разработчик (9,5%) — «привидение».  Его производительность меньше 10% от медианных показателей, он практически не работает или работает на нескольких работах одновременно. Всмотрелись в результаты исследования и пообщались с одним из его авторов — Егором Денисовым-Бланчем.

Падтрымайце нашую беларускую версiю: перайсцi

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

Исследователи создали алгоритм для оценки эффективности работы софтверных инженеров и предложили компаниям предоставить доступ к их внутренним репозиториям. Таким образом они проанализировали коды более 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 миллиардов долларов, потраченных впустую.

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

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

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

Егор Денисов-Бланч
Участники нашей исследовательской команды в своей карьере столкнулись с тем, что в отношении команд разработчиков объективные решения, основанные на данных, невозможны. Нам захотелось решить эту проблему. Исследование началось в 2022 году, больше двух лет назад. А собственно привлечение компаний-участников длится уже 1,5 года.

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

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

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

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

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

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

  • Количество строк кода и коммитов — плохие метрики, так как не учитывают объём выполняемой задачи.
  • 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-репозитории нескольких организаций.

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

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

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

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

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

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

Самый интересный факт — «привидения» встречаются даже в стартапах с командами из 15–20 инженеров.

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

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

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

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

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

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

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


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

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

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

«Нас не заменят, а выдавят». Беларусские айтишники об опыте работы с программистами из Индии
«Нас не заменят, а выдавят». Беларусские айтишники об опыте работы с программистами из Индии
По теме
«Нас не заменят, а выдавят». Беларусские айтишники об опыте работы с программистами из Индии
Место солидарности беларусского ИТ-комьюнити

Далучайся!

Читайте также
Как беларуские выпускники поступают в Польшу и Россию — и повлияла ли война. 4 истории
Как беларуские выпускники поступают в Польшу и Россию — и повлияла ли война. 4 истории
Как беларуские выпускники поступают в Польшу и Россию — и повлияла ли война. 4 истории
dev.by искал молодых людей, которые поступили этим летом в вузы за границу, — отозвались 4 человека. Двое выбрали Польшу, ещё двое  Россию (для одного это временный вариант, он планирует перепоступить в следующем году).  Спросили у ребят, как они выбирали вузы, куда поступали одноклассники и как на выбор повлияло вторжение России в Украину (и вчерашние новости о мобилизации). 
8 комментариев
EnCata будет штамповать заводы, которые штампуют дома
EnCata будет штамповать заводы, которые штампуют дома
EnCata будет штамповать заводы, которые штампуют дома
«Строительная отрасль полностью дисфункциональна», — говорит СЕО EnCata Олег Кондрашов. И предлагает «реанимировать стройку»: повторить успех Генри Форда и запустить конвейер, который будет штамповать модульные дома. А ещё — запустить мобильные заводы с этими конвейерами. Первый тестовый дом с железными стенами и окнами в пол уже построен — в нём 2 года как живёт СЕО. А сейчас в Великом камне достраивают тестовый завод. Есть ли будущее у проекта и какое, рассказывает dev.by Олег Кондрашов.
11 комментариев
Пара айтишников переехала в Австралию. Впечатления, цены, жильё
Пара айтишников переехала в Австралию. Впечатления, цены, жильё
Пара айтишников переехала в Австралию. Впечатления, цены, жильё
15 комментариев
Компания звонит по телефону — зовёт в ИТ без навыков и английского. У айтишников вопросы
Компания звонит по телефону — зовёт в ИТ без навыков и английского. У айтишников вопросы
Компания звонит по телефону — зовёт в ИТ без навыков и английского. У айтишников вопросы
Айтишники (и не только) жалуются, что им звонят по телефону из школы IT Overone и предлагают курсы для вхождения в ИТ без первоначальных навыков и английского. 
4 комментария

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

8

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

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

shipishi
shipishi Должность в Белокрылые лошадки
0

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

0

Ну так "Один пашет, а семеро руками машут" не на ровном месте придумали. Эта ситуация характерна для абсолютно любой отрасли. Просто у кодеров это проще проверить.

table
table Table в Database
4

количеством коммитов по индусской методе?

3

Да, за последние две недели, наверное пару комитов только сделал, в е остальное время ремоут парное программирование с обучением - 4 глаза в один дебаг.

ПС: самый не эффективный сотрудник :)))

Пользователь отредактировал комментарий 12 декабря 2024, 11:11

-1

Тут все просто, аутстафу и ауторсу выгодно продавать больше людей, а то что за них другие работают пофигу

0

Егор Денисов-Бланч, займитесь делом. А мы здесь без вас как-нибудь порешаем кто есть who.

-1

Ну он занимается делом, на какое ему дали гранты корпорации.

1

Это научное обоснование принуждению к возвращению в офис?

Дмитрий Иванов
Дмитрий Иванов ФРилансер в Global Freelance
-1

Айвэй ((

povelitel-krasnogo-drakona
povelitel-krasnogo-drakona Проектный мессенджер в 我想排便
1

Так, смотрим статью - https://arxiv.org/pdf/2409.15152v1

Метрики на статичном коде в гите?
Оценивающие "качество кода", при этом целевая аудитория - корпорации?
Метрика "Dependencies" (количество внешних зависимостей ака библиотек) скорее оценивает оные как негатив?

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

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

0

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

-1

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

1

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

0

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