Escribe un postmortem accionable

1957. Identidad de la lección

Módulo

4.16 — Postmortems

Lección

2 — Escribe un postmortem accionable

Tipo académico

Construcción guiada

Tipo de esquema

práctica

Orden

2 del módulo

Tiempo estimado

50–70 minutos, incluida la práctica

1958. Objetivo de aprendizaje

Al terminar esta lección, podrás redactar un postmortem sin culpas sobre tu propio trabajo estudiantil: separar observaciones de explicaciones, formular afirmaciones causales delimitadas, asignar responsabilidades accionables y definir cómo se verificará cada acción de seguimiento.

1959. Por qué importa

Un postmortem solo resulta útil si cambia las condiciones que produjeron el problema. Una cronología puede contar lo ocurrido, pero no indica qué debe cambiar después. En el desarrollo asistido por IA, el postmortem también evita conclusiones imprecisas como “la IA rompió el proyecto” o “el desarrollador debió revisar mejor”. El objetivo es conservar la evidencia, razonar con cuidado sobre las causas y crear acciones que otra persona pueda comprobar.

1960. Conocimientos previos

Debes haber completado 4.16 L1 — La evidencia antes que la explicación. Debes poder distinguir una observación de una interpretación, identificar la fuente de una afirmación, registrar la incertidumbre y evitar presentar una hipótesis no verificada como un hecho. También necesitas un caso concreto de tu trabajo estudiantil: por ejemplo, una implementación fallida, una sesión de retrabajo, un resultado de prueba rechazado o la recuperación de un estado roto.

1961. Concepto central

Un postmortem accionable conecta cuatro capas sin confundirlas:

1. Evidencia: ¿Qué puede comprobarse directamente?
2. Razonamiento causal: ¿Qué condiciones contribuyeron y con qué nivel de certeza?
3. Responsabilidad: ¿Quién ejecutará o coordinará la respuesta?
4. Prevención y verificación: ¿Qué cambiará y qué evidencia demostrará que el cambio funcionó?

El postmortem debe analizar el sistema de trabajo, no emitir un juicio sobre una persona. “Sin culpas” no significa ignorar consecuencias ni escribir de manera vaga. Significa describir decisiones, condiciones, interfaces, herramientas, comprobaciones y supuestos en lugar de atacar el carácter de alguien.

1962. Modelo mental

Usa la cadena E-R-R-V: Evidencia → Razonamiento causal → Responsabilidad → Verificación.

Una acción útil tiene esta forma:

La persona responsable cambiará o realizará [conducta o artefacto específico] antes de [límite definido], y se verificará mediante [condición observable de aprobación].

Evita acciones que solo expresan intención, como “tener más cuidado”, “usar mejor la IA” o “probarlo todo”. No especifican una conducta, una responsabilidad ni una forma de verificación.

1963. Ejemplo concreto

El siguiente es un escenario didáctico proporcionado para ensayar, no un incidente real de CONTRABAND ni un acontecimiento del estudio. Úsalo para practicar cómo identificar evidencia, separar afirmaciones causales y redactar acciones E-R-R-V. El artefacto de hito que entregarás en esta lección debe basarse en tu propio trabajo estudiantil; no entregues este escenario como tu postmortem. Si utilizas el escenario durante el ensayo, considera evidencia únicamente los hechos indicados aquí y no añadas registros, fechas, motivos ni historial del proyecto imaginados.

Imagina que una interacción creada por un estudiante funciona en una escena de prueba, pero falla después de volver a abrir el proyecto. La evidencia disponible es la siguiente:

• La interacción funciona inmediatamente después de la edición inicial.
• Falla al reabrir el proyecto.
• Falta una referencia necesaria de la escena después de volver a abrirlo.
• No existe un registro que demuestre que esa referencia se revisó antes de la primera prueba.
• La causa podría ser un estado del editor que no se guardó, una referencia serializada incorrectamente o un procedimiento de prueba incompleto. La evidencia no permite determinar cuál de estas opciones fue decisiva.

Una conclusión débil sería:

El estudiante tenía prisa, confió en la IA y olvidó guardar.

Eso atribuye una intención y una culpa sin demostrar ninguna de las dos. Una conclusión delimitada es más sólida:

La referencia de la escena estaba disponible durante la prueba inicial, pero no después de reabrir el proyecto. La evidencia establece un fallo de persistencia. No está establecido cuánto contribuyeron un estado no guardado y una referencia serializada incorrectamente. Además, la primera prueba no incluía cerrar, reabrir y volver a probar, por lo que el flujo de trabajo no detectó el fallo antes de considerar terminado el trabajo.

Acciones de seguimiento posibles:

• Estudiante: antes de marcar la siguiente interacción como terminada, añadir y ejecutar un paso de cerrar, reabrir y volver a probar en la lista de comprobación. La acción se verificará inspeccionando la lista completada y reabriendo el proyecto; se aprobará únicamente si la interacción funciona y la referencia necesaria sigue siendo válida después de una reapertura limpia.
• Estudiante: antes de la próxima revisión de la implementación, registrar la referencia necesaria de la escena y su estado esperado en las notas de implementación. La acción se verificará comparando las notas con el estado del proyecto reabierto; se aprobará únicamente si la referencia y el estado esperado están documentados y coinciden con el estado observado.
• Revisor o futuro responsable: antes de aceptar la interacción como terminada, reabrir el proyecto, reproducir la interacción e inspeccionar la referencia necesaria. La acción se verificará mediante el resultado registrado de la reproducción; se aprobará únicamente si la interacción funciona y la referencia sigue siendo válida después de una reapertura limpia.

El ejemplo no afirma que una sola acción haya causado el fallo. Identifica un fallo establecido, separa las hipótesis competidoras y crea una comprobación capaz de detectar su repetición.

1964. Error común

El error más frecuente es escribir el remedio antes de establecer el modo de fallo. Así aparecen acciones genéricas como “hacer más pruebas” o “revisar la salida de la IA”. Comienza por la evidencia y declara qué sigue sin saberse. Después elige la acción de seguimiento más pequeña que responda a una brecha observada o ponga a prueba una hipótesis importante. Si la evidencia no permite una afirmación causal, expresa esa limitación en vez de fabricar certeza.

1965. Práctica guiada

Crea el postmortem del hito a partir de un caso real de tu propio trabajo estudiantil. No uses un problema que todavía sea puramente hipotético ni entregues el escenario didáctico proporcionado como artefacto del hito.

Primero, utiliza el escenario didáctico proporcionado como ensayo si te resulta útil: identifica sus observaciones, redacta una explicación causal delimitada y comprueba si sus acciones incluyen responsabilidad y verificación. Después redacta un postmortem separado basado en tu propio trabajo estudiantil. Cita únicamente registros y observaciones que realmente puedas verificar. Tu artefacto puede analizar una implementación fallida, una sesión de retrabajo, un resultado de prueba rechazado o la recuperación de un estado roto. No añadas detalles inventados ni al escenario de ensayo ni a tu propia evidencia.

Paso 1: Delimita el incidente

Escribe un título neutral y una descripción de dos oraciones. Incluye qué se esperaba, qué se observó en cambio y dónde comienza y termina el análisis. No incluyas el nombre de una persona como explicación.

Paso 2: Construye la tabla de evidencia

Registra al menos cuatro observaciones de tu propio trabajo estudiantil.

Usa fuentes concretas: una reproducción, salida de prueba, estado del proyecto, captura, comportamiento registrado, commit o instrucción escrita. Si una fuente no está disponible, marca la afirmación como no verificada en lugar de tratarla como evidencia. Durante el ensayo con el escenario didáctico, identifica la afirmación del escenario que respalda cada observación en vez de inventar una fuente que no se proporcionó.

Paso 3: Construye la explicación causal

Escribe tres apartados breves:

• Establecido: afirmaciones respaldadas directamente por la evidencia.
• Contribuyentes probables: hipótesis apoyadas por parte de la evidencia, pero no demostradas.
• No establecido: explicaciones plausibles que requieren más evidencia.

Incluye al menos una incertidumbre explícita. Usa expresiones calibradas como “la evidencia muestra”, “probablemente contribuyó”, “pudo aumentar el riesgo” o “no puede determinarse con el registro disponible”.

Paso 4: Registra el resultado sobre la brecha del proceso

Registra exactamente uno de estos resultados, según lo que respalde la evidencia disponible:

• Brecha establecida: identifica una condición del flujo de trabajo respaldada directamente por la evidencia.
• Brecha probable: presenta la posible brecha expresamente como una hipótesis, no como un hecho establecido.
• Brecha no establecida: indica que la evidencia disponible todavía no permite establecer una brecha del proceso.

No fuerces la oración “El trabajo pudo avanzar sin detectar...” si la evidencia no la respalda. Si la brecha solo es probable o todavía no puede establecerse, define una comprobación concreta para obtener evidencia. Indica qué registro, reproducción, comparación u observación vas a obtener y qué resultado permitiría reducir la incertidumbre.

Paso 5: Describe el impacto y el alcance

Indica quién o qué se vio afectado y describe las consecuencias observables. Limita el alcance a los efectos respaldados por la evidencia citada; distingue el impacto confirmado del posible y registra qué aspectos del alcance siguen sin conocerse.

Paso 6: Reconstruye las decisiones relevantes

Para cada decisión relevante para el incidente, registra:

• la persona o el rol que la tomó;
• la información disponible en ese momento;
• los supuestos o las restricciones que influyeron en ella; y
• los aspectos importantes que todavía se desconocían.

Evalúa la decisión a partir de la información disponible cuando se tomó, no de los hechos conocidos posteriormente.

Paso 7: Redacta las acciones de seguimiento

Escribe entre dos y tres acciones usando el modelo E-R-R-V. Cada acción debe incluir:

• una persona o rol responsable;
• una conducta o artefacto específico que cambiará;
• un límite práctico o condición de finalización;
• un método de verificación;
• una condición de aprobación que otra persona pueda inspeccionar.

Al menos una acción debe prevenir la repetición y al menos una debe mejorar la detección si el problema vuelve a ocurrir.

Paso 8: Declara el límite del aprendizaje

Termina con dos oraciones:

1. Qué afirmación respalda este postmortem.
2. Qué afirmación no respalda.

Así evitas convertir un incidente pequeño en una teoría injustificada sobre el proyecto, la herramienta o la persona que realizó el trabajo.

1966. Validación / evidencia

1967. Ideas clave

• La evidencia describe lo que puede comprobarse; el razonamiento causal solo debe afirmar lo que la evidencia permite.
• El escenario didáctico proporcionado sirve para ensayar; el postmortem del hito debe usar tu propio trabajo estudiantil.
• Un análisis sin culpas se concentra en las condiciones y las brechas del flujo de trabajo, mientras que la responsabilidad accionable y la verificación observable definen la respuesta.
• Un postmortem creíble distingue la prevención de la detección y declara los límites de su conclusión.

1968. Próxima lección

Continúa con 4.16 L3 — Arma el paquete de evidencias de la Etapa 4. Lleva este borrador y su tabla de evidencia para refinar el análisis, poner a prueba las acciones de seguimiento y armar el paquete de evidencias según la secuencia curricular.

1969. Comprobación