Arma el paquete de evidencias de la Etapa 4

1970. Identidad de la lección

Módulo

4.16 — Postmortems

Lección

Arma el paquete de evidencias de la Etapa 4

Tipo académico

Integración

Tipo de esquema

Práctica

Orden

3 de 3 en este módulo

Tiempo estimado

60–90 minutos, incluida la práctica

Esta lección combina la decisión de lanzamiento del trabajo de producción anterior con el postmortem accionable de la lección previa. El resultado es un único paquete que permite seguir qué se decidió, por qué, qué evidencia respalda la decisión, qué versión candidata se evaluó, quién asume la responsabilidad, qué parte del producto se recortó, qué restricciones de producción y presupuesto aplicaron y qué debe ocurrir después.

1971. Objetivo de aprendizaje

Al terminar esta lección, el estudiante podrá entregar un memo completo de lanzar/no lanzar y un postmortem de su trabajo que identifiquen la versión candidata evaluada y vinculen explícitamente las afirmaciones, las evidencias de respaldo, las limitaciones, las acciones futuras, la persona responsable de la decisión, el plan aplicable de reversión/seguimiento/contención, los recortes de producto y el contexto de producción y presupuesto.

1972. Por qué importa

Una decisión de lanzamiento sin evidencia es solo una opinión. Un paquete sin un identificador preciso de versión candidata puede mezclar observaciones de distintas versiones o sesiones y volver imposible reproducir la decisión. Un postmortem sin contexto de decisión puede describir problemas sin mostrar sus consecuencias operativas. Al unir ambos documentos se crea un registro que puede revisarse, cuestionarse y utilizarse para elegir la siguiente acción. Nombrar a una persona responsable evita que la responsabilidad desaparezca dentro de un documento o una herramienta de IA. Registrar los recortes de producto y el contexto de producción y presupuesto mantiene la decisión limitada a las condiciones reales en que se tomó.

Cuando una decisión implica riesgo, el paquete debe indicar qué ocurrirá si ese riesgo se materializa. Según el caso, puede requerirse un plan de reversión, seguimiento o contención. No inventes un plan que no corresponda; explica por qué el plan aplicable no es necesario cuando sea pertinente.

1973. Conocimientos previos

Ya debes poder:

• tomar una decisión acotada de lanzar/no lanzar usando los criterios de lanzamiento establecidos anteriormente en la Etapa 4;
• distinguir observaciones verificadas de hipótesis y afirmaciones causales sin respaldo;
• escribir un postmortem accionable con responsable, siguiente acción y condición de validación;
• identificar el contexto de producción relevante para el trabajo estudiantil entregado;
• describir qué se recortó del alcance previsto e identificar las restricciones de producción o presupuesto que dieron forma al trabajo.

La dependencia inmediata es Escribe un postmortem accionable. Repasa esa lección antes de comenzar si tu postmortem todavía asigna culpas, trata una captura como prueba de la causa o enumera acciones sin una forma de verificarlas.

1974. Concepto central

El concepto central es la trazabilidad: toda decisión importante debe conectarse con evidencia, todo hallazgo importante debe conectarse con una acción futura y cada compromiso operativo debe tener una persona responsable y un plan de respuesta aplicable.

El paquete también debe identificar la versión candidata exacta que se está evaluando. Usa un identificador estable de tu propio trabajo, como un nombre de compilación, un commit, una etiqueta de exportación o un identificador fechado. No uses una etiqueta vaga como “la última versión”. Si no existe un número formal de compilación, crea un identificador claro para este conjunto de evidencias y explica cómo lo distingue de trabajos anteriores.

Un paquete defendible hace visibles las relaciones entre sus documentos. El revisor debe poder seguir esta cadena:

Decisión o afirmación → evidencia de respaldo → limitación o incertidumbre → acción o plan de respuesta → persona responsable → condición de validación

Usa esta cadena tanto para la decisión de lanzamiento como para el postmortem. Si una afirmación no tiene evidencia, márcala como interpretación o elimínala. Si una evidencia no afecta ninguna decisión ni acción, explica por qué se incluye o déjala fuera. Todo memo debe registrar también el identificador de la versión candidata, el recorte de producto y el contexto de producción y presupuesto relevante para la decisión.

1975. Modelo mental

Usa la matriz Decisión–Evidencia–Acción y los campos de contexto asociados:

Añade estos campos al paquete, no solo a la matriz:

• Identificador de la versión candidata: compilación, commit, etiqueta de exportación o identificador fechado exacto, con información suficiente para distinguirlo de versiones anteriores.
• Recorte de producto: funcionalidad, objetivo de calidad, plataforma, contenido o alcance previsto que se eliminó, aplazó o redujo; escribe “no se identificó ninguno” solo después de revisar el alcance original.
• Contexto de producción: forma de trabajo, herramientas relevantes, estado de desarrollo, condiciones de prueba y restricciones que afectaron el trabajo.
• Contexto de presupuesto: límite monetario real o supuesto de coste relevante. Si no se registró un presupuesto monetario, dilo e identifica la restricción práctica, como tiempo, cómputo, capacidad para crear recursos o disponibilidad de trabajo. No inventes una cantidad.
• Persona responsable de la decisión: la persona —no un sistema de IA, un rol sin nombre ni el documento— que acepta la responsabilidad de lanzar/no lanzar.
• Plan de respuesta aplicable: plan de reversión, seguimiento o contención, con activador, primera acción, responsable y validación. Si ninguno aplica, explica la razón.

El paquete completo normalmente contiene:

1. Memo de lanzar/no lanzar: identificador de la versión candidata, decisión, persona responsable, alcance, criterios, evidencia, riesgos, recorte de producto, contexto de producción/presupuesto y plan de respuesta.
2. Contexto de producción: qué se construyó, qué cambió, qué se probó, qué se recortó, qué restricciones aplicaron y qué queda fuera de la afirmación.
3. Postmortem del trabajo estudiantil: resultado observado, análisis acotado, condiciones contribuyentes, responsables de las acciones y seguimiento accionable.
4. Índice de evidencias: lista numerada de artefactos, con la afirmación o acción que respalda cada uno y la candidata o sesión a la que pertenece.

1976. Ejemplo concreto

Supón que debes decidir si un pequeño cambio de jugabilidad está listo para la siguiente versión interna. El paquete identifica la candidata como candidate-2026-08-22-a. Las notas muestran que la interacción funciona en una sesión nueva, pero no se ha probado después de volver a abrir el proyecto. El postmortem señala que el plan de pruebas omitió la persistencia y considera esa omisión una condición contribuyente.

Un paquete débil podría decir:

Lanzar. La funcionalidad funcionó durante la prueba. El fallo después de volver a abrir probablemente lo causó un script generado por IA.

La afirmación mezcla una observación limitada con una causa no demostrada, no identifica la candidata evaluada ni a la persona responsable, y no explica la respuesta ante la aparición del comportamiento pendiente.

Un paquete trazable diría en cambio:

• Identificador de la versión candidata: candidate-2026-08-22-a.
• Decisión: No lanzar el cambio en la candidata identificada.
• Persona responsable: [Nombre de quien toma y asume la decisión].
• Evidencia: La interacción pasó la prueba de sesión nueva, pero no existe una prueba documentada después de reabrir; por tanto, la evidencia actual no cubre el criterio declarado para esta candidata.
• Recorte de producto: El soporte del estado después de reabrir queda aplazado para esta candidata y no forma parte de la afirmación de lanzamiento.
• Contexto de producción/presupuesto: Se registra el tiempo de prueba, la forma de trabajo, las herramientas y la restricción de recursos sin inventar un coste.
• Limitación: La evidencia disponible no establece si el comportamiento pendiente se debe a la persistencia, a una referencia inválida o a otra condición.
• Plan de respuesta aplicable: Plan de seguimiento: la persona responsable añade una prueba de reapertura y reproduce el comportamiento antes de la siguiente decisión. Si aparece en una versión candidata, se contiene el cambio excluyéndolo de la versión o se revierte al último estado verificado.
• Validación: Registrar una prueba exitosa de sesión nueva y de reapertura, o documentar el fallo concreto, el resultado de la contención y su impacto acotado.

El ejemplo es genérico. Tu paquete debe usar evidencia de tu propio trabajo y no afirmar pruebas, costes, restricciones ni hechos que no hayas registrado.

1977. Error común

El error más frecuente es confundir completitud con volumen. Un paquete con muchas capturas, registros y notas puede seguir siendo débil si el revisor no puede identificar qué artefacto respalda cada afirmación o a qué candidata corresponde. Otro error es permitir que el postmortem contradiga al memo.

No resuelvas la incertidumbre escribiendo con más seguridad. No asignes la responsabilidad a “el equipo”, “la IA” o un rol sin nombre. Nombra a la persona responsable, identifica la candidata, el recorte de producto y el contexto de producción/presupuesto, y selecciona el plan que corresponda. Marca las causas no resueltas, reduce el alcance de la decisión y define la siguiente prueba o acción capaz de reducir la incertidumbre.

1978. Práctica guiada

Usa la lista canónica del paquete incluida en Validación / evidencia durante las Partes A–E. Las cinco partes construyen y auditan esa misma lista, en lugar de crear conjuntos independientes de requisitos. Los bloques de actividad suman entre 44 y 60 minutos; reserva el resto de la lección para la lectura, la revisión entre documentos y las correcciones.

Parte A: Define el alcance y el contexto de la entrega — 8–10 minutos

Escribe una declaración breve de alcance que contenga:

• el trabajo estudiantil o la versión que se evaluará;
• un identificador específico de versión candidata para esa compilación o conjunto de evidencias;
• las funcionalidades o criterios incluidos en la decisión;
• las funcionalidades, plataformas, estados o riesgos excluidos explícitamente;
• la fecha o identificador de sesión que distinguirá este conjunto de evidencias;
• el recorte de producto;
• el contexto de producción;
• el contexto de presupuesto o la restricción práctica de recursos.

Identifica a la persona responsable de la decisión, incluso si trabajas en solitario. Usa tu nombre visible en el curso, un identificador aprobado u otro nombre responsable reconocido en tu contexto; no uses etiquetas vagas como “el equipo”, “el desarrollador” ni el nombre de una herramienta de IA.

Parte B: Escribe el memo de lanzar/no lanzar — 12–15 minutos

Todos los campos son obligatorios, incluido el identificador de la versión candidata. Usa “no registrado”, “no se identificó ninguno” o “no aplica” solo con una explicación breve.

# Memo de lanzar/no lanzar

## Identificador de la versión candidata
[Compilación, commit, etiqueta de exportación o identificador fechado exacto; explica cómo se distingue de candidatas anteriores]

## Decisión
[Lanzar / No lanzar / Lanzar solo bajo estas condiciones]

## Persona responsable de la decisión
[Nombre visible en el curso, identificador aprobado u otro nombre responsable reconocido en tu contexto; no uses un equipo, rol o sistema de IA como etiqueta]

## Alcance
[Qué cubre y qué excluye esta decisión]

## Recorte de producto
[Funcionalidad, contenido, objetivo de calidad, plataforma o alcance eliminado, aplazado o reducido; explica si no aplica]

## Contexto de producción
[Forma de trabajo, herramientas, estado, condiciones de prueba y restricciones]

## Contexto de presupuesto
[Presupuesto o límite de recursos registrado; si no hubo presupuesto monetario, indícalo e identifica la restricción práctica]

## Criterios
[Las condiciones de aceptación utilizadas]

## Evidencia
[Elementos numerados vinculados con cada criterio y con el identificador de la candidata]

## Riesgos e incertidumbres conocidas
[Qué sigue sin verificarse o resolverse]

## Plan de respuesta aplicable
[Reversión, seguimiento o contención: activador, primera acción, responsable y validación; si no aplica, explica por qué]

## Condiciones o siguiente paso
[Qué debe ocurrir antes de cerrar la decisión, si corresponde]

Toma la decisión en el nivel más estrecho que permita la evidencia. Si un criterio no se verificó, no sugieras que todos fueron aprobados. El plan de respuesta debe ser operativo: indica qué lo activa, cuál es la primera acción, quién actúa y cómo se comprobará que la respuesta se completó.

Parte C: Ajusta el postmortem — 10–15 minutos

Comprueba que contenga:

• el identificador de la versión candidata o una indicación clara de la candidata y sesión descritas;
• el resultado observado, no solo una interpretación;
• el contexto de producción relevante;
• el recorte o aplazamiento de alcance, o una declaración explícita de que ninguno afectó el resultado;
• el contexto de producción/presupuesto, sin inventar cantidades ni restricciones;
• condiciones contribuyentes sin culpas personales;
• acciones concretas;
• una persona responsable para cada acción y para la decisión cuando corresponda;
• un plan de reversión, seguimiento o contención cuando exista riesgo operativo;
• una condición de validación para cada acción y plan de respuesta.

Revisa solo lo necesario para que el postmortem sea coherente con el memo. Si el memo indica “no lanzar” porque un criterio no se probó, el postmortem no debe presentar esa prueba ausente como un defecto confirmado. Si el memo aplaza una parte del producto por una restricción de producción o presupuesto, registra ese contexto sin tratar el recorte como evidencia de que la funcionalidad falló.

Parte D: Construye el índice de evidencias — 7–10 minutos

Crea un índice con al menos tres entradas, o menos solo si tu trabajo realmente genera menos de tres artefactos relevantes. Cada entrada debe indicar la candidata o sesión a la que pertenece:

Añade:

• Identificador de candidata registrado: [Identificador y ubicación]
• Persona responsable identificada: [Nombre]
• Recorte de producto representado: [Entrada o “no se identificó ninguno”, con explicación]
• Contexto de producción/presupuesto representado: [ID o explicación]
• Plan de respuesta representado: [ID o “no aplica”, con explicación]

La evidencia puede incluir notas de prueba, registros de reproducción, observaciones de la compilación, comparaciones, capturas, registros o artefactos del proyecto. Inclúyela porque respalda una afirmación, registra una restricción o aclara una limitación; no solo porque exista. Usa nombres de archivo y textos de enlace descriptivos. Añade una descripción textual breve del contenido relevante de cada artefacto visual y una transcripción legible, o un registro textual equivalente, para cada artefacto de audio. No obligues al revisor a depender solo del color, la posición o el contenido no transcrito de una imagen o grabación.

Parte E: Realiza la auditoría de trazabilidad — 7–10 minutos

Responde por escrito:

1. ¿El mismo identificador específico de versión candidata aparece de forma coherente en el alcance, memo, postmortem e índice?
2. ¿Cada criterio de lanzamiento aparece en el memo y está vinculado con evidencia o con “no probado”?
3. ¿Cada hallazgo importante está vinculado con una observación o artefacto?
4. ¿Se identifica a una persona responsable de la decisión y de cada acción?
5. ¿El recorte de producto es explícito y coherente?
6. ¿Los contextos de producción y presupuesto son explícitos y no inventados?
7. ¿Cada acción tiene una condición de validación?
8. ¿El plan aplicable incluye activador, primera acción, responsable y validación, o se explica por qué no aplica?
9. ¿Las hipótesis están marcadas como hipótesis?
10. ¿El memo y el postmortem son compatibles?
11. ¿Un revisor puede reconstruir el razonamiento sin pedir aclaraciones sobre la candidata o las evidencias?
12. ¿Los artefactos visuales o de audio incluyen descripciones textuales o transcripciones, y los archivos y enlaces tienen etiquetas descriptivas que no dependen solo del color, la posición o la imagen?

Resuelve cualquier respuesta “no” antes de entregar el paquete.

1979. Validación / evidencia

1980. Ideas clave

• Un paquete defendible identifica una sola versión candidata y vincula cada decisión o hallazgo importante con evidencia y cada acción con una condición de validación.
• Una persona responsable identificada hace explícita la responsabilidad de la decisión de lanzamiento; la IA no es la responsable.
• Los recortes de producto y el contexto de producción/presupuesto definen el límite real de la afirmación.
• Un plan de reversión, seguimiento o contención debe indicar activador, primera acción, responsable y validación cuando exista riesgo operativo.
• El memo, el contexto de producción, el postmortem y el índice deben funcionar como una sola entrega coherente.

1981. Siguiente lección

Siguiente: Diseña un sistema que una IA pueda modificar de forma segura, en la Etapa 5. Usa este paquete de evidencias como referencia al convertir una solicitud de funcionalidad ambigua en un brief de sistema acotado: conserva las restricciones verificadas, los riesgos pendientes, la responsabilidad asignada y los límites de las afirmaciones respaldadas por evidencia.

1982. Comprobación