Project management: 5 regole per team che reggono

Più di quindici anni fa ho avuto un PM che teneva un foglio Excel con i minuti che ciascuno di noi passava in bagno. Non scherzo. Un foglio condiviso, aggiornato a mano, con colonne per data, persona, orario di uscita, orario di rientro, durata. Lo mostrava in riunione settimanale a commento dell’andamento del progetto, come se i minuti lontano dalla scrivania spiegassero qualcosa dei ritardi.

Il risultato era prevedibile. Di mattina il team arrivava in silenzio, i passi in corridoio si facevano veloci e furtivi, la gente si scaglionava per non coincidere con un collega al gabinetto. Due persone si sono dimesse entro sei mesi. Il progetto è stato consegnato — solo che nei mesi successivi la metà del team era rotante e ogni nuovo arrivato doveva essere formato da zero.

Non racconto questa storia per far la morale. La racconto perché è utile metterla in contrasto con un’altra, più recente. Un PM in un progetto di consolidamento del data warehouse di una banca commerciale italiana che, quando arrivavano email di escalation a raffica dai piani alti, le leggeva lui, le traduceva in una singola domanda tecnica per noi e ci risparmiava il turbinio. A fine anno quel team aveva prodotto il doppio del lavoro con metà delle riunioni.

Le regole che raccoglierò qui non sono il mio decalogo da PM illuminato. Sono pattern che ho visto ricorrere in trent’anni di progetti — prima seduto dall’altra parte del tavolo come consulente, poi con il cappello del responsabile. Sono cinque, sono semplici, e quando ci sono fanno la differenza tra un team che regge sotto pressione e un team che si sfalda alla prima curva.

1️⃣ Dai alle persone il permesso di dire “non lo so” #

In un team, il silenzio non è quasi mai concentrazione. È paura di sbagliare. Paura che dire “non lo so” equivalga a dichiarare di non essere all’altezza del ruolo, della paga, delle aspettative. E così le persone bluffano. Accettano task che non sanno come affrontare, ci passano giorni senza chiedere, e la criticità emerge quando non c’è più margine per risolverla.

In un progetto presso un operatore telco mobile, qualche anno fa, un senior developer era bloccato da tre settimane sul bugfixing di un package PL/SQL complesso — cursori annidati, trigger che chiamavano altri trigger, transazioni autonome, e qualche chiamata a dbms_aq buttata lì senza un commento — scritto da un consulente andato via mesi prima. Riunioni di stato, email di stakeholder, rinvii — e nessuno sapeva che il blocco era lì. Fino a quando un nuovo PM, arrivato a progetto in corso, ha aperto la retro con una domanda secca: “Chi ha qualcosa su cui è bloccato e non riesce a sbloccare?”. Il senior ha alzato la mano, ha detto “questo package non riesco più a seguirne il flusso, mi sta facendo impazzire”. Un collega di un altro team, presente per caso in sala, ha detto “vieni di là, un package con la stessa struttura l’ho rifattorizzato per un altro cliente l’anno scorso, te lo mostro in mezz’ora”. Quarantacinque minuti dopo il blocco era sciolto.

Tre settimane contro quarantacinque minuti. La differenza non era competenza tecnica: il sapere c’era, in azienda, a due stanze di distanza. La differenza era la possibilità di ammettere di non sapere. Quando quel permesso manca, il team paga il prezzo del bluff. Quando c’è, l’informazione circola e i blocchi durano minuti invece di settimane.

Il termine tecnico è Psychological Safety . Non significa un clima morbido dove nessuno critica mai: significa un clima dove si può ammettere di non sapere senza conseguenze sul giudizio professionale. È il presupposto di tutto il resto.

2️⃣ Proteggi il team dal rumore #

Il PM non deve essere un moltiplicatore di riunioni. Deve essere un filtro. In ogni progetto di una certa dimensione c’è uno flusso continuo di richieste che arrivano dall’esterno del team: stakeholder che chiedono status aggiornato ogni giorno, direttori che vogliono “un punto veloce” ogni mattina, vendor che mandano email di escalation a mezza azienda, commerciali che chiedono slide per un incontro “da preparare entro domani”.

Se tutto questo arriva diretto al team, il team non lavora. Lavora a rispondere al micromanagement esterno, che è lo stesso meccanismo del PM che cronometra i minuti di gabinetto, solo delegato a stakeholder vari.

Nel progetto del DWH della banca che ho citato in apertura, il PM aveva trovato un equilibrio quasi artigianale: le richieste di status sui tempi di caricamento notturno, gli impatti sul modello di ogni nuova dimensione da aggiungere, le estrazioni una tantum per il controllo di gestione — le intercettava lui, le rispondeva con un report settimanale formato A4 che mandava il lunedì mattina a tutti gli interessati, e riusciva a bloccare sul nascere il 90% delle richieste puntuali. Al team arrivava, filtrata, la sola domanda tecnica che richiedeva davvero un approfondimento. Risultato: il team aveva otto ore di slot riunioni in meno a settimana. Otto ore per persona, moltiplicate per sette persone, sono oltre un mese-uomo di lavoro al mese recuperato.

Proteggere non significa barricare il team o fare il muro di gomma. Significa distinguere ciò che è rumore da ciò che è segnale — e il segnale lo si riconosce perché porta informazione nuova o decisioni vere, non perché arriva con un tag “urgente”.

3️⃣ Metti le persone dove rendono, non dove servono #

L’antipattern è comune: “serve qualcuno che faccia X, prendo quello del team che ha più tempo in calendario”. Ma il fatto che quella persona abbia tempo libero non la rende automaticamente la persona giusta. Spesso uno che “servirebbe” su X è uno che renderebbe molto di più su Y, con X coperto meglio da qualcun altro.

In un progetto per un ente della Pubblica Amministrazione italiana, c’era una collega assegnata al supporto di secondo livello sui database di produzione — ticket su query lente, lock contention, estrazioni una tantum da richiamare direttamente con gli utenti finali infastiditi. Tecnicamente brava, preparata, e tuttavia soffriva il contatto diretto con chi al telefono alzava la voce; tornava a casa la sera svuotata. Il suo output era buono ma mai eccellente. Dopo tre mesi il responsabile ha fatto un passo indietro, ha guardato le competenze reali e gli interessi della squadra, e ha riassegnato quella collega alla modellazione dimensionale del data warehouse che stavamo costruendo in parallelo — dove si è rivelata molto forte, disegnando fact table e gerarchie di dimensioni che hanno retto negli anni successivi senza grandi ristrutturazioni. Il supporto di secondo livello è stato coperto da un junior DBA che fino a quel momento era sui backup notturni: quel contatto diretto con le query problematiche lo formava, lo cresceva, lo faceva sentire utile.

Risultato: due persone che prima rendevano al 60% ora rendevano al 100%, e il progetto ne ha beneficiato senza aver assunto nessuno. La regola non è “riassegna tutti”, è più sottile: fai il punto ogni qualche mese, parla con le persone, osserva dove spendono energia e dove ne guadagnano. Un buon PM redistribuisce in base all’osservazione, non etichetta in base all’organigramma iniziale.

4️⃣ Fai girare la conoscenza, non le persone #

La prima domanda che un PM dovrebbe farsi è: “Se domani il team perdesse una persona, il progetto quanto si ferma?”. La risposta — quantificata in giorni, non in parole confortanti — si chiama bus factor . Un bus factor di 1 significa che la conoscenza critica è in una sola testa, e quella testa può ammalarsi, andare in ferie o cambiare azienda. Un bus factor di 3 significa che la stessa conoscenza è distribuita in almeno tre persone del team.

Gli strumenti per alzare il bus factor sono semplici e noti — documentazione minima, purché aggiornata, pair working sulle attività critiche, rotazione periodica delle responsabilità — e tutti e tre richiedono che il PM ci metta del tempo di calendario, non solo un’email di incoraggiamento.

In un progetto presso un operatore postale e logistico nazionale con circa 1500 istanze MySQL e PostgreSQL in produzione, la pressione operativa era altissima: quando un DBA era in ferie, il team restante andava in sofferenza perché un pezzo di conoscenza specifica mancava. Abbiamo introdotto un rito molto semplice: ogni martedì alle 14:30, un knowledge transfer di 30 minuti su un tema specifico (configurazione di un nodo Galera, procedura di recovery da binary log, troubleshooting di un lock wait su PostgreSQL, tuning del shared_buffers dopo un cambio di workload), tenuto a turno da un membro del team. Sessioni registrate, indicizzate in un wiki interno, cercabili.

Sei mesi dopo, quando un DBA è andato in paternità per tre mesi, il collega che lo sostituiva era già operativo dal primo giorno — non aveva mai toccato personalmente quei sistemi; aveva assistito o visto registrate le KT sulle procedure critiche. Il rito non è “ogni tanto facciamo un po’ di formazione”. Il rito è una mezz’ora bloccata in agenda, ogni settimana, che produce un asset del team condiviso. È una delle cose con il miglior rapporto costo-beneficio che ho visto applicare in un progetto.

5️⃣ Riconosci il lavoro, non solo i risultati #

I risultati di un progetto dipendono da variabili che spesso il team non controlla: decisioni del cliente, cambi di scope, ritardi dei vendor, vincoli normativi che arrivano a metà corsa. Il lavoro, invece, è sotto il controllo del team. Il lavoro è quello che è stato messo nella giornata: ore di analisi, ore di coding, ore di confronto, ore di test.

Se un PM riconosce solo i risultati, quando i risultati slittano per cause esterne le persone si demotivano. Hanno lavorato bene, in alcuni casi anche molto, e si sentono dire “comunque il go-live è saltato”. La prossima volta lavoreranno di meno, perché hanno imparato che il loro sforzo non conta se l’outcome esterno non arriva. Il termine tecnico è la distinzione tra outcome e output : l’output è ciò che il team ha prodotto, l’outcome è il risultato finale misurato dal business.

In un progetto di data warehouse nel settore assicurativo multi-paese, il team aveva completato lo sviluppo di un nuovo data mart per l’analisi delle commissioni pagate agli intermediari — modellazione dimensionale, processi ETL di caricamento notturno, riconciliazione con la contabilità di gruppo — rispettando tempi e qualità attesi. Poi, per decisioni di business che riguardavano il riallineamento di un’altra area del data warehouse, il go-live è slittato di tre mesi e il nuovo data mart è rimasto in attesa. La responsabile di progetto ha chiamato il team in una riunione di quindici minuti e ha detto con estrema precisione: “Avete consegnato quello che dovevate consegnare, nei tempi e con la qualità che ci eravamo detti. Il go-live dipende da fattori che non sono nelle vostre mani. Grazie del lavoro.”. Poi ha elencato, uno a uno, i pezzi di lavoro più difficili che il team aveva affrontato nei mesi precedenti — tre-quattro frasi, specifiche, concrete.

Sembrerà poco. È stato tantissimo. Quel team ha mantenuto il ritmo anche durante i tre mesi di attesa, e quando il go-live è partito è partito bene. La regola non è “distribuire medaglie”. La regola è distinguere ciò che il team ha fatto bene (output) da ciò che il business ha deciso (outcome), e riconoscere esplicitamente il primo quando il secondo non arriva.

🧭 Il PM come custode delle condizioni #

Un’estate di tanti anni fa, a Roma, con una di quelle afate che inchiodano all’asfalto, decisi di andare in ufficio in bermuda. Sapevo benissimo che non era l’abbigliamento più adatto per un contesto professionale; il caldo era davvero fuori scala. Appena arrivato, in corridoio, incontrai il manager. Mi guardò dalla testa ai piedi e, sorridendo, mi disse: “Oggi andiamo al mare?”. E io, d’istinto, mi battei l’indice sulla tempia e risposi: “Mi paghi per come mi vesto o per quello che c’è qui dentro?”. Scoppiò a ridere, mi diede una pacca sulla spalla, e tirò dritto verso la sua stanza. Da quel giorno abbiamo continuato ad avere un rapporto professionale eccellente, anche se poi le strade ci hanno portato in direzioni diverse.

Quella pacca sulla spalla è un’immagine che mi è rimasta addosso. In un altro contesto — quello del foglio Excel dei minuti di bagno — la stessa scena sarebbe finita in una formale segnalazione al reparto HR e in un appunto nella valutazione annuale. Il manager che quella mattina ha scelto di ridere aveva capito una cosa semplice: il valore di una persona in un progetto non sta nei bermuda o nel completo, sta nelle idee che produce e nel lavoro che fa girare. Quella scelta — ridere invece di sanzionare — è esattamente il mestiere del custode delle condizioni.

Queste cinque regole non sono un decalogo da PM che comanda. Sono osservazioni su cosa succede quando certe condizioni ci sono e quando mancano. Sotto ognuna c’è un filo comune: il PM non è il generale che guida le truppe, è più un custode delle condizioni. Il suo lavoro è fare in modo che ogni persona del team abbia il permesso, lo spazio e gli strumenti per fare bene il proprio lavoro.

Il successo di un progetto è del team che l’ha prodotto, non del PM. E la responsabilità dei fallimenti è del PM più che del team, perché le condizioni erano sotto il suo controllo. Questo ribaltamento — che per alcuni suona controintuitivo — è la parte che fa la differenza. Quando un team sente che chi lo guida prende la responsabilità per le condizioni e non si prende il merito per i successi, reggono meglio alla pressione, bluffano meno, si aiutano di più.

Ogni componente del team contribuisce al successo comune con la propria parte: tecnica, relazionale, organizzativa, di conoscenza del dominio. Il PM contribuisce con le condizioni. Se mancano le condizioni, il contributo di tutti si sgretola; se ci sono, il team regge. Le cinque regole sopra — tutte — sono modi concreti per mettere quelle condizioni in piedi e mantenerle nel tempo.

E no, non si fa un foglio Excel con i minuti di gabinetto. Quello è l’opposto esatto del lavoro di un PM. È il segnale che non si è capito il mestiere.

Glossario #

Psychological Safety — Clima di un team in cui le persone si sentono libere di ammettere errori, dire “non lo so” e sollevare problemi senza temere conseguenze sul giudizio professionale. Non significa clima morbido senza critiche, ma sicurezza professionale sul dire la verità tecnica.

Bus Factor — Numero di persone del team che, se venissero a mancare contemporaneamente, bloccherebbero il progetto. Un bus factor di 1 è un rischio critico: la conoscenza è concentrata in una sola testa. Obiettivo: mantenere il bus factor ≥ 3 sulle competenze critiche.

Micromanagement — Stile di gestione basato sul controllo puntuale delle attività quotidiane del team, spesso accompagnato da richieste continue di status e misurazione del tempo speso su singole operazioni. Genera calo di motivazione, turnover e disincentiva l’iniziativa.

Outcome vs Output — Distinzione tra ciò che il team produce concretamente (output: codice, documenti, deliverable) e il risultato finale misurato dal business (outcome: go-live, fatturato, KPI). L’output è sotto il controllo del team; l’outcome dipende anche da variabili esterne.

Knowledge Transfer — Processo strutturato di trasferimento di conoscenza tra persone o team, critico per alzare il bus factor e ridurre la dipendenza da singole persone. Può essere sincrono (sessioni pairing) o asincrono (documentazione, video registrati).