Azioni post-mortem: perché il tasso di completamento crolla

Il tuo team ha fatto un post-mortem martedì scorso. Avete scritto sei azioni post-mortem. Adesso, forse due hanno un ticket Jira. Una ha un owner che è impegnato su un altro incidente. Tre sono ancora nel Google Doc, sotto "Follow-up", intoccate.

Le azioni post-mortem sono il punto in cui un post-mortem paga o performa. La maggior parte fa la seconda cosa. La ricerca di incident.io indica un tasso di completamento inferiore al 50% per il team SRE mediano. Il che significa che il post-mortem medio produce pressappoco lo stesso cambiamento di un voto con gli sticker in retrospettiva: il processo gira, il blame rimane blameless, e lo stesso failure mode va in produzione sei settimane dopo.

La soluzione non è un template migliore. È una comprensione diversa di cosa rende un'azione reale.

Perché la maggior parte delle azioni post-mortem è strutturalmente rotta

Scrivere "migliorare il monitoring" in un post-mortem sembra produttivo. Non è un'azione post-mortem: è una categoria di lavoro senza owner, senza scadenza e senza definizione di "done".

Le azioni efficaci hanno tre parti irriducibili: cosa va fatto (specifico e misurabile), chi lo possiede (un ingegnere nominato, non un team), e entro quando (una data specifica, non "Q3"). Manca anche solo una parte e l'azione difficilmente si chiude, perché le azioni fittizie non vengono de-prioritizzate: si dissolvono. Nessuno decide attivamente di non farle. Semplicemente non emergono mai nei luoghi in cui il lavoro viene effettivamente pianificato.

Il passo manuale di copia da documento a ticket ha un tasso di completamento di circa il 40%. Non perché le persone siano negligenti: perché il passaggio manuale crea attrito sufficiente a garantire che metà del lavoro non arrivi mai nel backlog.

Il numero che dovrebbe preoccupare ogni team lead

Il 50% è la mediana. Nelle organizzazioni con una cultura degli incidenti debole, il tasso di abbandono supera il 70%. Significa che su dieci azioni scritte, sette non producono alcun cambiamento misurabile.

La ricerca DORA collega tassi di change failure rate più bassi alla chiusura delle azioni post-mortem, non alla qualità dei documenti. Non è la lunghezza del post-mortem a ridurre il blast radius del prossimo incidente. È se le azioni vengono effettivamente eseguite.

Senza un processo deliberato, la media si attesta intorno al 42% di completamento. Con owner nominati, integrazione nello sprint e revisione settimanale, i team raggiungono il 75-80% entro due trimestri. Non è un risultato eccezionale: è la differenza tra una routine funzionante e una che gira a vuoto.

Azioni mitigative e preventive: non stanno nella stessa coda

Confondere azioni mitigative e preventive è uno dei motivi più comuni per cui le cose non vengono fatte.

Le azioni mitigative riducono il blast radius: aggiungono circuit breaker, migliorano l'alert targeting, aumentano la granularità del rollout. Hanno un perimetro limitato e dovrebbero chiudersi entro uno sprint. Il loro valore si misura in: quanto più velocemente possiamo contenere il prossimo incidente simile?

Le azioni preventive rimuovono il failure mode alla radice: refactoring architetturale, migrazione a un servizio più affidabile, eliminazione di un single point of failure. Richiedono roadmap, PI planning, sponsor senior. Non stanno nel backlog dello sprint: stanno nel backlog del prodotto, con priorità esplicita.

Trattarle come una sola lista porta a un risultato prevedibile: le azioni preventive, più grandi e più complesse, vengono costantemente de-prioritizzate a favore di quelle mitigative. Poi, quando il sistema va di nuovo giù per lo stesso motivo, il post-mortem si chiede perché nessuno ha fixato la causa radice.

Dove le azioni post-mortem vanno a morire

Il percorso tipico: post-mortem su Google Docs o Notion, azioni in fondo al documento, meeting di chiusura in cui qualcuno dice "ci occupiamo di questi follow-up", nessun ticket aperto prima che la call finisca, nessuno che li apre nei giorni successivi.

Tre settimane dopo, durante lo standup del lunedì, nessuno menziona le azioni. Non perché siano state completate: perché non sono nel posto dove il team organizza il proprio lavoro.

Il pattern è sistematico. Le azioni post-mortem vivono in strumenti separati dal lavoro operativo quotidiano -- Jira, Linear, Azure DevOps, a seconda del team. Il gap tra "documento del post-mortem" e "backlog di sprint" è il luogo in cui le azioni muoiono.

La soluzione tecnica è banale: integrazione diretta tra il documento del post-mortem e il tracker di progetto. La soluzione organizzativa è più costosa: qualcuno deve essere responsabile di questo passaggio, e questo responsabile deve avere abbastanza autorità da inserire le azioni nel backlog con priorità reale, non solo simbolica.

Il problema dell'owner: i team non completano le task

"L'infra team se ne occupa" non è un owner. È una categoria organizzativa con sei persone, nessuna delle quali ha sentito il proprio nome pronunciato nell'ultima ora della call.

Il fatto che i team non completino le task non è una critica ai team: è il modo in cui funziona il commitment umano. Le persone completano le task che hanno esplicitamente accettato, con il loro nome, con una scadenza che ricordano. I team non accettano nulla: i team sono strutture di reporting, non unità di commitment.

Ogni azione deve avere un owner che sia:

• Una persona fisica con un nome

• Presente alla call (o contattata entro 24 ore e che ha confermato esplicitamente)

• Con l'azione nel proprio backlog personale, non solo nel documento

Un owner che non sa di essere owner è un placeholder, non un responsabile.

Gap di osservabilità: una categoria speciale

Alcune azioni post-mortem sono difficili da chiudere non per mancanza di ownership, ma per natura del problema: non si sa cosa misurare, quindi non si sa quando l'azione è risolta.

"Migliorare l'osservabilità sulla pipeline di pagamento" è un'azione preventiva con una definizione di done implicita e vaga. Un ingegnere potrebbe aggiungere tre dashboard e sentire di aver finito. Un altro potrebbe interpretare la stessa azione come l'aggiunta di distributed tracing end-to-end con SLO gate.

Le azioni legate all'osservabilità richiedono una specifica aggiuntiva: qual è il segnale che ci dirà che l'azione è completata? Un'alert specifica? Una soglia p99? Un nuovo SLO? Senza questa specifica, l'azione è ambigua per definizione e resterà aperta finché qualcuno non deciderà arbitrariamente che "basta così".

Chiudere il ciclo di feedback che nessuno chiude

Il ciclo di feedback più importante non è il post-mortem in sé: è la connessione tra un'azione chiusa e l'incidente che non è successo.

I team che mantengono alti tassi di completamento delle azioni condividono una pratica: quando si verifica un incidente, controllano se ci sono azioni post-mortem precedenti che avrebbero potuto prevenirlo o contenerne l'impatto. Se trovano azioni chiuse che hanno fatto la differenza, le evidenziano nel post-mortem corrente. Se trovano azioni aperte che avrebbero aiutato, ne aumentano la priorità.

Questo loop è difficile da mantenere perché richiede sforzo deliberato. È anche l'unica cosa che rende il processo auto-rinforzante nel tempo. Senza di esso, le azioni post-mortem sono un esercizio di compliance: si completano perché il processo lo richiede, non perché si vede il valore. Con esso, chiudere le azioni diventa una decisione razionale: il team può misurare cosa succede quando non lo fa.

Per approfondire la cultura post-mortem e il suo impatto sull'affidabilità del sistema, il capitolo del SRE Book di Google rimane il riferimento più citato nei post-mortem pubblici analizzati.

Come appare un'azione post-mortem funzionante

Un'azione post-mortem che si chiude ha queste caratteristiche:

• Titolo che descrive il cambiamento, non il problema: "Aggiungere alert su latenza p99 >500ms per il servizio order-processor" invece di "Migliorare il monitoring"

• Owner nominato che era presente alla call o è stato contattato entro 24 ore

• Data di scadenza specifica, preferibilmente entro lo sprint corrente o il prossimo

• Ticket nel tracker di progetto del team, non solo nel documento del post-mortem

• Definizione di done verificabile: cosa controlleremo per confermare che è chiusa?

Per le azioni preventive con orizzonte più lungo: ID del backlog item, trimestre target, e chi mantiene la visibilità nel PI planning.

Cosa richiede questo a un engineering lead

Tutto il processo sopra descritto richiede una cosa che non è tecnica: un engineering lead che consideri il tasso di completamento delle azioni post-mortem una metrica del team, non un fatto di housekeeping.

In pratica:

• Revisione delle azioni aperte nell'agenda del team ogni settimana, non solo quando arriva il prossimo incidente

• Retrospettive trimestrali che includano il tasso di completamento e il suo trend

• Visibilità verso il management: quando le azioni non vengono completate per mancanza di priorità di business, questo va segnalato esplicitamente

Il change failure rate di un team non è disconnesso da questo. DORA lo misura. Il tuo SLO budget lo riflette. A le 3 di notte, quando apri PagerDuty, stai pagando il costo delle azioni che non hai chiuso tre settimane prima.

La cadenza di revisione più efficace che abbiamo osservato nei team con alto tasso di completamento è settimanale, integrata nello standup o in una slot dedicata di quindici minuti. Non serve una cerimonia: serve visibilità costante sullo stato delle azioni aperte.

La domanda non è se hai tempo per chiudere le azioni post-mortem. È se puoi permetterti di non farlo.