Mai țineți minte când vorbeam de antecedente, consecințe, penalizări și managementul performanței? Tocmai mi-am adus aminte de o situație de incompatibilitate între presiunea la care era supusă echipa și calitatea livrată.
– Hai să-ți zic și eu păsul meu! îmi spunea un prieten, șef de proiect într-o companie de servicii IT.
…
– Cum merge treaba?
– Nasol. Am livrat acum două săptămâni lotul B. Și clientul s-a apucat să testeze lotul A. Ne-am trezit cu o grămadă de probleme. Dar noi trecuserăm deja de acceptanța lotului A.
– Interesant. Cum ați reacționat?
– Ne-am apucat să facem un patch rapid.
– Și cum a ieșit?
– Mai rău. O grămadă de probleme. Acum e mare scandal.
– Ai de gând să faci ceva despre asta?
– Păi, mai facem un patch.
– Și ce veți face diferit față de data trecută?
– Nimic, sperăm să avem mai mult succes.
Parcă-mi era milă de el. Muncea pe brânci. Nici el nu credea să mai iasă ceva bun din proiectul pe care lucra. În niciun caz pentru el. I-am spus că ceea ce face el se numește nebunie și că în niciun caz nu trebuie să continue fără să schimbe ceva. L-am întrebat ce se poate întâmpla în cel mai rău caz dacă spune că întreaga echipă trebuie să se oprească și să corecteze chestiunile critice, ceea ce ar implica refactoring masiv.
– Imposibil! Clientul creează acum o echipă de acceptanță aducând utilizatori din toate țările. Această echipă se va întruni peste câteva luni să testeze aplicația înaintea trecerii în producție. Sunt o grămadă de bani la mijloc și nu putem amâna acest moment.
– Singura diferență dintre a spune acum că nu reușiți să livrați și ceea ce faceți constă în cât de penibil va fi momentul în care problemele se vor adeveri.
Nu o singură dată mi s-a dat să discut cu responsabili de produs sau șefi de echipe nemulțumiți de calitatea muncii echipelor lor. Aceștia preferau să accepte însă munca dezvoltatorilor ca să întrețină sentimentul de progres sau ca să ascundă dificultățile față de persoanele care ar putea influența oprirea proiectului. E drept că șmecheria funcționează. Cu cât s-au cheltuit mai mulți bani, cu atât un proiect este mai greu de închis, pentru că nimeni nu vrea să-și asume responsabilitatea eșecului:
- ni se poate adresa problema de competență,
- riscăm să pierdem ceva sau să fim penalizați,
- de obicei celor cărora le revine responsabilitatea închiderii proiectului li se poate reproșa că nu s-au implicat suficient de mult,
- banii investiți sunt pierduți,
- etc.
Toate exemplele de mai sus sunt consecințe imediate și domină întotdeauna comportamentele cu consecințe sănătoase și îndepărtate. Din această cauză, închiderea devreme a proiectului este asociată cu eșecul. În cursurile mele subliniez că un proiect închis la timpul potrivit este tot un proiect de succes. Până la urmă, ne-am făcut treaba excelent:
- s-a dat vizibilitate pe progres și riscuri,
- s-au livrat prototipuri de calitate și
- am împiedicat aruncarea multor bani pe fereastră.
Însă din nefericire, am realizat și că în condițiile date, legate de
- buget,
- constrângeri calendaristice,
- competiție,
- disponibilitatea oamenilor
ceea ce ne dorim să facem nu este realizabil. Eu cred că ar trebui să ne mândrim și cu astfel de realizări.
Închiderea proiectului este un semn de profesionalism.
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 1487 ori