Del problema de negocio a la pantalla: cómo convertimos un requerimiento en solución

Cuando un gerente nos dice “necesito controlar mejor el crédito”, no está pidiendo una pantalla. Está describiendo un problema de negocio: clientes que no pagan, despachos que salen sin respaldo, cartera que crece. Nuestro trabajo es convertir ese problema en algo que el sistema pueda hacer, verificar y medir.

Las cuatro capas

1. Requerimiento de negocio (el “para qué”). El objetivo, en lenguaje de la empresa. “Reducir la cartera vencida sin frenar las ventas.”
2. Reglas de negocio (el “qué se decide”). Las políticas que la empresa define. “No se despacha a un cliente que supera su límite de crédito, salvo autorización de Créditos.”
3. Requerimientos funcionales (el “qué hace el sistema”). Comportamientos concretos y verificables. “Al confirmar un pedido a crédito, el sistema calcula la exposición del cliente y, si supera el límite, deja el pedido retenido.”
4. Criterios de aceptación (el “cómo sabemos que funciona”). Casos de prueba escritos antes de programar.

Saltarse una capa es la causa más común de proyectos que “funcionan” pero no resuelven nada.

Cómo lo hacemos

• Escuchamos el problema, no la solución. Si el usuario pide “un botón para bloquear clientes”, preguntamos por qué. Casi siempre hay una regla más general detrás.
• Escribimos la regla con la empresa. Las reglas las decide el negocio. Nosotros las hacemos explícitas, con sus excepciones y quién las aprueba.
• Bajamos a funcional con ejemplos. Cada requerimiento funcional lleva ejemplos concretos con números reales.
• Definimos la aceptación antes de programar. Con desarrollo guiado por pruebas, cada regla tiene su prueba automatizada desde el principio.
• Validamos con el usuario clave en el sprint. No al final del proyecto: en cada entrega de dos a cuatro semanas.
• Medimos. El requerimiento de negocio tenía un objetivo; después del arranque revisamos el indicador.

Caso 1: un mayorista que vendía a crédito sin control

Problema de negocio. Los vendedores tomaban pedidos a crédito sin saber cuánto debía el cliente; la cartera vencida crecía y Créditos se enteraba tarde.

Reglas de negocio.

• Cada cliente tiene un límite de crédito.
• La exposición es lo que el cliente ya debe más el pedido que se está confirmando.
• Si la exposición supera el límite, el pedido queda retenido; solo alguien con permiso puede liberarlo.
• Los anticipos del cliente se descuentan al facturar el pedido.

Requerimientos funcionales.

• Al confirmar un pedido a crédito, calcular la exposición y compararla con el límite.
• Si excede, marcar el pedido como retenido y avisar a Créditos.
• Un pedido retenido no puede despacharse ni facturarse.
• Al facturar, aplicar automáticamente el anticipo del cliente.

Criterio de aceptación (ejemplo). Dado un cliente con límite de Bs 50.000 y Bs 42.000 de deuda, cuando el vendedor confirma un pedido de Bs 12.000, entonces el pedido queda retenido, Créditos recibe el aviso y el botón de despacho se bloquea.

Caso 2: una importadora que no conocía su costo real

Problema de negocio. El precio de venta se calculaba sobre el valor de la factura del proveedor, sin flete, seguro, aduana ni gastos locales. Algunos productos se vendían a pérdida sin que nadie lo notara.

Reglas de negocio.

• El costo de un producto importado incluye todos los gastos de la importación.
• Cada gasto se reparte entre los productos según una base definida: valor, peso, volumen o cantidad.
• El costo final se conoce al cerrar la carpeta de importación.

Requerimientos funcionales.

• Una carpeta de importación agrupa las facturas del proveedor y todos los gastos asociados.
• Cada gasto elige su base de prorrateo.
• Al liquidar, el sistema calcula el costo unitario final de cada producto y actualiza el costo del inventario.
• A partir del costo final, se sugiere un precio de venta según el margen objetivo.

Criterio de aceptación (ejemplo). Dado un embarque con dos productos de igual valor y distinto peso, cuando el flete se prorratea por peso, entonces el producto más pesado absorbe más flete y su costo unitario lo refleja.

Por qué importa

Un requerimiento bien bajado a funcional se puede probar, se puede mantener y se puede medir. Uno mal bajado termina en personalizaciones que nadie entiende un año después.

Los dos casos de este artículo terminaron como flujos de MKA; el primero puede recorrerse en la demo de pedidos y despachos.