Reconozcámoslo: a ninguno de nosotros le gusta cometer errores. Los errores hacen que nuestros planes salgan mal, nos hacen perder tiempo y dinero, y nos pueden llevar al fracaso, que en muchas sociedades conlleva un fuerte golpe en nuestra reputación. Sin embargo, las personas que más éxito tienen son también las que más errores han cometido; lo importante es que son capaces de analizar sus errores y aprender de ellos para no cometerlos en el futuro.

En la industria informática, como es bien sabido, cometemos errores como el que más: proyectos que se salen de plazo, proyectos que nunca se terminan, redes que se caen, intrusiones en sistemas seguros, datos perdidos, etc. Vaya, que no nos han faltado oportunidades de aprender de nuestros errores, y una de las herramientas más importantes que tenemos para hacerlo es el “postmortem”.

El postmortem es un documento en el que se analiza un suceso. Este suceso suele ser un fallo, aunque se pueden hacer postmortem de cualquier tipo de suceso, incluso de éxitos inesperados. El objetivo de este análisis es conocer las causas del suceso y la manera de evitarlo en el futuro – o de repetirlo, si es un postmortem de un suceso exitoso. Como la mayoría de postmortem se escriben después de un fallo, en este artículo hablaré de fallos, soluciones y acciones paliativas.

Inevitablemente, un postmortem tendrá que hablar de errores cometidos y de malas decisiones tomadas por una o más personas. Es importante que no se utilice el postmortem para echar las culpas a nadie o para distribuir castigos. Para escribir un postmortem de calidad es imprescindible la colaboración de todas las personas implicadas, y es de suponer que no prestarán toda la ayuda necesaria si conlleva consecuencias negativas para ellos.

Un postmortem debería contener, como mínimo, explicaciones de qué sucedió, cómo sucedió, por qué sucedió, cómo terminó (si es que terminó), qué se hizo bien, qué se hizo mal, y qué se va a hacer en el futuro. Normalmente, los postmortem tienen una estructura similar a: resumen, secuencia temporal, acciones paliativas (realizadas y por realizar), lecciones aprendidas y acciones a largo plazo.

Los postmortem suelen entrar en detalles, ya que son documentos para uso interno: mencionan quién intervino en el suceso, qué máquinas y servicios estuvieron implicados, qué líneas de código tenían errores, … Como dije antes, no es objetivo del postmortem echarle la culpa a nadie, así que “aparecer” en uno no debería tener, por si mismo, más consecuencias que tener que aguantar que los compañeros se metan con uno de vez en cuando.

(Voy a aclarar esto, que tengo muchos lectores que se toman todo lo que leen con excesiva literalidad: estoy hablando de situaciones normales en las que uno se equivoca y pierde datos porque ha copiado un disco vacío sobre uno lleno o ha causado un fallo de servicio porque ha conectado la red de producción al “uplink” incorrecto, no de casos delictivos en los que el sistema falla catastróficamente porque alguien ha vendido los sistemas secundarios y se ha quedado con el dinero).

No obstante, en ocasiones hay que redactar postmortem dirigidos a audiencias externas. En esos casos, es habitual reducir el nivel de detalle del documento. Esto puede ser tan simple como eliminar nombres y referencias a elementos confidenciales, o puede ser una reescritura total del documento. El nivel de detalle queda, en general, a elección de la persona que vaya a publicar el postmortem, pero siempre debe ser suficiente para que el lector tenga una idea aproximada del fallo que hubo y pueda estar razonablemente seguro de que se están tomando medidas efectivas para evitar que vuelva a suceder. En general, la gente aprecia más los postmortem detallados.

Como sé que queréis ejemplos pero no tengo ganas de inventarme uno, voy a poneros un enlace a la versión pública del postmortem de un fallo de App Engine, que me gusta bastante como ejemplo porque es muy parecido a la versión interna, salvo por la ausencia de nombres de personas y otros datos confidenciales.

Al terminar este artículo me gustaría animaros a escribir postmortem, a convertirlo en una rutina cada vez que haya habido un problema (o algo haya salido mejor de lo esperado, para ver si se puede repetir), y a solicitar postmortem de vuestros proveedores cada vez que tengáis un problema gordo con su servicio.

Y vosotros, ¿escribís postmortem en vuestra empresa? ¿Los solicitáis de vuestros proveedores? ¿Conocéis mejores ejemplos de postmortem accesibles por la web? ¿Son cuatro preguntas al final de un artículo demasiadas? Escribid un comentario y dadme vuestra opinión.