Retrospettiva blameless e lezione appresa

In parole semplici

Risolvere il bug è metà del lavoro. L’altra metà è scrivere cosa abbiamo imparato in modo che il sistema, il processo, il team non ripetano lo stesso schema. La forma adulta di questa scrittura è il postmortem blameless: si concentra su sistemi e processi, non su persone.

Parole nuove

• postmortem: documento scritto dopo un incidente.
• blameless: senza colpevolizzazione personale.
• causa radice (root cause): il fattore profondo, non solo il sintomo.
• azione correttiva: modifica concreta che impedisce il ritorno.
• 5 whys: tecnica di indagine causale (chiedi “perché?” cinque volte).

Cosa impari

• Scrivere un postmortem in formato standard.
• Distinguere causa apparente da causa radice.
• Trasformare un incidente in azioni concrete.

Il formato del postmortem

# Incidente <id>: <titolo>

## Sintesi
<1-3 frasi: cosa è successo, durata, impatto>

## Timeline
HH:MM — evento
HH:MM — rilevamento
HH:MM — contenimento
HH:MM — fix
HH:MM — verifica

## Impatto
- utenti colpiti:
- funzionalità degradate:
- durata:
- perdita dati / sicurezza:

## Causa diretta
<cosa è andato storto in termini tecnici immediati>

## Causa radice
<perché era possibile che andasse storto in quel modo>

## Cosa è andato bene
<elementi del processo o del sistema che hanno aiutato>

## Cosa è andato male
<lacune del processo o del sistema>

## Azioni correttive
- [ ] <azione concreta, owner, scadenza>
- [ ] <...>

## Lezione condivisa
<una frase sintetica per il resto del team>

Blameless: cosa significa

“Blameless” non significa “nessuno ha sbagliato”. Significa che il documento si concentra su come il sistema ha permesso che l’errore avvenisse, non sul nome di chi ha cliccato il pulsante sbagliato.

Sbagliato:

“Carlo ha deployato senza guardare i test.”

Blameless:

“Il deploy è partito anche se la pipeline di test era in stato ‘pending’. Manca un check che blocchi deploy senza CI completo.”

Il fatto tecnico è lo stesso. La conseguenza è diversa: la prima cerca colpevoli, la seconda cerca miglioramenti.

5 whys: trovare la causa radice

Tecnica di Toyota. Chiedi “perché?” cinque volte (o quanto serve).

Esempio:

1. Perché il carrello non persisteva? Perché save() veniva chiamato prima dell’update.
2. Perché veniva chiamato prima? Perché era nel listener addToCart sincrono, ma il reducer è asincrono.
3. Perché si è scelto un listener sincrono? Perché la libreria store ufficiale non aveva un esempio “asincrono” nella documentazione.
4. Perché il team ha applicato pattern non documentato? Perché non c’è una guida interna su come integrare lo store con la persistenza.
5. Perché manca la guida? Perché non abbiamo mai scritto le decisioni di architettura come ADR (Architecture Decision Records).

Causa radice: assenza di documentazione architetturale strutturata. Azione correttiva: scrivere ADR per scelte di stato/persistenza.

I 5 whys evitano di fermarsi al primo “perché”.

Azioni correttive: concrete e con owner

Cattive azioni correttive:

• “Stare più attenti.”
• “Migliorare la cultura del testing.”
• “Investire in qualità.”

Buone azioni correttive:

• “Aggiungere check --no-pending nel hook pre-deploy. Owner: Anna. Scadenza: 2026-05-30.”
• “Scrivere ADR-007 ‘Persistenza dello store’. Owner: Carlo. Scadenza: 2026-06-07.”
• “Aggiungere test E2E cart-persist.spec.ts. Owner: Marco. Scadenza: 2026-05-23.”

Concretezza + owner + scadenza = azione che davvero avviene.

Cosa è andato bene

Spesso trascurato. Eppure importante: senza riconoscere ciò che ha funzionato, si rischia di smontare per errore parti del sistema che hanno funzionato.

Esempi:

• “L’alert dell’on-call ha rilevato il problema in 4 minuti.”
• “Il revert è stato applicato in produzione in 8 minuti.”
• “La documentazione del rollback era aggiornata.”

Lezione condivisa

Una frase per la chat del team. Esempio:

Incidente #142: il carrello non persisteva per race con dispatch. Lezione: ogni nuova interazione store ↔ side effect richiede un ADR e un test E2E.

Quella frase circola, viene ricordata, diventa parte della cultura.

Esercizio guidato

Prendi un bug che hai risolto recentemente (anche piccolo).

1. Compila il template del postmortem.
2. Applica i 5 whys: scrivi cinque “perché” in cascata fino a una causa radice non personale.
3. Formula tre azioni correttive concrete con owner ipotetico e scadenza.
4. Scrivi la lezione condivisa in una frase.

Errori frequenti del principiante

• Postmortem solo per incidenti grandi. Anche bug medi insegnano. Postmortem breve va bene.
• Cercare colpevoli. Riduce la trasparenza nelle prossime indagini.
• Azioni correttive vaghe. “Migliorare X” non avviene mai.
• Saltare la lezione condivisa. Il documento resta in un cassetto e nessuno impara.