El desperdicio invisible en los proyectos de software

Cuando un proyecto de software se atrasa o termina costando más de lo previsto, es fácil culpar a la estimación. Pero el problema rara vez está ahí. La fuga ocurre en silencio, repartida en decisiones cotidianas que nadie anota como pérdida — y al final suma una porción enorme del presupuesto.

El retrabajo se come la mitad del esfuerzo

Estudios clásicos de la industria —de Capers Jones, Barry Boehm y Steve McConnell— coinciden en algo incómodo: entre 30% y 50% del esfuerzo de un proyecto se va en rehacer trabajo ya hecho. Y la causa principal no es técnica. Son requisitos mal definidos, o que cambian sin un canal claro para procesarlos, así que el equipo construye sobre supuestos que después hay que deshacer.

El retrabajo no aparece en ninguna factura, pero se paga en cada sprint.

Construimos cosas que nadie usa

El otro gran sumidero es más difícil de ver porque el trabajo sí se terminó: simplemente no servía. El Standish Group estimó que cerca del 64% de las funcionalidades de un sistema se usan rara vez o nunca; un informe posterior de Pendo (2019) elevó esa cifra a ~80% con baja o nula adopción. Cada una de esas funciones se especificó, se programó, se probó y ahora hay que mantenerla. Es presupuesto convertido en complejidad, no en valor.

Lo que no se ve, no se corrige a tiempo

Un defecto detectado en producción cuesta entre 5 y 10 veces más que el mismo defecto detectado temprano. Y sin visibilidad real del avance, las desviaciones se descubren tarde, cuando ya son caras de revertir. No sorprende que, según el CHAOS Report del Standish Group, solo cerca de 1 de cada 3 proyectos cumpla a la vez plazo, costo y alcance; la mitad queda "desafiado" y el resto fracasa.

El patrón detrás de todo

Tres cosas separan a los proyectos sanos de los que se desangran, y ninguna es una metodología de moda:

Requisitos claros y un canal para cambiarlos. No congelar el alcance, sino tener un proceso explícito para decidir qué entra, qué sale y a qué costo.
Visibilidad del avance real. Datos del trabajo efectivamente terminado, no reportes maquillados que esconden el problema hasta que explota.
Entregas frecuentes. Cerrar el ciclo de feedback antes de construir de más: liberar seguido es la forma más barata de no equivocarse en grande.

La buena noticia es que la mayor parte de ese desperdicio es evitable. No se trata de trabajar más horas, sino de hacer visible lo que hoy se pierde y corregir antes de que escale. Eso es, en una frase, a lo que nos dedicamos en Syntaxis.

Fuentes: C. Jones; B. Boehm & V. Basili, Software Defect Reduction Top 10 List; S. McConnell, Software Quality at Top Speed; The Standish Group, CHAOS Report; Pendo, Feature Adoption Report (2019); CISQ, Cost of Poor Software Quality. Las cifras son referenciales y dependen del contexto de cada proyecto.