4.3 Taller E04: defender IN, OUT y BLOCKED

Al terminar esta lección

• Producir una frontera IN / OUT / BLOCKED del primer release de Nexo, con razón, evidencia y condición de reapertura por cada ítem.
• Redactar requerimientos funcionales refutables y NFR con estímulo, entorno, respuesta y medida.
• Convertir pasos actuales del proceso en requerimientos orientados al propósito, sin heredar el mecanismo.
• Defender oralmente un OUT y un BLOCKED frente a un cliente que insiste, sin sonar burocrático.
• Revisar tu entrega con un linter y con un agente de IA aceptando solo las observaciones que podés justificar.

Práctica E04 · Cortar el alcance del primer release

Situación. La dueña pide sumar recomendaciones de productos y automatización de WhatsApp porque "ya que estamos".

Entregá. frontera IN/OUT/BLOCKED con justificación; 5 requerimientos funcionales del slice; 4 NFR medibles.

Está listo cuando. cada IN responde a un objetivo; las exclusiones se pueden defender; los NFR tienen escenario y umbral; no se confunde solución actual con necesidad.

Solución comentada: Solución comentada E04. Comparala después de producir tu entrega.

Armá una frontera IN / OUT / BLOCKED del primer release de Nexo. Cada elemento debe tener una razón ligada a objetivo, evidencia, riesgo o dependencia. Si la razón es "para no hacer tanto", profundizá.

Los números del bloque "Entregá" son el contrato mínimo de evaluación: 5 requerimientos funcionales y 4 NFR. Los pasos de este recorrido te proponen llegar a 10 y 5 porque así se parece más a un catálogo real. Si el tiempo no te da, entregá el mínimo bien hecho antes que el máximo flojo.

Paso 0 · Preparar el material (10 minutos)

Objetivo. Tener a mano todo lo que vas a citar. Un requerimiento que no puede citar su origen vuelve a ser candidato.

Juntá seis cosas: el catálogo de evidencia (EV-01 a EV-08 más lo que sumaste en tus cuadernos de campo), las reglas RN-01 a RN-07 con su estado, el glosario y los desconocidos de tu entrega E03, la lista de 28 ideas de la lección 4.2 y los tres pedidos de la semana de observación que figuran más abajo. En las reglas, separá las del proceso actual (RN-01, RN-02 y RN-04) de las invariantes o políticas del sistema futuro derivadas del negocio (RN-03, RN-05, RN-06 y RN-07). Armá la estructura de archivos antes de escribir:

1mkdir -p nexo/docs/alcance nexo/requirements nexo/tools
2touch nexo/docs/alcance/frontera-release-1.yaml
3touch nexo/requirements/rf.yaml nexo/requirements/nfr.yaml

Un repositorio, aunque sea de texto, te obliga a versionar. Al final de cada paso hacé un commit con un mensaje que diga qué decidiste, no qué archivo tocaste.

Paso 1 · Objetivo y métrica (15 minutos)

Objetivo. Escribir el o los objetivos del release con una métrica y una línea base, antes de decidir qué entra.

Los pedidos de la semana de observación son tu dataset. Estos tres pedidos tardan casi lo mismo en cargarse, y sin embargo terminan de forma muy distinta:

Si transformás "agilizar pedidos" en "cargar una lista de productos en menos de dos minutos", podrías construir una interfaz excelente y dejar intacto el mayor tiempo de espera. El tiempo está en lo que ocurre después de la captura. La métrica candidata pasa a ser el tiempo desde la recepción hasta una decisión observable (confirmado, pendiente de autorización o rechazado con motivo), y una segunda métrica es el porcentaje de pedidos que necesitan volver a preguntar precio, crédito o stock por información que el sistema no puede resolver.

Ejemplo parcial. Un objetivo bien escrito para este release:

1- id: OBJ-1
2  statement: "Reducir el tiempo entre la recepción de un pedido y una decisión observable."
3  metric: "tiempo medio y p90 entre recepción y decisión (confirmado, pendiente, rechazado)"
4  baseline: "48311: 20 min; 48312: 330 min; 48313: 105 min (tres casos, no representativos)"
5  evidence: [EV-01, EV-04]
6  note: "la línea base real se mide con la consulta de la lección 4.2"

Paso 2 · La frontera IN / OUT / BLOCKED (25 minutos)

Objetivo. Decidir el estado de cada una de las 28 ideas, con razón, evidencia y condición de reapertura (o qué falta y quién lo resuelve). Además tenés que decidir qué hacer con los dos pedidos nuevos de la dueña: recomendaciones y automatización de WhatsApp.

Recorré las 28 ideas de la lección 4.2 y decidí vos antes de mirar su veredicto. Hacelo en este orden, que es el del árbol de decisión de la lección 4.1:

1. ¿Responde a un objetivo con evidencia? Si no, OUT.
2. ¿Las reglas y datos que necesita están confirmados? Si sí y aporta valor observable, IN.
3. Si no están confirmados: ¿hay alguien que pueda resolverlo? Si sí, BLOCKED con ese nombre; si no, OUT hasta que aparezca.

Ejemplo parcial. Tres ítems resueltos en el formato que tenés que usar:

1items:
2  - id: F08
3    name: "Reserva por depósito sin sobreventa"
4    state: IN
5    objective: OBJ-2
6    evidence: [EV-05]
7    exit_criteria: "con una unidad disponible y dos reservas simultáneas, exactamente una confirma"
8  - id: F13
9    name: "Chatbot de WhatsApp que toma pedidos"
10    state: OUT
11    reason: "los pedidos no fallan por el canal de entrada sino por validaciones posteriores"
12    reopen_when: "la medición muestra que la captura es el cuello de botella"
13  - id: F25
14    name: "Reserva con expiración automática"
15    state: BLOCKED
16    missing: "cuánto tiempo puede esperar una reserva sin autorización firme (RN-07)"
17    needed_from: "depósito y comercial"
18    resolves_by: "medición de la primera semana de operación"

Paso 3 · Requerimientos funcionales (25 minutos)

Objetivo. Escribir los RF del slice en lenguaje verificable, cada uno con su regla, su evidencia, su objetivo y su refutación. Mínimo 5; recomendado 10.

Evitá mencionar componentes de interfaz salvo que la interacción forme parte del contrato. Usá la plantilla de la lección 4.1: cuando [condición], el sistema [respuesta observable], [y deja/no deja] [efecto verificable], según [RN].

Ejemplo parcial. F09, estado visible del pedido. Fijate qué se evita decir:

1- id: RF-08
2  text: >
3    El sistema expone el estado de cada pedido (pendiente de autorización,
4    confirmado, rechazado) y no muestra un pedido como confirmado mientras la
5    evaluación de crédito siga abierta.
6  rules: [RN-01, RN-02]
7  sources: [EV-03, "minuta de la reunión 1 (Laura, pantalla compartida)"]
8  objective: OBJ-1
9  refutation:
10    - "un pedido con crédito pendiente nunca aparece como confirmado"
11    - "al autorizarse, el estado cambia y queda registrado quién lo hizo"

No dice "pantalla", "botón" ni "notificación". Habla de estados y de una condición que se puede contradecir. Fijate también en las fuentes: EV-03 (la vendedora, sobre Platino) sostiene el estado pendiente de autorización de RN-02, mientras que RN-01 se apoya en la minuta de la reunión 1. Y "confirmado" es CONFIRMADO_COMERCIAL (pasó crédito); la colisión con el "confirmado" de depósito se cierra en el modelo de estados.

Paso 4 · NFR medibles (20 minutos)

Objetivo. Escribir los NFR como escenarios con estímulo, entorno, respuesta y medida. Mínimo 4; recomendado 5. Tienen que incluir al menos performance, auditoría y seguridad, y disponibilidad operativa si la podés justificar.

Ejemplo parcial. NFR-03, seguridad, completo y con el estado del umbral:

1- id: NFR-03
2  quality: seguridad
3  stimulus: "un vendedor intenta operar un cliente que no está en su cartera"
4  environment: "sesión autenticada, cualquier horario"
5  response: "el sistema deniega la operación sin revelar datos del cliente y registra el intento"
6  measure: "100% de los intentos denegados quedan auditados (actor, instante, cliente)"
7  status: "cartera definida por administración; permiso explícito por acordar"
8  why: "reduce exposición y errores de contexto"

Antes de escribir los tuyos, fijate si tu métrica pasa la prueba de la pregunta incómoda: ¿qué dato tendría que mirar alguien para decir "se cumplió" o "no se cumplió"? Si la respuesta es "depende", reescribilo.

Paso 5 · De pasos actuales a propósitos (10 minutos)

Objetivo. Convertir tres pasos actuales del proceso en requerimientos orientados al propósito, y decir qué detalle de implementación eliminaste.

Elegí tres pasos de la reconstrucción AS-IS: por ejemplo reescribir los códigos del WhatsApp en el ERP, mirar la planilla de cheques antes de aprobar, mandar un audio para autorizar, imprimir el pedido o corregir un SKU con el Excel personal del vendedor.

Paso 6 · Defender dos OUT y dos BLOCKED (15 minutos)

Objetivo. Prepararte para defender cada decisión en 60 segundos sin sonar burocrático. La situación de la práctica ocurre así:

En la reunión de cierre de alcance, Marta propone: "Ya que estamos, sumemos recomendaciones de productos y que el chatbot tome los pedidos por WhatsApp. Se lo vendemos como diferencial."

Practicá la respuesta en voz alta con la simulación y después escribila.

Paso 7 · Revisión con linter y con IA (15 minutos)

Objetivo. Pasar tu catálogo por dos filtros: uno mecánico y uno de criterio. Primero el mecánico, porque es gratis:

npx tsx nexo/tools/req-lint.ts nexo/requirements/rf.yaml

El script es el que viste en la lección 4.1. Cada línea de salida es una pregunta que tenés que contestar, no un error automático: un "vocabulario de interfaz" puede ser legítimo si la interacción es parte del contrato. Corregí lo que corresponda y anotá lo que decidiste dejar.

Después hacé una revisión con IA buscando requisitos que no sean refutables, mezclen política con mecanismo o contengan adjetivos no medibles. Aceptá solo observaciones que puedas justificar.

1Rol: revisor de requerimientos. No agregues requerimientos nuevos.
2​
3Contexto adjunto: objetivos (OBJ-1, OBJ-2), reglas RN-01 a RN-07 con su
4estado, glosario y desconocidos de E03, evidencia EV-01 a EV-08, frontera
5IN/OUT/BLOCKED y mis archivos rf.yaml y nfr.yaml.
6​
7Para cada RF y cada NFR devolvé:
81. Si es refutable, con un caso que lo contradiga.
92. Si mezcla política con mecanismo, citando la frase.
103. Si contiene un adjetivo sin medida o un número sin fuente.
114. Si cita IDs que no existen en los archivos adjuntos.
12​
13No propongas valores para RN-02 ni RN-07. Si falta información, escribí "falta: ...".

Cómo revisar lo que devuelve. Para cada observación respondé tres preguntas: ¿el ID que menciona existe en mi catálogo?, ¿el caso que propone asume una regla BLOCKED?, ¿puedo explicar con una frase mía por qué la acepto? Si alguna respuesta es no, la descartás. Anotá en la hoja de entrega una propuesta que rechazaste y por qué: ese es el campo que más revela criterio.

Nexo B2B · La semana en que "agilizar pedidos" dejó de ser un requisito

Hasta este punto el equipo de Nexo repetía una frase cómoda: "queremos que cargar pedidos sea más rápido". Sonaba como un objetivo, pero mezclaba tres problemas distintos. Durante una mañana de observación aparecen los tres pedidos que viste en el paso 1. Tardan casi lo mismo en cargarse y, sin embargo, uno sale en veinte minutos, otro queda detenido hasta la tarde y el tercero termina cancelado. La diferencia no está en escribir los SKU. Está en las decisiones que ocurren después.

El pedido 48311 pertenece a un cliente estándar con saldo disponible. El vendedor copia dieciocho ítems desde WhatsApp, el sistema encuentra todos los productos y depósito confirma existencia. El 48312 tiene solo seis ítems, pero uno depende de un acuerdo de precio negociado que figura en el Excel de precios especiales, y solo puede confirmarlo el responsable comercial, que es quien mantiene ese Excel. El 48313 tiene nueve ítems y stock aparente, aunque la cuenta corriente supera el límite. El vendedor dice que "seguro lo aprueban porque compra mucho", pero no puede señalar una regla escrita ni una autorización previa equivalente.

En el playback, Nexo intenta sumar "automatizar autorizaciones de crédito" al primer release. El equipo no lo acepta todavía. Hay evidencia de que la autorización consume tiempo, pero no existe una política suficientemente definida: la decisión queda BLOCKED (F26). Sí entra mostrar el estado de evaluación, conservar quién tomó la decisión y evitar que un pedido aparente estar confirmado mientras el crédito sigue abierto. El software puede hacer visible una decisión humana sin inventar cómo debe tomarse.

El alcance del slice queda más pequeño y, a la vez, más útil: registrar un pedido con precio resuelto desde una fuente autorizada, verificar disponibilidad, evaluar la regla de crédito conocida, reservar stock cuando corresponda y devolver un resultado explícito. Las excepciones cuya política no está confirmada quedan visibles como pendientes, no escondidas dentro de un "caso especial". El requisito nace del problema observado, no de la pantalla que alguien imaginó en la primera reunión.

Nexo B2B · Expediente 04: backlog que se achica al entender mejor

La primera lista tenía 28 features: portal, carrito, historial, cuenta corriente, recomendaciones, facturación, tracking, sustitutos, reportes. Después de discovery, el primer horizonte se reduce a un conjunto más exigente pero coherente: intención de pedido, precio autoritativo, crédito, reserva, autorización y entrega a preparación. El backlog se hizo más pequeño y el problema más profundo.

Esto no es perder oportunidades. Es separar valor futuro de dependencias actuales. El historial puede agregarse después sin poner en riesgo la confirmación. Un motor de sustituciones necesita conocimiento que hoy no existe. La priorización cambia porque el equipo entiende qué sostiene la promesa central.

Cuaderno de campo 04 · Requerimientos que sobreviven a una revisión hostil

Entregable: 10 RF, 5 NFR, frontera IN/OUT/BLOCKED y justificación de prioridad. Es la versión ampliada del contrato mínimo (5 RF y 4 NFR).

1. Para cada RF escribí un contraejemplo que demostraría incumplimiento.
2. Para cada NFR escribí entorno y métrica. Si no podés medirlo, reescribilo o eliminalo.
3. Pedile a un compañero que intente mover un OUT a IN. Defendé con evidencia, riesgo y dependencia, no con preferencia personal.
4. Revisá cada requisito buscando palabras de UI. Si aparece "botón", "pantalla" o "modal", preguntá si el mecanismo es realmente obligatorio.
5. Mapeá cada requisito prioritario a un objetivo de negocio o a un riesgo. Los huérfanos necesitan justificación o eliminación.

Criterio de revisión. Un backlog más largo no es más completo. La calidad está en que cada elemento tenga razón de existir y criterio para saber si está cumplido.

Errores frecuentes

Para llevarte

• Una frontera defendible tiene, por cada ítem, razón, evidencia y condición de reapertura o qué falta y quién lo resuelve.
• El "ya que estamos" del cliente se contesta con el problema detrás de la idea, no con presupuesto ni complejidad.
• Un RF sin refutación, sin regla ni evidencia, todavía no es un RF.
• Un NFR sin estímulo, entorno, respuesta y medida es un adjetivo; el umbral que no se midió se marca como propuesto.
• Corré el linter antes de pedirle revisión a una persona o a un agente: lo mecánico se resuelve gratis.
• Registrá qué propuesta de IA rechazaste y por qué: ahí se ve tu criterio.

Hoja de entrega 4 · 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 4 · la frontera es defendible

Guardá tu entrega

Cuando termines tu entrega, compará tu razonamiento con la solución comentada E04. No hay una única respuesta correcta: la comparación busca fuentes, decisiones y evidencia.