Semana cuatro, Sprint terminado y Demo lista.
El equipo muestra lo que construyó y alguien del negocio, con toda la calma del mundo, dice la frase que ningún líder técnico quiere escuchar: "¿Esto es lo que pedimos?"
No hubo negligencia. No hubo mala fe. Los requerimientos existían, las reuniones se hicieron, el backlog estaba actualizado. Y, aun así, lo entregado y lo esperado eran cosas distintas.
El verdadero cuello de botella no es técnico
Ese momento tiene nombre: retrabajo. Y en la mayoría de las organizaciones se asume como parte del proceso, cuando en realidad es una señal de que algo está roto desde antes de escribir la primera línea de código.
En la mayoría de los proyectos de software, entre el 20% y el 35% del tiempo se invierte en corregir lo que ya se hizo. No en escalar, no en innovar. En deshacer y volver a empezar.
La causa casi siempre es la misma: ambigüedad en los requerimientos.
El equipo técnico interpreta. El negocio asume. Lo que queda documentado captura palabras, pero no contexto. Captura el qué, pero no el por qué ni los límites reales. Y ese vacío, invisible al inicio, se convierte en sobrecostos y sprints que nunca cierran bien.
Cuando le sumas IA a ese proceso, el problema no desaparece. Se amplifica. La IA no adivina: ejecuta con lo que recibe. Si lo que recibe es ambiguo, lo que produce también lo será.
