Realizar un análisis premortem de un proyecto

Autor: AILesson7 min de preparaciónProbado con:ChatGPTRevisado el: 2026-08-28

Respuesta rápida

Imagina un resultado fallido para revelar causas plausibles, señales débiles, pruebas y acciones preventivas. Proporciona: Proyecto y fecha del fracaso, Pruebas y supuestos, Participantes y autoridad para actuar. Resultado esperado: Un mapa priorizado de escenarios de fracaso con pruebas, indicadores, responsables y experimentos inmediatos.

1

Añade tu contexto

Tu texto permanece en este navegador. AILesson Prompts no lo envía a un modelo ni a un servidor.

2

Tu prompt

Los campos sin rellenar permanecen visibles como marcadores de posición, para que puedas copiar y editar el prompt

Realiza un análisis premortem del proyecto utilizando el contexto proporcionado.

Proyecto, usuarios, plan, objetivo y definición concreta del fracaso:
[project]

Restricciones, dependencias, incidencias, estimaciones, discrepancias e incógnitas:
[assumptions]

Perspectivas de los participantes, autoridad, capacidad de mitigación y momento de revisión:
[participants]

Supón que el proyecto ha fracasado en el momento futuro indicado y genera explicaciones distintas y plausibles en relación con el valor para el usuario, el alcance, la entrega, la calidad, las operaciones, las personas, los proveedores, la gobernanza, la seguridad, la accesibilidad, los datos y el contexto externo, pero solo cuando sean relevantes. Separa las preocupaciones respaldadas por pruebas de las hipótesis. Evita las catástrofes genéricas, la búsqueda de culpables y la certeza retrospectiva. Agrupa las causas en cadenas causales, identifica los indicadores observables más tempranos y ordénalas según su plausibilidad y daño con una justificación explícita, sin inventar precisión. Para los escenarios principales, proporciona una prueba barata, una medida preventiva, un desencadenante para activar la contingencia, una respuesta, un responsable explícito o «Sin asignar» y una fecha límite de decisión. Incluye escenarios contrarios a la intuición y fortalezas que reduzcan el riesgo.
Probar en Playground
Privado de forma predeterminadaLa preparación del prompt se realiza localmente en tu navegador. Evita introducir información confidencial en cualquier servicio de IA, a menos que tu organización lo permita.

De la entrada al resultado

Un ejemplo completo

Mira cómo un contexto concreto convierte esta receta en un resultado que puedes usar

Entrada real

Proyecto y fecha del fracaso
En marzo, una organización benéfica regional lanza un portal en línea para programar los turnos de 600 voluntarios y 40 coordinadores. El 30 de junio, se considerará un fracaso si los coordinadores siguen manteniendo hojas de cálculo paralelas, si se disputa más del 10% de los turnos programados o si menos del 50% de los voluntarios activos utiliza el portal cada mes. El piloto comienza con dos equipos en febrero.
Pruebas y supuestos
Muchos voluntarios utilizan el teléfono; el 18% de los registros actuales carece de una dirección de correo electrónico única. Los coordinadores usan nombres distintos para los turnos. El proveedor afirma que admite la importación de CSV, pero no ha probado nuestro archivo. El presupuesto de formación cubre dos sesiones en directo. A un coordinador le preocupa que los voluntarios no vean los avisos de cancelación. La autenticación usa enlaces por correo electrónico. Todavía no existen una prueba de accesibilidad, un turno de asistencia ni una regla para retirar las hojas de cálculo.
Participantes y autoridad para actuar
En el taller participan un coordinador de voluntarios, un representante de los voluntarios, el responsable de operaciones con autoridad para el lanzamiento, el responsable de datos, el responsable de comunicación y un especialista del proveedor. Quedan dos semanas-persona para la mitigación. Las decisiones se revisarán el próximo martes.

Ejemplo de salida

Historia de fracaso A—identidad e importación fragmentadas: el 18% sin correo electrónico único, junto con la importación de CSV sin probar, provoca cuentas duplicadas o ausentes; los voluntarios no pueden autenticarse; los coordinadores conservan las hojas de cálculo; aumentan las disputas. Respaldado por pruebas. Primeros indicadores: tasa de excepciones en la importación, cuentas duplicadas e inicios de sesión fallidos. Prueba barata: importar un archivo representativo desidentificado e intentar iniciar sesión por teléfono con registros que carezcan de correo electrónico o lo tengan duplicado. Prevención: definir cómo se corregirá la identidad y conciliar los recuentos antes del piloto. Responsable: responsable de datos para la prueba; responsable de la política de identidad Sin asignar. Decisión antes del próximo martes.

B—definiciones de turnos incoherentes: los distintos nombres se asignan de forma incorrecta, lo que genera horarios disputados y registros paralelos. Respaldado por pruebas. Probar una taxonomía común con los dos equipos piloto y conciliar todos los turnos importados. C—las cancelaciones fallan en las operaciones: los usuarios de enlaces por correo electrónico pueden no ver los avisos; no existe un turno de asistencia ni una regla de confirmación de avisos. La preocupación es explícita, pero el mecanismo del resultado es parcialmente hipotético. Probar la entrega y apertura, además de cinco recorridos de tareas con voluntarios; definir una vía alternativa urgente y su responsable. D—la adopción parece aceptable mientras los coordinadores mantienen hojas de cálculo paralelas; fracaso de gobernanza contrario a la intuición. Indicador: las ediciones continúan después del cambio. Definir antes del lanzamiento un criterio de retirada y un registro de excepciones.

Otras hipótesis: la accesibilidad móvil impide completar las tareas; dos sesiones no llegan a quienes trabajan por turnos; los defectos del proveedor superan las dos semanas-persona. Fortalezas: piloto escalonado con dos equipos, autoridad de lanzamiento identificada, perspectiva de los voluntarios y umbrales de fracaso medibles. Priorizar A/B antes del piloto porque comparten una base de datos, pero requieren comprobaciones de aceptación independientes.

Por qué funciona

  1. 1

    La retrospectiva prospectiva ayuda a los equipos a nombrar causas de fracaso que la planificación optimista suele reprimir.

  2. 2

    Los indicadores y las pruebas baratas convierten el fracaso imaginado en pruebas capaces de cambiar el plan.

Comprueba el resultado

  • ¿Los escenarios son específicos de este proyecto y están vinculados a las pruebas proporcionadas o identificados como hipótesis?

  • ¿Los escenarios principales incluyen indicadores tempranos, pruebas baratas, desencadenantes y respuestas viables?

  • ¿El resultado evita la culpabilización, las probabilidades falsas y la formulación duplicada de una misma cadena causal?

Úsalo con confianza

Preguntas frecuentes

Respuestas prácticas sobre cuándo usar esta receta, qué debes proporcionar y en qué casos la revisión humana sigue siendo importante

¿Qué debo preparar antes de usar «Realizar un análisis premortem de un proyecto»?

Para «Realizar un análisis premortem de un proyecto», prepara el Proyecto y fecha del fracaso, las Pruebas y supuestos y los Participantes y autoridad para actuar. Sustituye los marcadores de posición únicamente con información que puedas verificar. Si desconoces algún dato, conserva explícitamente esa incertidumbre en vez de pedir al modelo que lo deduzca.

¿Cuándo no está listo para usar el resultado de «Realizar un análisis premortem de un proyecto»?

El resultado no está listo si todavía no ofrece, a partir de las pruebas proporcionadas, el resultado declarado: un mapa priorizado de escenarios de fracaso con pruebas, indicadores, responsables y experimentos inmediatos; tampoco lo está si depende de suposiciones sin resolver, aprobaciones pendientes o detalles inventados. Usa las comprobaciones como criterios de aprobación: revisa los datos de origen o asigna una persona revisora identificada y autorizada, en vez de pulir un resultado sin respaldo.

¿Qué herramientas de IA tienen pruebas registradas para «Realizar un análisis premortem de un proyecto»?

El registro de pruebas publicado para «Realizar un análisis premortem de un proyecto» incluye ChatGPT a fecha de 2026-08-28. Esto confirma ejecuciones registradas, no garantiza la compatibilidad ni resultados idénticos en versiones posteriores del producto. Si usas otra herramienta o versión, mantén visibles todas las restricciones y repite las comprobaciones del resultado antes de usarlo.

Más formas de explorar

Dónde encaja esta receta

Mantén el trabajo en marcha