No se puede dar por acabado un proyecto de software hasta que no se haya redactado su postmortem.
Gracias a los chicos de Vidaextra, he podido conocer la práctica del postmortem, una retrospectiva global y pública con el objetivo de aprender de los errores propios e intentar que otros no los cometan. Pura transparencia y altruismo.
El postmortem se ha limitado casi exclusivamente al sector de los videojuegos, donde se hacen algunos de los desarrollos más complicados y estresantes del mundo. Desarrollos con cientos de personas involucradas, continuos cambios de requisitos y backlogs inestables. Sin embargo, creo que sería muy sano para la industria en general que esta práctica se generalizara y se normalizara.
El postmortem es un documento en el que el equipo de desarrollo escribe las cinco decisiones o circunstancias que más ayudaron a concluir con éxito un proyecto informático y las cinco cosas que más lo perjudicaron.
Se diferencia de una retrospectiva normal en que produce un artefacto formal, un documento escrito, y en que este suele hacerse público para que otros desarrolladores puedan aprender de nuestros aciertos y errores, éxitos y fracasos.
Todos los que han estado involucrados en el proyecto pueden contribuir al documento: desarrolladores, diseñadores, equipo de QA, gestores, product owners y scrum masters.
¿No había suficiente presupuesto? ¿El equipo no tenía el conocimiento técnico necesario? ¿Existía una alternativa previa y más interesante en el mercado? No hay nada que no se pueda incluir y documentar.
No se puede dilatar la redacción del postmortem ya que los seres humanos tendemos a descartar los malos recuerdos y a recordar sólo los buenos. Un buen postmortem debe escribirse inmediatamente después de concluir el proyecto y sin verse afectado por el éxito o fracaso del mismo. Al fin y al cabo, estamos hablando de proceso, no de producto.
[no_blockquote text=»yo no quiero trabajar con los que luchan por ser los mejores, sino con los que intentan crear el mejor producto» text_color=»» title_tag=»h2″ width=»» line_height=»» background_color=»» border_color=»» show_quote_icon=»yes» quote_icon_color=»» quote_icon_size=»»]
Pero ¿por qué escribir un postmortem? ¿Por qué hacer públicos nuestros propios errores? Primero, como un ejercicio de catarsis interna del equipo de desarrollo, un grupo de personas que han estado trabajando, codo con codo, con un único fin: conseguir acabar con éxito un proyecto o un producto.
Segundo, como una inmejorable oportunidad para construir nuestro curriculum. Internet está lleno de casos de éxito. Pero, he descubierto que respeto mucho más a los desarrolladores que tienen la sabiduría necesaria para reconocer sus propios errores y la valentía suficiente para hacerlo en público.
No sé lo que buscan otras personas, pero yo no quiero trabajar con los que luchan por ser los mejores, sino con los que intentan crear el mejor producto.
[quote]Escribir un postmortem no es un proceso placentero. La autocrítica sincera nunca lo es.[/quote]
No creo que escribir un postmortem sea un proceso placentero. La autocrítica sincera nunca lo es. Sin embargo, los más interesantes y de los que más se suele aprender son los que pertenecen a proyectos fallidos o sonados fracasos, como Tabula Rasa.
Cuando trabajaba en Sixservix, participé en el desarrollo de algunos de los proyectos de software más ambiciosos de este país. Hice algunas cosas buenas pero, sobre todo, hice muchas malas. Estoy seguro de que más de uno se hubiera ahorrado los mismos errores si hubiera podido leerlos.
A partir de ahora, intentaré escribir postmortems públicos de todos los proyectos en los que participe. ¿Y a vosotros? ¿Os gustaría hacer lo mismo?
BOLA EXTRA!