# Los elementos de acción post-mortem que nadie cierra URL: https://upstreamapi.com/es/journal/elementos-de-accion-post-mortem-que-nadie-cierra Type: blog Locale: es Published: 2026-09-05 Updated: 2026-09-06 --- > Los elementos de acción fallan no por saltarse el proceso: les faltan propietarios, viven en docs que nadie lee y nunca llegan al sprint. Los elementos de acción post-mortem son donde los post-mortems terminan de pagar o de hacer teatro. Tu equipo ejecutó uno el martes pasado. Escribiste seis ítems. Para ahora, quizá dos tienen tickets en Jira. Uno tiene un propietario que está apagando otro fuego. Los otros tres siguen en el Google Doc, bajo el encabezado "Seguimientos", sin tocar. La tasa de cierre está por debajo del 50% en el equipo SRE típico, según la investigación de incident.io. Eso significa que el post-mortem promedio produce tanto cambio real como una votación de retrospectiva con stickers: el proceso corre, la culpa se difumina, y el mismo modo de fallo llega a producción seis semanas después. La solución no es una mejor plantilla. Es una comprensión distinta de qué hace real a un elemento de acción. ## Por qué la mayoría de los elementos de acción están rotos desde el inicio Escribir "mejorar el monitoreo" en un post-mortem parece productivo. No es un elemento de acción: es una categoría de trabajo sin propietario, sin fecha límite y sin definición de hecho. Los elementos efectivos tienen tres partes irreducibles: qué hay que hacer (específico y medible), quién lo tiene (un ingeniero con nombre, no un equipo), y para cuándo (una fecha concreta, no "el Q3"). Si falta cualquiera de las tres, el ítem no se va a cerrar, porque los ítems ficticios no se priorizan: se disuelven. Nadie decide activamente no hacerlos. Simplemente nunca aparecen donde el trabajo real se programa. La diferencia es más aguda de lo que parece. "Mejorar el rate limiting" es ficción. "Añadir un circuit breaker en las llamadas upstream al servicio de búsqueda en el path de checkout, propietario: @anya, objetivo: fusionado antes del 2026-09-19" es un elemento de acción. Uno aparecerá en el standup. El otro no. El fallo estructural ocurre en el momento de escribir, cuando los ingenieros están cansados, la reunión se alarga, y la presión por terminar supera a la presión por ser precisos. Es exactamente entonces cuando la precisión más importa: el contexto se degrada rápido, y el detalle que omites a las 11pm es el que @anya necesitará preguntar tres semanas después. ## El número que debería inquietar a cualquier tech lead Más del 50% de los elementos de acción post-mortem nunca se completan en los equipos SRE típicos. En organizaciones con cultura de incidentes débil, esa cifra supera el 70%. Piensa qué implica eso para la fiabilidad a escala. Si tus post-mortems promedian cuatro ítems por incidente y tienes diez incidentes por trimestre, generas 40 ítems, completas menos de 20, y acumulas un backlog creciente de modos de fallo sin corregir. El próximo incidente es estadísticamente probable que sea una variante de algo que ya diagnosticaste. [La investigación DORA](https://sre.google/sre-book/postmortem-culture/) demuestra de forma consistente que las organizaciones de ingeniería de alto rendimiento tienen tasas de fallo de despliegue más bajas no porque escriban mejores post-mortems, sino porque cierran sus elementos de acción. El documento no es el trabajo. El ticket es el trabajo. Cuando las tasas de cierre caen por debajo del 50%, los post-mortems se convierten en teatro: escritos para satisfacer un proceso, no para cambiar nada. El equipo lo sabe. Los ingenieros que sí escriben ítems cuidadosos los ven pudrirse. Con el tiempo, la calidad de los ítems que se escriben degrada hasta igualar la tasa de cierre. Para qué escribir un ítem preciso y ejecutable si nadie cierra los que ya existen. ## Mitigadores y preventivos no van en la misma cola Los elementos de acción post-mortem se dividen en dos categorías, y tratarlas de forma idéntica es un error de planificación que se acumula con el tiempo. Los ítems mitigadores reducen el blast radius de la próxima ocurrencia antes de que hayas eliminado la causa raíz. Añadir un fallback. Establecer un timeout. Conectar un circuit breaker. Casi siempre son urgentes y deberían entrar en el sprint actual antes de que cierre la planificación, idealmente antes de que termine la propia reunión post-mortem si son lo suficientemente pequeños para estimarlos. Los ítems preventivos eliminan el modo de fallo por completo: refactorizar el consumer de la cola, rediseñar la lógica de retry, instrumentar el gap de SLO que permitió que esto escapase a tu alerta de burn rate. Requieren más tiempo, revisión de diseño, y compiten directamente con el trabajo de producto. Mezclar ambos bajo una etiqueta de "acciones post-mortem" hace que los preventivos largos arrastren la lista durante tanto tiempo que el equipo olvida por qué se escribieron, mientras los mitigadores esperan en la misma cola detrás de ellos. Sepáralos explícitamente. Mitigadores en el sprint actual, antes de que cierre la planificación. Preventivos, dimensionados y priorizados contra el roadmap de fiabilidad, tratados como cualquier otra inversión de plataforma, no como post-its pegados a un incidente ya cerrado. ![Un tablero kanban en un monitor mostrando tarjetas con estado vencido resaltado, ingeniero señalando ítems a revisar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/07c92a-inline1.webp) ## Adónde van a morir los elementos de acción El Google Doc es el cementerio más común. Los equipos redactan post-mortems en documentos compartidos porque tienen poca fricción durante un incidente. El problema es que el doc no es donde vive el trabajo de ingeniería. Jira lo es. Linear lo es. GitHub Issues lo es. Donde sea que ocurra la planificación del sprint, ahí es donde un elemento de acción necesita estar antes de que termine la reunión post-mortem. El gap de integración es el punto de fallo más predecible de todo el flujo. El incidente ocurre. El post-mortem corre. Se escriben buenos ítems. Luego alguien tiene que copiarlos manualmente al sistema de tickets. Ese paso de copia tiene una tasa de finalización de aproximadamente el 40% en equipos que no lo automatizan ni lo exigen. La solución no es una herramienta nueva: es eliminar el gap entre el documento post-mortem y el sistema de sprint. Varias plataformas de gestión de incidentes escriben tickets en Jira o Linear directamente desde plantillas post-mortem. El principio clave es que ningún ingeniero debería copiar y pegar desde un doc a un ticket después de una reunión de revisión de 90 minutos al final de un turno de guardia. ## El problema del propietario: los equipos no cierran tareas Asignar un elemento de acción a un equipo es el equivalente organizacional de no asignárselo a nadie. Los equipos no tienen recordatorios de calendario. No se les marca en Jira. No aparecen en el standup cuando un ítem lleva semanas vencido. "El equipo de plataforma" no tiene bandeja de entrada de notificaciones. @carlos sí. Los propietarios nombrados importan, pero los propietarios nombrados con contexto importan más. "Arreglar el consumer de la cola" asignado a @carlos es mejor que nada. "@carlos: añadir backoff exponencial al consumer SQS en payments-worker, ver la línea de tiempo del incidente para el patrón de ráfaga que ocurrió a las 14:23 UTC. Objetivo: fusionado antes del cierre del sprint del 2026-09-26, Jira: PAY-2891" es algo que @carlos puede ejecutar sin una conversación de seguimiento. El post-mortem es el momento en que el contexto está más alto. Ese es el momento en que escribes el ítem. El detalle se degrada rápido: en 48 horas, la mitad de la sala ha olvidado el patrón de ráfaga específico que desencadenó el fallo. En dos semanas, el incidente es ruido de fondo. El ítem escrito con contexto completo al final de la reunión post-mortem es el que se cierra. El ítem que recibe "lo escribiremos bien más tarde" queda huérfano. ![Equipo de ingeniería en una discusión post-mortem alrededor de una pizarra con diagramas de la línea de tiempo del incidente](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/b55433-inline2.webp) ## Cerrar el bucle de retroalimentación que nadie cierra Hay un paso después de la finalización que la mayoría de los equipos omite por completo: reconocerlo. Cuando un elemento de acción del post-mortem #47 previene la recurrencia que se habría convertido en el incidente #58, esa conexión debería hacerse visible. Escríbelo en tu canal de incidentes. Ponlo en la próxima actualización de ingeniería del all-hands. Deja que el ingeniero de guardia propietario de PAY-2891 sepa que su circuit breaker absorbió una ráfaga el jueves pasado y no sonó ninguna alerta. Los equipos cierran más elementos de acción cuando ven que su trabajo da resultados. Los equipos que escriben ítems en un doc al que nadie vuelve eventualmente dejan de escribirlos en serio: el formato permanece, pero la calidad cae para igualar el impacto percibido. Así es como una cultura post-mortem sin culpa puede seguir produciendo una cultura de fiabilidad sin memoria. El bucle de retroalimentación es lo que separa las culturas post-mortem que mejoran de las que actúan. A las 3 de la mañana, el ingeniero de guardia que solucionó un timeout el trimestre pasado porque tenía un ítem en propiedad sabe exactamente para qué era el trabajo. Haz esa conexión explícita para todo el equipo, no solo para la persona que por casualidad estaba de guardia cuando la solución demostró su valor. ## Cómo se ve un elemento de acción que funciona Este es el formato que cierra de forma consistente: `Ítem: Añadir circuit breaker en llamadas upstream a search-service (path de pagos) Propietario: @danielle Tipo: mitigador Fecha límite: 2026-09-12 (antes del próximo despliegue a prod) Ticket: PAY-2891 Contexto: los timeouts de search-service causaron fallo en cascada en checkout a las 14:23 UTC; el circuit breaker limita el blast radius en la próxima ocurrencia mientras se dimensiona el refactor`Siete campos. El campo "Contexto" no es opcional. Es lo que sobrevive al gap de tres semanas entre el post-mortem y el sprint donde @danielle finalmente tiene ancho de banda. Sin él, el ítem es una tarea sin historia. Con él, @danielle puede abrir PAY-2891 en frío y saber exactamente qué está construyendo y por qué importa. ![Desarrollador en portátil con indicadores de merge confirmado en pantalla, elemento de acción post-mortem cerrado](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/899b10-inline3.webp) ## Qué requiere esto del engineering lead La tasa de cierre de elementos de acción es una métrica del tech lead, no del ingeniero. Los ingenieros escriben los ítems. El lead es responsable del sistema que asegura que se cierren. En concreto, eso implica cuatro cosas. Primero, capacidad de sprint asignada para ítems mitigadores antes de que empiece la planificación, no después de que el equipo haya comprometido su velocidad al trabajo de producto. Si los ítems mitigadores tienen que competir por las sobras, pierden. Segundo, una revisión de cinco minutos de los ítems post-mortem abiertos en la sincronización semanal del equipo. No una ceremonia. Solo un escaneo: algo con más de 14 días sin ticket, algo vencido que necesita una decisión. Tercero, deprioritización explícita cuando algo genuinamente no puede hacerse. "No vamos a hacer PAY-2891 este trimestre porque el refactor de pagos llega en Q4 y esto se vuelve redundante" es una decisión. "PAY-2891 lleva tres meses en el backlog" es un fallo de proceso. Cuarto, seguimiento de la tasa de cierre como métrica de salud del equipo junto a la frecuencia de despliegue y el MTTR. Los equipos que la miden descubren que promedia alrededor del 42% sin proceso deliberado. Con propietarios nombrados, integración en sprint y revisión semanal, ese número sube por encima del 75% en dos trimestres. La diferencia en términos de fiabilidad equivale aproximadamente a prevenir un incidente mayor adicional por trimestre para un equipo que corre a un ritmo de diez incidentes. El post-mortem te dijo qué se rompió. El elemento de acción es el contrato para arreglarlo. Si ese contrato se cierra es una decisión de gestión, no un problema de calidad del documento. ## FAQ ### ¿Qué hace que un elemento de acción post-mortem sea efectivo? Un elemento efectivo tiene tres partes irreducibles: qué hay que hacer (específico y medible, no una categoría como 'mejorar el monitoreo'), quién lo tiene (un ingeniero nombrado, no un equipo), y para cuándo (una fecha concreta). Añadir un campo de contexto que explique por qué el ítem importa mejora significativamente las tasas de cierre cuando el ancho de banda escasea. ### ¿Cuál es la diferencia entre ítems mitigadores y preventivos en un post-mortem? Los ítems mitigadores reducen el blast radius de una futura ocurrencia antes de eliminar la causa raíz: circuit breakers, timeouts, fallbacks, umbrales de alerta. Son casi siempre urgentes y deben entrar en el sprint actual. Los ítems preventivos eliminan el modo de fallo por completo, como refactorizar la lógica de retry o rediseñar un consumer de cola. Requieren más tiempo y deben priorizarse contra el roadmap de fiabilidad por separado. ### ¿Por qué fallan los elementos de acción post-mortem en completarse? Las causas más frecuentes son las descripciones vagas ('mejorar el monitoreo'), la asignación a un equipo en lugar de a un ingeniero con nombre, y los ítems que quedan en un documento post-mortem que nunca se conecta con el sistema de tickets donde ocurre el trabajo del sprint. El gap de integración entre el doc y Jira o Linear es donde se pierde la mayoría de los ítems. ### ¿Cuál es una tasa de cierre realista para equipos SRE? La investigación de incident.io indica que el equipo SRE típico completa menos del 50% de los elementos de acción post-mortem. Sin proceso deliberado, las tasas de cierre promedian alrededor del 42%. Los equipos que añaden propietarios nombrados, integración en sprint y una revisión semanal de ítems abiertos suelen superar el 75% en dos trimestres. ### ¿Deberían los ítems mitigadores entrar en el sprint actual? Sí. Los ítems mitigadores deben llegar al sprint actual antes de que cierre la planificación, idealmente antes de que termine la propia reunión post-mortem si son lo bastante pequeños para estimarlos. Los preventivos se dimensionan y priorizan contra el roadmap de forma separada. Mezclar ambos en la misma cola sin distinguirlos es un error habitual de planificación. ### ¿Cómo se hace seguimiento de los elementos de acción sin añadir sobrecarga de proceso? El enfoque más efectivo es eliminar el gap entre el documento post-mortem y la herramienta de sprint que el equipo ya usa. Los ítems deben convertirse en tickets de Jira, Linear o GitHub Issues antes de que termine la reunión. Los equipos que dependen del copy-paste manual desde un doc a un sistema de tickets pierden alrededor del 60% de los ítems en ese paso.