Al terminar esta lección
- Producir el guion de defensa, el one-pager y la matriz de objeciones del Sprint de Nexo.
- Registrar riesgos, deudas y límites con dueño, señal y estado, y detectar entradas que no sirven.
- Respaldar cada número y cada garantía con una consulta, una prueba o un registro.
- Revisar el gate contra evidencia y dejar visibles los criterios que todavía no podés demostrar.
Práctica E12 · Defensa técnica y comercial
Situación. Presentá el Sprint de Nexo ante dos personas: una hace de dueño y otra de responsable operativo.
Entregá. pitch de 8 minutos; demo de decisión arquitectónica; respuesta a 5 objeciones; lista de límites.
Está listo cuando. no se usa jerga como argumento de autoridad; se puede admitir incertidumbre; las decisiones se explican por consecuencias; el valor está conectado a objetivos.
Solución comentada: Solución comentada E12. Comparala después de producir tu entrega.
Prepará una defensa de 15 minutos de la solución de Nexo para audiencia mixta: dueño, ventas y depósito. El contrato mínimo de evaluación es el pitch de 8 minutos del bloque Entregá. Si tenés tiempo, expandilo a 15 minutos con las preguntas del panel. Las cifras de los pasos son recomendadas, no obligatorias: lo que cuenta es que la entrega sea completa.
- Explicá tres decisiones arquitectónicas sin usar jerga como argumento de autoridad.
- Prepará respuesta para seis objeciones: costo, plazo, fuera de alcance, tecnología, IA y una regla que el cliente quiere cambiar.
- Incluí una diapositiva o página de "lo que esta solución no garantiza". La honestidad sobre límites forma parte de vender profesionalmente.
- Mostrá cómo una decisión vuelve a evidencia: problema → RN/CU → arquitectura → test → resultado.
Hacé role-play. La otra persona debe introducir una información nueva que invalide una decisión. Tu objetivo es reconocerlo y explicar qué artefactos habría que revisar, no defender el diseño viejo.
Criterio de revisión. Aprobás esta práctica cuando podés defender decisiones sin esconder trade-offs y también podés cambiar de opinión cuando aparece mejor evidencia.
Los pasos siguientes te llevan por el recorrido completo. Cada uno tiene un objetivo, un tiempo sugerido, un ejemplo parcial y una pista. La solución completa vive en 14.4. El orden importa: el diagrama muestra qué artefacto depende de cuál.
Cada flecha dice que el artefacto de la derecha no es confiable hasta que el de la izquierda existe. Por eso el guion es lo último que cerrás: se escribe primero para ordenar la conversación, pero solo se da por bueno cuando todo lo que dice tiene respaldo.
Nexo B2B · La defensa técnica se vuelve una conversación comercial real
En la reunión final el dueño abre con una objeción directa: "Yo pensaba que esto iba a automatizar todo el crédito". El equipo podría responder que eso nunca estuvo en alcance. En cambio vuelve al problema y a la evidencia: hoy existen autorizaciones que dependen de criterios todavía no unificados. Automatizarlas sin política estable convertiría una costumbre discutible en una regla rígida. El primer release reduce espera, hace visible el estado, evita confirmaciones inconsistentes y registra quién autorizó. La automatización completa queda como siguiente decisión, no como promesa incumplida.
Ventas pregunta por qué no se eligió una arquitectura de microservicios "para que escale". La explicación evita nombres como argumento de autoridad. El volumen actual, la necesidad de transacciones consistentes y el tamaño operativo favorecen un monolito modular con una base relacional autoritativa. Si cambian señales concretas, por ejemplo aislamiento operativo, equipos independientes o escalado desparejo demostrado, la decisión se revisará. Diseñar para un futuro imaginario hoy agregaría fallos y costo sin resolver un riesgo medido.
Depósito trae una objeción más incómoda: la reserva lógica no evita que alguien encuentre físicamente menos unidades. El equipo reconoce el límite. El sistema reduce sobreventa por concurrencia y conserva trazabilidad, pero no puede garantizar que inventario físico sea correcto si el proceso de conteo está degradado. Por eso el quiebre durante picking queda como evento observable con resolución y métrica. Defender la solución también implica explicar claramente qué problema no puede resolver por sí sola.
La conversación termina con próximos pasos verificables. Nexo no recibe "una plataforma moderna", recibe un primer release con comportamiento medible, un backlog condicionado por evidencia, riesgos conocidos y criterios de expansión. Para el equipo, esa reunión cierra el recorrido porque puede conectar cada afirmación comercial con una cadena: problema observado, regla o requerimiento, decisión, implementación y prueba. Si una promesa no puede recorrer esa cadena, todavía no debe venderse.
Nexo B2B · Expediente 12: la propuesta que puede sobrevivir a una pregunta incómoda
El cliente pregunta: "¿Qué pasa si después descubrimos que la política de crédito era distinta?". La respuesta no es "eso no estaba en alcance". El equipo muestra trazabilidad: una regla validada que cambia genera impacto en estados, permisos y tests; el cambio se estima sobre evidencia nueva. El proceso permite cambiar sin fingir que el pasado no existió.
Otra pregunta: "¿Entonces esto nos garantiza que nunca vendemos algo que no tenemos?". La respuesta precisa separa reserva digital de exactitud física. La primera está protegida; la segunda depende de procesos de inventario. Decirlo quizá suena menos espectacular, pero evita vender una promesa imposible.
Paso 1 · Guion de defensa de 8 minutos (20 min)
Objetivo. Escribir el guion que vas a decir en voz alta, con un tiempo por bloque y una decisión por bloque con su consecuencia.
Estructura sugerida. Dos minutos para el problema con el pedido 48172 como hecho. Dos minutos para tres decisiones, cada una con su consecuencia y su señal de revisión. Dos minutos para la evidencia: la prueba de carrera, la consulta de control y lo que todavía no está medido. Un minuto para los límites, leídos como frases completas. Un minuto para próximos pasos, con métricas y línea base.
Ejemplo parcial trabajado. Apertura de ejemplo: "Nexo registraba pedidos por WhatsApp y copiaba cada uno al ERP. El pedido 48172 pidió tres unidades de AX-442 con dos libres, y la falta apareció recién en picking. Hoy vamos a mostrar tres decisiones que cambian eso y, sobre todo, lo que no cambian."
Escribí el guion de la defensa
Escribí el guion de 8 minutos en prosa hablada: cada bloque con su tiempo, las tres decisiones con consecuencia y señal, la evidencia concreta (prueba, consulta o registro), los límites y los próximos pasos con métricas y línea base. Máximo 700 palabras.
Pistas para el guion
- El tiempo del guion no es decorativo: si el bloque de evidencia dura un minuto, no tenés evidencia, tenés una frase.
- Si una decisión no tiene consecuencia escrita, quitála del guion o escribí la consecuencia antes de ensayar.
- Los límites se leen en voz alta. Si no te suena bien dicho, probablemente no es verificable.
- Cerrá con una pregunta al cliente sobre el dato que falta, no con un agradecimiento.
Paso 2 · One-pager de la decisión DEC-12-02 (20 min)
Objetivo. Escribir un one-pager para la decisión de arquitectura: monolito modular con worker (ADR-001), en un formato que el dueño pueda leer sin el equipo.
Ejemplo parcial trabajado. Para la sección de garantías, una versión débil diría "el sistema es robusto y escala bien". La versión verificable dice: "El pedido y la reserva se confirman en una misma transacción: si falla la reserva, no queda pedido (INV-05, T09)." Fijate en que la garantía tiene una condición y una prueba.
Escribí el one-pager DEC-12-02
Escribí un one-pager de una página para la decisión DEC-12-02: monolito modular con worker (ADR-001). Secciones obligatorias: problema que resuelve, decisión, alternativas descartadas (al menos dos), qué garantiza, qué no garantiza, costo y riesgo que asumimos, qué haría cambiar la decisión, evidencia y lo que necesitamos del cliente.
Solución parcial: límites y señales
- Límite 1: el release no fija el tiempo de vida de la reserva blanda (RN-07 BLOCKED). Dueño: depósito y comercial.
- Límite 2: la latencia del ERP queda fuera de la garantía. Se mide con p95 de consultas y se controla con timeout y respuesta temporarily_unavailable.
- Señal de revisión: si el registro de pedido supera el umbral de NFR-01 en dos mediciones seguidas con la carga acordada y la causa está en la base, se reabre la decisión.
Paso 3 · Matriz de objeciones (25 min)
Objetivo. Preparar respuestas para seis objeciones, clasificadas por tipo, con su evidencia y la condición que cambiaría la respuesta.
Primero clasificá las objeciones de la reunión. La clasificación decide el tipo de respuesta que vas a dar, así que no la hagas de memoria: leé la frase y fijate qué pide realmente.
Clasificá las objeciones de la reunión
Para cada objeción elegí el tipo que mejor describe lo que pide el cliente. Después leé la explicación: indica qué tipo de respuesta corresponde.
¿Por qué no usamos microservicios para el stock? Es más escalable.
Pero nosotros sí necesitamos facturar con CAE en el primer release.
¿Qué pasa si el depósito tiene menos unidades que las que dice el sistema?
¿Cuánto cuesta el piloto y qué incluye exactamente?
Quiero que la IA apruebe automáticamente a los clientes buenos.
Con IA esto debería estar en una semana, ¿no?
Para cada una de las seis objeciones obligatorias (costo, plazo, fuera de alcance, tecnología, IA y una regla que el cliente quiere cambiar), completá esta ficha en una lista. Son cinco líneas por objeción:
- Objeción textual: la frase tal como la diría el cliente.
- Tipo: pregunta, riesgo, preferencia o cambio de alcance.
- Pregunta de fondo: qué quiere saber realmente.
- Evidencia: el artefacto, la consulta, la prueba o el registro que sostiene la respuesta.
- Qué la cambiaría: la condición observable que obligaría a revisar tu respuesta.
Ejemplo parcial (costo). Objeción textual: "¿Cuánto más cuesta hacerlo con controles de concurrencia?". Tipo: pregunta. Pregunta de fondo: si el costo justifica el riesgo. Evidencia: la prueba T06 y el costo de una sobreventa en picking (RSK-01). Qué la cambiaría: que el volumen de pedidos con la misma unidad sea cero en el piloto y que el ERP asuma las reservas.
Completá la ficha de la objeción de plazo
Completá la ficha de cinco líneas para la objeción de plazo: 'Si la IA escribe el código tan rápido, ¿por qué el piloto tarda tanto?'. Usá la clasificación correcta, la evidencia del proyecto y una condición observable que cambiaría tu respuesta.
Solución parcial: ficha de plazo
- Objeción textual: "Si la IA escribe el código tan rápido, ¿por qué el piloto tarda tanto?"
- Tipo: preferencia (expectativa de plazo).
- Pregunta de fondo: qué parte del trabajo depende de decisiones y no de escribir código.
- Evidencia: las decisiones pendientes del proyecto (precio correcto, autoridad de crédito, reserva concurrente, falla del ERP) y la cantidad de retrabajo que evitaron los supuestos corregidos en discovery.
- Qué la cambiaría: que esas decisiones estén tomadas y documentadas con dueño; entonces el plazo se revisa con datos.
Paso 4 · Registro de riesgos (15 min)
Objetivo. Mantener un registro de riesgos, desconocidos y deudas donde cada entrada tenga dueño, señal y estado. Un registro con entradas incompletas no sirve en la reunión.
Detectá los errores en este fragmento de registro. Hay cuatro líneas problemáticas: una promesa disfrazada de mitigación, una decisión disfrazada de riesgo, un estado sin evidencia y una entrada sin dueño. Marcá las líneas.
Cuatro errores en el registro
Hacé clic en cada línea que tenga un problema de forma o de contenido: una mitigación que promete lo imposible, una decisión registrada como riesgo, un estado sin evidencia o una entrada sin dueño.
Después de corregir el fragmento, agregá al menos tres entradas propias al registro del release. Una tiene que ser un desconocido, otra un riesgo y otra una deuda técnica con condición de pago. Usá el formato del registro de la lección 12.1.
Agregá tres entradas al registro
Agregá tres entradas al registro de riesgos de Nexo: un desconocido, un riesgo y una deuda técnica. Cada una con id, tipo, título, dueño (por rol), señal observable y estado. La deuda incluye costo y condición de pago. No uses valores inventados para plazos o montos: si no existen, marcá el desconocido.
Solución parcial: tres entradas posibles
- Desconocido: si la sustitución automática de SKU se necesita en el primer corte. Dueño: responsable de depósito y comercial. Señal: cantidad de pedidos con sustitución manual en la primera semana.
- Riesgo: el piloto recibe pedidos por WhatsApp fuera de la sincronización del ERP. Dueño: equipo Eje Z. Señal: pedidos cargados por fuera del sistema, medidos por semana.
- Deuda: el ERP no conoce las reservas (DEUDA-01). Costo: revisión manual de disponibilidad. Condición de pago: integración definida después de medir el piloto.
Paso 5 · Changelog de alcance (10 min)
Objetivo. Registrar un cambio de alcance con motivo, impacto y aprobador. Un cambio que no está en el changelog no existe para el cliente.
El depósito pidió que, si el depósito propio no tiene stock, el sistema reserve automáticamente desde el otro depósito. En el canon de Nexo, la división multi-depósito de pedidos grandes está BLOCKED: no hay documentado cómo se elige el depósito. Escribí la entrada del changelog.
Escribí la entrada del changelog
Escribí una entrada completa del changelog para la petición de reserva automática desde el otro depósito. Campos: id, cambio, motivo, impacto (plazo, costo, riesgo, pruebas), estado y duenos. Decidí si el cambio entra, sale o queda BLOCKED, y justificá con la evidencia disponible.
Solución parcial: entrada CL-004
- id: CL-004. Cambio: la división multi-depósito de pedidos grandes queda BLOCKED.
- Motivo: se pidió reserva automática desde otro depósito, pero no hay documentado cómo se elige el depósito ni cuántos pedidos grandes se dividen (menos del 5 % según el relevamiento).
- Impacto: plazo sin cambio en el primer corte; costo sin cambio hasta definir la regla; riesgo: los pedidos grandes siguen requiriendo decisión manual de depósito; pruebas: el caso queda pendiente y no se prueba en el release.
- Estado: BLOCKED. Duenos: responsable de depósito y comercial.
Paso 6 · Evidencia SQL y pruebas (15 min)
Objetivo. Escribir la consulta que respalda una frase concreta del piloto. Si la frase es "no hay pedidos duplicados por reintento en la semana", la consulta tiene que demostrarlo sobre un intervalo.
Las consultas de control de la lección 12.2 miran todo el estado. Para el piloto necesitás la versión por ventana de tiempo, que es la que se corre cada semana. Este es el ejemplo trabajado:
-- Parámetros: $1 inicio de la ventana, $2 fin (exclusivo). Debe devolver 0 filas.
SELECT k.request_id, COUNT(DISTINCT k.order_id) AS pedidos
FROM idempotency_keys k
WHERE k.created_at >= $1
AND k.created_at < $2
GROUP BY k.request_id
HAVING COUNT(DISTINCT k.order_id) > 1;
Aclaración que tiene que decir tu entrega: cero filas prueba que el mecanismo de idempotencia no creó dos pedidos para un mismo requestId. No prueba que dos pedidos distintos del mismo cliente con el mismo contenido sean reintentos y no pedidos legítimos. Esa pregunta es de negocio y se le hace al cliente.
Ahora escribí la consulta equivalente para el stock.
Escribí la consulta de la frase de stock
Escribí la consulta de control que respalda la frase 'al cierre de cada semana del piloto, ninguna reserva deja disponibilidad negativa en ningún depósito'. Debe usar la tabla stock_level de la lección 12.2 y devolver filas solo si la invariante se rompe. Después escribí una frase de una línea que diga qué significa 0 filas, y otra que diga qué no prueba.
Solución parcial: la consulta de stock
-- Debe devolver 0 filas al cierre de cada semana del piloto (INV-01).
SELECT product_id, warehouse_id, on_hand, reserved
FROM stock_level
WHERE reserved > on_hand;
0 filas significa que, en el momento de la consulta, ninguna combinación de depósito y SKU tiene más reservado que disponible. No prueba que el estante tenga esas unidades: eso lo mide el registro de quiebres en picking y el conteo del depósito.
Paso 7 · Role-play y panel de defensa (20 min)
Objetivo. Responder en vivo a una información nueva que invalida una decisión, y reconocerlo sin defender el diseño viejo.
El role-play tiene un simulador. Probá la conversación con Sergio (depósito) antes de hacer el panel con otra persona. Las salidas buenas no niegan el límite; las riesgosas prometen lo que el software no puede cumplir.
Sergio pregunta por el stock físico
Panel de defensa. Sergio (depósito) acaba de decir que en el conteo de la semana aparecieron unidades de menos en dos SKU. Quiere saber qué garantiza el sistema.
Sergio (depósito)
Si el físico está mal, igual van a prometer algo que no existe. ¿Cómo lo manejan?
¿Qué respondés?
Si la conversación del panel te exige decir "no lo sabemos", elegí la respuesta que tenga las cinco partes de la lección 12.1: qué falta, por qué importa, cómo se resuelve, quién decide y qué queda bloqueado. Si la otra persona trae un dato que cambia una decisión, tu obligación es actualizar el artefacto correspondiente (changelog, registro o one-pager) antes de cerrar la reunión.
Qué puede hacer el agente: hacer de reviewer escéptico, simular la pregunta incómoda del panel y detectar frases de tu guion sin respaldo.
Qué no debe decidir: qué garantías se escriben, qué riesgo se acepta, qué decisión cambia ni qué número se presenta. Eso queda en tu entrega y tiene tu firma.
Contexto mínimo útil: tu guion, el one-pager, el registro de riesgos, el changelog y las consultas de evidencia. Sin esos artefactos, el agente va a inventar respuestas.
Cómo verificar: cada afirmación del agente que cite una cifra debe apuntar a un archivo de tu entrega. Cada garantía que proponga debe tener condición y prueba. Si el agente inventa una cifra o una decisión, descartala y anotala como ejemplo de promesa indebida.
Prompt de ejemplo:
Actuá como reviewer técnico y comercial escéptico de la propuesta de Nexo B2B.
Leé el guion, el one-pager y el changelog adjuntos.
Tu tarea: encontrar cinco frases que prometan más de lo que las evidencias sostienen.
Para cada una:
- citá la frase exacta;
- decí qué artefacto debería respaldarla y si ese artefacto existe;
- proponé una reescritura que diga lo que sí se puede verificar.
No agregues cifras ni decisiones nuevas. Si algo no se puede verificar con los archivos, decilo.
Cuaderno de campo 12 · Panel de defensa
Entregable: panel de 20 minutos con tres roles: negocio, operador y reviewer técnico.
- Negocio pregunta por valor, costo y alcance.
- Operador pregunta por excepciones y día malo.
- Reviewer pide trazabilidad y justificación arquitectónica.
- Al menos una pregunta debe obligarte a decir "no lo sabemos todavía". Explicá qué harías para resolverlo.
- Al menos una pregunta debe hacerte cambiar una decisión. Actualizá el artefacto correspondiente.
Revisión: graduarse no significa tener siempre una respuesta. Significa saber distinguir respuesta, hipótesis, decisión y próxima evidencia.
Hoja de entrega 12 · 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.
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:
Gate 12 · podés defender el trabajo profesionalmente
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.
Antes de marcar cada criterio, buscá la evidencia que lo sostiene en tus artefactos. Marcar un criterio sin evidencia es el error más caro de este gate, porque la defensa frente al cliente va a revelarlo.
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 12, adjuntá evidencia y registrá los criterios del gate que todavía no podés demostrar.
Cuando termines tu entrega, compará tu razonamiento con la solución comentada E12. No hay una única respuesta correcta: la comparación busca fuentes, decisiones y evidencia.
Errores frecuentes
- Síntoma: el panel termina con una pregunta sin respuesta y el equipo improvisa una cifra. Causa: no se preparó la lista de preguntas que obligan a decir "no lo sabemos". Corrección: antes del panel, escribí tres preguntas que el negocio, el operador y el reviewer pueden hacer, y para cada una la respuesta con la parte de "qué falta" y "quién decide".
- Síntoma: la entrega tiene one-pager, changelog y registro, pero no se conectan entre sí. Causa: cada artefacto se escribió en un momento distinto y nadie revisó las referencias. Corrección: revisá que cada decisión del one-pager aparezca en el changelog o en el registro con el mismo identificador.
- Síntoma: el guion es impecable pero el reviewer pregunta de dónde sale un número y no hay respuesta. Causa: el número se copió de una nota de trabajo. Corrección: cada número del guion tiene su línea en una consulta, una prueba o un registro citado.
- Síntoma: el registro de riesgos tiene estados "cerrado" sin evidencia. Causa: se marcó como cerrado lo que se pensó que estaba resuelto. Corrección: un estado "cerrado" exige un enlace a la salida de la prueba o la consulta que lo respalda.
- Síntoma: el equipo defiende la decisión original cuando el panel trae un dato nuevo. Causa: la defensa se volvió identidad. Corrección: reconocé el dato, identificá la condición que cambió, actualizá el artefacto y explicá el impacto antes de responder.
Para llevarte
- El guion se escribe primero para ordenar la conversación y se da por bueno al final, cuando todo lo que dice tiene respaldo.
- Cada objeción se clasifica antes de responder: pregunta, riesgo, preferencia o cambio de alcance.
- Un registro de riesgos sirve si cada entrada tiene dueño por rol, señal medible y estado con evidencia.
- Una consulta de control demuestra lo que mide. Escribí siempre qué no prueba junto a lo que prueba.
- Un cambio de alcance sin entrada en el changelog y sin aprobador no existe para el cliente.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.