"Necesitamos un sistema que gestione reservas" no es un requisito, es un deseo, y ningún desarrollador puede presupuestar un deseo. La brecha entre lo que un cliente quiere decir y lo que un desarrollador realmente puede construir es donde la mayoría de los presupuestos fallan antes de escribir una sola línea de código, porque un briefing vago recibe una estimación vaga, y una estimación vaga es la semilla de cada disputa de alcance que le sigue.
La diferencia entre una función y un requisito
"Los clientes deben poder reservar en línea" describe una función. No dice qué ocurre cuando dos clientes intentan reservar el mismo horario en el mismo instante, si una reserva necesita aprobación o se confirma al instante, qué pasa si el pago falla después de retener el horario, o si la cancelación dentro de la hora previa a la cita se comporta distinto que una cancelación con una semana de antelación. Cada uno de estos puntos es una decisión real con un coste de desarrollo real, y ninguno es visible en la descripción de una sola frase — solo aparecen cuando alguien empieza a construir y tiene que adivinar, o se detiene y pregunta.
Los criterios de aceptación convierten un deseo en algo construible
Un requisito se vuelve estimable en cuanto indica, específicamente, cómo se ve "terminado": dada esta entrada, exactamente esta salida; dado este caso límite, exactamente este comportamiento. "Un cliente puede reservar una cita" se vuelve construible cuando se lee más como "un cliente selecciona un horario disponible, recibe una confirmación en menos de 60 segundos, y el horario deja de estar disponible para otros clientes en el momento en que se selecciona, no cuando se completa el pago". Ese nivel de precisión parece excesivo para una función pequeña y parece esencial la primera vez que una función ambigua provoca dos semanas de discusión sobre qué se había prometido realmente.
Las ambigüedades que causan sobrecostes de forma fiable
Un puñado de vacíos aparece en casi todo proyecto mal especificado: qué ocurre ante un error (el usuario no ve nada, un mensaje genérico o uno específico), qué ocurre en los límites del uso normal (cero resultados, la entrada máxima permitida, un envío duplicado), quién puede ver o editar qué, y qué debe hacer el sistema cuando dos personas intentan actuar sobre el mismo registro a la vez. Nada de esto es exótico — son situaciones ordinarias que ocurren constantemente en producción — pero son exactamente las situaciones que un briefing de un párrafo nunca menciona, porque solo se vuelven evidentes cuando alguien empieza realmente a construir.
Por qué esto protege a ambas partes, no solo al desarrollador
Un requisito detallado no es burocracia porque sí — es el documento al que ambas partes pueden recurrir cuando surge un desacuerdo más adelante. Sin él, "eso no es lo que pedimos" y "eso es exactamente lo que pedisteis" son ambas afirmaciones ciertas sobre la misma frase vaga, y resolverlo cuesta más tiempo y buena voluntad de lo que habría costado escribir bien el requisito desde el principio.
Acertar en esto desde el inicio forma parte de la misma decisión de comprar, construir o configurar — porque incluso el enfoque correcto solo produce un sistema que realmente funciona si lo que se construye se especificó con claridad suficiente para construirlo.
Nuestro equipo de software convierte la descripción sencilla de un cliente en requisitos a nivel de criterios de aceptación antes de estimar nada, para que el presupuesto refleje lo que realmente se va a construir, no una suposición sobre ello.
