# Azioni post-mortem: perché il tasso di completamento crolla URL: https://upstreamapi.com/it/journal/azioni-post-mortem-completamento-incidenti Type: blog Locale: it Published: 2026-09-05 Updated: 2026-09-06 --- > Le azioni post-mortem muoiono nei Google Doc. Come strutturarle con owner nominati e sprint integration per superare il 75% di completamento. 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. ![Un kanban board su monitor che mostra card di progetto con status scaduto evidenziato, ingegnere che indica gli item da rivedere](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/07c92a-inline1.webp) ## 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. ![Team di ingegneri in discussione post-mortem intorno a una lavagna con diagrammi della timeline dell'incidente](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/b55433-inline2.webp) ## 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](https://sre.google/sre-book/postmortem-culture/), 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. ![Sviluppatore al laptop con indicatori verdi di merge confermato visibili sullo schermo, azione post-mortem chiusa](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/899b10-inline3.webp) ## 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. ## FAQ ### Cos'è un'azione post-mortem? Un'azione post-mortem è un task specifico e misurabile derivato da un'analisi di incidente, con owner nominato e scadenza definita. Non è una nota generica: è un impegno concreto inserito nel backlog del team con una definizione di done verificabile. ### Perché la maggior parte delle azioni post-mortem non viene completata? La ricerca di incident.io indica che il tasso di completamento è inferiore al 50% per il team mediano. Le cause principali sono la mancanza di owner nominati, l'assenza di integrazione nel tracker di progetto, e l'assenza di revisioni periodiche che mantengano le azioni visibili nel tempo. ### Come si assegna un owner efficace a un'azione post-mortem? L'owner deve essere una persona fisica con nome, non un team. Deve essere presente alla call del post-mortem o contattata entro 24 ore per confermare esplicitamente l'ownership. Il task deve comparire nel suo backlog personale, non solo nel documento. ### Qual è la differenza tra azioni mitigative e preventive? Le azioni mitigative riducono il blast radius del prossimo incidente e si chiudono entro uno sprint. Le azioni preventive eliminano il failure mode alla radice e richiedono roadmap e sponsor senior. Mescolarle in una sola lista porta a de-prioritizzare sistematicamente quelle preventive. ### Come integro le azioni post-mortem nel flusso di sprint? Ogni azione deve diventare un ticket nel tracker di progetto del team prima che la call del post-mortem finisca. Il passo manuale da documento a ticket ha un tasso di completamento di circa il 40%: automatizzare questa integrazione o assegnare la responsabilità a una persona specifica è la prima cosa da fare. ### Qual è il ciclo di feedback più importante nel processo post-mortem? Collegare le azioni chiuse agli incidenti che non si sono verificati grazie ad esse. Quando arriva un incidente, controllare se ci sono azioni aperte che avrebbero potuto prevenirlo. Questo rende il processo auto-rinforzante: il team vede il valore concreto del completamento.