Analizzare un incidente da una riunione registrata: modello di post-mortem
Prepara un post-mortem dopo un guasto: cronologia, impatto, cause confermate e azioni. Con esempio e modello senza ricerca di colpe.
Ricostruisci prima gli eventi
Dopo un guasto, le persone ricordano momenti diversi: l’errore, l’avviso o l’inizio della correzione. Un racconto convincente può sbagliare la sequenza. Parti da una cronologia verificabile.
Fai il post-mortem dopo il primo ripristino. La registrazione raccoglie le spiegazioni. Confronta gli orari con messaggi, registri e altre fonti. Escludi i dati interni dal rapporto pubblico.
Costruisci l’analisi in quattro parti
Descrivi l’impatto
Indica quale funzione o operazione era indisponibile, per chi e per quanto tempo. Separa l’impatto confermato da quello possibile. Segnala un numero di utenti sconosciuto.
Costruisci la cronologia
Indica inizio, rilevamento, avviso, primi interventi e ripristino. Specifica il fuso orario. Se c’è solo il ricordo di un partecipante, conserva fonte e grado di certezza. Segnala gli orari approssimativi.
Verifica le spiegazioni
Distingui il fattore scatenante dalle condizioni che hanno permesso o prolungato il problema. Chiedi quali informazioni erano disponibili al momento della decisione. Collega ogni ipotesi alle evidenze e indica che cosa la smentirebbe.
Assegna azioni verificabili
Scegli misure che riducono un rischio o accelerano rilevamento e ripristino. Indica responsabile, risultato e verifica. «Fare più attenzione» non descrive un cambiamento verificabile.
Le notifiche delle nuove richieste non arrivano
L’esempio è fittizio. Nomi, condizioni e risultati servono a spiegare il metodo.
Le richieste venivano salvate ma le notifiche non arrivavano. Ce l’ha segnalato un referente. Abbiamo verificato l’elenco e lo abbiamo consultato a mano per un periodo.
Le richieste erano disponibili. Era interrotta la consegna delle notifiche. La distinzione determina impatto e azioni.
La cronologia è esemplificativa. Mostra l’intervallo tra inizio e rilevamento. Non dimostra la causa tecnica.
| Osservazione | Ipotesi | Prossima verifica |
|---|---|---|
| I record ci sono, le notifiche no | Guasto nella consegna | Consultare il registro degli invii |
| Lo segnala un referente | Mancava un avviso adatto | Controllare il monitoraggio della consegna |
| Il controllo manuale ha aiutato | C’è un’alternativa temporanea | Stabilire quando usarla |
Modello di post-mortem
Mantieni le possibili cause come ipotesi finché non sono verificate.
Incidente, periodo e fuso orario: Impatto confermato: Cronologia: ora / evento / fonte: Fattore scatenante: Condizioni che hanno contribuito: Che cosa ha funzionato nel ripristino: Che cosa resta da stabilire: Azione / responsabile / termine / verifica: Quando controllare l’esecuzione:
Verifica che l’analisi aiuti a prevenire il ripetersi del guasto
- L’impatto è più preciso di «si è rotto tutto».
- Gli orari degli eventi sono distinti da quelli della discussione.
- Le cause confermate sono distinte dalle ipotesi.
- Ogni azione riguarda un problema osservabile e ha una verifica.
Entriamo nei dettagli
Post-mortem e retrospettiva sono la stessa cosa?
Il post-mortem esamina un incidente specifico e le sue conseguenze. La retrospettiva può coprire tutto un periodo, comprese pratiche riuscite ed esperimenti.
Che cosa fare se la causa resta ignota?
Condividi internamente i fatti confermati e le verifiche aperte. Lascia la causa in sospeso finché mancano prove.