Estaba hoy leyendo este artículo en el que hablan de cuándo y cómo hacer pre-mortems con equipos de producto. Y, aunque creo que un buen pre-mortem puede hacerse de una forma bastante menos compleja de la que la autora sugiere, comparto su definición del pre-mortem como una herramienta del equipo para intentar anticiparse al error y mitigar riesgos.
Many engineering teams run post-mortems when there is a failure or error. The team needs to come together to discuss what went wrong and how to prevent it from happening again (not to assign blame or point fingers).
But what if we could anticipate and prevent these failures before they happen? Enter the pre-mortem. Pre-mortems are a powerful tool to increase the probability of a successful product launch and avoid difficult-to-recover failures.
Yue Zhao
A los pre-mortems a mi me gusta llamarlos hacer un “gafe time”. Es un nombre más divertido para el equipo y creo que se explica muy bien qué es lo que persigue una dinámica de este tipo:
- Anticiparte a analizar qué podría ir mal.
- Montar un plan para intentar prevenir que ese escenario suceda.
Un “gafe time” no es más que sentarte con el equipo a analizar con cierta profundidad todas las razones por las que el lanzamiento de una nueva funcionalidad, un nuevo producto, un refactor… podría ir mal.
Te pones en ese escenario en el que las cosas fallan y te pones a pensar en cómo las solucionarías de la manera más rápida y eficaz posible. Con eso, montas un plan que incluyes en la propia iniciativa.
Estamos más acostumbrados a los post-mortem que a los pre-mortem. Y eso no mola.
Las compañías en las que he trabajado siempre estaban bastante acostumbradas a hacer post-mortems, un análisis en el que cuando algo falla y siempre después de haberlo solucionado, intentas aprender de qué ha ido mal y reflexionas sobre cómo podrías evitar que vuelva a suceder una próxima vez.
Sin embargo, considero en demasiadas ocasiones evitamos hacer ese ejercicio de reflexión previo a un lanzamiento porque pecamos de optimistas o quizás sencillamente porque tenemos demasiado interiorizada esa cultura de “no blame”, de evitar la parálisis por análisis o de que está bien “aprender equivocándote”.
Y sí, lo comparto. Tenemos que poder equivocarnos en el trabajo y en la vida y saber que está bien. Pero si parte del trabajo de los perfiles de producto es mitigar riesgos y anticiparse a lo que puede ir mal ¿por qué no usar más los pre-mortems para ello?
¿Cuándo hacer pre-mortem?
Obviamente no te paras a hacer un pre-mortem con cada iniciativa que intentas mover. A mi hay algunos casos concretos en los que creo que aportan especial valor:
- Iniciativas que toquen piezas core del producto y que, de salir mal, puedan tener un alto impacto en operaciones (centenares de llamadas de clientes cabreados), churn de clientes y pérdida de ingresos.
- Iniciativas donde, que algo salga mal, sabes que significará tener muchos hotfixes y P0. Aquí entran las típicas iniciativas que suponen refactor de código importante, migración de servicios críticos, etc.
- Iniciativas que implican que varios equipos trabajen de forma coordinada. Si te esfuerzas en todo lo que puede ir mal, caerás en la cuenta de lo importante que es que todos los equipos estén bien sincronizados y pondrás mucho foco en hacer que suceda.
- Iniciativas con alta incertidumbre y donde hay ciertas dudas (del equipo o de stakeholders) de que se vaya a trabajar en lo correcto.
¿Cómo hacer pre-mortems?
No pretendo dar con una fórmula mágica. Siempre digo que soy poco de frameworks y mucho de entender cómo lo hacen otros pero crearte tu propia versión según el estado de tu empresa, la madurez de tu equipo o la fase en la que esté tu producto.
Pero por si te sirve, esta es la template que suelo utilizar yo.
Y tú ¿haces pre-mortems? ¿Cómo? ¡Cuéntame que seguro aprendo algo!
