ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 61
Abonament PDF

La ce să (nu) ne așteptăm!

Daniel Lăcătuș
Senior Software Developer
@Accesa



PROGRAMARE

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

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.

Proiecte interne - yeach !

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ță.

Nu, nu este o promovare

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ă.

Dincolo de zona de confort

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.

Deci, ce facem de fapt?

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.

Este necesar să avem cunoștințe tehnice?

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.

Concluzie

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.

În aceeaşi ediţie ... (61)

▼ TOATE ARTICOLELE ▼

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects

Daniel Lăcătuș a mai scris