È fallito. Perché?

Sono passati sei mesi e il progetto è fallito. Scrivi ogni motivo come se fosse già successo.

Ci siamo affidati alla sandbox del fornitore dei pagamenti e non abbiamo mai testato i limiti di produzione. Il traffico del giorno del lancio ha mandato giù il checkout.
Solo Priya conosceva gli script di migrazione dei dati. Al terzo mese è andata in congedo e si è bloccato tutto.
L'ufficio legale ha rivisto i termini di servizio due settimane prima del lancio e abbiamo dovuto rifare il flusso del consenso.
Segnali d'allarme

Cosa noteremmo per primo se iniziasse a succedere?

I ticket al supporto del fornitore impiegano più di due giorni per ricevere una risposta.
La stessa persona viene taggata in ogni revisione delle pull request di migrazione.
Compaiono nuovi ticket a metà sprint con 'richiesta veloce dal commerciale' nella descrizione.
Come lo preveniamo

Cosa possiamo fare ora per evitare che succeda?

Eseguire un test di carico sull'ambiente di produzione del fornitore nello sprint due, prima di costruirci sopra.
Affiancare qualcuno a Priya sugli script di migrazione e documentare il runbook entro fine mese.
Prenotare una revisione legale del flusso del consenso durante il design, non dopo lo sviluppo.
Responsabili e prossimi passi

Chi è responsabile di ogni rischio principale, ed entro quando?

Marco si occupa del test di carico del fornitore, entro la fine dello sprint due.
Mi affianco a Priya sulla migrazione e pubblichiamo il runbook entro il 15.
Dana prenoterà la revisione legale del flusso del consenso prima dell'approvazione del design venerdì prossimo.

Che cos'è una retrospettiva pre-mortem?

Un pre-mortem è una sessione sui rischi da svolgere all'avvio del progetto, prima che ambito, date e budget vengano fissati. Il team immagina un futuro preciso: sono passati sei mesi e il progetto è fallito. Ognuno scrive poi perché è fallito, come se il fallimento fosse già avvenuto. Lo psicologo Gary Klein ha sviluppato la tecnica e l'ha descritta nel suo articolo del 2007 sulla Harvard Business Review, "Performing a Project Premortem". La tecnica si basa sulle ricerche sul "prospective hindsight" (senno di poi prospettico), secondo cui immaginare che un evento sia già accaduto aiuta le persone a individuarne ragioni più specifiche. È l'impostazione a fare la differenza. Se chiedi a un team "cosa potrebbe andare storto?" ottieni risposte educate e generiche come "scope creep" o "problemi di comunicazione". Se chiedi "perché è fallito?" le persone indicano cause reali: l'API del fornitore mai sottoposta a test di carico, lo stakeholder che non è stato consultato, l'unico ingegnere che ha in mano tutte le conoscenze. Dare per scontato il fallimento permette anche di esprimere senza timori dubbi che altrimenti sembrerebbero negativi o sleali durante un kickoff pieno di ottimismo. Questo template di pre-mortem si sviluppa in quattro fasi in TeamRetro. Prima si elencano i motivi per cui il progetto è fallito. Poi si individuano i segnali d'allarme, si concordano le misure di prevenzione e infine si assegnano a ogni rischio principale un responsabile e una scadenza. L'ultimo passaggio è il più importante. Un rischio senza responsabile e senza scadenza di solito viene dimenticato entro la fine della prima settimana. Usa idee anonime, così l'anzianità non influenza ciò che le persone scrivono. Per i team distribuiti, raccogli le idee in modalità asincrona nell'arco di una giornata, poi incontratevi solo per votare e assegnare i responsabili.

Formato della retrospettiva pre-mortem

È fallito. Perché?

Sono passati sei mesi e il progetto è fallito. Scrivi ogni motivo come se fosse già successo.

Questa colonna è il cuore del pre-mortem. Descrivi chiaramente lo scenario: il progetto è concluso, è fallito e lo sanno tutti. Chiedi alle persone di scrivere al passato ("Abbiamo mancato il lancio perché..."), perché questa impostazione produce cause più concrete rispetto a ipotizzare cosa potrebbe andare storto. Mantieni le idee anonime, così le voci più senior non condizionano il gruppo. Concedi 8–10 minuti di scrittura in silenzio, incoraggia un solo motivo per idea, poi raggruppa le idee simili e fate una votazione per individuare i rischi principali da portare avanti.

Segnali d'allarme

Cosa noteremmo per primo se iniziasse a succedere?

I segnali d'allarme trasformano paure vaghe in elementi che il team può tenere d'occhio. Per ogni rischio principale emerso nella prima colonna, chiedi quale sarebbe il primo segnale osservabile: una metrica, un checkpoint mancato, uno schema ricorrente negli standup. Punta su segnali specifici e misurabili. "Il morale cala" è difficile da monitorare. "Due sprint di fila con lavoro riportato oltre il 30%" è facile da notare. Questi diventano i campanelli d'allarme che i responsabili dei rischi tengono sotto controllo.

Come lo preveniamo

Cosa possiamo fare ora per evitare che succeda?

Qui il team passa dalla preoccupazione all'azione. Concentrati solo sui rischi più votati, di solito da tre a cinque. Per ognuno, chiedi cosa può fare il team questa settimana o questo mese per ridurne la probabilità o l'impatto. Preferisci passi piccoli e concreti a grandi cambiamenti di processo. Se un'idea di prevenzione richiede un'approvazione o del budget, annota a chi bisogna chiederlo. Mantieni un approccio pratico: l'obiettivo è un elenco più breve di azioni che le persone porteranno davvero a termine.

Responsabili e prossimi passi

Chi è responsabile di ogni rischio principale, ed entro quando?

Questa colonna è lo scopo dell'intera sessione. Ogni rischio principale ha bisogno di un responsabile con nome e cognome e di una data, altrimenti le paure raccolte oggi svaniscono prima della fine della prima settimana. I responsabili non devono risolvere il rischio da soli: il loro compito è tenere d'occhio i segnali d'allarme e assicurarsi che la misura di prevenzione venga attuata. Registra ognuno come azione in TeamRetro, così verrà riportato nelle retrospettive successive, e pianifica un breve check-in alla prima milestone per verificare i progressi.

Quando utilizzare questa analisi retrospettiva

  • All'avvio di un nuovo progetto, di un lancio di prodotto o di un'iniziativa importante, prima che ambito, date e budget siano definiti.
  • Prima di una milestone ad alto rischio come una migrazione, un go-live o la firma di un contratto, quando una sorpresa dell'ultimo minuto costerebbe cara.
  • Quando un team è insolitamente ottimista su un piano e i membri più silenziosi potrebbero tenersi per sé i propri dubbi.
  • Quando si inizia a lavorare con un nuovo fornitore, partner o gruppo interfunzionale le cui dipendenze non sono ancora ben comprese.
  • All'inizio di un nuovo trimestre o program increment, per mettere alla prova il piano prima che il team si impegni.

Domande suggerite per rompere il ghiaccio

  • Qual è il piano più memorabile che hai visto andare storto, al lavoro o nella vita, e qual è stato il primo segnale d'allarme?
  • Se questo progetto fosse un film, a che genere apparterrebbe la versione in cui fallisce?

Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →

Idee e consigli per la vostra riunione di retrospettiva

  • Fai il pre-mortem all'avvio del progetto, prima che gli impegni vengano fissati. Non farlo mai nel pieno di una crisi, quando il team deve risolvere problemi e immaginare il fallimento non fa che aumentare l'ansia.
  • Mantieni le idee anonime. Se i nomi sono visibili, le paure della persona più senior condizionano il gruppo e tutti gli altri si limitano a darle ragione.
  • Pretendi l'uso del passato nella prima colonna. "Perché è fallito?" produce rischi più specifici e realistici di "Cosa potrebbe andare storto?", quindi riformula con delicatezza le idee che scivolano di nuovo nelle ipotesi.
  • Votate per ridurre l'elenco a tre-cinque rischi principali prima di discutere la prevenzione. Cercare di affrontare ogni idea disperde le energie del team e alla fine non si conclude nulla.
  • Non chiudere la sessione finché ogni rischio principale non ha un responsabile e una data. Senza questi, i rischi raccolti vengono dimenticati prima della fine della prima settimana.
  • Per i team distribuiti, passa all'asincrono: raccogli le idee nell'arco di una giornata tra i vari fusi orari, poi incontratevi per 30 minuti solo per raggruppare, votare e assegnare i responsabili.

Domande frequenti

Qual è la differenza tra un pre-mortem e un post-mortem?
Un post-mortem si svolge dopo che un progetto si è concluso o è fallito e analizza cosa è andato davvero storto. Un pre-mortem si svolge prima dell'inizio del lavoro e immagina il fallimento in anticipo, così il team può prevenirlo finché è ancora in tempo.
Chi ha ideato la tecnica del pre-mortem?
Lo psicologo Gary Klein ha coniato il termine pre-mortem e l'ha descritto nel suo articolo del 2007 sulla Harvard Business Review, "Performing a Project Premortem". La tecnica si basa su ricerche secondo cui immaginare che un risultato si sia già verificato aiuta le persone a individuarne ragioni più specifiche.
Quanto dura un pre-mortem?
La maggior parte dei pre-mortem dura 45–60 minuti per un team di cinque-dieci persone. Con l'opzione asincrona, la riunione dal vivo può ridursi a circa 30 minuti, perché le idee sono già state raccolte prima della chiamata.
Quando conviene fare un pre-mortem?
Fallo all'avvio del progetto, prima che impegni come ambito, scadenze e budget vengano fissati. Evita di farlo nel pieno di una crisi, quando il team deve concentrarsi sulla risoluzione di problemi reali.
Perché le idee del pre-mortem dovrebbero essere anonime?
Quando i nomi sono visibili, le persone tendono a ripetere le preoccupazioni della persona più senior presente. Le idee anonime fanno emergere i rischi che preoccupano davvero le persone, compresi quelli che chiamano in causa le decisioni della leadership.
Un pre-mortem si può fare in modalità asincrona?
Sì. I team distribuiti possono raccogliere le idee in TeamRetro nell'arco di una giornata, poi incontrarsi solo per raggrupparle, votare i rischi principali e assegnare responsabili e scadenze.
È pronto a condurre questa retrospettiva?Provi questa esibizione dal vivo in chiave retrospettiva