Close

El camino hacia una mejor gestión de incidentes empieza aquí

Creación de informes de análisis retrospectivos

Por qué recopilar y documentar datos es clave para el proceso de análisis retrospectivo de los incidentes

El análisis retrospectivo de un incidente se puede dividir en dos actividades distintas: la reunión en la que se examina el incidente y el correspondiente informe de análisis retrospectivo generado como consecuencia de dicha reunión.

Se suele decir "análisis retrospectivo" para referirse indistintamente a la reunión o al informe. Con este término, el personal podría estar hablando de una de estas actividades o de ambas.

¿Quieres ponerte manos a la obra con una plantilla de análisis retrospectivo? Echa un vistazo a nuestras plantillas de análisis retrospectivo.

Ahora bien, hay una diferencia entre la reunión del análisis retrospectivo y el informe por escrito del análisis retrospectivo.

En Atlassian, solemos usar el análisis retrospectivo, o análisis retrospectivo de incidentes, para describir todo el proceso de análisis de un incidente, que incluye lo siguiente:

  • Llevar a cabo una reunión de análisis retrospectivo de un incidente
  • Recopilar acciones e información durante la reunión
  • Obtener la aprobación para las acciones de seguimiento y comunicar el resultado de la reunión

Encontrarás más información sobre cómo gestionamos en Atlassian los análisis retrospectivos en nuestro manual de gestión de incidentes.

¿Qué debe reunir todo buen informe de análisis retrospectivo de un incidente?

Puntos claros y homogéneos

Todo buen informe debería basarse en un marco de trabajo claro y homogéneo. Los equipos eficaces preparan los análisis retrospectivos a partir de una plantilla, en la que los participantes contestan a una serie de preguntas o puntos.

De este modo, se garantiza que no se pase por alto ningún detalle clave. Además, se genera homogeneidad entre un incidente y otro, y al equipo le resulta más fácil identificar patrones, tendencias y oportunidades de mejora. El marco de trabajo se puede repetir y mejorar con el tiempo, pero todos estos cambios deberían ser intencionados.

Profusión de detalles y datos

En los campos de los análisis retrospectivos no hay que escatimar detalles ni contar los eventos por encima, sino ser minucioso y específico. No digas que has visto un repunte en el tráfico; di exactamente cuál es la métrica que ha cambiado y cuánto lo ha hecho. No digas que el equipo estaba confundido; extrae una cita literal del historial del chat en el momento en el que alguien manifestara confusión.

Lenguaje inclusivo sin culpar a nadie

Al igual que muchos otros equipos, en Atlassian hacemos análisis retrospectivos sin reproches. Es importante que los reproches no tengan cabida en la reunión ni en el análisis del incidente; procura tratar con el mismo cuidado el tono del informe. Evita que tus palabras carguen culpas sobre el personal y señalen a alguien con el dedo.

Preguntas importantes que debes plantearte al hacer un informe de un análisis retrospectivo

Estos son los puntos incluidos en la función de análisis retrospectivo de Opsgenie:

  • Origen
    Describe las circunstancias que dieron lugar al incidente
  • Fallo
    Describe qué no funcionó según lo esperado
  • Detección
    Describe cómo se detectó el incidente
  • Causas raíz
    Lleva a cabo un análisis de los 5 porqués para comprender las verdaderas causas del incidente
  • Mitigación y resolución
    ¿Qué medidas tomaste para resolver el incidente?
  • Lecciones aprendidas
    ¿Qué aspectos fueron bien? ¿Qué podría haber salido mejor? ¿Qué más aprendiste?

Consulta nuestro artículo sobre plantillas de análisis retrospectivos para ver más ejemplos de preguntas que puedes incluir en el informe de un análisis retrospectivo.

Qué más incluir en el informe de un análisis retrospectivo

  • Capturas de pantalla
    Adjunta capturas de pantalla pertinentes, especialmente las que el equipo de respuesta tomó durante la interrupción. ¿Qué cambios observaste en el producto? ¿Qué comportamiento del producto no ocurrió como se esperaba?
  • Tickets
    Enlaza los tickets pertinentes relacionados con el incidente.
  • Feedback del cliente
    ¿Se ha recibido feedback del cliente sobre el incidente? El cliente puede enviarlo desde sitios como un centro de ayuda, por correo electrónico o en redes sociales. No hace falta que lo incluyas todo.
  • Gráficos y diagramas
    ¿Qué visualizaciones de datos contribuyen a mostrar la repercusión del incidente?
  • Datos
    ¿Hay algún otro punto de datos clave sobre el incidente o su repercusión?
  • Conversaciones por chat
    Si el equipo usa alguna herramienta de chat (como Slack) durante las tareas de respuesta, plantéate la opción de incluir mensajes o conversaciones clave del historial de chat.
  • Cronograma
    Tener un cronograma claro del incidente ayuda muchísimo a analizarlo. ¿Cuáles fueron los eventos clave y a qué hora se produjeron durante el incidente?

Informes internos o externos de análisis retrospectivos

Aunque es menos habitual, algunas organizaciones optan por publicar una versión pública de un análisis retrospectivo después de un incidente. Esto sucede sobre todo en los servicios de consumo a gran escala con interrupciones que afectan a muchos usuarios. Podría darse el caso de que publiquen el informe completo del análisis retrospectivo o (lo que es más probable) de que publiquen una versión abreviada del informe interno. Probablemente, habrá que borrar información confidencial o privada.

A continuación
Meeting