Apenas el post pasado, fui un poco duro al mencionar un proyecto realmente malo y mencionaba al postmortem como una posibilidad de reivindicar los errores para lo que viene, porque no significa que si tuviste un proyecto malo, los posteriores tengan que serlo.
Así que profundizaré en eso.
Por ahí dicen que “de las victorias debes aprender, pero aún más debes aprender, de las derrotas”.
En todo proyecto de software al haber concluido bien o mal, es importante tener un análisis postmortem para revisar toda la historia y ver los puntos claves en donde se falló y en donde se hicieron bien las cosas. Es algo que a mi me ha tocado mucho hacer en la mayoría de proyectos que he finalizado y mis consideraciones se resumen a lo siguiente:
- Es necesario contar con el punto de vista de todos los involucrados, gerentes, líderes, desarrolladores, testers, analistas y hasta los stakeholders. Si es el caso que los stakeholders, están en la disposición de hacerlo, recomiendo siempre tener una conferencia distinta con el cliente y posterior con el equipo interno. Un poco más formal primero y a lo mejor más informal con el equipo interno, mencionando lo que los stakeholders dijeron sobre la satisfacción que tuvieron con el proyecto.
- Se debe hacer hincapié en todo lo que fue positivo y más lo negativo durante la ejecución.
- Se debe criticar el proyecto, las decisiones elegidas, no a las personas, este punto es importante si no el postmortem se sale de control y se vuelve una batalla campal.
- Todo lo recapitulado en un postmorten debe ser parte de un cierre de ciclo y plasmarlo en…
Lecciones aprendidas
Que es como la biblia de la empresa u organización, es el documento en ese repositorio que todos deberían tener y es el equipaje que la empresa carga de todas las malas y buenas decisiones tomadas.
Somos el único bicho que vuelve a tropezar dos veces con la misma piedra y recordar nuestros errores nos hace posiblemente evitarlos en el camino venidero, este documento siempre debe ser visible para todos.