«¿Alguien ve algún riesgo?» suele dar lugar a una conversación breve y una respuesta tranquilizadora. Un premortem de proyecto plantea una pregunta más concreta: «Imaginemos que el proyecto ya ha fracasado. ¿Qué ha ocurrido?». Ese cambio de perspectiva permite examinar una historia específica cuando todavía hay tiempo de modificar el plan.
El taller debería traducirse en unos pocos cambios en el proyecto: un supuesto que comprobar, una medida de protección que añadir, una señal de alerta que vigilar o un compromiso que renegociar.
Cuándo realizar un premortem de proyecto
Realiza el ejercicio cuando ya exista un plan reconocible, pero antes de asumir compromisos costosos o difíciles de revertir. Un despliegue, una migración, un evento o un lanzamiento entre varios equipos pueden ser buenos candidatos. Si el proyecto cambia de forma importante, vuelve sobre los riesgos afectados en lugar de repetir mecánicamente todo el taller.
Un premortem mira hacia el futuro a través de un fracaso imaginado. Una retrospectiva examina trabajo que ya ha ocurrido. Un registro de riesgos reúne y permite seguir los riesgos a lo largo del tiempo. El taller puede aportar información a ese registro, pero no sustituye las pruebas técnicas, la revisión de contratos ni los análisis de seguridad especializados.
La dinámica premortem de Atlassian utiliza la generación individual de ideas, el debate y las acciones con responsable para explorar los riesgos de un proyecto. El formato siguiente aplica ese enfoque general a un lanzamiento y presta especial atención a las señales de alerta temprana.
Describe un fracaso que el equipo pueda imaginar
Evita «El proyecto salió mal». Define un horizonte temporal y un resultado que importe. Para una migración de atención al cliente, prueba con esto: «Ha pasado un mes desde el despliegue. Los clientes siguen escribiendo a los buzones antiguos, los agentes no encuentran las conversaciones previas y el equipo ha vuelto al sistema anterior».
Es un escenario hipotético para el ejercicio, no un pronóstico. Proporciona un punto de partida común sin dictar a los participantes qué causas deben proponer. Un escenario limitado a «incumplimos la fecha» puede dejar fuera un proyecto que se lanza a tiempo, pero no responde a las necesidades de sus usuarios.
Comparte con antelación el plan actual del proyecto (en inglés), el resultado esperado y las restricciones conocidas. Invita tanto a quienes ejecutan el cambio como a quienes tendrán que trabajar con él. En la migración de soporte, los agentes y administradores pueden detectar formas de fracaso que el patrocinador del proyecto no ve.
Dirige el taller sin convertirlo en una discusión defensiva
Empieza aclarando que la crítica se dirige al plan, no a la competencia de sus autores. Pide a todos que escriban posibles causas por separado y que dediquen una nota a cada causa. Los responsables de mayor rango deberían esperar a que los demás hayan participado antes de plantear su explicación preferida. De lo contrario, el tablero puede convertirse en una lista de razones que respaldan la primera opinión de una persona con autoridad.
Lee las notas antes de agruparlas. «La formación no se ha completado» y «los agentes no saben responder a preguntas poco habituales» pueden estar relacionadas, pero no son lo mismo. La primera se refiere a la asistencia; la segunda, a la capacidad. Unirlas demasiado pronto puede hacer que se pierdan detalles sobre los que sí se puede actuar.
Para cada grupo, pregunta cómo se produciría el fracaso. Sustituye «mala comunicación» por una secuencia como esta: «La nueva dirección de contacto solo se anuncia en un boletín; los clientes reutilizan conversaciones antiguas; nadie revisa el buzón anterior después del cambio de sistema». Esa secuencia ofrece varios puntos en los que el equipo puede intervenir.
Ejemplo práctico: migrar un servicio de soporte
El siguiente tablero hipotético muestra cómo una historia de fracaso se convierte en decisiones. El equipo real añadiría los nombres y las fechas; los roles indicados son ejemplos de quién podría asumir cada responsabilidad.
| Posible causa | Señal de alerta temprana | Respuesta propuesta | Responsable por confirmar |
|---|---|---|---|
| El historial de conversaciones anteriores está incompleto | En una muestra de casos migrados faltan archivos adjuntos o enlaces | Contrastar casos representativos antes de aprobar el cambio de sistema | Responsable de la migración |
| Los clientes siguen utilizando los buzones antiguos | Los usuarios de la prueba piloto responden a conversaciones de correo anteriores | Preparar una vía de transición supervisada y mensajes claros para los clientes | Operaciones de soporte |
| Los agentes conocen la interfaz, pero no cómo resolver las excepciones | Los casos de práctica requieren repetidamente la intervención de un administrador | Ensayar casos poco habituales y definir una vía de escalado | Responsable de formación |
| La vuelta al sistema anterior está descrita, pero no es viable en la práctica | Nadie puede explicar cómo se conservarían las conversaciones nuevas | Probar el procedimiento de recuperación antes de aprobar el lanzamiento | Responsable técnico |
Observa que «la migración fracasa» es un resultado, no una causa. Del mismo modo, «supervisar el proyecto» no es una respuesta hasta que alguien concreta qué se va a observar y qué decisión se tomará después.
Prioriza sin fingir que conoces las probabilidades exactas
Valora las consecuencias, las evidencias de que el riesgo es plausible y hasta qué momento podría responder el equipo. Un riesgo fácil de revertir la semana que viene es distinto de otro que solo se hace visible después de un cambio irreversible. Si los participantes no tienen una base para estimar la probabilidad, márcala como desconocida en lugar de inventar un porcentaje preciso.
Una votación puede señalar preocupaciones que merece la pena debatir, pero no debería decidir por sí sola la respuesta final. Un especialista puede reconocer una forma de fracaso grave que recibe pocos votos porque nadie más la entiende. Pide que explique su razonamiento y deriva el asunto al experto adecuado.
Elige acciones proporcionadas a la decisión. Probar una muestra de la migración puede ser útil antes de aprobar un despliegue grande. Reescribir todos los materiales de formación podría ser un desperdicio si una breve sesión práctica revela primero que el problema principal son los permisos de acceso.
Distingue la prevención de la contingencia
Una acción preventiva reduce la probabilidad de un fallo o su impacto antes de que ocurra. Una contingencia define qué hará el equipo si se alcanza una condición determinada. Como prevención, el equipo de soporte puede contrastar los registros migrados antes del lanzamiento. Como contingencia, puede establecer las condiciones para aplazar el despliegue o restablecer el servicio.
La condición que activa la respuesta debe ser observable. «Si la situación pinta mal» obliga a negociar bajo presión. «Si durante el ensayo no se puede tramitar un tipo de caso obligatorio» da al responsable del lanzamiento algo concreto que evaluar. El umbral debe reflejar los requisitos del servicio del proyecto, no una cifra arbitraria copiada de un ejemplo.
Documenta las decisiones importantes en un registro de decisiones (en inglés), incluida la persona que puede aceptar el riesgo residual. El taller no debería transferir silenciosamente esa autoridad a quien facilita la reunión.
Mantén visibles las preocupaciones difíciles después de la sesión
Algunas personas pueden mostrarse reacias a cuestionar en grupo el calendario de un patrocinador. Ofrece una forma de aportar preocupaciones antes de la reunión y da seguimiento a los desacuerdos pendientes. No prometas anonimato si el método de recogida no lo garantiza.
Utiliza una matriz RACI si sigue sin estar clara la responsabilidad de una acción. En el tablero premortem, mantén una vista más sencilla: riesgo, señal, respuesta, responsable y fecha de la próxima decisión. Enlaza la tarea real de ejecución para no seguir el avance en dos lugares que compitan entre sí.
Abre Boardmix y coloca el escenario de fracaso de la migración de soporte en la parte superior del lienzo. Debajo, crea las cuatro columnas del ejemplo: Posible causa, Señal de alerta temprana, Respuesta propuesta y Responsable por confirmar. Mantén cada causa y su respuesta en la misma fila. Para el historial incompleto, conecta la comprobación fallida de los casos de muestra con una tarea de conciliación de datos a cargo del responsable de la migración. Antes de aprobar el cambio de sistema, revisa esa tarea y las demás señales pendientes. Si aún faltan archivos adjuntos obligatorios, el responsable del lanzamiento tendrá un motivo concreto para aplazarlo.
