De ce companiile ar trebui să se concentreze pe valoarea reală a angajaților, nu pe mitul “inginerilor fantomă”

Un studiu recent publicat de Universitatea Stanford din SUA arată că 1 din 10 ingineri software nu face aproape nimic la locul de muncă și totuși primește salariu, contribuția lor fiind astfel inexistentă. Autorul studiului, Yegor Denisov-Blank, îi numește „inginerii fantomă” – “ghost engineers”, aceștia regăsindu-se atât printre cei care lucrează de acasă, cât și printre angajații care muncesc de la birou. Potrivit acestuia, 9.5% din software developers operează 2-3 modificări de cod pe lună, însumând cca 5 ore de muncă pe săptămână, și încasează salarii de zeci de mii de dolari pe lună.

Blank a analizat private Git repositories ale peste 50.000 de ingineri din 100 de companii și a descoperit că 9,5% dintre inginerii software nu desfășoară practic nicio activitate semnificativă. Mai mult, munca la distanță amplifică această tendință, 14% dintre inginerii care lucrează complet remote fiind clasificați drept „fantome”, comparativ cu 6% dintre colegii lor care lucrează de la birou. Activitatea de commit este adesea nesemnificativă, 58% dintre ingineri realizând mai puțin de trei contribuții relevante pe lună.

De ce astfel de studii nu sunt relevante când analizăm valoarea unor angajați

Autorul studiului, dar și publicațiile care au preluat știrea, nu au luat în calcul faptul că un inginer software este plătit pentru a rezolva o problemă (sau mai multe). Acest lucru înseamnă sute de ore de efort mental pentru a găsi soluții. Procesul nu se rezumă la intervalul 9-17 cât angajatul este la birou. În majoritatea cazurilor, inginerii “rumegă” problema în mașină, la plimbare, în weekend, se documentează, discută cu alți colegi, urmând ca apoi să o transpună în lunii de cod. 

În plus, ignorarea muncii invizibile, dar esențiale, poate duce la concluzii eronate despre valoarea unui angajat. Inginerii software nu se rezumă doar la a scrie cod, ci participă activ la procese de brainstorming, design arhitectural, revizuirea codului altora, testare și rezolvare de bug-uri. Aceste activități, deși mai greu de măsurat decât liniile de cod, sunt fundamentale pentru succesul oricărui proiect software.

Studiul lui Blank, de exemplu, nu pare să fi luat în considerare cât de mult timp este dedicat înțelegerii codului legacy code, participării la ședințe, comunicării cu echipa sau sprijinirii altor colegi în rezolvarea problemelor tehnice. Fără aceste activități, proiectele s-ar opri din loc, iar calitatea produsului final ar fi compromisă.

TE-AR PUTEA INTERESA ȘI – Comunicare de criza: Când e bine ca brandurile să nu reacționeze

Cantitatea nu înseamnă calitate

În loc să măsoare succesul unui angajat în funcție de numărul de commit-uri, companiile ar trebui să evalueze impactul acestora. Un simplu refactoring sau o decizie bine gândită în design-ul unui sistem poate economisi zeci de ore de muncă în viitor. Prin urmare, o contribuție aparent „mică” în termeni cantitativi poate avea un efect major asupra viabilității și scalabilității unui proiect.

De exemplu, un inginer care identifică o problemă structurală majoră și implementează o soluție este mult mai valoros decât cineva care produce cantități mari de cod care, ulterior, necesită corecturi sau ajustări semnificative.

Cultura organizațională bazată pe merit real

Un alt risc al utilizării unor metrici superficiali este crearea unei culturi organizaționale bazate pe frică și presiune nejustificată. În astfel de medii, angajații sunt motivați să prioritizeze aparențele – cum ar fi să producă volume mari de cod sau să simuleze activitatea – în detrimentul rezolvării eficiente a problemelor.

În schimb, companiile ar trebui să promoveze o cultură a transparenței și meritului real, în care angajații sunt încurajați să colaboreze, să își asume riscuri și să se concentreze pe soluții de calitate. Măsurătorile ar trebui să includă factori precum complexitatea problemelor rezolvate, calitatea soluțiilor implementate și impactul asupra obiectivelor generale ale companiei.

Importanța leadership-ului tehnic

Un alt aspect pe care studiul îl trece cu vederea este rolul esențial al inginerilor cu experiență în mentorat și leadership tehnic. Aceștia investesc o parte semnificativă din timpul lor pentru a ghida echipa, a oferi feedback și a preveni greșelile care ar putea costa compania mult mai mult în viitor. Deși aceste activități nu apar în rapoartele de commit-uri, ele contribuie direct la succesul organizației.

CITEȘTE ȘI: La cine au plecat bursele de 5000 euro oferite de companiile de IT membre ANIS

Mitul „inginerului fantomă” în era muncii remote

Munca remote a amplificat provocările legate de măsurarea performanței. Lipsa interacțiunilor față în față poate duce la percepții greșite despre productivitate. Totuși, acest lucru nu justifică etichetarea unor angajați drept „fantome” pe baza unor măsurători incomplete. Managerii trebuie să-și ajusteze perspectivele și să înțeleagă că productivitatea în era digitală nu mai poate fi redusă la timpul petrecut în fața calculatorului sau la numărul de task-uri completate.

O nouă abordare asupra evaluării angajaților

Companiile de tehnologie trebuie să abandoneze mitul „inginerilor fantomă” și să adopte o abordare mai nuanțată, care să reflecte complexitatea muncii de inginer software. Accentul ar trebui să cadă pe calitatea și impactul contribuțiilor, pe colaborare și pe sprijinirea echipei, mai degrabă decât pe măsurători cantitative, care nu oferă o imagine completă. Doar astfel, companiile pot construi echipe motivate, eficiente și adaptate provocărilor tech ale viitorului.

 
 
 
 

 

 



Urmărește-ne și pe Google NEWS