12.1 Trade-offs, objeciones y límites de la propuesta

Al terminar esta lección

• Separar hechos, riesgos, decisiones y promesas dentro de una misma propuesta.
• Explicar un trade-off con lo que gana, lo que paga y la señal observable que obliga a revisarlo.
• Decir "todavía no lo sabemos" con un plan, un responsable y una decisión que queda bloqueada.
• Responder una objeción después de identificar si es pregunta, riesgo, preferencia o cambio de alcance.
• Registrar límites y deuda técnica en un registro de riesgos con dueño, señal y estado.

12. Defender la solución frente al cliente

La ingeniería no termina al tener razón técnica. También hay que poder explicar la decisión, escuchar objeciones, mostrar valor y admitir incertidumbre sin perder profesionalismo.

Defender no es convencer. El cliente no compra una arquitectura: compra una explicación que puede revisar. Cuando la explicación se apoya en hechos, riesgos y decisiones con dueño, la conversación se vuelve sobre datos. Cuando se apoya en autoridad ("es lo mejor", "así se hace"), la conversación se vuelve una pulseada, y el equipo pierde algo más que la discusión: el cliente deja de creer en las estimaciones y empieza a pedir garantías que nadie puede dar.

Vamos a trabajar sobre el Sprint de Nexo B2B. Después del módulo 11 existe un release integrado, probado en un entorno de prueba y demostrado con cinco historias. Lo que todavía falta es lo que el dueño va a preguntar antes de aprobar un piloto: por qué esta estructura, qué pasa cuando algo falla, qué no está incluido y qué sigue sin decidirse. Esas preguntas son el material de este módulo.

Hay una cadena que vamos a repetir en las tres lecciones:

preocupación del cliente → hecho observado → regla o requerimiento → decisión → consecuencia → señal de revisión

Si falta un eslabón, la defensa es débil aunque la técnica sea correcta. "Usamos PostgreSQL" no tiene hecho ni consecuencia. En cambio, "el pedido 48172 pidió tres unidades de AX-442 con dos libres, y el sistema tiene que impedir que esa falta aparezca recién en picking" recorre la cadena completa: hay un hecho, una regla (RN-05), una decisión y una consecuencia que el cliente puede verificar.

12.1 Separar hechos, riesgos, decisiones y promesas

Problema. En una reunión se dicen cuatro tipos de frases sin distinguirlas: lo que pasó, lo que podría pasar, lo que se decidió y lo que se promete que va a pasar. Cuando se mezclan, el cliente no sabe qué puede discutir. Si alguien dice "el sistema evita los errores de stock", está describiendo un riesgo, eligiendo un mecanismo y prometiendo un resultado en la misma frase. El cliente tiene que aceptar o rechazar todo junto, y como no puede rechazar una parte sin rechazar el resto, suele aceptar algo que no entiende.

Estas son las cuatro definiciones operativas que usamos en el curso:

• Hecho: algo observado o medido que alguien puede verificar. Tiene origen (una foto, un registro del ERP, una muestra) y fecha. Si no tiene origen, es una creencia, no un hecho.
• Riesgo: un evento posible con impacto concreto. Todavía no pasó, o no sabemos si pasa. Se controla, se acepta o se transfiere, pero siempre tiene dueño.
• Decisión: una elección entre alternativas, tomada por quien tiene autoridad para tomarla. Registra qué se descartó y por qué. Una decisión sin dueño es una opinión que todavía no se discutió.
• Promesa: un compromiso sobre un comportamiento futuro. Es verificable cuando tiene criterio de aceptación, método de medición y una decisión que la sostiene. Es indebida cuando no tiene ninguna de las tres.

Ejemplo en Nexo. El pedido 48172 llegó un jueves a las 10:02 por WhatsApp, con una foto de 23 códigos: dos mal escritos y uno discontinuado. Eso es un hecho, y su fuente es la foto y el registro del ERP. Que dos vendedores puedan prometer la misma unidad es un riesgo: hoy el único lugar donde se anota la reserva es una pizarra manual del depósito. Usar una actualización condicional en PostgreSQL para reservar stock es una decisión (ADR-002), con alternativas descartadas: una caché en Redis y reservar en el ERP, que no tiene reservas. Decir que el sistema "elimina los errores de stock" es una promesa indebida, porque una parte de esos errores ocurre en el estante, fuera del alcance de cualquier software.

Antipatrón. La frase de consenso "el sistema va a resolver el stock". Suena a descripción del producto, pero es un objetivo disfrazado de garantía. Nadie en la sala puede decir si se cumplió, y el cliente no sabe qué parte del problema queda afuera. Cuando el piloto muestre un faltante en picking, la discusión va a ser sobre quién mintió, no sobre qué hacer.

Cómo se verifica. Pedí la fuente de cada hecho, el episodio de cada riesgo, el dueño y las alternativas de cada decisión, y el criterio de aceptación de cada promesa. Si una promesa no tiene criterio, reescribila como criterio verificable o sacala de la propuesta. No hay término medio: una promesa sin criterio le cuesta credibilidad a todas las demás.

El flujo siguiente sirve como filtro para cualquier frase antes de presentarla. No es una regla mecánica: en los casos ambiguos, la pregunta de fondo es si alguien podría ser responsable de comprobar esa frase y con qué instrumento.

Probá el filtro con ocho frases de la propuesta de Nexo. Clasificá cada una y leé la explicación después de elegir. Muchas frases son mixtas, y la explicación te dice qué parte corresponde a cada categoría.

Dos de las ocho frases son trampas. La número 5 parece un hecho, pero sin fuente es un recuerdo de la reunión. La número 8 parece una promesa, pero en realidad es un límite declarado, y eso la vuelve más fuerte, no más débil. Una propuesta con límites escritos inspira más confianza que una que promete todo.

12.2 Trade-offs: lo que ganás, lo que pagás y la señal de revisión

"Usamos un monolito modular" no es una explicación para el cliente. Es una etiqueta. Lo que el cliente necesita es saber qué consigue con esa decisión, qué resigna y en qué momento el equipo va a reconsiderarla. "Mantuvimos pedidos y reservas juntos para que una confirmación no pueda quedar a mitad de camino; eso reduce complejidad operativa hoy. Si más adelante el stock necesita escalar o desplegarse de forma independiente, tenemos un criterio para revisar la decisión" sí conecta estructura con riesgo y costo.

Un trade-off bien presentado tiene cinco campos:

• Decisión: qué se eligió, en una frase.
• Lo que gana: qué problema concreto resuelve, con referencia a la regla o al requerimiento.
• Lo que paga: el costo, la limitación o el riesgo que la decisión introduce.
• Riesgo abierto: lo que sigue sin resolverse aunque la decisión sea correcta.
• Señal de revisión: la condición observable que obligaría a reabrir la decisión.

Si falta cualquiera de los cinco, el cliente va a hacer la pregunta que falta, y es mejor que la respuesta esté preparada. La comparación siguiente muestra la diferencia en la misma decisión.

La versión débil tiene dos problemas que el cliente detecta enseguida. El primero es que "escala bien" es una afirmación sin medida. El segundo es que "es lo que recomiendan" es autoridad externa: si el cliente recibe otra recomendación distinta, la conversación termina en quién tiene más prestigio. La versión fuerte no necesita nombres de patrones ni de proveedores para sostenerse.

La señal de revisión tiene que ser observable. "Si el volumen crece" no sirve, porque no dice cuánto, cuándo ni quién lo mide. Una señal útil tiene umbral, método de medición y condición. En Nexo, la referencia es NFR-01: p95 menor a 800 ms en el registro de pedido con 30 usuarios concurrentes. Todavía no hay medición, así que el umbral es una referencia de diseño, no un resultado. La señal solo tiene sentido después de la primera carga real, y hasta entonces la defensa debe decirlo.

Las decisiones también tienen ciclo de vida. Una propuesta no queda "aprobada para siempre": pasa por estados, y el cliente tiene que saber en cuál está cada una. El diagrama muestra el ciclo mínimo que usamos en el curso.

El estado Bloqueada no es un fracaso. Es la forma honesta de decir que la decisión existe, pero la evidencia o la autoridad todavía no. Por ejemplo, la reserva blanda de un pedido pendiente de autorización (RN-07) está bloqueada: el release la implementa sin expiración automática, porque el valor del plazo depende de medir la operación real.

Cuando el cliente no es técnico, el trade-off tiene que caber en una página sin perder la estructura. Un ADR (registro de decisión de arquitectura) resumido para no técnicos conserva los mismos campos que el registro completo, con el lenguaje de la operación. Este es el de la decisión de estructura del release:

1# ADR-001 · Monolito modular con un proceso de apoyo
2​
3Estado: vigente.
4​
5Qué decidimos: el sistema de pedidos se despliega como una sola aplicación, ordenada en módulos, más un proceso aparte que envía las tareas pendientes a preparación y a los proveedores externos.
6​
7Por qué: un pedido confirmado tiene que tener su reserva de stock y su registro de auditoría en el mismo lugar. Separarlos en servicios hoy obligaría a coordinar varios sistemas para algo que una transacción resuelve.
8​
9Qué ganamos: menos piezas para operar, una sola fuente para auditar y un equipo que puede entender el flujo completo de un pedido.
10​
11Qué pagamos: los módulos no se escalan ni se despliegan por separado. Hace falta disciplina para que los módulos no se mezclen.
12​
13Qué lo haría revisar: que el registro de pedido incumpla el umbral acordado en dos mediciones seguidas por causa de la aplicación y no de una consulta, o que aparezca un equipo que necesite desplegar el stock de forma independiente.
14​
15Alternativas que consideramos: servicios separados desde el inicio (descartada: más costo operativo y transacciones repartidas), y dejar la reserva en el ERP (descartada: el ERP no registra reservas).
16​
17Quién decide: la dueña de Nexo, con el equipo Eje Z.

El texto no tiene jerga ni nombres de patrones y responde las cuatro preguntas que el cliente va a hacer: qué cambia, por qué, qué cuesta y cuándo se revisa.

12.3 Cómo decir "todavía no lo sabemos" con estructura

La frase no debilita una propuesta cuando viene acompañada de un plan. "Todavía no tenemos suficiente evidencia para fijar el TTL de reserva. Lo dejaremos parametrizado y durante la primera semana mediremos cuántos pedidos quedan pendientes y cuánto demoran las autorizaciones. Después proponemos el valor." Eso es más profesional que elegir 24 horas porque parece razonable.

Esa respuesta tiene cinco partes, y todas son necesarias:

• Qué falta: el dato, la regla o la decisión concreta.
• Por qué importa: qué pasa si se elige mal.
• Cómo se resuelve: el método, la fuente y la duración.
• Quién decide: el dueño de la decisión, con nombre de rol.
• Qué queda bloqueado mientras tanto: qué no se hace hasta tener la respuesta.

Aplicado a la reserva de Nexo: qué falta es el valor del tiempo de vida de una reserva blanda. Importa porque una reserva corta libera stock que el vendedor ya prometió, y una larga congela unidades que nadie vende. Se resuelve midiendo, en la primera semana del piloto, cuántos pedidos quedan en PENDIENTE_AUTORIZACION y cuánto tarda cada autorización. Lo deciden el responsable de depósito y el comercial con ese dato delante. Mientras tanto, las reservas blandas no expiran solas: quedan hasta que alguien autorice o rechace el pedido.

Las respuestas que fallan suelen tener una o ninguna de esas partes. "Eso lo vemos después" no tiene plan ni dueño. "Depende" no dice de qué. "24 horas, porque es razonable" fija un valor sin evidencia y deja al cliente con la impresión de que el equipo decide por intuición. Este ejercicio te obliga a reescribir una de esas frases en la forma completa.

12.4 Cuestionar al cliente sin convertirlo en una pelea

El cliente puede estar equivocado sobre su propio proceso, especialmente cuando describe lo que "debería" ocurrir y no lo que ocurre. Nosotros también podemos estar equivocados. Por eso una contradicción se formula como evidencia: "Me dijiste que nunca se supera el límite, pero encontramos tres pedidos aprobados con firma manual. Quiero entender qué regla explica esos casos antes de automatizarla." No acusás; invitás a resolver una diferencia observable.

El método tiene tres movimientos, en este orden:

1. Pedir el episodio, no la regla. "¿Cuál fue el último caso que se aprobó por encima del límite?" obliga a describir algo que pasó. "¿Cuál es la política?" invita a repetir lo que debería pasar.
2. Preguntar por la trazabilidad. "¿Quedó registrado en algún lado quién lo aprobó y por qué?" revela si la práctica existe fuera del sistema y cuántas fuentes tiene.
3. Proponer la regla como pregunta. "¿Te parece que lo modelemos así?" deja que el cliente proponga la solución. Una regla que el cliente ayudó a formular se defiende sola.

Así se ve en una conversación con Marta (dueña) y Laura (administración y crédito), sobre la práctica de excepciones:

Marta: "Nunca autorizamos pedidos por encima del límite."

Equipo: "¿Me contás cómo fue el último caso que se aprobó por encima del límite?"

Laura: "Hubo varios. El de la semana pasada, por ejemplo, con un cliente de años."

Equipo: "Entendido. ¿Quedó registrado en algún lado quién lo aprobó y por qué?"

Laura: "En el audio y en mi cuaderno."

Equipo: "Entonces tenemos dos fuentes distintas para la misma excepción. Queremos que el sistema tenga una sola, con actor, motivo y regla aplicada. ¿Te parece que lo modelemos así?"

La conversación no contradice a Marta de frente, pero le muestra que su afirmación no coincide con la práctica, y le da a Laura un lugar para aportar la información que el equipo necesita. Lo que no hacemos es decir "eso no es lo que dijiste", "en realidad la regla es otra" o "eso no pasa". Cualquiera de esas frases convierte una diferencia de datos en una diferencia de personas.

12.5 Objeciones: separar pregunta, riesgo, preferencia y cambio de alcance

Una defensa técnica no se prepara para un cliente que asiente a todo. Prepará objeciones razonables: "¿por qué no hacerlo más simple?", "¿por qué no usamos una planilla?", "¿por qué tarda tanto si la IA programa rápido?", "¿por qué necesitamos esta fase de arquitectura?", "¿por qué no microservicios?", "¿qué pasa si el ERP cambia?", "¿cómo sé que esto no me deja atado a ustedes?". Una buena respuesta conecta costo, riesgo y evidencia, no autoridad personal.

El error más común es responder todas las objeciones con el mismo tono y el mismo tipo de argumento. Pero una objeción puede ser de cuatro clases, y cada clase necesita una respuesta distinta:

• Pregunta de información: el cliente quiere saber algo que el equipo puede averiguar o que todavía no se sabe. Se responde con el dato o con qué falta y cómo se obtiene.
• Riesgo: el cliente describe algo que puede salir mal. Se responde con el control, el dueño y la señal.
• Preferencia: el cliente prefiere una forma de hacer las cosas, por ejemplo una tecnología o un plazo. Se responde con trade-offs y con la señal que revisaría la opción.
• Cambio de alcance: el cliente pide algo que cambia una regla confirmada o el alcance. Se responde con un cambio visible en tiempo, costo, riesgo y pruebas, no con una negativa ni con un sí automático.

Este diagrama muestra el recorrido de una objeción desde que se escucha hasta que queda registrada.

Los pasos para responder una objeción tienen un orden que importa. Si saltás al paso de respuesta antes de identificar el tipo, la respuesta suele ser correcta para otra objeción.

Estas son las objeciones que la reunión de Nexo va a provocar. Para cada una dejamos la pregunta de fondo, la evidencia que la sostiene y la condición que cambiaría nuestra respuesta.

• "¿Por qué no hacemos todo de una vez?" Tipo: cambio de alcance o preferencia, según quién lo pida. Pregunta de fondo: qué parte del problema se resuelve primero. Evidencia: el backlog de 28 features, de las cuales 10 entran en el primer corte, 12 quedan fuera y 5 están bloqueadas. Qué la cambiaría: que aparezca un requisito que el primer corte no puede cumplir sin lo que se pospone. Respuesta modelo: "Preferimos demostrar el circuito crítico de pedido, crédito y stock, medirlo y ampliar con evidencia. El diseño deja rutas de extensión, pero no vamos a pagar hoy por complejidad hipotética."

• "¿Por qué no metemos IA para que decida el crédito?" Tipo: cambio de alcance. Pregunta de fondo: quién responde por una decisión que cambia dinero. Evidencia: la política de crédito no está unificada y hay excepciones por audio. Qué la cambiaría: una política validada y auditable, con datos y métricas propias. Respuesta modelo: "La IA puede ayudar a preparar información o detectar anomalías, pero la política de crédito cambia dinero y necesita reglas auditables. Primero automatizamos la política confirmada. Si luego quieren un modelo de riesgo, será otro problema con datos, métricas y autoridad propias."

• "Otro proveedor dice que microservicios es más escalable" Tipo: preferencia. Pregunta de fondo: qué problema medible resuelven los microservicios hoy. Evidencia: la transacción cruza pedidos, crédito y reservas, y el volumen no exige distribución. Qué la cambiaría: aislamiento operativo, equipos independientes o escalado desparejo demostrado. Respuesta modelo: "Puede ser una buena arquitectura cuando hay motivos para aislar escala, equipos o fallos. En este caso, la transacción cruza pedidos, crédito y reservas, y el volumen actual no justifica pagar coordinación distribuida. Dejamos criterios concretos para revisar la decisión si cambia el contexto."

• "Con IA esto debería estar en una semana" Tipo: preferencia, con una expectativa de plazo implícita. Pregunta de fondo: qué parte del trabajo no se acelera con IA. Evidencia: las decisiones pendientes (precio correcto, autoridad de crédito, reserva concurrente, falla del ERP). Qué la cambiaría: que esas decisiones estén tomadas y documentadas. Respuesta modelo: "La IA reduce mucho el tiempo de escribir y revisar código cuando el comportamiento está definido. Lo que no reduce es la necesidad de acordar qué precio es correcto, quién puede autorizar crédito, cómo evitamos reservar la misma unidad dos veces o qué hacemos si el ERP falla. Si salteamos esas decisiones, podemos producir más código en una semana y también más retrabajo."

• "¿No estamos sobrecomplicando?" Tipo: preferencia o riesgo. Pregunta de fondo: qué costo tiene cada mecanismo y qué pasa si se quita. Evidencia: una sobreventa o un pedido duplicado tiene costo real. Qué la cambiaría: que el riesgo que cubre un mecanismo no exista en la operación. Respuesta modelo: "Podemos simplificar y de hecho lo hicimos: no estamos proponiendo microservicios ni reemplazar todo el ERP. Sí mantenemos transacción e idempotencia porque una sobreventa o un pedido duplicado tiene costo real. Si quieren, les muestro qué riesgo cubre cada mecanismo y cuál sacaríamos si ese riesgo no existe."

Responder así abre la decisión. El cliente puede decir que cierto riesgo es aceptable y entonces la solución puede simplificarse. La arquitectura no se defiende como un dogma: se negocia con consecuencias visibles.

12.6 Límites honestos: qué no garantiza la solución

Un límite es una declaración escrita de lo que la solución no hace, en qué condiciones, y quién se hace cargo de eso. No es una excusa ni una cláusula legal. Es la parte de la propuesta que más protege al equipo y al cliente, porque evita que la expectativa se construya sola a partir de lo que se mostró en la demo.

Conviene escribir cada límite con tres columnas: lo que la solución garantiza, lo que no garantiza y de qué depende lo que no garantiza. El ejemplo clásico de Nexo es la diferencia entre reserva digital y exactitud física:

• Garantiza: dos pedidos concurrentes no reservan más unidades que las registradas en el sistema para un depósito y un SKU (AC-06, INV-01).
• No garantiza: que la unidad esté efectivamente en el estante. Un movimiento físico mal registrado o un robo no se corrigen con software.
• Depende de: el proceso de conteo y ajuste del depósito, y de que los quiebres en picking se registren como evento auditado.

Esa es la respuesta que el responsable de depósito necesita escuchar. El diálogo del manual lo muestra: "El sistema no va a fingir que la reserva lógica elimina el quiebre físico. Durante picking podés reportarlo, la reserva se ajusta con auditoría y el pedido vuelve a una decisión de sustitución." La respuesta no promete menos de lo que el software puede cumplir; promete exactamente lo que puede cumplir y dice dónde empieza lo que no puede.

Los límites no son solo técnicos. Hay límites comerciales (no se incluye la cuenta corriente completa en el primer release), límites de datos (los 41 acuerdos de precio sin vencimiento se revisan a mano) y límites de autoridad (la tolerancia Platino no está definida y la decide la dueña con administración). Si el cliente encuentra un límite que la propuesta no declaró, la defensa pierde credibilidad aunque el límite sea menor.

12.7 Registro de riesgos y deuda técnica: el artefacto que sostiene los límites

Los límites, los riesgos y la deuda técnica necesitan un lugar donde vivan. Si quedan en una reunión o en la cabeza de una persona, desaparecen en la primera discusión difícil. El artefacto es un registro de riesgos: una lista viva con una entrada por cada riesgo, desconocido o deuda, y cuatro campos obligatorios: tipo, dueño, señal y estado.

Tres distinciones importan:

• Riesgo: puede pasar. Se controla, se acepta o se transfiere, y tiene una señal que avisa si se está materializando.
• Desconocido: no sabemos si pasa ni cuánto. Su tratamiento es un plan de medición o una decisión pendiente, y tiene un dueño que tiene que responder.
• Deuda técnica: una concesión consciente. Hoy hacemos algo más simple o incompleto, sabiendo el costo que eso tiene y la condición bajo la cual vamos a pagarlo. "Lo arreglamos después" no es deuda registrada: no tiene costo, condición ni dueño.

El registro siguiente tiene entradas de los tres tipos del release de Nexo. Fijate en cómo cada entrada tiene una señal observable y un dueño con nombre de rol.

1proyecto: nexo-b2b-release-1
2actualizado_por: equipo Eje Z
3entradas:
4  - id: DESC-01
5    tipo: desconocido
6    titulo: Duración de la reserva blanda de un pedido pendiente (RN-07)
7    descripcion: No hay dato sobre cuánto tarda una autorización de crédito en la operación real.
8    impacto: puede congelar stock que nadie vende o liberar stock que el vendedor ya prometió
9    estado: BLOCKED
10    duenos: [responsable de depósito, comercial]
11    senal: pedidos en PENDIENTE_AUTORIZACION sin resolver al cierre del día, medidos durante la primera semana del piloto
12    decision_vinculada: RN-07
13  - id: RSK-01
14    tipo: riesgo
15    titulo: Stock físico distinto del registrado
16    descripcion: la pizarra y el ERP no coinciden con el estante en algunos SKU
17    impacto: el pedido se confirma y recién en picking aparece la falta
18    mitigacion: evento de quiebre durante picking, ajuste auditado y métrica semanal de diferencias
19    estado: aceptado con control
20    duenos: [responsable de depósito]
21    senal: cantidad de quiebres por semana y depósito, comparada con la línea base
22  - id: RSK-02
23    tipo: riesgo
24    titulo: Acuerdos de precio sin vencimiento
25    descripcion: en el game day había 41 acuerdos sin fecha de vigencia
26    impacto: se aplica un precio que la empresa ya no sostiene
27    mitigacion: el pedido queda pendiente de revisión comercial; no se inventa una vigencia
28    estado: abierto
29    duenos: [dueña de Nexo]
30    senal: pedidos con acuerdo sin vencimiento en revisión comercial
31  - id: DESC-02
32    tipo: desconocido
33    titulo: Tolerancia de crédito para clientes Platino (RN-02)
34    descripcion: el porcentaje o el monto de tolerancia no está validado
35    impacto: pedidos Platino sobre el límite sin autoridad clara
36    estado: BLOCKED
37    duenos: [dueña de Nexo, administración y crédito]
38    senal: decisión registrada antes del piloto
39    decision_vinculada: RN-02
40  - id: RSK-03
41    tipo: riesgo
42    titulo: Proveedor fiscal caído después del commit
43    descripcion: el pedido ya quedó confirmado y la emisión del comprobante no responde
44    impacto: pedido válido sin comprobante emitido
45    mitigacion: intención fiscal dentro de la transacción y worker con reintentos; el pedido queda como pendiente de facturación
46    estado: controlado por prueba T12
47    duenos: [equipo Eje Z]
48    senal: intentos fallidos del worker por día
49  - id: RSK-04
50    tipo: riesgo
51    titulo: Latencia del ERP en horario pico
52    descripcion: en el game day una consulta al ERP tardó 28 segundos
53    impacto: el vendedor espera o pierde la intención del pedido
54    mitigacion: timeout propuesto de 5 segundos y respuesta temporarily_unavailable
55    estado: abierto
56    duenos: [equipo Eje Z]
57    senal: p95 de consultas al ERP por día
58  - id: DEUDA-01
59    tipo: deuda
60    titulo: El ERP no conoce las reservas
61    descripcion: el stock del ERP queda desfasado respecto de las reservas del sistema nuevo
62    costo: revisión manual de disponibilidad en el ERP durante la etapa 1
63    condicion_de_pago: integración con el ERP definida después de medir el piloto
64    estado: aceptada
65    duenos: [dueña de Nexo]
66  - id: DEUDA-02
67    tipo: deuda
68    titulo: Emisión de comprobantes con CAE fuera del primer release
69    descripcion: la integración fiscal completa queda como integración posterior
70    costo: los pedidos quedan marcados como pendiente de facturación hasta emitir
71    condicion_de_pago: integración fiscal aprobada y probada contra el proveedor real
72    estado: aceptada
73    duenos: [dueña de Nexo, equipo Eje Z]

Cada entrada cumple una regla simple: si no tiene dueño, señal y estado, no es un riesgo gestionado, es una lista de preocupaciones. La deuda registrada tiene además costo y condición de pago. La condición importa porque convierte un "después" en algo que alguien puede revisar: la integración fiscal se paga cuando hay un proveedor aprobado y una prueba contra él, no cuando el equipo tenga tiempo.

Usá el registro en la reunión, no solo antes. Cuando el cliente pregunte por un tema, buscá la entrada, mostrá la señal y preguntá quién tiene el dato. Si la entrada no existe, es una señal de que hay que crearla antes de responder.

1Actuá como responsable de operaciones de Nexo B2B: escéptico y con poco tiempo.
2Leé la propuesta adjunta y el registro de riesgos.
3Planteá cinco objeciones concretas que un dueño haría sobre el primer release. Para cada una:
4- decí si es pregunta de información, riesgo, preferencia o cambio de alcance;
5- citá la parte de la propuesta que la provoca;
6- no inventes cifras ni plazos que no estén en los documentos.
7No respondas las objeciones. Marcá qué información falta para responderlas.

Vocabulario de la defensa

Repasá estos términos antes de la lección 12.2. Conviene que puedas explicar cada uno con un ejemplo de Nexo.

Errores frecuentes

• Síntoma: el cliente repite la misma objeción en cada reunión. Causa: respondiste la posición, no la pregunta de fondo, o no identificaste el episodio que la motiva. Corrección: repetí la objeción con tus palabras, pedí el episodio y clasificá el tipo antes de responder.
• Síntoma: el cliente pide "que prometan que no va a pasar". Causa: la propuesta tiene promesas sin criterio de aceptación. Corrección: reescribí cada promesa como criterio verificable (por ejemplo, AC-06) o como riesgo con control y dueño. Lo que no se puede verificar no se promete.
• Síntoma: el registro de riesgos existe pero nadie lo abre. Causa: las entradas no tienen dueño, señal medible ni estado actualizado. Corrección: cada entrada debe responder quién la mira, con qué dato y cuándo se cierra. Sin eso, es una lista de deseos.
• Síntoma: la deuda técnica se acepta "para después" y reaparece en el piloto. Causa: no hay costo, condición de pago ni dueño. Corrección: registrala como deuda con una condición observable para pagarla, por ejemplo "integración fiscal aprobada y probada contra el proveedor real".
• Síntoma: el equipo se pone a la defensiva cuando el cliente tiene razón. Causa: la defensa se volvió identidad y no una explicación. Corrección: volvé al hecho nuevo, preguntá qué condición cambió y decidí si el impacto obliga a revisar la decisión.

Para llevarte

• Antes de defender, separá hechos, riesgos, decisiones y promesas. Solo las promesas con criterio y evidencia entran al compromiso.
• Todo trade-off tiene cinco campos: decisión, ganancia, costo, riesgo abierto y señal observable de revisión.
• "Todavía no lo sabemos" es una respuesta completa cuando dice qué falta, por qué importa, cómo se resuelve, quién decide y qué queda bloqueado.
• Clasificá cada objeción como pregunta, riesgo, preferencia o cambio de alcance. Cada tipo se responde de forma distinta.
• Los límites se declaran por escrito y con dueño. Un registro de riesgos sin dueño ni señal no protege a nadie.