O experiență personală a tranziției de la rolul de Software Developer la Project Manager
Ai obținut poziția mult dorită: ești programator. Tocmai ai terminat facultatea, ai planuri mari, te-ai mutat sau locuiești deja într-un oraș mare cu posibilități nenumărate de dezvoltare în IT. Lumea este a ta și ești.pe.val! Totul e incitant în jurul tău și știi că ești într-un loc bun. Pasiunea și cafeaua te motivează în fiecare dimineață în care devorezi acest domeniu. Trec niște ani, ai învățat deja metodologiile, procesele și modul de lucru. Împărtășești opiniile liderilor, înveți de la ei, dar apoi îți dezvolți propriile opinii. Unele lucruri le fac ei bine, altele le faci tu mai bine. Trec mai mulți ani, îți dezvolți noi abilități care nu sunt atât de orientate spre tehnologie, ci spre oameni. Începe să îți pese de sănătatea echipei tale, iar efortul tău de a îmbunătăți lucrurile este observat în compania în care lucrezi. Te afli în poziția de leader formal sau informal și ai satisfacția de a-i ajuta pe ceilalți. Poate trec mai mulți ani, iar dupa 10+ ani de programare, vrei o schimbare: te gândești la management. Schimbarea e posibilă doar cu ajutorul companiei, dar, dacă ești norocos, acum începe partea grea. Urmează o serie de traininguri high level și ți se arată cam ce e de făcut. Devii Project Manager și ți se oferă o listă de proiecte din care poți alege la ce vrei să lucrezi, ceva apropiat de lucrurile cu care ești familiar.
Ești tu acesta? Te regăsești în această situație? Te imaginezi vreodată aici? Situația mea este similar cu cea descrisă mai sus și voi continua prin a o prezenta din perspectiva proprie.
Primul proiect pe care îl gestionezi are un impact pozitiv sau negativ. Deci, ce am ales? Am ales proiectul care mi-a fost prezentat drept o provocare, pentru că mă plictisesc repede. Încă din faza de analiză, mi-am dat seama că are probleme la mai multe nivele: livrare, procese, distribuția bugetului și toți aveau o problemă cu faptul că era un proiect intern. De ce se întâmpla aceasta? Nu știu. Poate problema era că e o aplicație veche cu mult legacy code sau poate era o problemă cu stakeholderii proiectului: un grup de 17 persoane, toți colegi. M-am alăturat echipei și am început să fac management.
Pe lângă această provocare, am mai luat un proiect, pentru un nou client al companiei. Dacă pentru proiectul intern nu a fost nevoie să se construiască o relație, ci doar să se repare niște disfuncționalități, cu proiectul extern, povestea a fost complet diferită. A trebuit să construiesc o relație de încredere cu clientul, să investesc în construirea echipei și în învățarea unei nișe.
Nu știu de ce toți fug de proiectele interne. De acord! Există niște părți negative: nu sunt delegații, nu sunt bonusuri, ci doar contact direct cu "clientul" cu care interacționezi zilnic în companie. Poți simți ușor gustul amar al eșecului. Am abordat proiectul intern la fel ca pe cel extern, mizând pe aceeași rutină, pe aceeași atenție la detalii și la nevoile clientului (fără compromisuri). Această abordare a schimbat complet percepția echipei și a proiectului. Trebuie să menționez că am fost norocos să am o echipă și un Product Owner implicați. Nu este încă finalizat, dar suntem pe drumul cel bun. Ca să fiu sincer până la capăt: dacă, la început, mă enervau colegii care se plângeau de software, după o vreme, acesta a fost unul din principalii factori motivanți pentru mine: dacă aș reuși să schimb această percepție, aș fi deja cu un pas în față.
Primul lucru pe care oamenii l-au făcut a fost să mă felicite pentru promovare, chiar și pe LinkedIn. Nu! Nu este o promovare. Am fost "promovat" dintr-un job în care știam perfect ce se așteaptă de la mine, în unul în care aveam o privire de ansamblu asupra a ceea ce se întâmplă și unde totul depindea de mine. Am trecut de la un job în care am crescut și unde aveam mulți ani de experiență la unul cu o perspectivă radical diferită: progresul se măsoară în funcție de efortul echipei.
Deci, cum funcționează acest lucru? Fiind programator știam prea bine care sunt cerințele "lucrului bine făcut": scriere de cod curat, review realizat cu succes, teste "verzi", toate acestea respectând designul general al aplicației. Nu este neapărat un lucru simplu, dar este clar. Am putut urmări progresul și mi-am dat seama că merge în direcția bună. Pe de altă parte, ca manager, lucrezi cu o gamă variată de oameni. Mai mult, rezultatul nu este imediat vizibil, uneori durează o vreme pentru a se putea vedea rezultatele acțiunilor tale, nu mereu rezultate dorite. Fiecare persoană este motivată de alți factori, iar încrederea echipei trebuie câștigată.
Una din marile mele frustrări ca Project Manager a fost că, după o zi de muncă, doream să fac un rezumat a ceea ce s-a realizat (aceeași abordare ca în programare), dar nu exista nimic care să fie "done done". Poziția mea presupune întâlniri, discuții, statistici, rapoarte și certitudinea că totul funcționează; ceea ce diferă mult de la un proiect la altul... Cu alte cuvinte nu simțeam că eram productiv.
Trebuie să îți reînțelegi responsabilitățile și nu există un model clar de urmat, trebuie să gandești outside the box pe cât posibil, atâta timp cât abordezi problema corect. Acesta este un avantaj dacă ești creativ și poți ține cont de personalitatea fiecărui om din proiect. Un proiect reușit este o reușită a echipei, iar un proiect ratat este un eșec al Project Manager-ului.
Mai trebuie menționat că nu mai poți fi prietenul lor. În curând, constați cu tristețe că ești exclus din grupul lor de glume. Aceasta nu ar trebui văzută ca o parte total negativă. Ești acolo, ei vor încerca să pună un zid între ei și tine, iar tu trebuie să spargi bariera. Dezvoltarea relațiilor este un aspect important al managementului și trebuie să înțelegi această distanță pentru a ști cum să interacționezi cu echipa.
Am aflat că satisfacția vine în multe forme. Ca programator, satisfacția a fost constantă, vizibilă, dar relativ mică, în timp ce rezultatele unei echipe pot fi mari (deși nu se văd pe termen scurt) când constați că ai reușit să ajuți o persoană să-și atingă potențialul, că un client are încredere în echipă datorită bunei comunicări, că tu și echipa rezolvați problemele pentru o dată limită critică, că pachetul de release nu a crăpat.
Tot ce am spus până acum se bazează pe percepție. Pentru a aprecia rezultatele unei zile de muncă, trebuie schimbat punctul de vedere și am dorit să explic de ce acest lucru este foarte important. Este foarte multă muncă de făcut, multă responsabilitate și o curbă de învățare lentă.
Sunt multe procese în munca ta: formarea echipei, negocierea proiectului, parcurgerea specificațiilor, estimarea bugetului, crearea unui plan de livrare, respectarea acelui plan, îndepărtarea impedimentelor pentru o relație de încredere cu clientul (poate cea mai dificilă). Vorbind de buget, am descoperit o cu totul altă perspectivă a lucrurilor. Estimarea costurilor e foarte dificilă: nu vorbesc de planificare, ci de respectarea planului asumat.
Project Managementul nu trebuie privit ca o sarcină facilă, sunt multe reguli și bune practici. Ca în programare, există o mare parte "tehnică" și sunt entități care reglementează acest aspect. Project Management Institute (PMI) este una dintre cele mai apreciate organizații, iar a deveni un profesionist PMI este mai greu decât obținerea unei certificări tehnice: sunt multe condiții de intrare (experiență de ani buni în project management, credite PDU, participarea la cursuri și prezentări) și doar după aceea ești eligibil, să obții certificarea.
Nu trebuie subestimată problema responsabilității; Project Managerul răspunde total de succesul unui proiect, luând în considerare toate aspectele: client, echipă și profitabilitate. Acestea fiind zise, aș spune că este o meserie grea care nu se potrivește oricui, dar care aduce multe provocări și satisfacții.
Din proprie experiență, cei mai buni manageri sunt cei care lucrează alături de echipă, nu cei care doar cer și controlează. Echipa face munca grea, iar motivația lor nu se măsoară doar din perspectiva unei compensații salariale, ci a unui mediu de lucru echilibrat.
Aceasta este o discuție aprinsă. Totul se rezumă la ce presupune munca unui PM. Chiar dacă am descris acest lucru, rolul unui PM este 80% menținerea de bune relații, comunicare clară și gestionarea oamenilor. Deci, este necesar? PM-ii nu trebuie să fie "techie", dar dacă își ascultă echipa și învață zi de zi, vor avea un mare avantaj. Dacă PM este familiar cu tehnologiile utilizate în proiect, acesta se va dovedi cu atât mai util echipei și clientului.
Atrag astfel atenția asupra faptului că tranziția nu este obligatorie. Nu este calea "normală" de a deveni PM: nicăieri nu scrie că trebuie să fii programator senior mai întâi. Ajută? Evident că da! Chiar dacă nu te implici în partea tehnică (pentru mine este greu să nu mă implic), perspectiva tehnică te ajută să identifici riscurile și să ajuți echipa în ciclul de dezvoltare.
Partea tehnică ajută în estimări. Atenție! A avea prea multe informații tehnice poate fi o capcană: nu uita care este rolul tău.
Deci, merită? Răspunsul ar fi că depinde de fiecare individ.
Pot spune că sunt foarte fericit cu această schimbare, cu bune și rele, cu noi situații și dificultăți. Pot confirma că aceasta tranzitie te scoate clar din zona de confort, dar tocmai de aceea iubesc ce fac. Privind în urmă, a fost o provocare pe care mă bucur că am acceptat-o.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
