Cât PMP și cât Agile trebuie să fie într-un proiect?

Dacă prin PMP înțelegem project management à la carte cred că am dat peste întrebarea secolului! În primul rând, care este diferența dintre ele?

Mi-am pus această întrebare acum ceva vreme când pregăteam un curs combinat (Agile și PMP), moment în care constatat că nu aveam un răspuns la îndemână. Am căutat pe net și am găsit o diferențiere interesantă: în timp ce PMI este un standard, Agile este un framework. Găsiți aici articolul complet: Difference between PMP, PRINCE2 and Scrum/Agile.

Altfel spus, PMP conține un set de best practices, iar Agile pune la dispoziție un cadru de lucru; PMP subliniază importanța colaborării și a comunicării, pe când Agile specifică necesitatea unei întâlniri zilnice a cărei durată să nu depășească (recomandabil) 15 minute.

Interesant, ați putea zice (iar eu v-aș da dreptate), dar până la urmă câte măsuri de PMP și cam câte de Agile este nevoie să amestecăm pentru a obține soluția perfectă de project management?

Personal nu cred că există așa ceva, soluția perfectă, acea combinație miraculoasă care vindecă calviția, scoate negii, petele de grăsime de pe covor și lustruiește argintăria. În schimb, cred în flexibilitate și în posibilitatea de a găsi pentru fiecare proiect în parte acea soluție care i se potrivește cel mai bine. Nu aș alege altceva decât Kanban pentru o perioadă de bug fixing, dar nu aș vrea să locuiesc lângă o centrală nucleară construită Agile; sau și mai interesant, să fiu supus unei intervenții chirurgicale condusă după principiul “Mai tăiem și mai vedem”. Brrr. Mă rog, dacă mă întrebați, aș prefera să locuiesc la foarte mare distanță de orice centrală nucleară (indiferent cum a fost construită), iar bisturiu să văd doar în Doctor House.

Până la urmă ce încercam să aflăm înainte să ne luăm cu vorba? Ah, da, mi-am amintit. Până unde putem împinge flexibilitatea în proiectele noastre comparativ cu cantitatea de hârțogăraie ce trebuie întocmită. Ups! Stai, că parcă nu așa suna tema inițială…

Hm, de fapt, aici era problema, nu este așa? Simțim managementul à la carte (de guler alb, cum i se mai spune) organic asociat de birocrație și formularistică. Noi nu adunăm date de contact în caz ca ne cade casa în cap și avem nevoie să dăm un telefon, ci constituim Stakeholder Register – pe care un om de bine din cadrul companiei l-a făcut să poată concura cu bazele de date ale serviciilor secrete. Nu contează că tot ce avem nevoie este o adresă de mail și un id de Skype, mai trebuie să completăm funcția în cadrul organizației, departamentul din care face parte, tipul de stakeholder, așteptările pe care le are și influența deținută în proiect, plus multe alte informații “absolut necesare”. Iar când aceste date se introduc electronic prin intermediul unei aplicații interne (care nu te lasă să salvezi ce ai muncit până nu introduci toate informațiile solicitate și nu juri pe roșu că te lași de fumat și nu mai mănânci grăsimi după ora șase), situația începe să capete accente de comedie bufă.

Nu cumva întrebarea pe care ne-o punem este: “Câtă formularistică trebuie să completăm versus câtă flexibilitate putem avea?”. Ce ar fi să căutăm răspunsul din această perspectivă?

Prima dată când am realizat gradul de toxicitate al unui template de proiect folosit în litera lui a fost acum mulți ani în timpul unei ședințe (care conform tarifelor practicate de cei aflați în sală, ardea în jur de 2,000+ de euro pe oră), subiectul fiind template-ul (cu T mare) care urma să fie folosit pentru colectarea unei informații banale. Oare o trebui păstrată zona X? Că parcă nu se aplică în cazul nostru… Eu zic că da; dacă este acolo, înseamnă că este nevoie de ea. Lasă că vedem noi ce scriem. Și tot așa, oră după oră. Nu este de mirare că asemenea gen de experiențe ajung să îi facă pe practicieni (dacă toată ziua ședințăm, noi când mai muncim?) să stuchească în sân doar când aud de project management. Problema este că opusul, anarhia, este la fel de rea ca și organizarea închistată.

Revenind la întrebarea inițială:

Cât Agile? Suficient de mult încât membrii echipei să își înfulece micul dejun cu gândul la acele lucruri interesante pe care le vor face imediat ce ajung la birou, de unde să nu le mai vină să plece acasă la sfârșitul programului. Cei ce au o pasiune, oricare ar fi ea, știu la ce mă refer.

Cât PMP? Poate surprinzător pentru un Agile practitioner, dar părerea mea este că tot PMP-ul – dar, atenție, în spirit, nu în formularistică și raportări! Abordat din perspectiva potrivită, acest lucru devine posibil.

Astfel, scopul proiectului poate fi foarte bine reprezentat prin user stories scrise pe bucăți de carton, nu aveți neapărată nevoie de Doors (aplicația de la IBM, nu trupa lui Jim Morrison) pentru managementul cerințelor. Având în vedere natura iterativă a proiectelor în Agile, puteți scăpa fără mari regrete de Work Breakdown Structure (WBS), dar un Product Breakdown Structure (PBS) poate fi de mare ajutor în constituirea backlog-ului. Riscul poate fi adresat prin intermediul unor banale coli de hârtie pe care să le țineți la vedere pe whiteboard-ul vostru.

La fel, aveți nevoie de o diagramă Gantt pentru a vedea pe axa timpului momentele importante din proiect, oferindu-vă oportunitatea de a orchestra interdependețele existente, dar este complet lipsit de sens să folosiți Microsoft Project pentru pontajul zilnic. Succesul se măsoară în software de calitate, nu în ore lucrate; iar dacă cineva nu mă crede, îi recomand atașeze la o aplicație evaluată la o stea pe Android Market o situație privind pontajul, să vadă cu cât se îmbunătățește ratingul.

QA, managementul costurilor, achiziții… Vă recomand un exercițiu simplu: deschideți PMBOK-ul la întâmplare și citiți primul cuvânt pe care vă pică ochii; foarte probabil veți constata că nu v-ar prinde rău să aveți așa ceva în proiectul vostru Agile – bineînțeles, cu condiția obligatorie ca acel concept, Individuals and interactions over processes and tools, enunțat în Agile Manifesto, să fie respectat întocmai și nu de formă.

Image taken from www.deviantart.com

Share with your friends










Submit