El retrabajo en proyectos de software raramente viene de errores técnicos. Casi siempre viene de requerimientos que nadie cuestionó. Es decir, un desarrollador puede construir exactamente lo que se le pidió, con buen código, buenas pruebas, y aun así entregar algo que no sirve porque lo que se pidió no era lo que el negocio necesitaba. Ese tipo de retrabajo no aparece en ningún reporte de calidad de software. Aparece como ”cambios de alcance”, como reuniones adicionales, como una fecha de entrega que se corre por tercera vez.
Por qué esto no se nota hasta que ya es tarde
Un requerimiento ambiguo se ve perfectamente bien en el momento en que se aprueba. Suena claro, todos asienten en la reunión, nadie pide más detalle porque preguntar demasiado se siente como desconfiar del equipo o retrasar el proyecto. El problema es que “sonar claro” y “ser preciso” no son lo mismo y esa diferencia solo se hace visible cuando el desarrollador ya construyó algo, y ese algo no es lo que el gerente tenía en la cabeza.
Para entonces, el costo ya no es solo de tiempo. Es de dos versiones de la misma funcionalidad que ahora hay que reconciliar, de un equipo que empieza a dudar de cada instrucción futura, y de un proyecto que se retrasa no por complejidad técnica, sino por algo que se pudo resolver con una pregunta bien hecha al principio.
Antes y después: cómo se ve la diferencia
Ejemplo 1 — Aprobación de descuentos
Ambiguo: “El sistema debe permitir aprobar descuentos especiales para clientes importantes.”
Bien escrito: “Yo como gerente comercial, quiero que el sistema bloquee automáticamente y me envíe a aprobación cualquier cotización con un descuento superior al 15% sobre el precio de lista, para evitar que se otorguen descuentos que afecten el margen sin mi revisión. Si el descuento es igual o menor al 15%, el sistema debe aprobarlo automáticamente, sin que 'cliente importante' sea un criterio válido de excepción.”
Ejemplo 2 — Reporte de inventario
Ambiguo: “Necesitamos un reporte que muestre el estado del inventario en tiempo real.”
Bien escrito: “Yo como jefe de bodega, quiero ver en pantalla las unidades disponibles, comprometidas y en tránsito por bodega, actualizadas cada vez que se registra un movimiento de inventario, para tomar decisiones de despacho sin depender de reportes desactualizados. Adicionalmente, como gerente, quiero recibir esta misma información como archivo exportable cada mañana a las 6:00 a.m., para revisarla antes de mi primera reunión del día.”
Por qué el formato importa tanto como el contenido
Hay una razón por la que “Yo como [rol], quiero [funcionalidad], para [beneficio]” se volvió un estándar en la industria de software: obliga a responder tres preguntas que un requerimiento suelto puede dejar implícitas. Quién lo necesita, qué necesita exactamente, y para qué lo necesita.
Esa tercera parte el “para qué” es la que más se salta, y es la más reveladora. Un requerimiento sin ese propósito explícito se puede construir técnicamente bien y aun así no resolver el problema real, porque nadie verificó que la funcionalidad y el objetivo de negocio estuvieran alineados. Cuando el “para qué” queda escrito, cualquiera que lea la historia:el desarrollador, el gerente, un consultor nuevo en el proyecto, puede evaluar si lo que se construyó realmente cumple su propósito, no solo si cumplió la instrucción literal.
El formato, por sí solo, no elimina la ambigüedad, eso lo hacen los criterios de aceptación y las condiciones verificables de los ejemplos anteriores. Pero sí obliga a una disciplina de pensamiento: escribir un requerimiento en esta estructura hace mucho más difícil dejar una intención a medias sin notarlo.
Checklist antes de aprobar un requerimiento
Antes de dar por bueno un requerimiento, vale la pena que quien lo aprueba se haga estas preguntas:
• ¿El requerimiento define una condición verificable, o solo una intención general?
• ¿Están resueltos los casos límite y las excepciones, o solo el caso ideal?
• ¿Quedó claro quién hace qué, en qué momento o hay roles o pasos implícitos que “se dan por entendidos”?
• ¿Alguien del equipo técnico y alguien del negocio leyeron el mismo requerimiento y entendieron exactamente lo mismo?
• Si se lo diera a leer a alguien que no estuvo en la reunión, ¿podría construir lo correcto sin tener que preguntar nada más?
Si alguna de estas preguntas no tiene una respuesta clara, el requerimiento todavía no está listo para aprobarse y aprobarlo así no ahorra tiempo. Solo lo traslada, con intereses, a más adelante en el proyecto.