Modello di post-mortem di progetto Template (Free)

Panoramica, obiettivi e perimetro

Cosa doveva realizzare il progetto, ed entro quando?

L'obiettivo era spostare tutta la fatturazione clienti sulla nuova piattaforma entro la fine del terzo trimestre, senza alcun downtime per gli account enterprise.

Abbiamo rilasciato il portale clienti con tre settimane di ritardo rispetto alla data originale, tagliando due delle cinque funzionalità previste.

I criteri di successo non sono mai stati scritti da nessuna parte, almeno non che io abbia trovato, quindi avevo in testa una mia versione.

Cosa è andato bene

Quali successi e processi vale la pena ripetere?

I sync quotidiani di quindici minuti nel periodo più intenso hanno tenuto tutti allineati senza appesantire il calendario delle riunioni.

Il nostro runbook di reperibilità era accurato, quindi applicare la correzione ha richiesto minuti invece di ore.

Affiancare subito i nuovi sviluppatori a dei revisori li ha resi produttivi più in fretta di quanto mi aspettassi.

Cosa non è andato bene

Dove ci siamo bloccati, cosa si è rotto, quali obiettivi abbiamo mancato?

I requisiti continuavano a cambiare e nessuno era chiaramente responsabile di decidere quando fossero definitivi.

I test sono stati compressi negli ultimi giorni, ed è per questo che due difetti sono arrivati ai clienti.

Il nostro monitoraggio non copriva la profondità della coda, quindi eravamo al buio finché le cose non si erano già accumulate.

Analisi delle cause profonde

Non solo cosa è andato storto, ma perché?

La causa principale è stata una modifica di configurazione rilasciata direttamente in produzione, perché la nostra pipeline non prevedeva una fase di revisione obbligatoria.

Abbiamo sottostimato perché la stima è stata fatta prima dello spike tecnico e poi trattata come un impegno.

Nessuno era responsabile dell'integrazione tra i due team, quindi la lacuna è rimasta invisibile fino alla settimana di integrazione.

Lezioni apprese

Quali lezioni portiamo con noi?

Fare lo spike tecnico prima di impegnarci su qualsiasi data, poi rifare la stima in modo trasparente.

Mettere per iscritto i criteri di successo al kickoff. Se non riusciamo a metterci d'accordo, non siamo pronti per partire.

Le modifiche al perimetro richiedono un checkpoint scritto invece di essere assorbite in silenzio dal team.

Azioni, responsabili e scadenze

Chi fa cosa, ed entro quando?

Aggiungere una fase di revisione obbligatoria alla pipeline di deploy in produzione. Responsabile: Priya. Scadenza: fine del prossimo sprint.

Preparare un modello di project charter di una pagina con i criteri di successo. Responsabile: Sam. Scadenza: il 15.

Aggiungere alert su profondità della coda e tasso di errore, indirizzati ai turni di reperibilità. Responsabile: Dev. Scadenza: questa settimana.

Apprezzamenti e riconoscimenti

Chi merita un riconoscimento prima di chiudere?

Grazie a Priya, che ha mantenuto la calma durante la bridge call e ha tenuto tutti concentrati sulla soluzione.

Complimenti al team di supporto, che ha gestito i contatti dei clienti quasi senza preavviso.

Un grande grazie a Sam, che senza dire niente ha scritto il runbook che nessuno aveva chiesto e poi ci ha salvato proprio con quello.

Che cos'è una retrospettiva post-mortem?

Un post-mortem è la conversazione che il team fa quando qualcosa si conclude. A volte quel qualcosa è un incidente: un sistema si è rotto, un rilascio è andato storto, un cliente ne ha subito le conseguenze. Altrettanto spesso è un normale progetto appena terminato, e ti serve un'agenda chiara per la revisione invece di inventarne una da zero. Questo modello copre entrambi i casi. Definisci il quadro con gli obiettivi e il perimetro del progetto, ripercorri cosa è andato bene e cosa no, approfondisci le cause profonde dove serve e trasforma gli aspetti più sinceri in lezioni apprese che la tua organizzazione può riutilizzare. Ecco come funziona in TeamRetro. Ognuno aggiunge prima le proprie osservazioni in privato, così la voce più forte nella stanza non impone la sua versione prima che i più riservati abbiano scritto qualcosa. Le idee vengono poi raggruppate, discusse e votate, e questo ti permette di concentrarti sui pochi temi che contano davvero invece di scorrere quaranta commenti senza un ordine preciso. Ecco la differenza rispetto a un documento compilato da soli: è un debriefing dal vivo che tutto il team conduce insieme, e si chiude con responsabili e scadenze su azioni concrete, non con un report che nessuno riaprirà più. Usalo come revisione di progetto standard alla chiusura di una consegna, una campagna, una migrazione o un trimestre, e come revisione degli incidenti quando qualcosa è andato storto e ti serve una ricostruzione senza colpevoli della sequenza temporale e delle cause. L'ultimo argomento lascia spazio ai riconoscimenti, perché ringraziare le persone che hanno portato avanti il lavoro fa parte di una chiusura fatta come si deve. In ogni caso, il team dovrebbe uscire sapendo cosa ripetere, cosa smettere di fare e chi fa cosa adesso. Al termine esporta il report, così le lezioni restano reperibili per il prossimo team che si troverà nella stessa situazione.

Formato della retrospettiva post-mortem

Panoramica, obiettivi e perimetro Cosa doveva realizzare il progetto, ed entro quando?: Questo argomento definisce il quadro prima che qualcuno giudichi qualcosa. Chiedi l'obiettivo originale, il perimetro concordato, le tempistiche e i criteri di successo, oltre a ciò che è stato effettivamente consegnato rispetto a questi. In una revisione di un incidente, usalo invece per la sequenza temporale: cosa si è rotto, quando è stato rilevato, chi è stato coinvolto e come è stato risolto. Tieni le interpretazioni fuori da questa colonna e riserva le opinioni agli argomenti successivi. Se le persone non sono d'accordo nemmeno su quali fossero gli obiettivi o i criteri di successo, quel disaccordo è già un risultato da registrare.
Cosa è andato bene Quali successi e processi vale la pena ripetere?: I team tendono a passare in fretta su questo argomento, soprattutto dopo un progetto difficile o un incidente stressante, quindi difendi il tempo dedicato. Stai cercando pratiche da ripetere, non complimenti: i riconoscimenti hanno un argomento tutto loro più avanti. Quando qualcuno scrive un elogio, chiedi cosa nello specifico ha fatto funzionare le cose, così la risposta si può riutilizzare. Fai attenzione ai successi nati da atti di eroismo individuale e segnalali come rischi.
Cosa non è andato bene Dove ci siamo bloccati, cosa si è rotto, quali obiettivi abbiamo mancato?: Qui sta la maggior parte dell'apprendimento, quindi prima di iniziare enuncia ad alta voce la regola di base: niente ricerca di colpevoli, si esaminano sistemi e decisioni, non persone. Chiedi dettagli concreti invece di lamentele vaghe. "La comunicazione era pessima" non porta ad alcuna azione, ma "abbiamo saputo del cambio di scadenza da una chiacchierata in corridoio" sì. Usa il voto, così la discussione non si disperde su ogni fastidio degli ultimi tre mesi.
Analisi delle cause profonde Non solo cosa è andato storto, ma perché?: Facoltativo per una semplice revisione di progetto, essenziale per un incidente. Prendi i problemi più votati dell'argomento precedente e continua a chiederti perché finché non arrivi a una condizione, non a una persona: una protezione mancante, un responsabile poco chiaro, la pressione dei tempi, un'ipotesi che nessuno ha verificato. I 5 perché funzionano bene qui, così come chiedersi cosa abbia fatto sembrare ragionevole, in quel momento, l'azione sbagliata. Fermati quando arrivi a qualcosa che potete davvero cambiare e annota i fattori concomitanti separatamente dall'evento scatenante.
Lezioni apprese Quali lezioni portiamo con noi?: Questo è il "e quindi?" che trasforma le osservazioni in conoscenza riutilizzabile. Insisti su ogni idea finché non individua un comportamento, un segnale scatenante o una protezione che abbia ancora senso nel prossimo progetto. Distingui ciò che il team può cambiare da solo da ciò che va portato a un responsabile o a un altro gruppo, e sii onesto sulla seconda lista. Scrivi ogni lezione in modo che chi non era presente possa leggerla nel report esportato e capirla senza che tu sia lì a spiegarla.
Azioni, responsabili e scadenze Chi fa cosa, ed entro quando?: Un post-mortem senza azioni assegnate non vale, quindi dedica a questa parte tempo vero invece di comprimerla negli ultimi due minuti. Trasforma le lezioni più votate in poche azioni specifiche, ciascuna con un responsabile indicato per nome e una scadenza registrata in TeamRetro, così torneranno fuori nella sessione successiva. Due o tre azioni con un responsabile chiaro valgono più di dieci buone intenzioni. Se un'azione spetta a qualcuno che non è presente, concordate chi gliela porterà ed entro quando.
Apprezzamenti e riconoscimenti Chi merita un riconoscimento prima di chiudere?: Chiudi sulle persone, non sui problemi. Chiedi a ciascuno di nominare una persona specifica e una cosa specifica che ha fatto: vale molto più di un ringraziamento generico e funziona anche dopo un progetto difficile. Conta soprattutto quando la revisione è stata faticosa, perché ricorda al team che esaminare un fallimento non significa darsi la colpa a vicenda. Tienilo breve, leggine qualcuno ad alta voce e lascia che il report esportato raccolga il resto.

Quando utilizzare questa analisi retrospettiva

Un progetto, una consegna, una migrazione o una campagna si è appena concluso e vuoi una revisione strutturata, non una chiacchierata informale destinata a perdersi
Un incidente, un disservizio o un rilascio fallito richiede un post-mortem senza colpevoli che copra la sequenza temporale, le cause profonde e le azioni preventive
Un programma di lunga durata ha completato una fase e vuoi raccogliere le lezioni apprese finché i dettagli sono ancora freschi
Un gruppo interfunzionale si sta sciogliendo e questa è l'ultima occasione per fare un debriefing e riconoscere il contributo di ciascuno prima che le persone passino ad altro
Qualcosa è andato inaspettatamente bene e vuoi capire perché, così da poterlo ripetere invece di attribuirlo alla fortuna

Domande suggerite per rompere il ghiaccio

In una parola, come ti sentivi nel pieno di questo progetto o incidente?
Se potessi mandare un consiglio di una sola frase a te stesso il primo giorno, cosa diresti?

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

Fallo entro una o due settimane dalla chiusura del progetto o dalla risoluzione dell'incidente. I ricordi svaniscono in fretta, e con loro i dettagli utili
Enuncia all'inizio la regola del niente colpevoli. State esaminando decisioni, sistemi e pressioni, non cercando qualcuno da ritenere responsabile
Dedica qualche minuto a concordare la panoramica del progetto prima che arrivino le opinioni. Un quadro condiviso evita che la sessione diventi un dibattito su quale fosse l'obiettivo
Salta o accorcia l'analisi delle cause profonde in una revisione di progetto senza intoppi, e dedicale più tempo negli incidenti, dove lo scopo è la prevenzione
Stabilisci le priorità con il voto e non chiudere la riunione senza responsabili e scadenze per le azioni principali, altrimenti le lezioni apprese restano teoria
Porta in sala le azioni del post-mortem precedente e rivedile per prime. Niente aiuta a portare a termine gli impegni quanto sapere che verranno verificati

Domande frequenti

Che cos'è un post-mortem di progetto?

È una revisione strutturata che il team conduce quando un lavoro è terminato, come il lancio di un prodotto, una migrazione, una campagna o una consegna a un cliente. Si analizzano gli obiettivi e il perimetro originali, cosa è andato bene, cosa no e le lezioni da portare avanti. A differenza di un post-mortem di un incidente, non è necessario che qualcosa sia andato storto: il lavoro è semplicemente finito e c'è conoscenza che vale la pena conservare.

In cosa differisce un post-mortem di progetto da un post-mortem di incidente?

Un post-mortem di incidente nasce da un guasto, quindi si concentra su sequenza temporale, rilevamento, risposta e causa profonda, con l'obiettivo della prevenzione. Un post-mortem di progetto nasce dalla conclusione del lavoro e copre obiettivi, stime, perimetro, collaborazione e passaggio di consegne, con l'obiettivo di far andare meglio il progetto successivo. Entrambi dovrebbero escludere la ricerca di colpevoli ed entrambi dovrebbero concludersi con azioni assegnate.

Cosa includere in un post-mortem di progetto?

Parti dalla panoramica del progetto: obiettivi, perimetro, tempistiche, criteri di successo e ciò che è stato effettivamente consegnato. Poi affronta cosa è andato bene, cosa no e le cause profonde dei problemi principali. Chiudi con le lezioni apprese, le azioni con responsabili e scadenze e un giro di riconoscimenti: tutti e sette gli argomenti stanno in un'unica sessione TeamRetro.

Devo per forza usare l'argomento dell'analisi delle cause profonde?

No, è facoltativo. Dà il meglio nelle revisioni degli incidenti e nei progetti che hanno mancato obiettivi importanti. Per una consegna senza intoppi, saltalo oppure prendi i due problemi più votati e chiediti perché qualche volta prima di passare alle lezioni apprese.

Quanto dura un post-mortem?

Prevedi 60–90 minuti per la maggior parte dei progetti e degli incidenti, oppure circa 45 minuti per un piccolo progetto se salti l'analisi delle cause profonde. I programmi più grandi spesso richiedono due sessioni, una per i fatti e le cause e una per i miglioramenti e le azioni.

Chi dovrebbe partecipare a un post-mortem?

Le persone che hanno svolto il lavoro e quelle che ne sono state toccate: il team di delivery, il project lead e chi ne ha ereditato il risultato nel supporto, nel design o nelle operations. Per un incidente, aggiungi chi è intervenuto e chiunque abbia gestito la comunicazione con i clienti. Mantieni il gruppo abbastanza ristretto da permettere una conversazione sincera e chiedi ai partecipanti senior di ascoltare, non di difendere le decisioni prese.