5 reguli pe care le-am văzut funcționând în echipele de proiect care rezistă

Cu mai bine de cincisprezece ani în urmă am avut un PM care ținea un fișier Excel cu minutele pe care fiecare dintre noi le petrecea la baie. Nu glumesc. Un fișier partajat, actualizat manual, cu coloane pentru dată, persoană, ora ieșirii, ora întoarcerii, durata. Îl arăta în ședința săptămânală de status ca un comentariu la progresul proiectului, ca și cum minutele departe de birou ar explica ceva despre întârzieri.

Rezultatul era previzibil. Dimineața echipa venea în tăcere, pașii pe coridor se făceau rapizi și furișați, lumea își decala drumurile la baie ca să nu coincidă cu vreun coleg. Două persoane și-au dat demisia în șase luni. Proiectul s-a livrat — doar că în lunile următoare jumătate din echipă era rotativă și fiecare nou-venit trebuia format de la zero.

Nu povestesc asta ca să dau lecții de morală. O povestesc pentru că e util să o punem alături de alta, mai recentă. Un PM într-un proiect de consolidare a data warehouse-ului pentru o bancă comercială italiană care, atunci când veneau mail-uri de escalation în cascadă de la etajele superioare, le citea el, le traducea într-o singură întrebare tehnică pentru noi și ne scutea de vârtej. La sfârșitul anului acea echipă produsese dublul muncii cu jumătate din ședințe.

Regulile pe care le voi aduna aici nu sunt decalogul meu de PM iluminat. Sunt pattern-uri pe care le-am văzut repetându-se în treizeci de ani de proiecte — mai întâi stând de cealaltă parte a mesei ca și consultant, apoi cu pălăria de responsabil. Sunt cinci, sunt simple, și când sunt la locul lor fac diferența între o echipă care rezistă sub presiune și o echipă care se destramă la prima curbă.

1️⃣ Dă oamenilor permisiunea să spună “nu știu” #

Într-o echipă, tăcerea aproape niciodată nu este concentrare. Este frică de a greși. Frică că a spune “nu știu” înseamnă a declara că nu ești la înălțimea rolului, a salariului, a așteptărilor. Și așa oamenii blufează. Acceptă task-uri pe care nu știu cum să le atace, petrec zile fără să întrebe, iar chestiunea iese la suprafață când nu mai e margine să o rezolvi.

Într-un proiect pentru un operator telco mobil, acum câțiva ani, un senior developer stătea de trei săptămâni blocat pe bugfixing-ul unui package PL/SQL complex — cursori imbricați, trigger-e care apelau alte trigger-e, tranzacții autonome, și câteva apeluri către dbms_aq lăsate acolo fără un comentariu — scris de un consultant plecat cu luni în urmă. Ședințe de status, mail-uri de la stakeholderi, reprogramări — și nimeni nu știa că blocajul era acolo. Până când un nou PM, venit cu proiectul în desfășurare, a deschis retrospectiva cu o întrebare directă: “Cine are ceva pe care e blocat și nu reușește să deblocheze?”. Senior-ul a ridicat mâna și a spus “acest package nu mai reușesc să-i urmăresc fluxul, mă înnebunește”. Un coleg dintr-o altă echipă, prezent în sală din întâmplare, a spus “vino dincolo, un package cu aceeași structură l-am refactorizat pentru alt client anul trecut, ți-l arăt în jumătate de oră”. Patruzeci și cinci de minute mai târziu blocajul dispăruse.

Trei săptămâni față de patruzeci și cinci de minute. Diferența nu era competența tehnică: know-how-ul era acolo, în companie, la două camere distanță. Diferența era posibilitatea de a admite că nu știi. Când acea permisiune lipsește, echipa plătește prețul blufului. Când este, informația circulă și blocajele durează minute în loc de săptămâni.

Termenul tehnic este Psychological Safety . Nu înseamnă un climat moale unde nimeni nu critică niciodată: înseamnă un climat unde poți recunoaște că nu știi fără consecințe asupra evaluării profesionale. Este premisa tuturor celorlalte.

2️⃣ Protejează echipa de zgomot #

PM-ul nu trebuie să fie un multiplicator de ședințe. Trebuie să fie un filtru. În orice proiect de o anumită mărime există un flux continuu de cereri care vin din afara echipei: stakeholderi care cer status actualizat în fiecare zi, directori care vor “un punct rapid” în fiecare dimineață, vendor-i care trimit mail-uri de escalation la jumătate de companie, comerciali care cer slide-uri pentru o întâlnire “de pregătit până mâine”.

Dacă toate astea ajung direct la echipă, echipa nu lucrează. Lucrează ca să răspundă micromanagement -ului extern, care este același mecanism cu al PM-ului care cronometrează minutele de baie, doar delegat către diverși stakeholderi.

În proiectul DWH al băncii pe care l-am citat la început, PM-ul găsise un echilibru aproape meșteșugăresc: cererile de status despre timpii de încărcare nocturnă, impactul pe model al fiecărei noi dimensiuni de adăugat, extragerile ad-hoc pentru control de gestiune — le intercepta el, le răspundea cu un raport săptămânal în format A4 pe care îl trimitea luni dimineața tuturor interesaților, și reușea să blocheze din start 90% din cererile punctuale. La echipă ajungea, filtrată, doar întrebarea tehnică ce cerea într-adevăr o aprofundare. Rezultat: echipa avea opt ore mai puțin de sloturi de ședințe pe săptămână. Opt ore per persoană, înmulțite cu șapte persoane, sunt peste o lună-om de muncă recuperată pe lună.

A proteja nu înseamnă a zidi echipa sau a face zidul de gumă. Înseamnă a distinge zgomotul de semnal — iar semnalul se recunoaște pentru că aduce informație nouă sau decizii adevărate, nu pentru că vine etichetat “urgent”.

3️⃣ Pune oamenii unde randează, nu unde e nevoie #

Antipattern-ul este comun: “e nevoie de cineva care să facă X, iau pe cel din echipă care are cel mai mult timp în calendar”. Dar faptul că acea persoană are timp liber nu o face automat persoana potrivită. Adesea unul care “ar fi necesar” pe X este unul care ar randa mult mai mult pe Y, cu X acoperit mai bine de altcineva.

Într-un proiect pentru o instituție a Administrației Publice italiene, o colegă fusese asignată la suportul de nivel 2 pe bazele de date de producție — tichete pe interogări lente, lock contention, extrageri ad-hoc de rezolvat direct cu utilizatori finali iritați la telefon. Tehnic bună, pregătită, și totuși suferea contactul direct cu cine la telefon ridica vocea; se întorcea acasă seara golită. Output-ul ei era bun dar niciodată excelent. După trei luni responsabilul a făcut un pas înapoi, a privit competențele reale și interesele echipei, și a reasignat acea colegă la modelarea dimensională a data warehouse-ului pe care îl construiam în paralel — unde s-a dovedit foarte puternică, proiectând fact table-uri și ierarhii de dimensiuni care au rezistat de-a lungul anilor fără restructurări majore. Suportul de nivel 2 a fost acoperit de un junior DBA care până în acel moment era pe backup-urile nocturne: acel contact direct cu interogările problematice îl forma, îl făcea să crească, îl făcea să se simtă util.

Rezultat: două persoane care înainte randau la 60% randau acum la 100%, și proiectul a beneficiat fără să fi angajat pe nimeni. Regula nu este “reasignează-i pe toți”, este mai subtilă: fă punctul la fiecare câteva luni, vorbește cu oamenii, observă unde cheltuie energie și unde câștigă. Un bun PM redistribuie pe baza observației, nu etichetează pe baza organigramei inițiale.

4️⃣ Pune cunoașterea să circule, nu oamenii #

Prima întrebare pe care un PM ar trebui să și-o pună este: “Dacă mâine echipa ar pierde o persoană, cât s-ar opri proiectul?”. Răspunsul — cuantificat în zile, nu în cuvinte liniștitoare — se numește bus factor . Un bus factor de 1 înseamnă că know-how-ul critic este într-un singur cap, iar acel cap se poate îmbolnăvi, poate pleca în concediu sau poate schimba compania. Un bus factor de 3 înseamnă că aceeași cunoaștere este distribuită în cel puțin trei persoane din echipă.

Instrumentele pentru a ridica bus factor-ul sunt simple și cunoscute — documentație minimă și mereu la zi, pair working pe activitățile critice, rotație periodică a responsabilităților — și toate trei cer ca PM-ul să pună timp de calendar, nu doar un mail de încurajare.

Într-un proiect la un operator poștal și logistic național cu aproximativ 1500 de instanțe MySQL și PostgreSQL în producție, presiunea operațională era foarte ridicată: când un DBA era în concediu, restul echipei suferea pentru că o bucată de cunoaștere specifică lipsea. Am introdus un ritual foarte simplu: în fiecare marți la 14:30, un knowledge transfer de 30 minute pe o temă specifică (configurarea unui nod Galera, procedura de recovery din binary log, troubleshooting-ul unui lock wait pe PostgreSQL, tuning-ul shared_buffers după o schimbare de workload), susținut pe rând de un membru al echipei. Sesiuni înregistrate, indexate într-un wiki intern, căutabile.

Șase luni mai târziu, când un DBA a plecat trei luni în concediu de paternitate, colegul care îl înlocuia era deja operațional din prima zi — nu atinsese niciodată personal acele sisteme; asistase sau văzuse înregistrate KT-urile pe procedurile critice. Ritualul nu este “din când în când facem puțină formare”. Ritualul este o jumătate de oră blocată în agendă, în fiecare săptămână, care produce un activ al echipei partajat. Este unul dintre lucrurile cu cel mai bun raport cost-beneficiu pe care le-am văzut aplicate într-un proiect.

5️⃣ Recunoaște munca, nu doar rezultatele #

Rezultatele unui proiect depind de variabile pe care echipa adesea nu le controlează: decizii ale clientului, schimbări de scope, întârzieri ale vendor-ilor, restricții normative care sosesc la mijlocul drumului. Munca, în schimb, este sub controlul echipei. Munca este ce s-a pus în ziua de lucru: ore de analiză, ore de coding, ore de discuție, ore de testare.

Dacă un PM recunoaște doar rezultatele, atunci când rezultatele se amână din cauze externe oamenii se demotivează. Au muncit bine, uneori chiar mult, și aud “oricum go-live-ul a picat”. Data viitoare vor munci mai puțin, pentru că au învățat că efortul lor nu contează dacă outcome-ul extern nu vine. Termenul tehnic este distincția între outcome și output : output-ul este ce a produs echipa, outcome-ul este rezultatul final măsurat de business.

Într-un proiect de data warehouse din sectorul asigurărilor multi-țară, echipa finalizase dezvoltarea unui nou data mart pentru analiza comisioanelor plătite intermediarilor — modelare dimensională, procese ETL de încărcare nocturnă, reconciliere cu contabilitatea de grup — respectând timpii și calitatea așteptate. Apoi, din cauza unor decizii de business care vizau realinierea unei alte zone a data warehouse-ului, go-live-ul s-a amânat trei luni și noul data mart a rămas în așteptare. Responsabila de proiect a chemat echipa într-o ședință de cincisprezece minute și a spus cu mare precizie: “Ați livrat ce trebuia să livrați, în timpii și la calitatea pe care ne-am propus-o. Go-live-ul depinde de factori care nu sunt în mâinile voastre. Mulțumesc pentru muncă.”. Apoi a enumerat, una câte una, bucățile de muncă cele mai dificile pe care echipa le înfruntase în lunile anterioare — trei-patru propoziții, specifice, concrete.

Va părea puțin. A fost enorm. Acea echipă și-a menținut ritmul și pe durata celor trei luni de așteptare, iar când go-live-ul a pornit a pornit bine. Regula nu este “distribuie medalii”. Regula este să distingi ce a făcut echipa bine (output) de ce a decis business-ul (outcome), și să recunoști explicit primul când al doilea nu vine.

🧭 PM-ul ca păzitor al condițiilor #

O vară de acum mulți ani, la Roma, cu una dintre acele caniculei care te țintuiesc pe asfalt, am decis să merg la birou în bermuda. Știam perfect că nu era vestimentația cea mai potrivită pentru un context profesional; căldura era într-adevăr în afara scalei. De cum am ajuns, pe coridor, l-am întâlnit pe manager. M-a privit din cap până în picioare și, zâmbind, mi-a spus: “Azi mergem la mare?”. Iar eu, din instinct, mi-am bătut arătătorul pe tâmplă și am răspuns: “Mă plătești pentru cum mă îmbrac sau pentru ce e aici înăuntru?”. A izbucnit în râs, mi-a dat o palmă pe umăr, și a mers drept către biroul lui. Din acea zi am continuat să avem o relație profesională excelentă, chiar dacă mai apoi drumurile ne-au dus în direcții diferite.

Acea palmă pe umăr este o imagine care mi-a rămas lipită. Într-un alt context — cel al fișierului Excel cu minutele de baie — aceeași scenă ar fi sfârșit într-o sesizare formală la HR și într-o notă în evaluarea anuală. Manager-ul care în acea dimineață a ales să râdă înțelesese un lucru simplu: valoarea unei persoane într-un proiect nu stă în bermuda sau în costum, stă în ideile pe care le produce și în munca pe care o face să circule. Acea alegere — a râde în loc de a sancționa — este exact meseria de păzitor al condițiilor.

Aceste cinci reguli nu sunt un decalog de PM care comandă. Sunt observații despre ce se întâmplă când anumite condiții sunt la locul lor și când lipsesc. Sub fiecare dintre ele există un fir comun: PM-ul nu este generalul care conduce trupele, este mai degrabă un păzitor al condițiilor. Munca lui este să facă în așa fel încât fiecare persoană din echipă să aibă permisiunea, spațiul și instrumentele ca să-și facă bine munca.

Succesul unui proiect este al echipei care l-a produs, nu al PM-ului. Iar responsabilitatea eșecurilor este a PM-ului mai mult decât a echipei, pentru că condițiile erau sub controlul lui. Această inversare — care pentru unii sună contraintuitiv — este partea care face diferența. Când o echipă simte că cine o conduce își asumă responsabilitatea pentru condiții și nu își asumă meritul pentru succese, rezistă mai bine la presiune, blufează mai puțin, se ajută mai mult.

Fiecare membru al echipei contribuie la succesul comun cu partea lui: tehnică, relațională, organizațională, de cunoaștere a domeniului. PM-ul contribuie cu condițiile. Dacă lipsesc condițiile, contribuția tuturor se năruie; dacă sunt, echipa rezistă. Cele cinci reguli de mai sus — toate — sunt modalități concrete de a pune în picioare acele condiții și de a le menține în timp.

Și nu, nu se ține un fișier Excel cu minutele de baie. Aceea este exact opusul muncii unui PM. Este semnul că nu s-a înțeles meseria.

Glosar #

Psychological Safety — Climatul unei echipe în care oamenii se simt liberi să recunoască greșelile, să spună “nu știu” și să ridice probleme fără să se teamă de consecințe asupra evaluării profesionale. Nu înseamnă un climat moale fără critici, ci siguranță profesională în a spune adevărul tehnic.

Bus Factor — Numărul de persoane din echipă care, dacă ar lipsi simultan, ar bloca proiectul. Un bus factor de 1 este un risc critic: cunoașterea este concentrată într-un singur cap. Obiectiv: menținerea bus factor-ului ≥ 3 pe competențele critice.

Micromanagement — Stil de management bazat pe controlul punctual al activităților zilnice ale echipei, adesea însoțit de cereri continue de status și de măsurarea timpului petrecut pe operațiuni individuale. Generează scădere de motivație, turnover și descurajează inițiativa.

Outcome vs Output — Distincția dintre ce produce concret echipa (output: cod, documente, deliverabil) și rezultatul final măsurat de business (outcome: go-live, venit, KPI). Output-ul este sub controlul echipei; outcome-ul depinde și de variabile externe.

Knowledge Transfer — Proces structurat de transfer al cunoașterii între persoane sau echipe, critic pentru a ridica bus factor-ul și a reduce dependențele de persoane individuale. Poate fi sincron (sesiuni pairing) sau asincron (documentație, video-uri înregistrate).