Escribir un informe de incidentes que alguien quiera leer

He leído cientos de informes de incidentes. La mayoría tienen el mismo problema: están escritos para cerrar el ticket, no para que alguien aprenda algo.

La estructura que usamos#

1. Qué notó el usuario, en una frase y sin jerga
2. Cronología con horas reales, no con «poco después»
3. Por qué fue posible, no quién se equivocó
4. Qué cambiamos, con responsable y fecha

Un buen informe se lee en cinco minutos y cambia algo en cinco días.

Lo que evitamos#

• Nombres propios en la sección de causas
• «Error humano» como conclusión: siempre hay un por qué detrás
• Acciones sin fecha, que nadie hace

Un truco: pedimos a alguien de otro equipo que lo lea antes de publicarlo. Si no lo entiende, no está terminado.