Aprende de los errores ajenos: lee un postmortem

Aprende de los errores ajenos: lee un postmortem

Una competencia muy importantes en informática es la capacidad de aprender de los errores. No todos los proyectos acaban bien, no todas las decisiones son acertadas y no todos los productos acaban siendo un éxito.

En algunas ocasiones, el fracaso es inevitable. Puede ser que aparezca un imprevisto que no podía anticiparse (¿alguien se esperaba la pandemia de coronavirus?). O que se apueste por una tecnología que no se acaba imponiendo. Tal vez un cliente impone (contra nuestro criterio) un requisito incompatible con los objetivos del proyecto. O todo un clásico: que los recursos disponibles (presupuesto, personal o tiempo, entre otros) sean insuficientes para alcanzar los objetivos. Por otro lado, puede ser que un proyecto acabe de forma exitosa, pero se deba a una causa fortuita, un golpe de suerte o a una idea feliz.

No se aprende solo de los éxitos

Suele ser fácil encontrar información sobre los proyectos o productos exitosos en el sector TIC. Sin embargo, estos relatos suelen estar teñidos de un tono épico y heroico. La visión, ingenio y trabajo duro de ciertas figuras clave (generalmente, los que explican la historia en primera persona) ha permitido alcanzar el éxito y «todo ha salido como había planeado desde el principio» (menos un par de baches imprevistos para darle algo de emoción a la historia).

A pesar de la importancia de analizar los éxitos, no hay que caer en el survival bias: es muy importante revisar qué ha pasado con aquellos proyectos que no han salido adelante.

Aquí es donde entra en juego la filosofía «fail fast, fail often«, adorada (o muy odiada, según gustos del consumidor) por (una parte de) el sector del emprendimiento tecnológico. Las empresas que siguen esta filosofía son conscientes de la necesidad de explorar muchas ideas y evaluar su viabilidad rápidamente, tomando decisiones según las conclusiones obtenidas. Esto conlleva un proceso de revisión continua y de adaptación (pivoting) a la realidad del proyecto y del mercado. Además, muchas empresas suelen explicar públicamente este proceso de «pivoting«: nunca antes había sido posible contemplar con tanto lujo de detalle las pifias ajenas. Diríase que las empresas se enorgullecen y presumen de sus errores para mostrar cuán ágiles son y cómo se adaptan a una realidad cambiante. Vale, quizás tienen que justificar ante sus inversores y clientes por qué han dejado de hacer X y ahora harán Y.

Tanto en los éxitos como en los fracasos, es importante extraer conclusiones sobre qué ha ido bien y qué ha ido mal para no volver a tropezar con la misma piedra. En las organizaciones, este ejercicio de reflexión debería formar parte del ciclo de vida de los proyectos. Diferentes metodologías lo incluyen en diferentes etapas del desarrollo, ya sea como un proceso recurrente (la retrospectiva SCRUM) o como respuesta a un incidente como un fallo, un problema de seguridad o una pérdida de disponibilidad (el postmortem).

Postmortem para aprender: War Stories de Ars Technica

Leer un postmortem es un ejercicio divertido y muy educativo. Su objetivo no es encontrar culpables sino entender las causas de un problema y las soluciones. Desde este entrada os recomendamos la serie de vídeos «War Stories» del portal Ars Technica. En esta serie, los desarrolladores de los videojuegos más populares hablan sobre sus éxitos y fracasos. Por ejemplo:

  • Lord British (creador de la saga Ultimaexplica el ingente trabajo invertido en crear una ecología realista para el juego Ultima Online. ¿El problema? No anticiparon las ansias asesinas de los jugadores, que mataban cualquier animal que se cruzaba en su camino. Es difícil mantener un equilibrio entre depredadores y presas cuando no quedan animales vivos.
  • Jordan Mechner (el creador del Prince of Persia original)  explica cómo tuvo que introducir el combate en el juego en una fase avanzada del desarrollo. Esta decisión de última hora causó muchos problemas de gestión de memoria: ¡no quedaba espacio libre!

Limitaciones tecnológicas, un código con demasiados errores, un calendario imposible… todos podemos sentirnos identificados con alguno de estos episodios. Desde aquí os los recomiendo.

Robert Clarisó es profesor en los Estudios de Informática, Multimedia y Telecomunicación de la UOC.

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.