¿Por qué debería ser obligatorio escribir un post mortem por cada proyecto de software fallido?

La clave para aprender de nuestros errores es documentar nuestros fallos. Escribir un post mortem de cada proyecto finalizado debería ser una costumbre habitual en la industria del software. Tanto de los proyectos que salen horribles como los que a primera vista parecen exitosos. Lamentablemente para muchos desarrolladores y jefes de equipo es una autentica perdida de tiempo. Una lástima ya que debería ser tomado como uno de los pilares en la cultura de la mejora continua.

A pesar de los frenéticos avances tecnológicos en la industria del software aun seguimos intentamos construir catedrales que se desmoronan constantemente. Necesitamos aprender de nuestros errores y entender que detrás de todo esto hay humanos, más allá de lenguajes o tecnologías.

Vamos a repasar las principales características de un post mortem, cómo deberíamos hacerlo y cuál es el objetivo.

¿Qué es un documento de postmortem en un proyecto software?

Como comentábamos al principio: la clave para aprender de los errores es documentarlos. Forma parte de la mejora continua que debemos practicar como equipo de trabajo.

En mi opinión, los principales objetivos para dedicar tiempo a escribir un postmortem de un proyecto (totalmente o parcialmente fallido) es reflejar qué hemos aprendido durante el proceso y qué vamos a cambiar para mejorarlo. Dejarlo todo por escrito y en un lugar accesible nos asegura que podremos consultarlo en el futuro y cualquier nuevo miembro del equipo podrá aprender de la experiencia vivida y narrada fielmente.

Podemos hacer un postmortem desde el proyecto más minuscolo, un error en producción o de todo lo que ha salido mal en un trimestre completo dentro de la organización.

A la hora de escribir un post mortem debemos ser honestos con nosotros mismo y con el equipo, no se trata de encontrar la persona que falló, sino ver cuáles son los procesos que no aseguraron en su día el éxito del proyecto. Debemos encontrar cosas concretas y escribirlos sin censuras. Evitar las excusas. No sirven de nada, necesitamos encontrar soluciones no vale de nada seguir justificando decisiones erróneas.

Estructurando un postmortem

Justo después de acabar un proyecto o de apagar un fuego en producción sería el momento adecuado para recopilar toda la información del suceso y hacer un informe del drama para compartirlo con el equipo. La mente humana es muy frágil y olvida rápido.

La estructura básica sería la siguiente:

• Una breve introducción del proyecto o del error. Es importante remarcar el contexto, la finalidad o el asunto por el que se escribe este postmortem. Ya sea, un proyecto, un trimestre de trabajo o un error detectado en producción.

• Una línea temporal desde que se originó el problema, incluso remontándonos si lo sabemos a su puesta en producción o arranque del proyecto. Debemos describir cada detalle, problema detectado y la persona que lo ha reportado para obtener más información si fuera necesario.

• Análisis de la causa del problema. Después de mostrar la línea en el tiempo, debemos analizar con detalle la causa del problema dando datos sobre cómo implementamos el problema y dónde estuvo el error. Hay que ser critico con los errores que hubo: mala comunicación, falta de prototipado, uso de tecnologías poco maduras, falta de analisis para escalar el volumen de peticiones, etc..

• Impacto y daños causados. Análisis del impacto desde que se originó hasta su resolución. Deberíamos hablar de datos concretos, aunque aquí se pueden mezclar sentimiento contrapuesto de búsqueda de culpables debemos asumir los errores de la forma más constructiva posible. El postmortem puede ser requerido para analizar y comprender ciertas caídas en métricas, es importante ser honesto con lo sucedido.

• Acciones para solucionar el error inmediatamente. Aquí explicaremos algunas de las acciones que ya habremos puesto secuencialmente en el timeline de los hechos. Explicaremos como hemos podido parar la hemorragia del problema y cuáles han sido las soluciones temporales al error.

• Action point para llevar a cabo para que no vuelva a ocurrir. Aqui es dónde más analiticos debemos ser y construir acciones que aporten valor para superar el error. Estas acciones pueden ser a corto como a largo plazo, es decir, podemos hablar de proyecto futuros y refactor que facilitarán que el error no vuelva a llegar a producción.

• Lecciones aprendidas. Para mi uno de los puntos más importantes junto con los action point. De aquí extraemos las conclusiones que todo el equipo ha aprendido del error. Será uno de los puntos que compartamos con mayor intereses con toda la organización para posibilitar la mejora continua y el conocimiento colectivo.

Tanto para la elaboración parcial como completa del postmortem deberías tener en cuenta al máximo número de personas del equipo implicadas. Piensa que lo que para ti pueda ser obvio o ser un sentimiento claro de fracaso para otras puede que no lo sean. Probablemente porque no son conscientes.

Recuerda que documentar adecuadamente nuestros errores hace más fácil que otras personas (presentes y futuras) puedan conocer lo sucedidos y evitar que la historia se repita.

Un buen postmortem ayudará a que todo el equipo trabaje mejor y no cometa de nuevo los mismos errores. En definitiva, aprendizaje continuo.

Foto | Flickr