oldtimer

Uneori mi se pare ca ne-am fixat ca motto „Sa traim doar paradoxuri”! Suntem pasionati de ultimele tehnologii, insa o expozitie cu obiecte vintage ne atrage iremediabil. Ne plac masinile puternic accesorizate si computerizate, dar oftam cu subinteles cand vedem pe strada un model oldtimer. Ultima versiune de smartphone ne e mereu la indemana, da nu pierdem nici un moment sa ne amintim si sa vorbim de vechiul nostru telefon (cu taste) care niciodata nu ne „trada”.

Sa fie reticenta la schimbare (si, implicit, la nou)? Sa fie o imposibilitate umana de a ne debarasa de trecut si de lucrurile care ne-au marcat la un moment dat? Sau poate amandoua, in egala masura?

Oricum, cert este ca ne place acest „amestec” nostalgic in care sa includem permanent si o ramasita din alte epoci. O facem, uneori, pentru siguranta lucrului trainic. Alteori, pentru ca ultima „descoperire” nu pare suficient de stabila si de acoperitoare. De fapt, cred ca aici este problema: evolutia este atat de rapida, transformarile atat de subite incat elementele inconjuratoare (tehnologii, metodologii, standarde etc) nu reusesc sa tina pasul. Construim, adaugam „etaje” dar ancorele incep sa cedeze. Si atunci simtim nevoia sa punem un „ingredient” vechi, traditional. E o senzatie ca intarim intregul esafod si ca riscam mai putin o demolare brusca si foarte costisitoare.

Managementul proiectelor nu face exceptie. Febra „Agile” a cuprins intreaga comunitate. Am observat intreaga paleta de emotii – de la neincrederea specifica oricarei noi abordari pana la entuziasmul asociat unei solutii indelung asteptate. Sprinturi, cerinte adaugate pe tot parcursul proiectului, rezultate intermediare, termene reduse etc – toate fac parte din recuzita unei umbrele de metodologii („Agile”) si promit a ne face viata de manageri de proiect mult mai usoara.

Totusi, imediat ce entuziasmul (de sezon) s-a mai domolit, iar lucrurile au inceput sa se mai aseze, surprizele nu au intarziat sa apara. Prima (oarecum asteptata) a fost legata de domeniile in care se poate aplica abordarea Agile. Nici macar industria software – „incubatoarea” acestei abordari – nu se poate baza, in toate ramurile ei, pe Agile techniques. De celelalte domenii, nici nu mai vorbim.

Dintr-odata, noua „abordare-minune” a inceput sa si dovedeasca limitarile, dezamagind adeptii mult-prea grabiti in a generaliza. Umbrela „Agile” se dovedeste insuficienta pentru a acoperi tot procesul de managementul proiectelor si suficient de instabila pentru a deschide noi semne de intrebare. Dar nu-i nimic! Intra in functiune „reteta” prezentata la inceput. Paradoxul e la indemana noastra si incepem sa „amestecam”.

Nu avem suficienta vizibilitate, nu simtim un control suficient asupra fazelor unui proiect? Atunci imbunatatim abordarea Agile cu… planificarea traditionala. Nu mai pastram ideea de planificare per etapa (pas cu pas), incercam si un plan general. Nu putem evidentia legatura proiecte – strategia companiei? Cerintele, scopul – nu sunt de ajuns pentru a raspunde intrebarilor managementului? Ce ar fi sa mixam technicile Agile cu…managementul prin obiective (Management by objectives)? Chiar daca ultima este o abordare cu state vechi (descrisa de Peter Drucker in 1954). Are stabilitate dovedita, succes demonstrat si e deja perfectionata. Echipa nu comunica asa cum trebuie, in ciuda faptului ca am mers pe o abordare tip fractal (1 expert, 1 om de marketing, 1 dezvoltator etc)? Hai sa folosim tehnici de comunicare din managementul traditional (si decrepit!) al proiectelor – intalniri mai de durata cu toate echipele din proiect. Contravine principiului „Agile”? Posibil! Insa doar putin si ne ajuta sa mentinem controlul, sa avem performante.

In final, obtinem un amalgam care raspunde cerintelor specifice unei situatii dar care este departe de propunerea initiala. Nu pot si nu vreau sa ma pronunt pentru validitatea unei astfel de abordari. Cu alte cuvinte, este si bine si rau. Pe de-o parte, este bine intrucat nicio abordare nu trebuie considerata ad-literam ci trebuie imbunatatita/ajustata permanent. Nu exista o reteta, iar standardele/metodologiile sunt doar „coloana vertebrala” a managementului proiectelor. Restul tine de inspiratie, intuitie si experienta managerului de proiect.

Pe de alta parte, raul vine tocmai din ceea ce prezentam la inceput. Avalansa de informatii/tehnici/schimbari determina o nesiguranta si (de aici) o reticenta cronica la asumarea riscurilor pentru ceea ce e (relativ) nou si (poate) insuficient aplicat. Si atunci, adaugam elemente deja impamantenite, cu performante dovedite.

Daca imi permiteti o comparatie aluziva – am migrat de la McArthur-i si Ioane D’Arc la „comitete si comitii” care acopera (de multe ori) „spatele” in cazul deciziilor dificile.  Clamam aplicarea (numai a) tehnicilor noi si inovatoare. Dar, pastram (la loc de cinste) o „vitrina de pe vremea bunicii” din care mai scoatem o planificare tip waterfall, o comunicare top-down sau o guvernanta cu Steering Committee.  Paradoxal, nu?