Al terminar esta lección
- Armar una defensa que permita recorrer una decisión desde su fuente hasta su prueba.
- Asignar niveles de la rúbrica según evidencia concreta, y no según la impresión de haber trabajado mucho.
- Escribir una autoevaluación que distinga lo verificado de lo pendiente, con su responsable.
- Organizar una revisión por mentor o par con momentos, responsables y registros claros.
La defensa frente a un panel
La defensa es la última prueba del proyecto. El panel no evalúa si el proyecto es grande ni si los documentos son muchos. Elige una decisión al azar y pide la cadena completa: de dónde salió, qué regla o hipótesis la sostiene, qué quedó fuera por ella, cómo se implementó y qué prueba la verifica. Si no podés responder alguno de esos eslabones, la defensa muestra la deuda de trazabilidad, aunque el resto del trabajo sea bueno.
Por eso conviene pensar la defensa como un recorrido que lleva al panel a lo que puede verificar. El orden siguiente va de lo que el cliente entiende a lo que el panel puede comprobar con sus propios ojos.
Ordená el guion de la defensa
Usá las flechas para dejar las partes en el orden de la defensa. El orden importa porque cada parte prepara la evidencia de la siguiente.
- Posición 1 de 6: Evidencia de comportamiento: demo o ejecución de pruebas, con comando y resultado
- Posición 2 de 6: Una decisión elegida por el panel, recorrida desde la fuente hasta la prueba
- Posición 3 de 6: Unknowns y límites, con responsable y qué los cambiaría
- Posición 4 de 6: Respuesta a tres objeciones con evidencia, sin argumento de autoridad
- Posición 5 de 6: Problema, con un episodio real que lo muestre
- Posición 6 de 6: Objetivo y frontera IN / OUT / BLOCKED, con la razón de cada exclusión
Un detalle del guion: los tiempos. Cuando el panel tiene que elegir decisiones al azar, el recorrido de cada una debería caber en unos tres minutos. Si necesitás más, la decisión es demasiado grande para la defensa y conviene partirla en dos.
Defensa débil y defensa fuerte (ejemplo genérico, no de DICSA)
"Usamos esta arquitectura porque es la mejor y escala. Los tests pasan y el código está limpio."
No dice qué requisito resuelve ni qué se descartó. Tampoco dice qué prueba demuestra el comportamiento ni qué lo haría cambiar.
"Elegimos una base transaccional única para la regla de cupo, porque el riesgo es que dos operaciones tomen el último lugar al mismo tiempo. Descartamos dos servicios separados porque no había un requisito de escala independiente. La prueba que lo demuestra es la de concurrencia, y la decisión se reabre si aparece un volumen que la prueba de carga no cubra."
Tiene fuente (el riesgo), alternativa descartada (los dos servicios), prueba (concurrencia) y condición de cambio. Cada parte puede verificarse.
La cadena de una decisión
El panel pide la cadena completa porque ahí aparece el criterio. Una decisión sin cadena puede ser correcta por casualidad. Una decisión con cadena puede explicarse, discutirse y cambiarse con método. El diagrama muestra los eslabones que el panel espera ver, en ese orden.
Recorrela en los dos sentidos. Hacia adelante, para explicar cómo una fuente llega a una prueba. Hacia atrás, para probar que la prueba responde a una fuente real. Si el camino se corta en algún punto, ahí está la deuda de trazabilidad, y conviene anotarla antes de que la encuentre el panel.
Un eslabón que suele faltar es la condición de cambio. Una decisión defendible dice qué evidencia la haría revisar: una medición distinta, un documento nuevo, una regla que cambia. Si no podés escribir esa condición, probablemente no entendés del todo por qué la tomaste.
Ver una cadena de ejemplo (genérica)
Ejemplo ficticio, sin datos de ningún caso real.
- Fuente: un episodio en el que dos personas tomaron la misma unidad de un producto, registrado en una planilla con fecha y hora.
- Regla: no se puede confirmar una cantidad mayor que la disponible en el momento de la confirmación.
- Alcance: IN la validación de cantidad; OUT la reserva con vencimiento, porque no hay evidencia de su duración; BLOCKED la regla de excepciones, a la espera de quien autoriza.
- Decisión: la disponibilidad se controla dentro de la misma transacción que registra el pedido.
- Implementación: el cambio está en un solo módulo, con un diff de pocas líneas revisado por una persona.
- Prueba: dos confirmaciones concurrentes sobre la última unidad. El oráculo verifica que solo un pedido se confirme y que el stock no quede negativo.
- Evidencia: el comando de la prueba de concurrencia, con su resultado y la fecha de ejecución.
- Condición de cambio: si aparece un volumen de confirmaciones que la prueba no cubre, o si la política de excepciones cambia el orden, se reabre la decisión.
Hoja de entrega 13 · completá antes de pasar el gate
Este bloque no se completa de memoria. Volvé a tus artefactos, evidencia y resultados. El objetivo es obligarte a hacer explícito qué vas a defender frente a un mentor o cliente. Si una respuesta queda vacía, el gate no se pasa.
Artefacto que entrego y versión:
Tres evidencias que sostienen mis decisiones:
Decisiones que tomé yo y que un agente no podía tomar:
Desconocidos o riesgos que siguen abiertos:
Feedback o propuesta de IA que rechacé, y por qué:
Qué tendría que ocurrir para que yo mismo cambie esta conclusión:
Revisión de calidad: qué corregí antes de enviar o presentar:
Firma del mentor/reviewer o referencia del feedback:
Rúbrica del portfolio
La rúbrica tiene siete dimensiones y tres niveles. Cada nivel se describe con lo que se puede observar en el trabajo, no con lo que el estudiante siente haber hecho. La última columna indica qué evidencia mira el mentor o el par para asignarlo.
| Dimensión | Insuficiente | Competente | Estándar Eje Z | Evidencia que revisa el mentor o par |
|---|---|---|---|---|
| Discovery | Confunde declaraciones con hechos y salta a la solución. | Registra evidencia y unknowns, cada uno con fuente. | Triangula fuentes, detecta excepciones y prioriza los unknowns por impacto en la decisión. | Dossier con categoría y fuente en cada línea; matriz de contradicciones; unknowns con responsable y decisión bloqueada. |
| Relación con cliente | Interrogatorio o promesas prematuras. | Conduce una reunión ordenada, con preguntas abiertas. | Trabaja con episodios, maneja contradicciones y cierra con responsables y evidencia pedida. | Notas de reunión con fuente; playback registrado; pedidos de documentos con motivo. |
| Requerimientos | Lista de features o pantallas. | Reglas y casos de uso razonables. | Frontera defendible, reglas verificables, garantías y trazabilidad hasta las pruebas. | Tabla IN / OUT / BLOCKED con justificación; reglas con condición y resultado; garantías con su escenario. |
| Arquitectura | Patrones elegidos por moda. | Diseño coherente con el alcance. | ASR → decisión → trade-off → prueba; riesgos y fallos explícitos; descarta lo que no hace falta. | ADR solo para decisiones con alternativas; mapa de riesgos con tratamiento; condición de cambio por decisión. |
| IA | Acepta output sin revisar o usa prompts gigantes. | Usa un agente con tests que verifican su trabajo. | Controla bundle, plan, alcance y diff; devuelve ambigüedades a la spec y registra lo que rechazó. | Plan previo del agente; diffs revisados; registro de propuestas rechazadas y de decisiones humanas. |
| Testing | Happy path y cobertura como meta. | Pruebas unitarias, de integración y de extremo a extremo razonables. | Pruebas derivadas de riesgo, bordes, fallos y concurrencia, con oráculo que mira efectos y no efectos. | Matriz de pruebas por riesgo; comandos y resultados; defectos encontrados y cómo se corrigieron. |
| Defensa | Jerga o afirmaciones absolutas. | Explica la solución completa. | Conecta decisión con valor y riesgo, reconoce límites y responde objeciones con evidencia. | Guion de defensa; respuestas a objeciones registradas; lista de límites y de lo que quedó fuera. |
Cómo se asigna un nivel. Empezá por el nivel competente y pedí evidencia para subir. Si no podés señalar el artefacto que respalda un nivel, el nivel es el inferior. Un "estándar Eje Z" en testing, por ejemplo, exige mostrar un test que fallaría si la regla se rompe, no solo una lista de tests que pasan.
Criterio de no aprobación: cualquier regla crítica inventada, tests sin oráculo derivado, arquitectura defendida por moda, ausencia de evidencia frente a contradicciones o incapacidad de explicar qué quedó fuera y por qué. Ese criterio no se compensa con otras dimensiones altas. Un proyecto con defensa brillante y una regla inventada no aprueba.
Autoevaluación escrita
Antes de pedir revisión, escribí tu autoevaluación. Es el ejercicio que obliga a separar lo que verificaste de lo que creés. No cuenta como aprobación; sirve para preparar la revisión y para que el revisor sepa dónde mirar.
Autoevaluación de una decisión del proyecto
Elegí una decisión de tu proyecto DICSA y escribí su cadena completa: fuente, regla o hipótesis, alcance, decisión, implementación y prueba. Después ubicá tu trabajo en dos dimensiones de la rúbrica (una donde te sientas fuerte y otra donde no) y decí qué evidencia concreta respalda cada nivel. Cerrá con lo que dejaste pendiente.
Plan de revisión por mentor o par
Una autoevaluación sin revisión externa no alcanza. La revisión tiene momentos definidos, y cada uno deja un registro. La tabla organiza quién revisa qué y qué queda escrito.
| Momento | Quién revisa | Qué revisa | Qué queda registrado |
|---|---|---|---|
| Dos días antes de la defensa | Par (otro estudiante o colega) | Que cada decisión tenga fuente o unknown, y que cada exclusión del alcance tenga una razón escrita. | Lista de hallazgos con fecha, respuesta del autor y cambio hecho en el artefacto de origen. |
| Antes de la defensa | Mentor | Una decisión elegida al azar, con su cadena completa de fuente a prueba. | Cadena documentada, o deuda de trazabilidad con la fecha en que se detectó. |
| Durante la defensa | Panel (mentor y par) | Trazabilidad desde una decisión de negocio hasta un test, y respuesta a las objeciones. | Notas del panel, objeciones sin respuesta y niveles propuestos por la rúbrica. |
| Después de la defensa | Vos y el mentor | Qué cambios derivan del feedback y en qué artefacto de origen se hicieron. | Versión nueva del artefacto, motivo del cambio y derivados actualizados. |
Algunas reglas del plan. Cada hallazgo se corrige en su origen, no en el derivado: si una regla estaba mal, se corrige la regla y después el caso de uso y la prueba. Un hallazgo no se cierra porque el autor diga que está resuelto; se cierra cuando el revisor puede verificar el cambio. Y las preguntas que el revisor hace y no tienen respuesta se registran como pendientes, no como detalles.
Si cursás de forma autónoma, el par puede ser una autoevaluación escrita con las mismas preguntas del plan, hecha con un día de distancia. No reemplaza a una revisión externa. Lo que sí hace es obligarte a volver sobre tus artefactos con otra mirada, y dejar registro de qué encontraste.
Revisión final del portfolio
Elegí con tu mentor o par una decisión del proyecto y recorré su cadena: fuente, regla, alcance, arquitectura, implementación y prueba. Mostrá también una decisión rechazada, una incertidumbre pendiente y un cambio que surgió de validar con usuarios. Si cursás de forma autónoma, documentá estos puntos como autoevaluación y conservá pendientes las verificaciones que requieren fuentes externas.
Registrá los hallazgos en el plan de revisión de arriba. Lo que no puedas verificar sigue pendiente, con su responsable, hasta que haya evidencia.
Gate 13 · graduación
Un gate no es una formalidad. Si una condición crítica no se cumple, el trabajo correcto es hacer visible la incertidumbre y volver a buscar evidencia.
El checklist registra tu autoevaluación en este navegador. Marcar un criterio no aprueba el gate: la aprobación requiere que el mentor o par revise la evidencia de cada criterio.
Criterios de revisión
Revisá tus artefactos antes de marcar cada criterio. El checklist registra tu autoevaluación; la aprobación requiere revisar la evidencia.
Guardá tu entrega
Completá la entrega 13, adjuntá evidencia y registrá los criterios del gate que todavía no podés demostrar.
Nexo B2B · La última lección no está en el código
Meses después del primer release, Nexo cambia una política comercial: los clientes platino ya no tienen un porcentaje fijo de sobregiro; la autorización depende de historial y monto. El sistema no se rompe porque “la regla estaba bien programada”. El equipo vuelve a la fuente, modifica la RN, los escenarios y el caso de uso, revisa el estado pendiente, actualiza tests y recién después cambia código. La trazabilidad convierte un cambio de negocio en trabajo localizable.
El mismo proyecto confirma que algunas decisiones iniciales eran temporales. El monolito modular sigue funcionando y nadie necesita dividirlo. La reserva por PostgreSQL soporta el volumen real. En cambio, la calidad de stock físico requiere un proyecto operativo adicional que ningún software puede resolver solo. Poder distinguir qué decisión envejeció bien y qué problema pertenece fuera del sistema es parte de la madurez profesional.
Un junior nuevo entra al equipo y recibe CU, RN, ADR, tests y runbook. No necesita leer conversaciones históricas para entender por qué el precio no viene del request ni por qué una autorización queda auditada. Esa transferencia es una medida práctica de calidad documental. Si una decisión solo vive en la cabeza de quien estuvo en discovery, el sistema sigue dependiendo de conocimiento tácito.
Nexo deja de ser el ejemplo que el estudiante debe copiar y pasa a ser una prueba de una idea más general: enfrentar un proyecto significa construir comprensión antes de compromiso, conservar la cadena de evidencia, elegir mecanismos por riesgos concretos, verificar comportamiento y poder explicar límites. La graduación ocurre cuando esa forma de pensar aparece también en un dominio distinto.
Errores frecuentes
Síntoma: la defensa arranca con la arquitectura y el panel no entiende qué problema resuelve. Causa: pusiste la solución antes del episodio y de la frontera. Corrección: reordenar el guion; el primer minuto es un episodio real con su fuente.
Síntoma: al elegir una decisión al azar, no podés llegar al test sin saltar pasos. Causa: la decisión se tomó en una conversación y nunca se registró como regla. Corrección: escribir la regla con condición y resultado, y enlazarla con el caso de uso y el test. Si el eslabón no existe, dejalo visible como deuda.
Síntoma: el gate tiene todos los criterios marcados pero la evidencia de prueba es una captura de pantalla. Causa: confundiste mostrar con demostrar. Corrección: guardar el comando, el resultado y la fecha, y mostrar que la prueba falla si la regla se rompe.
Síntoma: el portfolio tiene muchos documentos y el mentor no encuentra la decisión que le interesa. Causa: los artefactos no tienen trazabilidad entre sí. Corrección: la matriz de trazabilidad del cuaderno, con cada decisión enlazada a su fuente, su prueba y su estado.
IA EN ESTA FASE
Qué puede hacer el agente. Armar la matriz de trazabilidad a partir de los artefactos, buscar en el repositorio la prueba de cada regla declarada y ordenar hallazgos de la revisión por tipo y origen.
Qué no debe decidir. Qué nivel de la rúbrica merece tu trabajo, si una decisión sobrevive a la defensa y qué firma el revisor. Esas decisiones son humanas y el registro tiene que mostrarlo.
Contexto mínimo útil. Los artefactos del proyecto, el cuaderno de trabajo y la lista de reglas. No le pases tu autoevaluación ya escrita: la tendría como respuesta y no como hipótesis.
Cómo verificar. Cada celda de la matriz tiene que enlazar a un artefacto o a un test que existe. Si el agente escribe "cubierto" sin enlace, marcalo como sin evidencia. Revisá también que los comandos citados se hayan ejecutado y que el resultado coincida.
Prompt de trabajo.
Con los artefactos adjuntos, armá una matriz con las columnas: fuente o evidencia, regla o
hipótesis, decisión, implementación (archivo o diff), prueba (archivo y nombre) y comando con
resultado. Si una celda no tiene evidencia en los artefactos, escribí "sin evidencia" y no
completes con suposiciones. No evalúes niveles de la rúbrica ni marques criterios del gate.
Para llevarte
- La defensa es un recorrido verificable: episodio, alcance, decisión, prueba y límites, en ese orden.
- Una decisión sin fuente, sin alternativa descartada o sin condición de cambio todavía no está defendida.
- El nivel de la rúbrica se asigna con un artefacto, no con la sensación de haber trabajado.
- La autoevaluación separa lo verificado de lo pendiente, y cada pendiente tiene responsable.
- El gate se aprueba con revisión de evidencia. Marcar casillas registra tu autoevaluación y nada más.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.