4.2 Aceptación, prioridades y trazabilidad

Al terminar esta lección

• Derivar un requerimiento desde el propósito de un paso manual, sin copiar el mecanismo del proceso actual.
• Triar un backlog de 28 ideas en IN, OUT y BLOCKED y justificar cada veredicto con evidencia.
• Definir aceptación y métricas con línea base antes de diseñar, incluyendo una consulta SQL sobre datos exportados del cliente.
• Priorizar combinando valor observable, reducción de riesgo, aprendizaje y dependencia.
• Negociar un OUT con el cliente dejando una condición de reapertura y un responsable.

4.6 Derivar requerimientos sin automatizar desperdicio

Una vez entendido el proceso aparece una tentación nueva: convertir cada paso manual en una función. Esa traducción uno a uno produce software que imita las limitaciones del proceso anterior. El trabajo correcto es volver a los objetivos, reglas y fricciones, y preguntar qué resultado debe garantizar el sistema y qué decisiones deben permanecer humanas.

Por ejemplo, "imprimir el pedido para llevarlo a depósito" no se convierte en RF-17 Imprimir pedido. Primero preguntamos qué propósito cumple. Si el papel hace visible una cola de preparación, el requisito puede ser que depósito reciba y priorice pedidos confirmados. El mecanismo futuro podría ser una vista, una impresora, una pantalla industrial o una integración. El requisito conserva el objetivo sin congelar una solución.

Una nota de vocabulario para toda la lección: "confirmado" como estado significa CONFIRMADO_COMERCIAL (el pedido pasó crédito). Para depósito "confirmado" quiere decir otra cosa; esa colisión se cierra en el modelo de estados.

Este ejercicio de preguntar "¿para qué?" se repite con cada paso de la reconstrucción AS-IS:

La tercera fila muestra un matiz importante: el software puede hacer visible una decisión humana sin inventar cómo debe tomarse.

También conviene separar requisito de política. "El sistema debe bloquear pedidos que exceden el límite" parece funcional, pero contiene una regla que quizás admita autorizaciones. Una formulación mejor describe la capacidad y referencia reglas trazables: el sistema debe evaluar la exposición de crédito y producir aprobado, requiere autorización o rechazado según RN-01 y RN-02. Cuando cambie la política comercial no hay que reescribir la intención del caso de uso.

4.7 Requisitos negativos y fuera de alcance

Definir lo que el sistema no hará evita una fuente enorme de retrabajo. Un fuera de alcance no es una lista de cosas olvidadas: es una decisión deliberada. En el primer release de Nexo podemos decidir que el sistema no gestione cuentas corrientes completas, no reemplace el ERP fiscal y no automatice sustituciones de productos sin aprobación. Esas exclusiones protegen el slice y hacen que la propuesta sea defendible.

BLOCKED es diferente de OUT. OUT significa que decidimos no incluirlo. BLOCKED significa que todavía no hay evidencia suficiente para decidir. Esta diferencia tiene que sobrevivir hasta el Sprint de Arquitectura. Si una política de reserva depende de un TTL desconocido (RN-07), no la escondemos dentro de una estimación: el diseño relacionado queda condicionado.

Nexo B2B · El backlog de 28 ideas

Después de la primera semana, el borrador comercial contiene veintiocho ideas: portal B2B, chatbot, carga por foto, stock en tiempo real, autorización automática de crédito, recomendaciones, dashboard, app de depósito, integración fiscal, notificaciones, seguimiento de transporte y varias más. La lista parece progreso, pero mezcla dolores, soluciones, apuestas y deseos.

Veintiocho ideas no son veintiocho requerimientos. Antes de decidir nada, el equipo hace lo único que escala: volver a la evidencia y preguntar qué problema sostiene cada ítem. Para eso primero hay que poder distinguir qué tipo de cosa es cada línea.

Con esa mirada, la tabla completa del borrador queda así. La última columna no es una votación: es el resultado de preguntarle a cada ítem qué evidencia lo sostiene, qué regla necesita y si alguien puede resolverlo.

El resultado: diez ítems IN, doce OUT, cinco BLOCKED y uno que se disuelve. El portal no desapareció; se descompuso en lo que de verdad sostiene la evidencia. En este release esas capacidades (F02 a F05) las usan los vendedores, que son quienes hoy arman y confirman cada pedido; el portal para clientes sigue fuera, como ya lo dejaba el slice candidato del módulo 1, y se apoya después sobre las mismas capacidades. El chatbot pierde prioridad porque los pedidos no fallan principalmente por el canal. En la ronda de observación de la primera semana, doce de quince pedidos seguidos de punta a punta consumieron tiempo en validaciones posteriores a la captura; solo dos tuvieron problemas de interpretación del mensaje. Carga por foto queda como experimento futuro porque el mayor tiempo está en decidir precio, crédito y stock.

Nexo B2B · El primer corte de alcance se rompe

Después del playback, Marta, la dueña, insiste en que "el primer release tiene que incluir cuenta corriente para que el cliente vea todo". El equipo pregunta qué significa "todo". Aparecen saldos, comprobantes, cheques pendientes, notas de crédito, vencimientos, reclamos y conciliación. La frase agrega un subdominio entero que no era necesario para confirmar un pedido.

La respuesta profesional no es decir que no porque complica el desarrollo. Es explicar el costo de acoplar dos objetivos. El slice inicial necesita una lectura de la exposición de crédito para decidir un pedido, sin convertir el producto en un sistema completo de cuentas corrientes. Mostrar un saldo resumido podría ser una capacidad posterior o una integración de solo lectura.

Probá esta conversación. No hay una única salida buena: cada elección abre un camino con consecuencias distintas.

Al mismo tiempo, Sergio, de depósito, pide que el sistema sugiera sustitutos automáticamente cuando falta stock. En observación vimos que las sustituciones dependen de marca, compatibilidad y preferencia del cliente, y que no existe una matriz confiable. Esa funcionalidad queda BLOCKED (F24), no porque sea mala idea, sino porque la empresa todavía no posee el conocimiento estructurado para automatizarla con seguridad.

Dejar la decisión por escrito

Las dos conversaciones terminan en un registro corto, no en un recuerdo. Este es el formato que usa el equipo:

1## DEC-04-01 · Cuenta corriente completa queda OUT del release 1
2​
3**Contexto.** Marta pidió "cuenta corriente para que el cliente vea todo" (reunión de playback).
4Al desglosar aparecen siete capacidades (saldos, comprobantes, cheques, notas de crédito,
5vencimientos, reclamos, conciliación). El release necesita solo una: leer la exposición
6de crédito para decidir un pedido (RN-01).
7​
8**Alternativas consideradas.**
9- A. Incluir la cuenta corriente completa. Descartada: agrega un subdominio entero y
10  depende de cheques pendientes, que están BLOCKED (F27).
11- B. Mostrar al cliente un saldo resumido de solo lectura. Descartada por ahora:
12  sin una fuente confiable de "comprometido", el número que se muestre puede ser incorrecto.
13- C. OUT con lectura interna de exposición. Elegida.
14​
15**Decisión.** C. La lectura de exposición entra en F06. La vista al cliente es F23, OUT.
16​
17**Reabrir cuando** exista evidencia de reclamos de clientes por falta de comprobantes
18y una fuente confiable de saldos. Responsable de reabrir: Marta.

El valor de este registro está en la sección de alternativas: cuando alguien pregunte en tres meses "¿por qué no mostramos el saldo?", la respuesta ya está escrita y con sus razones.

4.8 Aceptación y métricas antes del diseño

Un requerimiento útil permite imaginar cómo demostrarlo. "Agilizar pedidos" no puede probarse. "Para pedidos válidos de hasta 50 líneas, el vendedor no debe recargar manualmente SKU ya identificados por el cliente" sí puede observarse. No toda métrica es de performance técnica: puede ser tiempo de ciclo, cantidad de dobles cargas, errores de precio, pedidos que requieren intervención o porcentaje de excepciones.

Lo que se mide antes de construir es la línea base. Sin ella, cualquier mejora posterior es una opinión. En Nexo, Sistemas exportó del ERP los estados reales de los pedidos de las últimas semanas (la tabla erp_pedido_estados de la lección 2.2), y con esa exportación se puede aproximar el tiempo que hoy tarda un pedido en llegar a una decisión. Ojo: la consulta trabaja con los estados del ERP legacy, no con los del sistema futuro.

1-- Línea base: minutos entre el ingreso al ERP y la primera aprobación.
2-- Fuente: exportación de Sistemas (lección 2.2):
3--   erp_pedido_estados(pedido, estado, cambiado_en, usuario)
4-- Estados del ERP legacy: INGRESADO, EN_REVISION, APROBADO, IMPRESO,
5--   MODIFICADO, PREPARADO, FACTURADO, DESPACHADO.
6-- El ERP no tiene "pendiente de autorización" ni "rechazado": APROBADO es la
7-- única decisión que la exportación permite fechar.
8with hitos as (
9  select pedido,
10         min(cambiado_en) filter (where estado = 'INGRESADO') as ingresado_en,
11         min(cambiado_en) filter (where estado = 'APROBADO')  as aprobado_en
12  from erp_pedido_estados
13  group by pedido
14)
15select
16  count(*)                                                        as pedidos,
17  round(avg(m.minutos)::numeric, 1)                               as promedio_min,
18  round(percentile_cont(0.5)  within group (order by m.minutos)::numeric, 1) as p50_min,
19  round(percentile_cont(0.9)  within group (order by m.minutos)::numeric, 1) as p90_min
20from hitos h
21cross join lateral (
22  select extract(epoch from (h.aprobado_en - h.ingresado_en)) / 60 as minutos
23) m
24where h.ingresado_en >= current_date - interval '28 days'
25  and h.aprobado_en is not null;

La otra métrica candidata, cuántos pedidos necesitaron intervención posterior a la captura, no sale del ERP: el ERP no registra por qué se tocó un pedido (a lo sumo, que pasó a MODIFICADO). Los tipos de intervención los anotó el equipo en la muestra observada de 60 pedidos (lección 3.2), y la segunda consulta corre sobre esa muestra, cargada a mano en dos tablas:

1-- % de pedidos con al menos una intervención posterior a la captura.
2-- Fuente: muestra observada de 60 pedidos (lección 3.2), cargada a mano en
3--   muestra_pedido(pedido) y muestra_intervencion(pedido, tipo).
4-- Estos tipos NO salen del ERP: la exportación solo registra estados.
5select
6  count(*) as pedidos,
7  count(*) filter (where exists (
8    select 1 from muestra_intervencion i
9    where i.pedido = p.pedido
10      and i.tipo in ('CORRECCION_SKU', 'REVISION_PRECIO',
11                     'AUTORIZACION_CREDITO', 'DIFERENCIA_FISICA')
12  )) as con_intervencion,
13  round(100.0 * count(*) filter (where exists (
14    select 1 from muestra_intervencion i
15    where i.pedido = p.pedido
16      and i.tipo in ('CORRECCION_SKU', 'REVISION_PRECIO',
17                     'AUTORIZACION_CREDITO', 'DIFERENCIA_FISICA')
18  )) / nullif(count(*), 0), 1) as porcentaje
19from muestra_pedido p;

Antes de confiar en los números, leé sus límites. INGRESADO se registra cuando la vendedora carga el pedido, no cuando llega el mensaje por WhatsApp (en el 48172, la foto llegó a las 10:02 y el ERP marca INGRESADO a las 10:08); la exportación subestima el tiempo real. Además, cambiado_en es la hora en que alguien cargó el cambio, no la hora en que ocurrió, y los pedidos que nunca llegan a APROBADO quedan fuera del cálculo. Es una línea base conservadora, y por eso se complementa con observación directa, como en el pedido 48231 (de 08:47 a 09:51). El dato exportado dice cuánto pasa desde que el pedido está en el ERP, y no cuánto desde que el cliente lo mandó.

Con eso se puede armar una tabla de aceptación a nivel de objetivo:

Las dos últimas filas no se suman: la reserva evita la carrera digital, pero no arregla un estante que no coincide con el registro. Estas métricas se vuelven a usar al defender el valor frente al cliente, así que conviene elegirlas bien ahora.

4.9 Priorización: valor, riesgo y dependencia no son lo mismo

Después de delimitar alcance todavía queda decidir secuencia. Una funcionalidad puede tener alto valor pero depender de una regla no resuelta. Otra puede tener valor moderado y eliminar un riesgo arquitectónico temprano. Priorizar solamente por "lo que más pide el cliente" o por facilidad técnica produce roadmaps frágiles.

La heurística considera cuatro cosas: valor observable, reducción de riesgo, aprendizaje y dependencia. El primer slice de Nexo justifica resolver precio, crédito y reserva porque ahí se concentran las decisiones que determinan si un pedido puede confirmarse. Una pantalla de historial puede ser valiosa, pero no reduce ese riesgo central.

El portal completo ocupa el cuadrante incómodo: mucho valor visible pero poco riesgo reducido. Construirlo antes de definir precio y confirmación solo escala la ambigüedad. A veces el primer slice que conviene construir no es el más visible para el cliente, sino el que reduce un riesgo estructural y crea una base verificable para lo demás. Esa decisión tiene que poder explicarse en lenguaje de negocio.

4.10 Requisitos no funcionales que nacen de operación real

Los NFR no deben salir de una lista estándar. Disponibilidad importa distinto si los vendedores trabajan solo de 8 a 18 que si hubiera un portal 24/7. Performance depende de volumen y momento. Recuperación depende de cuánto dato puede perderse. Seguridad depende de qué acciones tienen impacto comercial o legal.

Para Nexo, la latencia se enfoca en búsqueda y confirmación durante horario comercial; la auditoría, en autorizaciones y cambios de precio; la disponibilidad, en la capacidad de registrar pedidos; la recuperación, en no perder pedidos confirmados. Si no podemos explicar el daño de incumplir un NFR, quizá no es prioritario.

Nexo B2B · La palabra "rápido" se convierte en escenario

Marta dice "el portal tiene que volar". En vez de prometer 100 ms, el equipo pregunta qué demora interrumpe el trabajo. Los vendedores muestran que esperan varios segundos al buscar un SKU, mientras que la confirmación puede tardar algo más si está haciendo validaciones. Se acuerda medir la búsqueda interactiva por separado de la confirmación transaccional.

Dos operaciones, dos tolerancias. Un vendedor que busca "tornillo 6 mm" y espera cuatro segundos pierde el hilo; uno que confirma un pedido de cincuenta líneas tolera medio segundo más si sabe que están corriendo validaciones. El escenario resultante para la confirmación es NFR-01 (p95 del registro de pedido menor a 800 ms con 30 usuarios concurrentes). Para la búsqueda queda el escenario y el umbral en blanco:

1- id: NFR-05
2  quality: latencia
3  stimulus: "un vendedor busca un producto por SKU o descripción"
4  environment: "horario comercial, 30 usuarios concurrentes, catálogo completo (más de 8.000 productos)"
5  response: "el sistema devuelve coincidencias ordenadas"
6  measure: "p95 < [umbral por definir]"
7  status: "sin umbral: se mide en prototipo con búsquedas reales antes de comprometerlo"
8  why: "es la operación que más veces repite un vendedor en el día"

La especificación no inventa una cifra antes de medir. El 800 ms de NFR-01 es un umbral propuesto, marcado como tal; el de NFR-05 ni siquiera se propone todavía. Las dos decisiones son honestas con lo que se sabe.

Microtaller · Defender un OUT

4.11 Derivar requerimientos como una cadena de razonamiento

Un requerimiento defendible no aparece porque una persona pidió una pantalla. Aparece cuando podemos conectar una necesidad observable con un comportamiento y con una evidencia que permitirá verificarlo. La cadena es: problema o riesgo, objetivo, regla o restricción, comportamiento requerido, criterio de aceptación. Si falta un eslabón, el equipo corre el riesgo de implementar una preferencia sin saber qué problema resuelve.

Aplicada al caso más delicado, la reserva, la cadena se ve así. El pedido 48172 pedía tres unidades de AX-442. En CBA había ocho en el ERP, pero seis ya estaban reservadas (marcadas a mano en la pizarra de depósito) para pedidos impresos y todavía no preparados, que el ERP no descontaba: quedaban dos vendibles, faltaba una unidad, y se descubrió recién en el picking a las 10:31. En el estante había ocho: no fue un error de conteo, sino una carrera digital. Ese episodio es la evidencia.

Fijate cómo cambió "stock en tiempo real". La propuesta inicial prometía exactitud física perfecta, algo que Nexo no puede garantizar. Reformulada como requisito verificable: al confirmar una reserva, el sistema debe preservar disponible >= 0 para la fuente autoritativa por depósito; si durante el picking se detecta un quiebre físico, debe registrar el evento y volver el pedido a un estado de resolución. La primera frase vendía una ilusión; la segunda expresa una garantía que el software sí puede defender.

"Automatizar crédito" también se divide. Para clientes dentro del límite con datos completos, el sistema puede decidir automáticamente (F06). Para excepciones, conserva una autorización humana registrada (F07). Los casos con cheques pendientes sin fuente confiable (F27) y la tolerancia PLATINO (F26) quedan BLOCKED. El resultado no es menos ambicioso: es una frontera que distingue automatización segura de automatización prematura.

Un ejemplo de cómo quedan esos requerimientos como artefacto, con trazabilidad y refutación:

1# file: requirements/rf.yaml  (fragmento del catálogo de Nexo)
2- id: RF-03
3  text: >
4    Al armar un pedido, el sistema resuelve el precio de cada línea desde la
5    lista vigente y los acuerdos autorizados; ignora cualquier precio enviado
6    por el cliente.
7  rules: [RN-03]
8  sources: [EV-04]
9  objective: "precios-correctos"
10  refutation:
11    - "si el request incluye unitPrice distinto al autorizado, el pedido usa el autorizado"
12    - "un acuerdo vencido no se aplica a un pedido posterior a su vencimiento"
13​
14- id: RF-06
15  text: >
16    Al confirmar, el sistema reserva la cantidad pedida por depósito y SKU; si
17    el disponible no alcanza, no confirma y devuelve los faltantes.
18  rules: [RN-05]
19  sources: [EV-05]
20  objective: "sin-promesa-duplicada"
21  refutation:
22    - "con una unidad disponible y dos confirmaciones simultáneas, exactamente una reserva"
23    - "el disponible final nunca es negativo"

Estos dos están a propósito incompletos como catálogo: el resto lo construís vos en la práctica. Pero ya muestran el patrón: cada uno cita una regla y una evidencia, y trae su refutación.

Cuando una regla todavía está abierta, el requerimiento dependiente puede quedar BLOCKED sin bloquear el proyecto entero. Podemos diseñar la búsqueda de catálogo mientras la política de crédito sigue abierta, pero no aprobamos el flujo de confirmación si ese cálculo define si un pedido existe o queda pendiente. La incertidumbre se localiza, no se derrama.

1Revisá la frontera de Nexo (adjunta) contra las evidencias EV-01 a EV-08, las
2reglas RN-01 a RN-07 con su estado, el glosario y los desconocidos de E03 (adjuntos).
3​
4Para cada ítem IN devolvé: (a) la evidencia que lo sostiene, (b) si falta alguna
5regla confirmada, (c) un caso que lo refute.
6Para cada ítem OUT devolvé qué evidencia haría falta para reabrirlo.
7Marcá cualquier IN que dependa de una regla BLOCKED y cualquier RF que mencione
8un componente de interfaz.
9​
10No propongas valores para RN-02 ni RN-07. No agregues ítems nuevos.
11Si no encontrás evidencia para un ítem, escribí "sin evidencia".

La respuesta típica de un agente marca como "sin evidencia" justamente los ítems que más te cuesta soltar. Es una pista útil, no un veredicto: volvé a tu cuaderno de campo y fijate si la evidencia existe y no la citaste, o si de verdad no existe.

Nexo B2B · El backlog se reduce mientras aumenta el conocimiento

Cuando Marta pregunta por qué la primera versión ya no incluye chatbot ni dashboard, el equipo muestra la cadena de evidencia: doce de quince pedidos observados consumieron tiempo en validaciones posteriores a la captura; solo dos tuvieron problemas de interpretación del mensaje. La prioridad se conecta con episodios, no con una preferencia técnica. Nexo acepta concentrar el primer release en una confirmación confiable para los vendedores; el autoservicio del cliente se construye después sobre esa base.

La frontera resultante, ya con motivo y condición de reapertura en cada decisión:

1release: nexo-release-1
2objective: "Reducir el tiempo entre recepción de un pedido y una decisión observable."
3in:
4  - "F02 Catálogo con búsqueda"
5  - "F03 Identificación de cliente y cartera"
6  - "F04 Armado y envío del pedido"
7  - "F05 Precio autoritativo"
8  - "F06 Crédito estándar"
9  - "F07 Autorización de excepción registrada"
10  - "F08 Reserva por depósito"
11  - "F09 Estado del pedido visible"
12  - "F10 Entrega a preparación (marca pendiente de facturación)"
13  - "F11 Equivalencias de SKU vigentes"
14out:
15  - { item: "F12 Recomendaciones", reopen_when: "existe una métrica de venta cruzada con línea base" }
16  - { item: "F13 Chatbot de WhatsApp", reopen_when: "la medición muestra que el canal de entrada es el cuello de botella" }
17  - { item: "F23 Cuenta corriente completa", reopen_when: "hay reclamos de clientes por falta de comprobantes y fuente de saldos confiable", owner: "Marta" }
18blocked:
19  - { item: "F24 Sustitución automática", missing: "matriz de marca, compatibilidad y preferencia", needed_from: "Sergio y comercial" }
20  - { item: "F25 Reserva expirable (RN-07)", missing: "TTL aceptable", needed_from: "depósito y comercial", resolves_by: "medición de la primera semana" }
21  - { item: "F26 Autorización automática PLATINO (RN-02)", missing: "tolerancia", needed_from: "dirección y administración" }
22  - { item: "F27 Cheques pendientes", missing: "fuente confiable de 'comprometido'", needed_from: "administración (Laura)" }
23  - { item: "F28 Devoluciones complejas", missing: "políticas y volumen", needed_from: "comercial" }

Esa reducción mejora todo lo que viene después. Los casos de uso tienen menos objetivos mezclados, el modelo de dominio necesita menos entidades especulativas, la arquitectura puede concentrarse en consistencia e integraciones existentes y el plan de pruebas se alinea con riesgos reales. Un buen discovery no siempre produce más requerimientos. Muchas veces produce menos, pero mucho mejores.

Comprobá tu criterio

Errores frecuentes

Para llevarte

• Traducir cada paso manual en una función hereda el desperdicio; preguntá para qué existe el paso y escribí el propósito.
• Un backlog de 28 ideas se reduce con evidencia: diferenciá dolores, soluciones, apuestas y deseos, y descomponé las ideas paraguas.
• Cada OUT necesita un motivo y una condición de reapertura con responsable; cada BLOCKED, qué falta, quién resuelve y cuándo.
• Medí la línea base antes de diseñar y declará los sesgos de la fuente: sin ella no vas a poder demostrar mejora.
• Priorizá combinando valor visible, reducción de riesgo, aprendizaje y dependencia; lo más visible no siempre va primero.
• Registrá las decisiones de alcance con sus alternativas descartadas: el "por qué no" es lo que se pierde primero.