Describe un proyecto y Joy corre un pre-mortem: imagina que el lanzamiento ya fracasó, trabaja hacia atrás para sacar a la luz los modos de fallo probables, los ordena por probabilidad e impacto, y te da una señal de alerta temprana y una solución concreta para cada uno, para que cierres las brechas antes de construir.
Haz un pre-mortem de nuestro [nuevo despliegue de capacitación de cumplimiento que lanza en el T3] y señala los mayores riesgos.
Un ejemplo ilustrativo: tu resultado dependerá de tus fuentes, datos y peticiones.
Asumí que el despliegue ya había fracasado y trabajé hacia atrás, usando tu plan del proyecto y la retro del despliegue del año pasado en el Knowledge Center para basar cada riesgo. Aquí está la lectura ordenada, con los dos que destacan señalados.
Imaginé que es fin del T3 y el despliegue salió mal, luego trabajé hacia atrás desde ese fracaso usando tu plan del proyecto, la retro del despliegue del año pasado y el mapa de stakeholders en el Knowledge Center. Seis modos de fallo explican la mayoría de las formas en que podría salir mal. Puntué cada uno como probabilidad × impacto en una escala de 1–5, así que el puntaje de riesgo va de 1 a 25. Dos están muy por delante del resto: baja finalización antes de la fecha límite (20) y contenido desactualizado frente a la regulación actual (16). Ahí es donde pondría tu atención primero.
Puntaje de riesgo por modo de fallo (probabilidad × impacto, 1–25)
Baja finalización antes de la fecha límite — puntaje 20. Probabilidad alta (5), impacto alto (4). La retro del año pasado muestra la finalización estancándose cerca del 61% a dos semanas del cierre, y esta cohorte es más grande. Si la cifra de la semana dos está por debajo de aproximadamente 50%, trátalo como el fracaso ya en curso. La solución es escalonar la asignación por equipo con un checkpoint duro a mitad de trimestre y darle a cada gerente una lista semanal de finalización de sus propios reportes.
Contenido desactualizado frente a la regulación actual — puntaje 16. Probabilidad alta (4), impacto alto (4). La política fuente se revisó por última vez antes del cambio de norma más reciente, así que el curso podría enseñar un requisito superado. La señal que hay que vigilar es que no haya visto bueno de cumplimiento en el guion final; la solución es una revisión legal y de cumplimiento con fecha antes del congelamiento del build en lugar de después del lanzamiento.
El ranking completo, con una señal de alerta temprana y una mitigación concreta para cada uno, está abajo.
| Riesgo | Probabilidad | Impacto | Señal de alerta temprana | Mitigación |
|---|---|---|---|---|
| Baja finalización antes de la fecha límite | Alta | Alto | Finalización de la semana dos por debajo de aproximadamente 50% | Escalonar la asignación por equipo con un checkpoint duro a mitad de trimestre, y darle a los gerentes una lista semanal de finalización de sus propios reportes |
| Contenido desactualizado frente a la regulación actual | Alta | Alto | Sin visto bueno de cumplimiento en el guion final | Conseguir una revisión legal y de cumplimiento con fecha del contenido antes del congelamiento del build, no después del lanzamiento |
| Falta de respaldo de gerentes | Alta | Medio | Gerentes que no reenvían la nota de kickoff a sus equipos | Informar primero a los gerentes y entregarle a cada uno un guion de dos líneas más la lista de su propio equipo |
| Retrasos de traducción y localización | Alta | Medio | Archivos localizados sin regresar para el congelamiento del build | Fijar el texto fuente temprano y correr la localización en paralelo con el build, no después de él |
| Problemas de acceso a LMS y SSO | Media | Medio | Fallos de inicio de sesión del grupo de prueba en staging | Correr una prueba de humo de SSO con un pequeño grupo piloto a dos semanas del cierre |
| La fatiga de encuestas sesga la retroalimentación | Media | Bajo | Respuesta a la encuesta post-curso por debajo de aproximadamente 20% | Mantener la encuesta en tres preguntas e integrarla al final del último módulo |
Si endureces dos cosas antes de construir, que sean el plan de finalización y el visto bueno de cumplimiento — juntos cargan los dos puntajes más altos. Los cuatro más bajos (respaldo de gerentes en 15, retrasos de localización en 12, acceso a LMS y SSO en 9, y fatiga de encuestas en 6) cada uno merece una mitigación pero no debería frenar el lanzamiento.
¿Quieres que convierta el riesgo principal en una lista de responsables y acciones, o que redacte el plan de mitigación completo para uno de estos riesgos?
Pre-Mortem de Proyecto le da la vuelta al post-mortem. Describes el proyecto, y Joy asume que ya fracasó, luego trabaja hacia atrás para nombrar las formas específicas en que eso podría pasar. Ordena cada modo de fallo por probabilidad e impacto, señala la señal de alerta temprana que hay que vigilar, y la empareja con una mitigación concreta, para que las brechas sean visibles mientras todavía puedes actuar sobre ellas.
Dile a Joy qué vas a lanzar, cuándo y para quién. Apúntala hacia el plan del proyecto, las retros pasadas y el mapa de stakeholders en tu Knowledge Center para que los riesgos se basen en tu contexto real.
Pídele a Joy que asuma que el proyecto fracasó y trabaje hacia atrás. Usa el comando /analyze o simplemente describe lo que necesitas. Saca a la luz los modos de fallo probables y puntúa cada uno por probabilidad e impacto.
Joy devuelve una tabla de riesgos ordenada con una señal de alerta temprana y una mitigación para cada uno, además de una gráfica de los puntajes de riesgo para que los dos primeros sean obvios. Cuestiónala o agrega contexto y vuelve a ordenar.
Copia la tabla de riesgos y las mitigaciones en tu documento del proyecto, tu deck de kickoff o tu bitácora RAID. Joy saca los riesgos a la luz; tú decides para cuáles construir salvaguardas.
Guarda esta petición como un comando personalizado en el asistente que tu equipo ya usa, para que cualquiera pueda ejecutarla en un solo paso.
En lugar de una lista de verificación de riesgos genérica, Joy asume que el proyecto fracasó y razona hacia atrás sobre las formas específicas en que pudo pasar, para que la lista sea sobre tu proyecto, no cualquier proyecto.
Cada riesgo recibe una calificación de probabilidad e impacto y un puntaje de 1–25, para que la prioridad sea obvia a simple vista en lugar de una lista plana que discutir.
Cada riesgo viene con la señal concreta que hay que vigilar, para que sepas cuándo un riesgo se está convirtiendo en el fracaso mientras todavía hay tiempo de actuar.
Joy empareja cada riesgo con una mitigación específica que puedes dejar directamente en el plan, no un vago 'monitorear de cerca'.
Córrelo en una nueva política o cambio de proceso para sacar a la luz los riesgos de adopción y comunicación antes de anunciarlo.
Apúntalo hacia una migración de LMS o plataforma para atrapar los riesgos de acceso, datos y tiempos antes del cutover.
Pon a prueba el plan de L&D del próximo año antes de comprometer el presupuesto, para que los supuestos frágiles salgan temprano.
Somete a estrés una fecha límite de certificación o cumplimiento para ver dónde se concentran los riesgos de finalización y contenido.
Un pre-mortem es un ejercicio de planeación en el que imaginas que un proyecto ya fracasó y trabajas hacia atrás para nombrar las razones. Saca a la luz los riesgos antes que una revisión de riesgos normal porque asumir el fracaso hace más fáciles de ver los puntos débiles. Joy corre el ejercicio sobre tu proyecto y devuelve una lista ordenada de modos de fallo con señales de alerta y soluciones.
Un post-mortem ocurre después de que un proyecto termina y explica qué salió mal. Un pre-mortem ocurre antes de construir, mientras todavía puedes cambiar el plan. Esta receta corre el pre-mortem, para que las brechas salgan lo bastante temprano como para cerrarlas.
No. Es un análisis bajo demanda. Lo corres cuando ayuda (antes del kickoff, antes del congelamiento del build, antes del lanzamiento) y Joy lee el plan actual y devuelve una lectura fresca. No hay un tablero permanente que mantener al día.
Joy califica cada riesgo en probabilidad e impacto y los multiplica en un puntaje de 1–25, luego ordena la lista por ese puntaje. La gráfica y la tabla muestran las calificaciones para que veas el razonamiento, ajustes los supuestos y le pidas a Joy que vuelva a ordenar.
Sí. Joy puede redactar una lista de responsables y acciones para el riesgo principal, o un plan de mitigación más completo para cualquier riesgo, como texto en el chat. Tú lo copias en tu documento del proyecto, bitácora RAID o deck de kickoff. Joy redacta el plan; no asigna responsables ni le da seguimiento al trabajo por ti.
Únete a la lista de espera y sé de los primeros en probar este flujo de trabajo cuando JoySuite se lance.