La evidencia antes que la explicación

1943. Identidad de la lección

Módulo

4.16 — Postmortems

Lección

La evidencia antes que la explicación

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1

Tiempo estimado

35–45 minutos, incluida la práctica

1944. Objetivo de aprendizaje

Después de esta lección, podrás organizar un incidente de un proyecto estudiantil en una línea de tiempo basada en hechos, una descripción del impacto, condiciones contribuyentes y una hipótesis de causa raíz, señalando las suposiciones y las preguntas aún sin resolver.

1945. Por qué es importante

Un postmortem solo sirve si ayuda al equipo a tomar una mejor decisión sobre su proceso o su juego. Si empiezas con un relato presentado con excesiva certeza, puedes atribuir culpas en lugar de registrar evidencia y corregir un síntoma en vez de la condición que permitió el incidente. Separar con claridad los hechos, las suposiciones y las hipótesis proporciona material que una persona o un colaborador de IA puede verificar. Así, un fallo confuso se convierte en un aprendizaje reutilizable.

1946. Conocimientos previos

Debes haber completado 4.15 — Presupuestación, incluida Construir un presupuesto listo para decidir. Debes poder distinguir entre un resultado observado del proyecto y una previsión, una suposición o una decisión. No necesitas conocer ningún incidente específico de CONTRABAND para esta lección.

1947. Concepto central

Un postmortem debe avanzar desde lo que se observó hacia lo que resultó afectado, después hacia las condiciones que contribuyeron y, por último, hacia una hipótesis de causa raíz que todavía pueda comprobarse.

Cada categoría responde a una pregunta diferente:

• Línea de tiempo: ¿Qué ocurrió y cuándo?
• Impacto: ¿Qué cambió para el jugador, el proyecto, el equipo o la decisión?
• Condiciones contribuyentes: ¿Qué circunstancias hicieron más probable o más costoso el incidente?
• Causa raíz: ¿Qué condición subyacente, si se cambiara o controlara, probablemente evitaría que se repitiera?

La causa raíz no es automáticamente la primera causa en el tiempo, la persona que cometió el último error ni la explicación más llamativa. Es una afirmación respaldada por evidencia y relacionada con una acción de prevención o detección.

1948. Modelo mental

Usa la Escalera de evidencia:

Aplica esta regla: escribe primero la evidencia, etiqueta la incertidumbre y explica solo hasta donde permita la evidencia. Si una afirmación no puede comprobarse, no la presentes como un hecho sin indicarlo.

1949. Ejemplo concreto

Imagina que un equipo estudiantil descubre que falta su última compilación jugable después de una sesión de trabajo.

Una explicación prematura podría decir: «El programador olvidó hacer commit y por eso el equipo perdió un día».

Un relato basado en evidencia es más preciso:

• Línea de tiempo: A las 10:00, el equipo abrió el proyecto. A las 12:15, la compilación era jugable. A las 13:00, comenzó una importación de recursos. A las 13:20, el editor se cerró inesperadamente. A las 13:30, el equipo volvió a abrir el proyecto y descubrió que faltaban los cambios más recientes de la escena.
• Impacto: El equipo no pudo demostrar el estado jugable actual y tuvo que dedicar la siguiente sesión a reconstruir cambios.
• Hechos observados: La carpeta local contiene la versión anterior de la escena. Las notas de la sesión no registran ningún respaldo. El repositorio no contiene un commit posterior a la versión anterior de la escena.
• Suposiciones que deben comprobarse: La importación causó la pérdida. El commit ausente habría recuperado todo el trabajo perdido. Un recurso específico provocó el cierre del editor.
• Condiciones contribuyentes:
  • Inferencia acotada: No se observa ningún punto de recuperación en las notas de la sesión ni en el historial del repositorio proporcionados.
  • Hipótesis: El flujo de trabajo no exigía un punto de recuperación antes de una importación arriesgada.
  • Pregunta abierta: ¿Existía otro respaldo o método de recuperación fuera de las notas y del repositorio proporcionados?
• Hipótesis de causa raíz — Hipótesis: El flujo de trabajo carecía de un punto de recuperación verificado antes de realizar operaciones que podían dañar o reemplazar el estado actual.

Observa que la hipótesis no acusa a una persona. Señala un cambio de proceso que puede comprobarse: definir un punto de control antes de las operaciones arriesgadas y verificar que el proyecto pueda restaurarse desde ese punto.

1950. Error común

El error más común es convertir una explicación plausible en un hecho registrado. Un postmortem puede afirmar «la importación corrompió la escena» aunque nadie haya revisado los registros ni reproducido el fallo. Otro error es llamar «alguien se equivocó» a la causa raíz. Puede ser cierto en un nivel, pero no explica por qué el flujo permitió que un error produjera el impacto observado ni por qué el error no se detectó antes.

1951. Práctica guiada

Redacta una nota de incidente de cuatro partes a partir de este escenario:

Un equipo estudiantil planeaba probar un nuevo encuentro con un enemigo el viernes. El encuentro no estaba listo durante la sesión. El equipo pasó la mayor parte de la mañana ajustando los tiempos de animación del enemigo. A las 16:00, decidió trasladar el encuentro a la siguiente sesión. Ese día no se grabó ninguna prueba jugable. El lunes, el equipo descubrió que los cambios de animación también habían alterado el tiempo de ataque del enemigo.

Escribe cuatro secciones:

1. Línea de tiempo: Enumera solo los hechos con una hora indicada o con un orden claramente delimitado.
2. Impacto: Describe el efecto concreto sobre la prueba del juego y la decisión del proyecto.
3. Condiciones contribuyentes: Identifica al menos dos condiciones y marca cada una como hecho o suposición.
4. Hipótesis de causa raíz: Escribe una explicación comprobable que apunte a una condición del proceso o del sistema, no a una persona.

Después, etiqueta cada oración de tu nota como Hecho, Inferencia, Suposición o Pregunta abierta. Toma una decisión: elige el único punto de control u observación temprana que habría reducido más la incertidumbre y explica por qué.

1952. Evaluación práctica y plantilla

Usa el escenario proporcionado o un incidente documentado de tu propio proyecto. No inventes datos que falten del historial del proyecto. Copia y completa esta plantilla:

Incidente:
Fuentes de evidencia consultadas:

1. Línea de tiempo acotada
- [Hecho / Inferencia / Suposición / Pregunta abierta] Suceso y hora u orden delimitado:

2. Impacto
- [Etiqueta] Efecto concreto sobre el juego, el proyecto, el equipo o la decisión:

3. Condiciones contribuyentes
- [Etiqueta] Condición 1:
- [Etiqueta] Condición 2:

4. Hipótesis de causa raíz
- [Hipótesis] Explicación comprobable sobre el proceso o el sistema:
- [Pregunta abierta] Cuestión sin resolver:
- Punto de control propuesto:
- Por qué este punto reduciría la incertidumbre o el impacto:

Causa raíz frente a síntoma: Un síntoma es el fallo o impacto observado. Una condición contribuyente es una circunstancia del proceso o del sistema que hizo que el incidente fuera más probable o costoso. Una hipótesis de causa raíz propone una relación comprobable entre esa condición y la repetición del incidente; no es un hecho definitivo mientras la evidencia no la respalde.

Puntúa la plantilla de 0 a 2 en cada categoría:

La evaluación práctica se completa con 6 de 8 puntos o más, sin obtener 0 en Estado de la evidencia ni en Prudencia causal. El cuestionario de la lección sigue siendo una comprobación de reconocimiento independiente.

1953. Validación y evidencia

1954. Ideas clave

• Los hechos describen lo que puede comprobarse; las suposiciones y las hipótesis deben etiquetarse.
• Una línea de tiempo establece la secuencia, pero por sí sola no demuestra causalidad.
• El impacto describe la consecuencia para el juego, el proyecto, el equipo o la decisión.
• Las condiciones contribuyentes explican la vulnerabilidad; una hipótesis de causa raíz identifica una condición que merece ser comprobada y cambiada.
• Escribir a partir de evidencia reduce la culpabilización y produce mejores decisiones correctivas.

1955. Siguiente lección

Continúa con 4.16 L2 — Escribe un postmortem accionable, donde usarás esta estructura de evidencia para definir acciones correctivas y comprobaciones de seguimiento.

1956. Comprobación