Por qué los proyectos de software se atrasan
Casi ningún atraso viene de que programar tomara más de lo previsto. Estas son las causas reales, en orden de frecuencia.
· 3 minutos de lectura
Cuando un proyecto se atrasa, la explicación habitual es que se subestimó el trabajo. A veces es cierto. Pero en la mayoría de los casos el retraso no se generó escribiendo código, sino en los espacios entre una decisión y la siguiente.
Vale la pena separar las causas, porque cada una se corrige de forma distinta y no todas dependen de la misma parte.
Las causas más frecuentes
El alcance nunca estuvo escrito
Sin un documento que diga qué se construye y qué no, cada conversación agrega algo. Nadie lo nota porque cada agregado parece pequeño, y la suma es el retraso.
Es la causa número uno y la única que se puede eliminar por completo, porque se resuelve antes de empezar.
Las decisiones quedan esperando
Una pregunta enviada el lunes y respondida el jueves son tres días detenidos. Repetido cada semana durante tres meses, son semanas.
Se corrige asignando de tu lado una persona con capacidad de decidir y con tiempo reservado para el proyecto. No es un rol simbólico: es la diferencia entre avanzar y esperar.
Los datos estaban peor de lo previsto
Migrar información acumulada durante años casi nunca es copiar y pegar. Aparecen duplicados, campos vacíos, formatos que cambiaron a mitad de camino y registros que no cuadran entre sistemas.
Se corrige revisando una muestra real de los datos durante la definición, no al momento de migrar.
Los accesos no llegaron a tiempo
Credenciales de un sistema externo, permisos que dependen de otra empresa, una cuenta que había que crear. El trabajo está listo y no se puede probar.
Se corrige pidiendo todos los accesos en la primera semana, aunque se vayan a usar en el tercer mes.
Las pruebas se dejaron para el final
Cuando todo se prueba junto al terminar, aparecen a la vez errores que se podrían haber encontrado semanas antes, y cada uno puede afectar decisiones ya construidas encima.
Se corrige entregando por partes y probando cada una al cerrarla.
El equipo no era estable
Personas que entran y salen del proyecto. Cada incorporación consume tiempo de quien ya estaba, justo cuando más falta hace.
Cómo detectarlo temprano
Un proyecto no se atrasa de golpe: se atrasa un poco cada semana y se nota al final. Tres señales que aparecen antes:
- Pasaron más de tres semanas sin algo que puedas abrir y probar. Es la señal más confiable de todas.
- Los avances se describen en porcentajes. «Vamos en un 70 %» no es información. «El flujo de cotización está terminado y probado» sí.
- Las mismas dudas vuelven a aparecer. Significa que algo no quedó definido y se está construyendo sobre una interpretación.
Qué hacer si ya va tarde
Agregar personas casi nunca funciona, y presionar por la fecha original suele producir entregas incompletas que después hay que rehacer.
Lo que sí funciona:
- Volver a escribir el alcance restante, con lo que falta de verdad.
- Separarlo en lo que tiene que estar para la fecha y lo que puede esperar. Casi siempre hay más de lo segundo de lo que parece.
- Entregar completo lo primero y planificar el resto con fecha propia.
- Fijar entregas cada dos semanas de aquí en adelante, para que el próximo desvío se note en catorce días y no en dos meses.
Un sistema con una función terminada sirve el primer día. Uno con cinco a medias no sirve ninguno.
Si necesitas una mirada externa
Revisar un proyecto que va mal, ordenar qué se rescata y qué se corta, es uno de los usos de la consultoría tecnológica. También sirve leer cuánto demora un proyecto y, si el proyecto quedó a medias, cómo continuar uno incompleto.