El 8 de octubre de 2026, MIT News publicó un informe que describe el curso 6.C31, Hack Yourself, una iniciativa conjunta con el Experimental Study Group desarrollada por la profesora sénior de EECS Ana Bell, el instructor visitante de ESG Carter Jernigan y la profesora sénior de ESG Paola Rebusco. Según el informe, el instructor Carter Jernigan describe una práctica llamada premortem: un grupo imagina que un proyecto ya ha fracasado, enumera todo lo que pudo haber salido mal y trabaja hacia atrás para prevenir esos problemas. El artículo también señala que ninguna intervención única resultó ser universalmente la mejor, y no afirma un tamaño de efecto medido para los premortems específicamente.
El siguiente formato de reunión adapta esa idea a trabajos de clase en grupo: un informe compartido, una memoria de laboratorio, una presentación o un proyecto de construcción de un semestre. Estos pasos son sugerencias editoriales de IvyClaw, no orientación oficial del MIT. El informe no confirma el acceso al curso para estudiantes externos, y el ejercicio no promete mejores calificaciones. Adapten la reunión a la tarea, el tiempo disponible y las necesidades del equipo.
Por qué hacer un premortem en absoluto
Consideren algunos problemas posibles: alguien no puede asistir a las reuniones acordadas, dos personas redactan secciones que se solapan o limpiar los datos exige más tiempo del previsto. Son riesgos hipotéticos para discutir, no hallazgos sobre la frecuencia del fracaso de proyectos estudiantiles. Prueben a reservar entre treinta y cuarenta y cinco minutos al inicio. Es una duración orientativa; una tarea pequeña puede requerir menos conversación. El objetivo es identificar acciones mientras aún hay tiempo para ajustar el plan.
La pregunta cambia el tiempo verbal de la conversación: “Imaginen que hemos llegado a la fecha límite y el proyecto ha fracasado: ¿qué salió mal?”. Traten la respuesta como un relato hipotético, no como una predicción. Inviten a expresar preocupaciones sobre el plan sin convertirlas en críticas personales. Si el enfoque incomoda a alguien, expliquen su propósito y acuerden una formulación que todo el equipo pueda usar.
Paso uno: escribe un escenario de fracaso específico
Antes de la reunión, el líder del equipo o quien convocó la reunión de arranque escribe un único escenario de fracaso concreto y lo envía a todos. Las consignas vagas producen listas vagas. "El proyecto va mal" es inútil. "Faltan dos días para la fecha límite y el informe final carece de su sección de análisis porque la limpieza de datos tomó tres semanas en lugar de una" es útil, porque apunta a una causa sobre la que puedes actuar.
Mantén el escenario en dos o tres frases. Nombra el momento de la fecha límite, el síntoma visible y una cadena de eventos plausible. No estás intentando predecir el futuro; estás dando al equipo un objeto compartido al que reaccionar. Si tu curso tiene múltiples entregables, puedes hacer el ejercicio una vez por entregable principal, pero para un primer intento, un escenario es suficiente.
Paso dos: recopila causas de forma independiente y luego compara
Antes de que alguien hable, ofrezcan cinco minutos tranquilos para que cada persona anote posibles causas. Así todos pueden aportar una primera perspectiva antes de escuchar las demás. Permitan respuestas escritas u otro formato accesible si leer en voz alta resulta difícil. El ejercicio necesita preocupaciones diversas, no una competición por hablar con más seguridad o presentar la lista más larga.
Para empezar, pidan varias causas, incluidas las menos llamativas: conflictos de horarios, reparto poco claro, dependencia de una respuesta del docente, versiones incompatibles o una persona que asume la redacción mientras las demás esperan instrucciones. Recojan las aportaciones en un documento compartido y discútanlas después. Las preocupaciones repetidas merecen atención, pero su frecuencia no determina por sí sola su importancia; una cuestión planteada por una sola persona también puede poner en riesgo todo el proyecto.
Paso tres: elige tres riesgos accionables
En lugar de abordar todas las posibilidades a la vez, comiencen con tres riesgos plausibles que puedan afectar seriamente la entrega y admitan una respuesta práctica. Tres es un límite sugerido, no un óptimo demostrado. No pueden controlar un cambio de rúbrica, pero sí acordar quién revisa los avisos oficiales y pregunta por requisitos poco claros. Distingan el acontecimiento externo de la acción que el equipo puede adoptar.
Revisen especialmente las dependencias: tareas que deben seguir un orden o requieren algo externo. Por ejemplo, acceso a datos, aprendizaje de una herramienta, comentarios del docente o reserva de un espacio autorizado. Pregunten qué tareas posteriores se detendrían si cada dependencia se retrasara. Marquen el acceso sin confirmar como tal y consideren una alternativa que siga cumpliendo la tarea, en vez de dar por hecho que el recurso llegará.
Paso cuatro: asigna un responsable, un paso de prevención y una alerta temprana
Para cada uno de los tres riesgos, registra tres cosas en el documento compartido: un responsable (una persona con nombre, nunca "todos"), un paso de prevención y una señal de alerta temprana. El responsable no hace todo el trabajo; el responsable rinde cuentas por vigilar ese riesgo y plantearlo.
Este es un ejemplo hipotético de planificación, no un caso estudiantil: riesgo — limpiar los datos lleva más tiempo del previsto. Responsable — la persona elegida para coordinar las comprobaciones. Prevención — cargar una muestra autorizada y documentar problemas antes del siguiente punto acordado. Alerta — la muestra no se carga, falta un campo obligatorio o la revisión no termina a tiempo. Respuesta — discutir el obstáculo y consultar al docente antes de cambiar el alcance exigido. Elijan umbrales adecuados a sus datos; “unas pocas filas incorrectas” no es una prueba universal.
Otro ejemplo hipotético: riesgo — dos miembros redactan secciones solapadas. Responsable — quien coordina el esquema. Prevención — compartir un plan de una página antes de redactar y pedir que todos confirmen sus tareas. Alerta — una sección sigue sin asignar en el punto acordado o dos borradores cubren el mismo contenido. Respuesta — resolver juntos el solapamiento y actualizar el esquema. El equipo debe acordar los nombres y fechas reales en su propio documento.
Paso cinco: acuerden cuándo revisarlo
Un documento de premortem que nunca se vuelve a abrir es teatro. Al final de la reunión, acuerden un disparador de revisión específico y escríbanlo. Dos opciones posibles: un punto de control fijo, como los primeros diez minutos de cada segunda reunión del equipo, o un disparador de evento, como que se active cualquier alerta temprana. También decidan dónde vivirá el documento — la misma carpeta compartida que sus borradores — y quién pega los tres riesgos en la agenda de la reunión cada vez.
Finalmente, respeta las reglas reales de tu curso. Si la tarea requiere la aprobación del instructor de los roles del equipo o de los hitos, canaliza tu plan a través de ese proceso. Un premortem complementa los requisitos de tu curso; nunca los reemplaza.
Tu próxima acción
En la próxima reunión de inicio, prueben la secuencia de una vez: envíen un escenario concreto, ofrezcan tiempo tranquilo para listar causas, recojan las preocupaciones de todos, elijan tres riesgos abordables y anoten un responsable, una medida preventiva y una alerta observable para cada uno. Antes de terminar, acuerden la primera revisión y dónde estará el registro. Salgan con unas pocas decisiones que el equipo pueda utilizar.
Resumen en chino
El 8 de octubre de 2026, MIT News describió el premortem en un reportaje sobre el curso 6.C31, Hack Yourself: imaginar que el proyecto ha fracasado, enumerar posibles causas y considerar medidas preventivas. El formato propuesto aquí para trabajos en grupo es una sugerencia editorial: listar causas de forma independiente, discutir dependencias, elegir tres riesgos abordables y acordar para cada uno un responsable, una medida preventiva y una alerta observable; después, fijar una revisión. Las cantidades y duraciones son puntos de partida, no óptimos demostrados. El plan debe respetar las reglas del curso y no garantiza eliminar riesgos ni mejorar las calificaciones.