Una de mis primeras experiencias cuando trabajaba con una empresa de desarrollo de software fue cuando un compañero de otra empresa me dijo que tenían un proceso de evaluación de los fracasos. En mi equipo hizo gracia porque, bueno, normalizar el tratamiento del fracaso da que pensar que es algo lo bastante habitual como para normalizarse. Lo cierto es que con un poco más de experiencia, y después de seguir cuestiones como el desarrollo de videojuegos me di cuenta de que esto era algo común y se llama Post-mortem. Lo cierto es que mi personalidad quizá un poco obsesiva me llevaba a revisar una y otra vez las cosas cuando salían mal. Esto creo que me ha hecho mejor en casi todo: mejor consultor, docente, cocinero y demás. Así que me dije, ¿por qué no aplicar esto en las AAPP y en los servicios y productos digitales?
¿Qué es un post mortem?
Un post mortem es una técnica de gestión de proyectos de software que se aplica a los cierres de proyectos. El término en sí mismo da una pista de su aplicación más frecuente o común, que es la de los fracasos. Un post-mortem es, generalmente, una revisión de la historia de un proyecto de software que acaba en un fracaso con la intención de descubrir qué ha generado problemas y cómo podemos evitarlos en el futuro.
Esto es una buena práctica en general. Es un lugar común cuando hablamos de que se aprende de los fracasos, pero, siendo un poco puntillosos, diría que lo que se aprende es de lo que se estudia de los fracasos. Es decir, esto de la locura de repetir lo mismo y esperar un resultado diferente (el fracaso serializado) es fruto de la ignorancia activa o pasiva de las causas de dicho fracaso.
Sin embargo, nos podemos ir más allá de los fracasos. Una persona puede aprender de lo que son fracasos y de lo que son éxitos. Por ejemplo, yo cuando cocino no me limito a pensar qué ha salido mal, sino por qué algo afecta al resultado final para bien. Digamos que si aplicamos una revisión de los proyectos solo a los fracasos, cometeremos menos errores, si los aplicamos a todos, también entendemos nuestros éxitos.
¿Por qué la eAdministración tiene que hacer post mortem de servicios públicos?
No vamos a negar que la eAdministración tanto en su vertiente interna como en los servicios digitales es una industria pujante, creciente y continua. En todo caso, pese a las múltiples iniciativas y cambios no siempre han sido exitosos. De hecho, en muchos, muchos, muchos casos los errores se repiten. En otros casos, las iniciativas de éxito acaban analizándose superfluamente con aspectos quizá necesarios pero no suficientes (como era el uso de «EL LIDERAZGO» a principios de década). Así que podríamos decir que los post mortem es necesario para:
- Entender todo lo que ha pasado en un proyecto. Cuando tenemos un proyecto, sobre todo con cierta complejidad o alargado en el tiempo, perdemos óptica de detalles que quizá no están muy presentes, pero que tienen influencia.
- Identificar dónde empezó a torcerse todo. Los proyectos tienen una parte muy importante de emociones y, generalmente, hay un punto de ruptura en el que el proyecto genera un estrés desproporcionado respecto a la carga real de trabajo. Esto no significa que las cosas se han torcido ahí, pero si que ahí ya el proyecto ha cambiado a una situación de crisis. Dar una revisión a la gestión de las emociones de un equipo es una manera de tener más aciertos y evitar errores en el futuro.
- Detectar el peso de las variables de un proyecto en el resultado. Cuando sabemos lo que hemos usado y qué papel ha jugado, podemos entender qué papel puede jugar en otros proyectos. Si, por ejemplo, vemos que todas las mañanas se lanza un correo de tareas pendientes para todo el equipo y eso ha facilitado tener a todo el mundo alineado, lo podemos incorporar a futuras iniciativas.
- Facilita la comunicación de las personas. Hablar sobre experiencias y sensaciones es gratificante, y ser escuchado mucho más. En las AAPP muchas veces esta ocasión no se tiene y eso genera climas negativos.
- Convierte el oficio en conocimiento. Documentar las causas y factores de éxito o fracaso convierte experiencias individuales en sabiduría colectiva.
¿Qué dificultades tiene hacer un post-mortem de servicios públicos?
Ahora bien, las AAPP tienen algunos factores que dificultan hacer un post mortem. Entre ellos destacaríamos:
- Cultura de equipos. En muchas organizaciones públicas es extremadamente complicado llegar a sentar todos los implicados en un proyecto o proceso y hablar sobre qué ha funcionado y qué no ha funcionado. Aspectos de verticalidad o de permanencia en la organización (en el sector privado la gente se mueve más que en el público) dificultan este diálogo fluido
- Aceptación de la crítica. Muchas veces los proyectos están demasiado asociados a personas como para que una reflexión sobre el éxito o el fracaso no se pueda ver como un ataque o alabanza personal.
- Falta de orientación a proyectos. En muchos casos, la administración no trabaja sobre proyectos lo que hace que se dificulte identificar resultados concretos. Un cambio con un proyecto define alcances y objetivos, pero si no lo hay es muy difícil saber qué ha ido bien y qué no más allá de impresiones.
- Lo que falla no es parte del proyecto. Otra cosa que pasa es que un proyecto acaba con éxito, pero muere al salir de la cuna. Falta de comunicación o de impulso, problemas de definición del público, abandono organizativo… son fracasos de facto pero que estructuralmente en la administración no caen dentro del proyecto y no se analizarían posiblemente.
- Falta de escalonamiento. Cuando escribo esto escucho en una entrevista al director del Washington Post diciendo que no plantea nuevos proyectos en español hasta que no evalúe los resultados de lo que ya tiene en marcha. En las AAPP muchas veces los proyectos se solapan, o no se entienden como proyectos, o se lanzan continuaciones sin que hayamos terminado algunos que podrían ayudarnos a centrar el tiro a futuro. Quizá, aunque Radar Covid siga en activo, habría que hacer un post mortem de su lanzamiento.
¿Cómo se hace un post mortem?
Hay múltiples artículos al respecto, como este de Juan M Sosa, muy centrado en videojuegos, o este de Martin M Marquez que incluye ideas sobre cómo hacer un cuestionario pero me quedo con este de Mike Gundelroy con 9 condiciones:
- Planificarlos de manera sistemáticamente. Hay que introducirlo como un anexo a cada proyecto
- Hazlos próximos en el tiempo, pero quizá no justo al terminar, sobre todo si las emociones son fuertes. Se trata de aprender, no de liarse a palos.
- Registra toda la información del proyecto para que la discusión sea sobre lo concreto y no sobre impresiones difusas.
- Implica a todo el mundo, no hay perfiles pequeños. Normalmente escribe una invitación explicando lo que se pretende y lo que se espera de cada persona.
- Escribe las conclusiones para ponerla a disposición de todo el mundo.
- Registra lo bueno y lo malo, y lo que puede haber contribuido a cada cosa. A veces un elemento puede influir a ambas partes.
- Deja claro que el objetivo es aprender, no ejercer ningún tipo de represalia
- Haz un plan de acción para compartirlo con el resto de la organización, especialmente aspectos muy extrapolables
- Ponlo a disposición de todo el mundo de manera permanente. Crear conocimiento tiene sentido si está siempre accesible.
Conclusión
Seguramente algunas de las personas que leeis esto ya lo hacéis. Por ejemplo, la metodología MIMOS que usamos en Innovación On Tour incluye una parte importante de revisión. En ese caso, posiblemente no tengáis mucho de aquí. Por otro lado, seguro que hay cientos de adaptaciones y peculiaridades para sacarle el mayor jugo a esta herramienta.
Puede que digáis, «no veo como hacer esto con un servicio que llega años funcionando«. En ese caso, plantead un pequeño proyecto para conseguir más uso, o una mejora, o un rediseño y aplicadlo. Siempre será una fuente de ideas y oportunidades para seguir.
En todo caso, desde luego, os animo a incorporar un post mortem a vuestros proyectos de servicios digitales, incluyendo, además cuestiones como la comunicación o la definición de públicos. Piensa que el post mortem no es solo de la herramienta, sino del conjunto del propósito que teníamos. Trabajamos con propósitos, no con distinciones metodológicas.
