Retrospectiva de proiect: cum tragi lecțiile la final

Retrospectiva de proiect este întâlnirea de la finalul unui proiect în care echipa și principalele părți interesate analizează cum a decurs munca, ce a funcționat, ce nu și din ce motive, cu scopul de a schimba ceva concret în proiectele următoare. Se mai numește analiza lecțiilor învățate sau, în unele organizații, post-mortem, deși ultimul termen sugerează greșit că discuția are loc doar după un eșec. Un proiect reușit are la fel de multe de învățat ca unul cu probleme, pentru că succesele care nu sunt înțelese nu pot fi repetate.

Diferența dintre o retrospectivă utilă și una de formă este simplă: prima produce câteva acțiuni concrete, cu responsabil, care ajung în modul de lucru al organizației; a doua produce o listă de impresii arhivată într-un dosar pe care nu îl mai deschide nimeni. Ghidul de mai jos arată cum pregătești, conduci și valorifici o retrospectivă de final, pentru proiecte mici și mijlocii.

Retrospectiva de final față de retrospectiva de sprint

Retrospectiva de final privește întregul proiect, de la inițiere la predare, pe când retrospectiva de sprint privește doar ultimul ciclu de lucru al unei echipe agile. Cele două se completează și folosesc tehnici asemănătoare, dar au scopuri și participanți diferiți.

Dacă echipa a lucrat în sprinturi, notele din retrospectivele de sprint sunt o materie primă excelentă pentru cea de final. Cum funcționează retrospectiva în cadrul Scrum este explicat în Scrum pe înțeles: roluri, sprinturi și ceremonii.

Când o organizezi și cine participă

Retrospectiva de final se organizează cel mai bine la una–două săptămâni după predarea rezultatului, când oamenii încă își amintesc detaliile, dar nu mai sunt sub presiunea lansării. Amânată o lună sau mai mult, se transformă într-un exercițiu de memorie, iar oamenii sunt deja absorbiți de alte proiecte.

Participanți recomandați:

• echipa de proiect, inclusiv cei care au plecat din proiect înainte de final, dacă sunt disponibili;
• managerul de proiect, care de multe ori nu ar trebui să fie și facilitator;
• sponsorul, cel puțin pentru partea de rezultate și acțiuni;
• reprezentanți ai utilizatorilor sau ai departamentelor afectate;
• furnizori-cheie, pentru o sesiune separată sau pentru o parte a discuției.

Cine facilitează

Ideal, facilitatorul este cineva neutru: un manager de proiect din altă echipă, un coleg de la resurse umane sau un facilitator extern. Managerul proiectului este parte din poveste și le este greu oamenilor să critice deciziile lui în fața lui. Dacă nu ai altă variantă, spune deschis că vei încerca să fii neutru și cere explicit observații despre propriul rol.

Cum pregătești retrospectiva

Pregătirea face diferența dintre o discuție bazată pe impresii și una bazată pe fapte. Cu o săptămână înainte, adună datele și construiește o imagine comună a proiectului.

Ce pregătești:

1. Cronologia proiectului: jaloanele planificate și reale, deciziile importante, schimbările de domeniu, momentele de criză.
2. Datele comparative: durata și costul estimate față de cele reale, numărul de schimbări aprobate, riscurile produse, problemele de calitate după predare.
3. Un chestionar scurt și anonim, trimis participanților: ce a mers bine, ce nu, ce ar face diferit, cât de mulțumiți sunt de rezultat și de colaborare, pe o scară de la 1 la 5.
4. Registrul de riscuri și lista de probleme din timpul proiectului; vezi Riscurile în proiect: cum le identifici și le ții sub control.
5. Feedback de la beneficiari, cules prin discuții scurte sau printr-un formular.
6. Agenda și regulile întâlnirii, trimise din timp.

Comparația dintre estimări și realitate merită o atenție aparte: ea calibrează estimările proiectelor viitoare, așa cum explică ghidul despre estimarea duratei și a costurilor.

Regula de bază: căutăm cauze, nu vinovați

O retrospectivă funcționează doar dacă oamenii pot vorbi deschis despre greșeli, inclusiv despre ale lor, fără teama de consecințe. De aceea, multe echipe pornesc de la un principiu formulat de consultantul Norm Kerth, cunoscut ca „directiva de bază” a retrospectivelor. Ideea lui, pe scurt: indiferent ce descoperim, pornim de la premisa că fiecare a făcut cea mai bună treabă de care era capabil, cu ce știa atunci, cu abilitățile și resursele pe care le avea și în situația dată.

Principiul nu înseamnă că nimeni nu răspunde de nimic. Înseamnă că discuția caută ce condiții au făcut posibilă o greșeală (informații lipsă, presiune de timp, roluri neclare, proceduri inexistente), pentru că acestea pot fi schimbate. Căutarea vinovaților îi face pe oameni să-și ascundă greșelile data viitoare.

Important: Retrospectiva nu este locul pentru evaluarea performanței individuale și nici pentru discuții disciplinare. Dacă apar probleme de comportament sau de performanță ale unei persoane, ele se discută separat, între manager și persoana respectivă, după regulile obișnuite din organizație.

Mediul în care oamenii pot recunoaște greșeli fără teamă se construiește în timp, nu doar în ziua retrospectivei; vezi Siguranța psihologică în echipă: ce este și cum o creezi.

Structura întâlnirii, în cinci faze

O structură în cinci faze, popularizată de Esther Derby și Diana Larsen în lucrările lor despre retrospective, ține discuția pe drumul de la fapte la acțiuni. Duratele de mai jos sunt orientative, pentru o întâlnire de aproximativ trei ore.

Pauzele contează: o întâlnire de trei ore fără pauză își pierde energia după prima oră și jumătate. Pentru regulile generale de conducere a unei ședințe, vezi Ședințele eficiente: cum le pregătești, conduci și închei.

Cronologia, punctul de plecare

Desenează pe un perete sau pe o tablă digitală o axă a timpului proiectului și roagă fiecare participant să adauge evenimentele importante pentru el, cu o culoare pentru momentele bune și alta pentru cele dificile. Oamenii descoperă rapid că au trăit proiectul diferit: ce a fost o criză pentru echipa tehnică poate să fi trecut neobservat pentru vânzări.

Formate utile pentru adunarea observațiilor

Formatul potrivit depinde de mărimea grupului, de tipul proiectului și de cât de des a mai făcut echipa retrospective. Schimbarea formatului de la o retrospectivă la alta menține discuția proaspătă.

Indiferent de format, cere-le oamenilor să scrie întâi individual, în tăcere, câteva minute, apoi să citească pe rând. Astfel, vocile mai discrete contează la fel de mult ca cele mai sigure pe ele.

De la simptome la cauze

Observațiile de tipul „am întârziat la testare” sunt simptome. Ca să ajungi la cauze, folosește tehnica „5 de ce”: întrebi repetat „de ce?” până ajungi la o cauză pe care o poți schimba. Exemplu: am întârziat la testare → pentru că mediul de test a fost gata târziu → pentru că nimeni nu era responsabil de el → pentru că nu apărea în planul de proiect → pentru că șablonul de plan al firmei nu are o secțiune pentru infrastructură. Acțiunea rezultată, completarea șablonului, previne problema în toate proiectele viitoare.

Pentru probleme cu mai multe cauze, diagrama cauză–efect, numită și diagrama Ishikawa sau „os de pește”, grupează cauzele pe categorii: oameni, metode, instrumente, informații, mediu.

De la observații la acțiuni concrete

O retrospectivă se măsoară prin acțiunile care se aplică după ea, nu prin numărul de observații adunate. Pentru ca acțiunile să nu rămână pe hârtie, limitează-le și formulează-le precis.

Reguli pentru acțiuni:

• puține: trei–cinci acțiuni importante, nu douăzeci;
• concrete: „adăugăm în șablonul de plan o secțiune despre infrastructura de test” în loc de „comunicăm mai bine”;
• cu un responsabil, o singură persoană pe acțiune;
• cu termen și cu modul în care verifici că s-a făcut;
• cu sponsor, când acțiunea cere decizii sau resurse în afara echipei.

Multe dintre cele mai valoroase acțiuni sunt modificări ale procedurilor, șabloanelor sau listelor de verificare ale organizației. Cum le scrii astfel încât să fie chiar folosite este explicat în Procedurile de lucru: cum le scrii ca să fie folosite. Recunoașterea contribuțiilor și observațiile despre colaborare se dau, la rândul lor, după principiile din Feedbackul constructiv: metode, exemple și greșeli de evitat.

Sfat: Programează încă de la retrospectivă o verificare scurtă, la o lună sau două, în care sponsorul și responsabilii confirmă stadiul acțiunilor. Fără acest pas, majoritatea acțiunilor se pierd în agitația proiectului următor.

Documentul de lecții învățate și cum îl folosești

Documentul de lecții învățate păstrează rezultatul retrospectivei într-o formă pe care o pot folosi alte echipe, peste luni sau ani. Trebuie să fie scurt, structurat și ușor de găsit.

Structura recomandată:

1. Date de identificare: proiectul, perioada, sponsorul, managerul de proiect.
2. Rezumatul rezultatelor: obiectiv, durată și cost estimate față de cele reale, principalele abateri.
3. Ce a funcționat și merită repetat.
4. Ce nu a funcționat, cu cauzele identificate.
5. Recomandări pentru proiecte similare, formulate ca sfaturi practice.
6. Acțiunile stabilite, cu responsabili și termene.

Arhivează documentul într-un loc comun, cu etichete după tipul proiectului, și fă din consultarea lui un pas obligatoriu la pornirea proiectelor noi: managerul de proiect citește lecțiile proiectelor asemănătoare înainte de a planifica. Altfel, organizația plătește de mai multe ori pentru aceeași lecție.

Greșeli frecvente la retrospectiva de proiect

• Retrospectiva sărită pentru că „proiectul s-a terminat și toată lumea e ocupată”.
• Organizată prea târziu, când detaliile s-au uitat.
• Căutarea vinovaților, care îi face pe oameni să tacă.
• Doar despre probleme, fără a analiza ce a funcționat.
• Prea multe acțiuni vagi, fără responsabil și termen.
• Document arhivat și necitit la proiectele următoare.
• Managerul de proiect facilitează și se apără de fiecare observație critică.

Ce iei cu tine din acest ghid

Retrospectiva de final este momentul în care experiența unui proiect devine cunoaștere pentru organizație. O pregătești cu date reale, o conduci după o structură care trece de la fapte la cauze și apoi la acțiuni, protejezi deschiderea oamenilor și urmărești ca acțiunile să fie chiar aplicate. Pentru locul ei în etapa de închidere și în ciclul de viață al proiectului, vezi ghidul de management de proiect.

De reținut:

• organizeaz-o la una–două săptămâni după predare, cu un facilitator neutru;
• pregătește cronologia, datele comparative și un chestionar anonim;
• caută condițiile care au produs problemele, nu vinovații;
• urmează cele cinci faze: cadru, date, cauze, acțiuni, închidere;
• limitează acțiunile la câteva, fiecare cu responsabil și termen;
• fă din lecțiile învățate o lectură obligatorie la pornirea proiectelor noi.