Métodos prácticos para que empresarios y gerentes evalúen el progreso real de un proyecto de software más allá de los porcentajes y reportes auto-declarados por el proveedor, usando demostraciones, hitos verificables y preguntas que exponen el estado real.
"¿Cómo va el proyecto?" "Bien, vamos al 70%." Esa conversación ocurre en algún momento de prácticamente todo proyecto de software. Y en una cantidad preocupante de casos, ese 70% declarado esconde un proyecto que está mucho más atrasado de lo que parece —o peor, que está avanzando en dirección equivocada—.
El problema de fondo es que el avance en software no se mide bien con porcentajes. Un proyecto puede tener el 70% de las funcionalidades codificadas y sin embargo estar a meses del lanzamiento, porque lo que falta es lo más complejo, o porque lo construido no funciona junto, o porque nadie lo probó con usuarios reales. Este artículo describe cómo evaluar el progreso real de un proyecto de desarrollo, sin necesidad de conocimientos técnicos.
El porcentaje de avance en software sufre de varios vicios:
Se basa en estimaciones que ya son inciertas. Si el proyecto se estimó en ochocientas horas y se llevan trabajadas cuatrocientas, decir que va al 50% asume que la estimación original era correcta. Pero las estimaciones de software son, por definición, aproximadas. Un proyecto puede consumir las horas estimadas y aun así estar lejos de completo, porque la estimación subestimó la complejidad real.
No distingue entre partes fáciles y difíciles. Construir un formulario de registro puede tomar un día. Construir un motor de reglas de negocio puede tomar un mes. Si el proyecto empezó por lo fácil, el porcentaje de avance va a ser alto durante semanas para después estancarse cuando se llegue a lo complejo.
Confunde esfuerzo con resultado. Un equipo puede haber trabajado mucho —muchas horas, mucho esfuerzo— y sin embargo haber avanzado poco en términos de producto funcionando. El porcentaje mide esfuerzo consumido, no valor entregado.
Ignora la integración. Tener diez funcionalidades construidas por separado no es lo mismo que tenerlas integradas y funcionando juntas. El porcentaje de avance por funcionalidad ignora el trabajo —a menudo considerable— de integración, pruebas y ajustes.
Hay un fenómeno conocido en desarrollo de software: el proyecto que lleva semanas "al 90%". Lo que ocurre es que el último 10% —integración, pruebas, ajustes de usabilidad, corrección de errores que solo aparecen cuando todo funciona junto— concentra una cantidad desproporcionada del esfuerzo real. Cuando un proyecto lleva más de dos reportes consecutivos en el mismo porcentaje alto, es una señal de que ese porcentaje no está reflejando la realidad.
En lugar de preguntar por un porcentaje, estas son las prácticas que ofrecen una evaluación más realista:
Demostraciones de lo que efectivamente funciona. Nada reemplaza a ver el producto en acción. Si el equipo dice que el módulo de reportes está avanzado, la verificación es simple: que lo muestren funcionando, con datos reales o realistas, recorriendo el flujo completo que haría un usuario. Lo que se muestra en una demo existe; lo que solo se describe puede existir o puede ser una intención.
Hitos binarios y verificables. En lugar de "el módulo de facturación está al 80%", definir hitos binarios: "el sistema emite una factura electrónica con los datos de una venta de prueba y la envía al cliente". Ese hito está cumplido o no está cumplido. No hay grises. Una lista de hitos binarios —diez, quince, los que correspondan al proyecto— permite saber exactamente qué funciona y qué no, sin espacio para interpretaciones.
Lo construido versus lo probado. Una funcionalidad no está terminada cuando el desarrollador dice que la terminó: está terminada cuando alguien que no la construyó —otro desarrollador, un tester, el cliente— la usó y confirmó que funciona como se esperaba. Medir el avance sobre funcionalidades probadas y aceptadas, no sobre funcionalidades que el equipo declara como terminadas, reduce significativamente las sorpresas.
La tendencia de la velocidad real. Si el equipo entrega tres funcionalidades por semana de manera consistente, esa velocidad es más informativa que cualquier estimación. Si la velocidad baja, hay un problema que conviene investigar —puede ser un bloqueo técnico, una dependencia externa, o un requerimiento que resultó más complejo de lo previsto—. Seguir la tendencia permite detectar problemas antes de que descarrilen el cronograma.
Hay preguntas que, hechas en el momento adecuado, revelan más sobre el estado de un proyecto que un reporte de veinte páginas:
La primera pregunta es probablemente la más poderosa: obliga a pensar en términos de valor concreto y demostrable, no de abstracciones. Y la última revela la distancia real al lanzamiento: si lo que funciona hoy está muy lejos de lo que se necesita para salir a producción, el proyecto está menos avanzado de lo que cualquier porcentaje podría sugerir.
Una práctica simple y efectiva: cada semana, el equipo envía un resumen de no más de media página con tres secciones: qué se construyó esta semana (con enlaces o capturas de lo que se puede ver funcionando), qué se va a construir la semana próxima, y qué bloqueos o riesgos hay. Leer cuatro de estos resúmenes seguidos muestra la tendencia real mucho mejor que cualquier dashboard de porcentajes.
Más allá de las métricas y las demos, hay señales cualitativas que sugieren que el progreso real es menor al declarado:
Ninguna de estas señales, por sí sola, indica un problema grave. Pero cuando aparecen varias juntas, conviene prestar atención.
El artículo sobre cómo evaluar técnicamente a un proveedor sin ser programador ofrece criterios adicionales para evaluar la calidad del trabajo, y el artículo sobre señales de alerta al recibir una propuesta de desarrollo ayuda a detectar problemas desde el inicio de la relación.
Saber si un proyecto está realmente avanzado no requiere conocimientos de programación. Requiere disciplina para mirar más allá de lo que el reporte dice, y exigir evidencia concreta de lo que efectivamente funciona. El proveedor que puede mostrar progreso real no necesita refugiarse en porcentajes.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →