El postmortem termina con diez acciones en una planilla y tres abiertas el trimestre siguiente. La revisión de incidentes cambia el comportamiento solo cuando la acción tiene responsable, plazo y verificación posterior. Los cuatro ajustes siguientes vienen de revisiones que conduje en equipos con guardia propio, y cada uno cierra con un número que aparece en el reporte mensual.
Una acción con responsable, de a una
Si nadie acepta la acción, no es una acción. El Site Reliability Engineering (Beyer et al., O'Reilly, 2016) describe postmortems sin culpa y con ítems de acción priorizados, porque un ítem sin responsable se vuelve prosa. Antes de cerrar la reunión, pide el nombre de quien se hace cargo y la fecha. Tres acciones aceptadas valen más que quince anotadas.
Plazo de 30 días y la lista anterior revisada
El primer punto de la próxima revisión es la lista anterior. Cada reunión abre con el estado de las acciones de los últimos dos incidentes. La atención se vuelve rutina cuando una persona sabe que va a responder delante del equipo, y la revisión destapa la acción que necesita presupuesto. Esa sale del guardia y se vuelve decisión de gestión, con otro responsable.
Causa del sistema, con la persona protegida
Sidney Dekker, en The Field Guide to Understanding Human Error (Routledge, 2014), muestra que castigar a una persona termina la investigación temprano y esconde la condición que permitió el error. La pregunta correcta es qué combinación de alerta, código y proceso dejó posible ese camino. Amy Edmondson, en The Fearless Organization (Wiley, 2018), mide cuánto habla la gente de los errores cuando se siente segura para hacerlo.
Lecciones fuera del equipo
Una nota de cinco líneas en el canal de la empresa. Escribe qué pasó, qué cambió en el sistema y qué deben chequear otros equipos. Un equipo que lee el incidente de otro aprende sin vivirlo, y el capítulo de posincidente del libro de SRE de Google recomienda exactamente ese hábito. El texto corto es el formato que la gente lee.
Porcentaje de acciones cerradas en 30 días
Una línea en el reporte mensual de confiabilidad. Acompaña el tiempo entre el incidente y la primera acción terminada. El State of DevOps Report de DORA vincula la cultura de aprendizaje con resultados de estabilidad, y estos dos números muestran si la revisión se volvió práctica del equipo o un formulario completado después. Si el número baja dos meses seguidos, lleva la lista a la reunión de gestión.
