Стэнфардскі ўніверсітэт правёў даследаванне прадукцыйнасці распрацоўшчыкаў софту. І зрабіў уражальныя высновы: амаль кожны дзясяты распрацоўшчык (9,5%) — «здань». Яго прадукцыйнасць меншая за 10% ад медыянных паказчыкаў, ён практычна не працуе або працуе на некалькіх працах адначасова. Угледзеліся ў вынікі даследавання і пагутарылі з адным з яго аўтараў — Ягорам Дзянісавым-Бланчам.
Стэнфардскі ўніверсітэт правёў даследаванне прадукцыйнасці распрацоўшчыкаў софту. І зрабіў уражальныя высновы: амаль кожны дзясяты распрацоўшчык (9,5%) — «здань». Яго прадукцыйнасць меншая за 10% ад медыянных паказчыкаў, ён практычна не працуе або працуе на некалькіх працах адначасова. Угледзеліся ў вынікі даследавання і пагутарылі з адным з яго аўтараў — Ягорам Дзянісавым-Бланчам.
Даследчыкі стварылі алгарытм для ацэнкі эфектыўнасці працы софтверных інжынераў і прапанавалі кампаніям даць доступ да іх унутраных рэпазіторыяў. Такім чынам яны прааналізавалі коды больш як 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 года.
А ці вялікая даследчая група? Колькі аўтараў у алгарытму, з дапамогай якога вызначалі эфектыўнасць распрацоўшчыкаў? І наколькі вы задаволеныя гэтым алгарытмам?
У артыкула, які апісвае канцэпцыю алгарытмічнай мадэлі, чатыры аўтары: я, Ігар Чобану, Сымон Обстбаум і Міхал Касінскі. Гэта першая з серыі артыкулаў па гэтай тэме; наступная будзе апублікаваная праз некалькі тыдняў.
У даследчай групе прыкладна шэсць асноўных удзельнікаў і яшчэ пяць-дзесяць чалавек, якія былі задзейнічаныя на розных этапах.
Атрыманай мадэллю мы вельмі задаволеныя, так як гэта першы выпадак, калі прадукцыйнасць у распрацоўцы софту ацэньваецца на аснове ўтрымання зыходнага кода, а не павярхоўных метрык, такіх як колькасць радкоў кода або камітаў. Мы разумеем, што мадэль можна значна палепшыць.
Раскажыце пра гэта падрабязней.
Людзям трэба стварыць умовы для раскрыцця іх патэнцыялу і адначасова пазначыць адказнасць за вынікі. У галіне распрацоўкі софту патрабуецца больш рашэнняў, заснаваных на даных, і празрыстасці. Аднак цяперашнія метрыкі прадукцыйнасці ў ІТ скажаюць рэальнасць.
У выніку кіраўнікі распрацоўкі сутыкаюцца з выбарам: прымаць рашэнні на аснове скажоных даных або дзейнічаць зусім без даных, спадзеючыся на інтуіцыю.
Абодва падыходы зніжаюць якасць рашэнняў.
Нашае даследаванне накіраванае на стварэнне рашэння, якое дазволіць вымяраць выніковасць каманд распрацоўкі софту. Гэта крок да больш абгрунтаваных і празрыстых рашэнняў у ІТ-арганізацыях.
Пры гэтым рашэнне нельга выкарыстоўваць без кантэксту. Яно працуе лепш за ўсё ў спалучэнні з іншымі метрыкамі. І карысней ужываць яго для ацэнкі каманд, чым асобных людзей.
Як ІТ-кампаніі рэагавалі на прапанову паўдзельнічаць у даследаванні? Ці лёгка давалі доступ да рэпазіторыяў?
Існуе эфект сеткавага ўзаемадзеяння: чым больш удзельнікаў, тым лепш мы можам кантэкстуалізаваць вынікі кожнай каманды і тым каштоўнейшым для ўсіх становіцца ўдзел.
Калі мы пачалі прыцягваць удзельнікаў паўтара года таму, працэс ішоў павольней, хоць цікавасць была высокай. Пасля прэзентацыі на буйной канферэнцыі ў верасні ўсё паскорылася, а цяпер, дзякуючы PR, у нас чарга з сотняў кампаній. Так што мы вельмі задаволеныя.
Атрымаць доступ да прыватных Git-рэпазіторыяў заўсёды няпроста, і, на мой погляд, менавіта таму такія даследаванні раней не праводзіліся. Для буйных кампаній мы разгортвалі агента на іх серверах. Для невялікіх кампаній падключаліся да іх Git праз Personal Access Token.
Так як мы аналізуем даныя Git, а не паводзіны людзей, гэта спрасціла даследаванне. Даныя Git належаць кампаніям, і мы нікога не маніторым.
А ці папярэджвалі саміх распрацоўшчыкаў, што іх код будуць правяраць?
Мы аналізуем код, а не саміх інжынераў. Таму ў большасці юрысдыкцый кампаніі могуць вырашыць не паведамляць пра даследаванне. Я не магу каментаваць, ці папярэджваюць кампаніі свае каманды.
Мы таксама бачым гісторыю Git за мінулыя гады. Гэта азначае, што калі вы летам 2020 года нічога не рабілі, мы гэта заўважым, бо інфармацыя захоўваецца ў гісторыі Git.
Дарэчы, гэта ўсё заходнія кампаніі? Ці кампаніі з Кітая, Японіі, Паўднёвай Карэі, Індыі там таксама былі?
У даследаванні ўдзельнічаюць кампаніі з усяго свету. Сярод іх шмат аўтсорсінгавых кампаній, якія працуюць ва Усходняй Еўропе і СНД. Усе згаданыя вамі краіны краіны таксама прысутныя.
Якія адрозненні паміж Захадам і Усходам? Няўжо ў «працагалічных» Японіі і Карэі таксама 10 працэнтаў «зданяў»?
Мы не праводзілі гэтага аналізу, але плануем заняцца гэтым у будучыні.
Чаму наогул спатрэбілася даследаванне, каб вылічыць «зданяў»? Чаму гультаёў не выяўляюць цімліды і іншыя кіраўнікі?
Апошнія дзесяцігоддзі попыт на распрацоўшчыкаў быў высокім і яны мелі шмат кар’ерных магчымасцяў. Кампаніі маглі б страціць спецыялістаў, калі б уводзілі строгую справаздачнасць.
Гэта вяло да маўклівага дапушчэння: частка інжынераў магла быць нізкаэфектыўнай, і гэта лічылася нармальнымі выдаткамі.
Праблема была вядомая, але яе нельга было вымераць.
Развіццё AI і LLM (Large Language Models) змяніла сітуацыю: празрыстасці ў працы софтверных каманд стала больш. Прадукцыйнасць інжынераў расце, і гэта дазваляе кампаніям развівацца пры стабільнай колькасці супрацоўнікаў.
У інжынераў менш вольніцы, а кампаніі смялей укараняюць празрыстасць і мерытакратыю. Ацэнка эфектыўнасці — складаная праблема, і яна не ў цімлідоў.
Многія «здані» дзяліліся гісторыямі [як яны сталі «зданямі»]. Звычайна гэта пачынаецца са страты матывацыі або з расчаравання. З часам такія супрацоўнікі пачынаюць правяраць, наколькі можна скараціць намаганні без наступстваў. Так што часцей за ўсё тут няма злога намеру, гэта вынік рабочага асяроддзя.
Менеджары хочуць фармаваць паспяховыя каманды, але сутыкаюцца з супярэчнасцямі. Прызнанне праблем можа паўплываць на іх рэпутацыю, а палітыка кампаніі часам перашкаджае скарачэнню каманд нават там, дзе гэта павысіла б эфектыўнасць. Праз недахоп часу і прыярытэты менеджарам складана аказваць камандам патрэбную падтрымку.
Яны далёкія ад аперацыйнай працы і давяраюцца даным, якія могуць быць ненадзейнымі (напрыклад, колькасць радкоў кода). Часам у іх таксама няма стымулу занурацца ў праблемы каманд, бо іхняя ўвага засяроджаная на стратэгічных задачах.
Выснова: дысфункцыя ў арганізацыі стварае ўмовы для з’яўлення «зданяў». Празрыстасць і рашэнні, заснаваныя на даных, могуць палепшыць працоўнае асяроддзе, знізіць расчараванне супрацоўнікаў, даць менеджарам інструменты для падтрымкі каманд і забяспечыць старшых лідоў патрэбнай інфармацыяй для прыняцця рашэнняў.
Як ІТ-кампаніі адрэагавалі на вынікі? Ці не спрабавалі дазнацца імёнаў «зданяў»?
Кампаніі засталіся вельмі задаволеныя. Зрэшты, у нашым наборы даных можа прысутнічаць эфект самаселекцыі: кампаніі, якія лічаць, што ў іх ёсць праблемы з прадукцыйнасцю, больш схільныя ўдзельнічаць у даследаванні, чым тыя, хто так не лічыць. Гэта як візіт да доктара: 100% пацыентаў на штосьці скардзяцца.
У залежнасці ад юрысдыкцыі і дзейных законаў кампаніі маглі мець або не мець доступ да імёнаў так званых «зданяў».
Хачу падкрэсліць, што для выяўлення «зданяў» мы не абмяжоўваліся алгарытмічнай мадэллю. У многіх выпадках мы правяралі даныя сумесна з кампаніямі, удакладняючы, ці не быў гэты супрацоўнік заняты чымсьці іншым (продажы, ментарства, адпачынак і г. д.).
Які партрэт тыповай «здані»? Хто гэта — гультай ці лжэраспрацоўшчык? А можа, той, хто проста лявачыць на чатырох працах?
Мы не звязваліся непасрэдна з людзьмі, якіх ідэнтыфікавалі як «здані». Але людзі самі выходзілі на сувязь са мной праз сацсеткі, прачытаўшы пра вынікі даследавання, і дзяліліся сваімі гісторыямі.
У мяне няма дакладных даных, акрамя анекдатычных сведчанняў (з асабістых гутарак са «зданямі» і вывучэння матэрыялаў у X, Blind, Reddit), але я думаю, што існуе дзве катэгорыі «зданяў».
Першая група працуе на некалькіх працах адначасова. Другая мае адную працу, але альбо выдаткоўвае вялікую частку часу на іншыя справы, альбо проста вельмі неэфектыўная.
У нашым датасэце ёсць кейсы, калі адзін чалавек адначасова ўносіў змены ў Git-рэпазіторыі некалькіх арганізацый.
А ці вядома вам, што здарылася са «зданямі» з вашага даследавання? Іх звольнілі?
Мы выразна пазначаем, што не ўдзельнічаем у наступствах, гэта выходзіць па-за рамкі нашага даследавання. Кампаніі маюць дапускаць, што нашыя даныя могуць утрымліваць памылкі, і самастойна правяраць інфармацыю. Даныя не маюць выкарыстоўвацца для звальнення супрацоўнікаў, так як гэта можа пацягнуць юрыдычную адказнасць. Мы вельмі ясна заяўляем пра гэта. Яны маюць прымаць рашэнні на аснове ўласных расследаванняў.
А якія меры падаюцца правільнымі вам?
Я не магу раіць, што менавіта кампаніі павінны рабіць са «зданямі», але я за тое, каб даваць ім другі шанец. Звычайна супрацоўнікі становяцца «зданямі» без злога намеру.
Якія яшчэ цікавыя вынікі паказала даследаванне?
Самы цікавы факт — «здані» сустракаюцца нават у стартапах з камандамі з 15-20 інжынераў.
Рэкамендую падпісацца на мой X і LinkedIn, дзе мы рэгулярна публікуем новыя інсайты.
Якія высновы робяць працадаўцы на аснове вашага даследавання? Што праца з офісаў эфектыўнейшая за аддаленую?
Мы не вывучалі дынамікі колькасці «зданяў» у часе, але можна меркаваць, што іх колькасць павялічылася з распаўсюджваннем аддаленай працы.
Тым не менш праца з офіса неабавязкова эфектыўнейшая за аддаленую. Гэта залежыць ад канкрэтнай сітуацыі. Некаторыя кампаніі лепш працуюць аддалена, іншыя — не. Аддаленая праца дае магчымасць наймаць спецыялістаў з іншых краін, што часам выходзіць таннейшым або якаснейшым варыянтам.
Небяспечна рабіць універсальныя высновы. Мы наўрад ці хутка прыйдзем да адназначнага адказу, што лепш: аддаленая, офісная або гібрыдная праца. Усё залежыць ад мэтаў кампаніі, яе культуры, лідарства і многіх іншых фактараў.
Як вы самі ацэньваеце ўплыў аддаленай працы на стан ІТ-галіны? Ці становіцца аддаленая праца праблемай? Якія ў яе перспектывы?
Аддаленая праца — гэта выдатны фармат, але ён падыходзіць не ўсім. Важна пазбягаць паспешных высноў на аснове нашага даследавання. Я падтрымліваю аддаленую працу, але толькі калі забяспечаныя празрыстасць і адказнасць.
Ці памятаеце вы, як беларускае ІТ ператварылася ў феномен? Мы вучыліся адно ў аднаго, дзяліліся першымі поспехамі, разам радаваліся, калі нашыя кампаніі, прадукты і каманды атрымлівалі сусветнае прызнанне. Сёння многія з нас — у розных краінах, таму яшчэ важней захоўваць сувязі і працягнуць развіццё. 16 гадоў dev.by — «дэфолтная» крыніца інфармацыі пра беларускае ІТ, пляцоўка для камунікацыі і абмену вопытам. Разам мы пераадольваем крызісы, трымаем удары, радуемся поспехам, спадзяемся.
Цяпер вы можаце дапамагчы dev.by. Калі ўсе спосабы манетызацыі беларускіх медыя амаль зніклі, рэгулярныя данаты дазваляюць плаціць заробкі рэдактарам і аўтарам, рыхтаваць важныя матэрыялы.
Калі вы маеце магчымасць і лічыце нашую працу важнай, падтрымайце dev.by.
Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.
Применить бы такую аналитику к чиновникам в разных странах, уххх, окажется, что итишники вообще самые продуктивные по сравнению с ними)))).
А что касается ИТ, продуктивность и будет снижаться, ЗП в IT уже не растут многие годы, рост есть только за счет повышения своих навыков, поэтому это естественный процесс, когда люди компенсируют это снижением работоспособности.
Если бы значительная часть чиновников просто ничего не делала, всем было бы только лучше. Вместо этого они генерят переписку друг с другом и с бизнесом, что только отвлекает ресурсы, которые иначе могли бы быть использованы на что-нибудь полезное.
Ну так "Один пашет, а семеро руками машут" не на ровном месте придумали. Эта ситуация характерна для абсолютно любой отрасли. Просто у кодеров это проще проверить.
количеством коммитов по индусской методе?
Да, за последние две недели, наверное пару комитов только сделал, в е остальное время ремоут парное программирование с обучением - 4 глаза в один дебаг.
ПС: самый не эффективный сотрудник :)))
Карыстальнік адрэдагаваў каментарый 12 снежня 2024, 11:11
Тут все просто, аутстафу и ауторсу выгодно продавать больше людей, а то что за них другие работают пофигу
Егор Денисов-Бланч, займитесь делом. А мы здесь без вас как-нибудь порешаем кто есть who.
Ну он занимается делом, на какое ему дали гранты корпорации.
Это научное обоснование принуждению к возвращению в офис?
Айвэй ((
Так, смотрим статью - https://arxiv.org/pdf/2409.15152v1
Метрики на статичном коде в гите?
Оценивающие "качество кода", при этом целевая аудитория - корпорации?
Метрика "Dependencies" (количество внешних зависимостей ака библиотек) скорее оценивает оные как негатив?
Ну понятно. Денежков заработать на корпорациях, по карьерной лестнице в университете пролезть - это было бы неплохо, я понимаю.
И юридически отгородиться от возможных последствий. Как будто это самое страшное.
тссс. мужик решил срубить бабок вернув из небытия индусский подсчет количества строк налабанных программером
в амазоне сеньор-уровня разработчики вообще не пишут код. они пишут только дизайны и участвуют в митингах
кроме дизайнов и митингов, есть code review, oncall duties и менторинг. Могут также писать отчеты. Как правило, чем более сеньорный разработчик, тем меньше пишет кода.
Ну, это зависит от компании и процессов. Иногда быстрее все самому в две руки сделать прототип, чем объяснить команде что от них требуется, это потом когда в суппорт и развитие фичу отдаешь команда начинает работать.
Вы про какой амазон говорите? В авс пишут на ура.
кроме того, большое количество кода вовсе не значит что код хороший. Он может плохой быть. Видел я людей которых выгоняли за большое количество плохого кода. Уж лучше вообще не писать, чем писать плохой код. Сойдешь за полезного инженера, тебя будут даже уважать в тиме, считать ценным сотрудником.