Articolul a apărut mai întâi în varianta în limba engleză.

Profesând de ceva vreme în domeniul managementului de proiect, dar fiind și un programator experimentat, aud destul de des câteva idei greșite, în special de la programatori, despre ceea ce face într-adevăr un Manager de Proiect (PM = Project Manager). Am scris mai jos o mică explicație despre fiecare. De menționat că aceste idei se referă în general la rolul de PM în cadrul metodologiei clasice, Waterfall.

 

1) Project Managerii nu sunt necesari și nu ar trebui să existe într-o companie.

Project Managerii chiar există, și, de zeci de ani au avut un rol important în toate companiile mari, medii și mici. O mulțime de oameni inteligenți au fost implicați în aceste companii de-a lungul anilor și au apreciat munca Project Managerilor. Care sunt șansele ca programatorul X de la compania Y, în orașul Z, țara W, să fi descoperit chiar acum că Project Managerii sunt inutili? Nu ar fi o explicație mai logică faptul că programatorul să nu fi reușit încă să înțeleagă care este rolul lor?

 

2) Care este rolul lor? Nu par să aibă nici o responsabilitate.

Ei bine…ei sunt responsabili pentru întregul proiect.

Programatorii nu realizează de obicei că un proiect are mai multe faze: inițierea, planificarea, execuția, monitorizarea & controlul, închiderea. Programatorul este de obicei implicat într-o mică parte a fazei de execuție. PM-ul, în schimb, este responsabil pentru toate aceste faze.

PM-ul știe de la cine a venit cerința de feature pe care programatorul lucrează. El a discutat cu clientul despre aceasta, a negociat alte cerințe, a înțeles problema de business a clientului pentru care s-a cerut dezvoltarea feature-ului. PM-ul a analizat feature-ul pentru a înțelege cum ar afecta produsul și cum ar afecta alte părți interesate. Apoi a cerut o estimare de la programator (sau a folosit alte metode pentru a obține estimări). Apoi a calculat riscurile: ce se întâmplă dacă programatorul  ar părăsi compania, dacă tehnologia decisă acum se va schimba în doi ani, dacă etc…PM-ul a evaluat ce impact va avea feature-ul și l-a inclus în planul de dezvoltare. Pe baza acestui lucru el a negociat din nou cu clientul/sponsorul proiectului. Apoi a integrat cerința de feature într-o multitudine de documente pe care probabil programatorul nu le va vedea vreodată.

Abia în acest punct, programatorul își face munca lui de a implementa cerința, iar apoi încetează să-i pese ce se întâmplă cu feature-ul dezvoltat. Dar, chiar în timp ce programatorul lucrează la implementare fără a avea nicio altă grijă, PM-ul trebuie să se asigure că are o echipă pe care să se bazeze. El trebuie să gestioneze conflictele, să “consolideze” echipa, să facă sarcinile legate de HR, evaluări, etc. După ce programatorul încheie dezvoltarea feature-ului, PM-ul trebuie să se asigure că aceasta îndeplinește pe deplin cerințele, de obicei făcând legătura cu oamenii de QA. După ce toate lucrările sunt efectuate de către toți oamenii și departamentele implicate, PM-ul trebuie să-i arate clientului că munca a fost făcută în conformitate cu cerințele și să obțină semnarea procesului verbal de finalizare a implementării. Apoi, PM-ul trebuie să ajute viitorii managerii de proiect prin documentarea fiecărui pas și a fiecărei decizii luate în proiect.

Am descris doar o mică parte a activității Project Manager-ului. În final, scopul său este de a avea un proiect de succes și un client fericit.

 

3) De ce mă obligă să fac estimări? E treaba lui de a planifica. De ce îi fac eu treaba?

Nu, programatorul nu face munca PM-ului atunci când acesta îi solicită estimări. Treaba PM-ului este de a obține cele mai exacte estimări posibile. Și cine poate da mai bine o estimare dacă nu persoana care va face efectiv munca?

 

4) Task-ul îmi va lua probabil o zi. Dar nu sunt chiar sigur, așa că voi da o estimare de două zile, pentru a proteja proiectul de întârzieri.

Nu face asta! Spune-i PM-ului că nu ești sigur cu privire la estimare, iar acesta va planifica în consecință. El va include riscul ca task-ul să dureze două zile în loc de una. PM-ul trebuie să gestioneze proiectul utilizând în mod optim resursele avute la dispoziție, deci dacă ai terminat cu o zi înainte față de estimare și nu comunici acest lucru, compania va pierde bani deoarece nu îți poate folosi în mod optim abilitățile. Iar legat de protejat proiectul de întârzieri, ține minte: sarcina programatorului este să programeze, iar sarcina PM-ului este de a gestiona proiectul. Lasă-l să facă acest lucru.

 

5) Pentru că tot am ceva timp liber, voi dezvolta un nou feature pentru proiect. Pun pariu că PM-ul va fi foarte fericit.

Nu, nu va fi. Ceea ce faci se numește “gold-plating” și nu este recomandat deloc. Pentru că tu, programatorul, ai luat o decizie cu privire la ceea ce este important pentru client. Gândește-te ce se poate întâmpla: dacă task-urile pe care chiar le-ai avut de făcut nu sunt grozave, există riscul ca clientul să spună “De ce naiba ai dezvoltat un feature pe care nu l-am cerut, în loc să faci o treabă bună cu feature-ul de care chiar aveam nevoie?” Mai multe detalii despre ce este gold-plating-ul poți afla în acest articol.

 

6) Deși face parte din echipa noastră, PM-ului pare să-i pese mai mult de client.

Îmi pare rău să te dezamăgesc, dar chiar așa este. PM-ul trebuie întotdeauna să păstreze un echilibru între interesul tuturor persoanelor implicate în proiect: senior management, managerii altor departamente, echipa, clienții – toată lumea. Deci, deși pare să facă parte din echipa ta (și chiar așa este), treaba lui nu este doar să te țină fericit. De fapt, treaba lui este să-l păstreze pe client fericit.

 

7) PM-ul cere oamenilor să facă ore suplimentare. Trebuie să fie un PM foarte bun dacă reușește să convingă oamenii să facă acest lucru.

Îmi pare rău că te dezamăgesc încă o dată, dar de fapt nu este.  A cere oamenilor să facă ore suplimentare, mai ales în mod regulat, este ultimul lucru pe care un PM trebuie să-l facă pentru a se ține de program. Deci, cererea de ore suplimentare este de fapt un semn că ai de-a face cu un PM foarte slab pregătit.

 

8) Întotdeauna se implică în tot acest PM. E enervant.

PM-ul încearcă să se implice în toate activitățile, discuțiile, conflictele etc. pentru că trebuie să înțeleagă și să controleze tot ceea ce ar putea avea impact asupra proiectului. Dar, abilitatea de a te implica în tot, fără să-ți fie cerut acest lucru, e un soft-skill ce se dezvoltă în timp. Dă-i timp PM-ului să învețe să o facă mai cu naturalețe.

 

9) Am descoperit această librărie mișto open-source, care îmi va permite să termin munca mai devreme, astfel că PM-ul va fi fericit.

Nu, nu va fi. Neluând în considerare faptul că, dacă vei termina mai devreme, programul proiectului va trebui modificat, PM-ul ar trebui să fie foarte îngrijorat de această librărie descoperită. Ce se întâmplă dacă părăsești compania? Vor fi găsiți alți programatori care vor înțelege această librărie? Care va fi costul acestor programatori? De asemenea, librăria este open-source pentru moment, dar va rămâne așa peste 5 ani? Dar va mai exista această librărie peste 5 ani? Există suport și documentație adecvată pentru această librărie? Care este impactul asupra altor secțiuni ale proiectului? Ție, ca programator, nu-ți pasă de toate aceste lucruri. Tocmai ai terminat un task de 8 ore în 2 ore mulțumită acestei librării. Dar, pentru PM acest lucru poate fi foarte costisitor.

 

10) PM-ul nu înțelege termenii tehnici. Dacă gestionează un proiect tehnic, nu ar trebui să fie o persoană tehnică?

Deși PM-ul trebuie să înțeleagă foarte bine domeniul în care lucrează, nu este necesar ca el să fie un expert în toate tehnologiile utilizate în cadrul acelui proiect. Trebuie doar să înțeleagă suficient pentru a gestiona cu succes proiectul. Ducând asta la extrem, ar fi posibil ca, având o pregătire corespunzătoare, un PM specializat pe IT să poată conduce, de asemenea, construirea unui zgârie-nori.

 

În concluzie, PM-ul este cea mai importantă persoană implicată într-un proiect. Este persoana care pune toate piesele proiectului împreună într-un tot unitar. De îndată ce programatorul înțelege cu adevărat rolul PM-ului, el poate deveni un profesionist mai bun prin sprijinirea activă a acestuia.

10 idei greșite pe care programatorii le au despre Project Manager

Vrei să te anunţăm când scriem ceva nou?

Politica de confidențialitate