Che cos'è una retrospettiva post-mortem?
Un post-mortem è la conversazione che il team affronta dopo la conclusione di qualcosa. A volte quel qualcosa è un incidente: un sistema si è rotto, un rilascio è andato storto, un cliente ne ha subito le conseguenze. Altrettanto spesso si tratta di un normale progetto che è semplicemente terminato e vuoi un modello di postmortem chiaro per condurre la riunione di revisione senza dover inventare un'agenda da zero. Questo formato copre entrambi i casi. Definisci il quadro con gli obiettivi e il perimetro del progetto, passi in rassegna ciò che è andato bene e ciò che non ha funzionato, approfondisci le cause radice dove serve e trasformi gli aspetti più onesti in lezioni apprese che la tua organizzazione può davvero riutilizzare. Ecco come funziona in TeamRetro. Ognuno aggiunge prima le proprie osservazioni in privato, così la voce più forte della stanza non imposta la narrazione prima che le persone più silenziose abbiano scritto qualcosa. Le idee vengono poi raggruppate, discusse e votate, il che permette di dare priorità ai pochi temi che contano davvero invece di masticare quaranta commenti senza un ordine preciso. Questa è la differenza rispetto a un modello di post mortem statico che compili da solo: è un debrief di squadra dal vivo che tutto il gruppo conduce insieme e che si chiude con responsabili e scadenze associati ad azioni reali, non con un documento che nessuno riaprirà. Usalo come revisione di progetto predefinita alla chiusura di una consegna, di una campagna, di una migrazione o di un trimestre, e come revisione degli incidenti quando qualcosa è andato male e ti serve un resoconto senza colpevoli della cronologia e delle sue cause. L'ultimo argomento lascia spazio ai kudos, perché riconoscere le persone che hanno portato avanti il lavoro fa parte di una chiusura fatta come si deve. In entrambi i casi l'obiettivo è lo stesso. Vuoi che il team esca sapendo cosa ripetere, cosa smettere di fare e chi farà cosa in seguito. Il report viene esportato automaticamente, così le lezioni apprese restano ricercabili per il prossimo team che si troverà nella stessa situazione.
Formato della retrospettiva post-mortem
Panoramica, obiettivi e perimetro del progetto
Cosa doveva realizzare il progetto, ed entro quando?
Questo argomento definisce il quadro prima che qualcuno giudichi qualsiasi cosa. Chiedi l'obiettivo originale, il perimetro concordato, la tempistica e i criteri di successo, oltre a ciò che è stato effettivamente consegnato rispetto ad essi. Per una revisione di un incidente, usalo invece per i fatti della cronologia: cosa si è rotto, quando è stato rilevato, chi è stato coinvolto e come è stato risolto. Tieni l'interpretazione fuori da questa colonna e rimanda le opinioni agli argomenti successivi. Se le persone non concordano su quali fossero gli obiettivi o i criteri di successo, quel disaccordo è già di per sé un risultato da annotare.
Cosa è andato bene
Quali successi e processi vale la pena ripetere?
I team corrono via da questo argomento, soprattutto dopo un progetto difficile o un incidente stressante, quindi proteggi il tempo dedicato. Stai cercando pratiche ripetibili, non complimenti: i kudos hanno un argomento dedicato più avanti. Quando qualcuno scrive un elogio, chiedi cosa specificamente ha funzionato, così la risposta possa essere riutilizzata. Fai attenzione ai successi nati da eroismi individuali e chiamali rischi anziché successi.
Cosa non è andato bene
Dove ci siamo bloccati, rotti o mancato gli obiettivi?
È qui che si trova il vero valore, quindi enuncia a voce alta la regola del "senza colpevoli" prima di iniziare: state esaminando sistemi e decisioni, non persone. Incoraggia i dettagli concreti invece dei mugugni vaghi, perché "la comunicazione era scarsa" non è azionabile, mentre "abbiamo scoperto del cambio di scadenza in una conversazione di corridoio" lo è. Usa la votazione qui per evitare che la discussione si allarghi a ogni fastidio degli ultimi tre mesi.
Analisi delle cause radice
Perché è andata male, non solo che è andata male?
Opzionale per una semplice revisione di progetto, essenziale per un incidente. Prendi i problemi più votati dell'argomento precedente e continua a chiedere perché finché non arrivi a una condizione anziché a una persona: una protezione mancante, un responsabile poco chiaro, una pressione sui tempi, un'assunzione che nessuno ha verificato. I Cinque Perché funzionano bene qui, così come chiedersi cosa faceva sembrare ragionevole l'azione sbagliata in quel momento. Fermati quando raggiungi qualcosa che puoi effettivamente cambiare e annota i fattori contribuenti separatamente dall'innesco.
Lezioni apprese
Quali sono i punti chiave che portiamo avanti?
Questo è il "e quindi?" che trasforma le osservazioni in conoscenza riutilizzabile. Spingi ogni idea finché non nomina un comportamento, un innesco o una protezione, così possa sopravvivere al contatto con il prossimo progetto. Distingui tra le cose che questo team può cambiare da solo e quelle che devono salire a un manager o a un altro gruppo, e sii onesto sulla seconda categoria. Formula i punti chiave in modo che qualcuno esterno alla stanza possa leggerli nel report esportato e capirli senza che tu sia lì a spiegarli.
Azioni, responsabili e scadenze
Chi fa cosa, ed entro quando?
Un post-mortem senza azioni assegnate non vale, quindi lascia tempo reale per questa parte anziché comprimerla negli ultimi due minuti. Converti le lezioni più votate in un numero ridotto di azioni specifiche, ognuna con un responsabile nominato e una scadenza registrata in TeamRetro, così da farle riemergere alla sessione successiva. Due o tre azioni ben assegnate valgono più di dieci aspirazionali. Se un'azione appartiene a qualcuno esterno alla stanza, concordate chi glielo porterà e entro quando.
Riconoscimenti e kudos al team
Chi merita un riconoscimento prima di chiudere?
Chiudi sulle persone, non sui problemi. Invita tutti a nominare una persona specifica e una cosa specifica che ha fatto: è molto più significativo dei ringraziamenti generici e funziona bene anche dopo un progetto difficile. Questo conta soprattutto quando la revisione è stata dura, perché ricorda al team che esaminare un fallimento non equivale a incolparsi a vicenda. Tieni il ritmo rapido, leggine alcuni ad alta voce e lascia che il report esportato riporti il resto.
Quando utilizzare questa analisi retrospettiva
- Un progetto, una consegna, una migrazione o una campagna si è appena conclusa e vuoi una revisione strutturata anziché una chiacchierata informale che poi svanisce.
- Un incidente, un disservizio o un rilascio fallito richiede un post-mortem senza colpevoli che copra cronologia, cause radice e azioni preventive.
- Un programma di lunga durata ha completato una fase e vuoi raccogliere le lezioni apprese mentre i dettagli sono ancora freschi.
- Un gruppo cross-funzionale si sta sciogliendo e questa è l'ultima occasione per un debrief di squadra e per riconoscere i contributi prima che le persone si disperdano su nuovi lavori.
- Qualcosa è andato inaspettatamente bene e vuoi capire perché, così la pratica possa essere ripetuta anziché considerata fortuna.
Domande suggerite per rompere il ghiaccio
- In una parola, come ti sei sentito durante questo progetto o incidente, mentre eri nel mezzo?
- Se potessi mandare una frase di consiglio a te stesso del primo giorno, cosa direbbe?
Desidera un esercizio di riscaldamento che la Sua squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate le attività di rompighiaccio gratuite →
Idee e consigli per la vostra riunione di retrospettiva
- Conducilo entro una o due settimane dalla chiusura del progetto o dalla risoluzione dell'incidente. I ricordi svaniscono rapidamente e con essi i dettagli utili.
- Enuncia la regola del "senza colpevoli" all'inizio. State guardando decisioni, sistemi e pressioni, non cercando qualcuno da ritenere responsabile.
- Dedica qualche minuto a concordare la panoramica del progetto prima che inizino le opinioni. Un quadro condiviso evita che la sessione diventi un dibattito su quale fosse l'obiettivo.
- Salta o accorcia l'analisi delle cause radice per una revisione di progetto senza problemi, e approfondiscila per gli incidenti dove la prevenzione è il punto centrale.
- Dai priorità con la votazione, poi non lasciare che la riunione finisca senza responsabili e scadenze sulle azioni principali, altrimenti le lezioni apprese restano teoriche.
- Porta in sala le azioni del post-mortem precedente e rivedile per prime. Niente migliora il follow-through come sapere che verrà verificato.
Domande frequenti
Che cos'è un post-mortem di progetto?
In cosa un post-mortem di progetto è diverso da un post-mortem di incidente?
Cosa dovrebbe includere un post-mortem di progetto?
Devo usare l'argomento dell'analisi delle cause radice?
Quanto dura un post-mortem?
Chi dovrebbe partecipare a un post-mortem?
Modelli correlati
Allineare il team sugli obiettivi del progetto e pianificare l'esecuzione.
Retrospettiva di Fine Anno
Rifletti sui successi, le sfide e gli insegnamenti dell'anno passato.
Retrospettiva di Chiusura Progetto
Rifletti su successi, sfide e lezioni da un progetto completato.
Pianificazione del Ritiro di Team
Un approccio strutturato per pianificare un ritiro di team coinvolgente e produttivo.