Por qué tu proyecto de software se retrasó 6 meses (y no fue culpa de los programadores)
Los retrasos casi nunca vienen de escribir código lento. Vienen de decisiones que se tomaron antes de escribir la primera línea.
El proyecto se cotizó en cuatro meses. Van diez. Nadie se ha ido, nadie está flojeando, todos trabajan más horas de las que deberían, y aun así la fecha se sigue moviendo. En la junta de seguimiento alguien pregunta por qué los programadores no avanzan más rápido, y esa pregunta —bienintencionada— es la señal más clara de que el problema está en otro lado.
Escribir código representa una fracción del tiempo total de un proyecto de software. La mayor parte se va en entender qué hay que construir, esperar definiciones, rehacer lo que se construyó con supuestos equivocados y descubrir integraciones que nadie mencionó. Los retrasos casi nunca vienen de teclear despacio.
Estas son las seis causas que explican la enorme mayoría de los proyectos que se estiran, cada una con el síntoma que aparece semanas antes y lo que sí funciona para corregirla. Ninguna requiere cambiar de proveedor.
Sumario
- 01El costo de la decisión postergada
- 02Alcance que nunca se cerró
- 03Definiciones que llegan tarde
- 04Un comité en lugar de un dueño
- 05Deuda técnica que encarece cada cambio
- 06Estimaciones sin las tareas invisibles
- 07Dependencias externas descubiertas tarde
El costo de la decisión postergada
Antes de las causas, el concepto que las conecta a todas. Cuando una definición del lado del cliente se retrasa, el costo no es cero mientras se espera: el equipo sigue contratado, sigue trabajando en lo que puede, y una parte de su capacidad queda bloqueada.
Equipo: 4 personas (análisis, 2 desarrollo, pruebas)
Costo del equipo por día hábil ......................... $16,000
La definición del esquema de descuentos tarda 9 días
Capacidad bloqueada mientras tanto: 40%
9 días × $16,000 × 0.40 ............................. $57,600
La definición llega distinta a lo supuesto: hay retrabajo
6 días de reconstrucción × $16,000 .................. $96,000
COSTO DE ESA DECISIÓN ................................. $153,600Ciento cincuenta mil pesos por una definición que en su momento pareció «un pendiente menor de la semana». Y casi nunca es una sola: un proyecto de seis meses acumula entre quince y treinta decisiones de este tipo.
Hay además un multiplicador que agrava todo: el mismo cambio cuesta radicalmente distinto según cuándo se decide. Es una de las regularidades más consistentes en desarrollo de software, y los órdenes de magnitud son aproximadamente estos:
| Cuándo se decide el cambio | Costo relativo | Por qué |
|---|---|---|
| En descubrimiento | ×1 | Se corrige un documento y una conversación |
| En diseño | ×3 | Se rehacen pantallas y modelo de datos, todavía en papel |
| Durante la construcción | ×10 | Hay código escrito, probado e integrado que hay que deshacer |
| Después de liberar | ×30 o más | Se suma migración de datos existentes, recapacitación y corrección de lo ya operado |
Las semanas de descubrimiento que muchos clientes quieren saltarse «para ya empezar a programar» son las más baratas del proyecto entero. Cada definición que se resuelve ahí cuesta una décima parte de lo que costará tres meses después.
El alcance nunca se cerró
Se acordó una idea, no un alcance. «Un sistema para controlar pedidos» significa cosas muy distintas para quien lo pidió y para quien lo construye, y la diferencia no aparece en la reunión inicial: aparece en la primera demostración, cuando alguien dice «pero esto también tiene que hacer…».
En la primera revisión aparecen tres funcionalidades que «se daban por obvias» y no estaban en ningún documento. Si eso pasa en la semana 3, va a pasar cada tres semanas hasta el final.
Criterios de aceptación escritos por cada funcionalidad, en lenguaje de negocio: «cuando el vendedor captura un pedido de un cliente con crédito vencido, el sistema lo bloquea y notifica a Cobranza». Y una lista explícita de lo que NO incluye esta fase. Esa lista negativa evita más discusiones que toda la documentación positiva junta.
Las definiciones llegan tarde
Es la causa número uno de retraso en proyectos que por lo demás están bien llevados, y la que más sorprende a los clientes porque el retraso lo genera su propio lado. El equipo pregunta cómo se calcula una comisión; la respuesta requiere hablar con Ventas, que está cerrando el mes; pasan dos semanas.
Una lista de dudas abiertas que crece más rápido de lo que se cierra. Si en la semana 4 hay seis preguntas sin responder de la semana 2, el proyecto ya se está retrasando aunque el reporte diga que va al corriente.
Compromiso explícito de tiempo de respuesta —48 horas hábiles— y una regla de escalamiento clara: lo que no se responde en ese plazo sube a dirección automáticamente, sin que nadie tenga que quedar mal pidiéndolo. Y que las dudas abiertas sean el primer punto de cada junta de avance, antes que el porcentaje de progreso.
Un comité en lugar de un dueño
Cuatro áreas opinan y ninguna decide. Cada demostración genera peticiones contradictorias: Ventas quiere menos clics, Contabilidad quiere más validaciones, Operaciones quiere ambas. El equipo de desarrollo termina arbitrando decisiones de negocio que no le corresponden, y cada ronda cuesta días.
Una funcionalidad que se rehace dos veces por peticiones opuestas de dos áreas distintas. Eso no es un problema de desarrollo: es un vacío de autoridad.
Una persona con nombre, con conocimiento del proceso y con autoridad real para decidir aunque un área no quede contenta. No un coordinador que consulta: alguien que resuelve. Es el rol más determinante del proyecto y el que con más frecuencia se deja vacante.
La deuda técnica que encarece cada cambio
Aplica sobre todo cuando se construye encima de un sistema existente. Los primeros cambios salen rápido; los siguientes tardan cada vez más, porque cada nueva pieza tiene que convivir con decisiones viejas que nadie documentó. La velocidad no baja de golpe: se desgasta.
Cambios de tamaño parecido que tardan cada vez más, y correcciones que rompen algo distinto cada vez. Si el equipo empieza a decir «es que tocar eso es delicado», ya estás pagando la deuda con intereses.
Reservar entre 15% y 20% de la capacidad de cada ciclo para sanear lo que se está tocando, desde el inicio. Suena a que va a retrasar el proyecto y es exactamente al revés: sin eso, el ritmo se cae a la mitad hacia el mes cuatro, justo cuando más presión hay.
La estimación olvidó las tareas invisibles
Se estimó la construcción y se omitió todo lo demás: migrar los datos históricos —que siempre están más sucios de lo que alguien admite—, las pruebas del área usuaria, la capacitación, el periodo en que conviven el sistema viejo y el nuevo, y los ajustes de las primeras dos semanas reales de uso.
El plan no tiene una línea llamada «migración de datos» ni otra llamada «estabilización». Si no están escritas, no se estimaron; y van a ocurrir de todas formas, robando tiempo de otro lado.
Que el plan tenga renglones explícitos para migración, pruebas del usuario, capacitación y estabilización, cada uno con su duración. Y estimaciones en rango —«de 10 a 14 semanas»— en lugar de fechas puntuales que fingen una precisión que nadie tiene.
Las dependencias externas aparecieron tarde
El sistema tiene que integrarse con el ERP, y el proveedor del ERP cobra por la integración y tiene cuatro semanas de fila. O el banco tarda un mes en dar acceso a su ambiente de pruebas. Ninguna de estas esperas es responsabilidad del equipo de desarrollo y todas detienen el proyecto igual.
En la semana 2 nadie ha solicitado todavía los accesos, credenciales o ambientes de terceros. Cada semana de demora ahí es una semana de retraso al final, sin excepción.
Levantar el inventario de dependencias externas en la primera semana y solicitar todo de inmediato, aunque se vaya a usar hasta el mes tres. Con responsable, fecha comprometida y seguimiento semanal. Es la tarea más aburrida del proyecto y la que más retrasos evita.
Cómo se ve un proyecto que sí va a tiempo
No se distingue por ir más rápido. Se distingue por ser aburrido: no hay sorpresas grandes, porque las chicas se atendieron a tiempo.
- ▪Hay algo funcionando desde temprano. Al final del segundo mes ya existe una parte que alguien del área usuaria puede tocar, aunque le falte la mitad.
- ▪Las demostraciones son frecuentes y cortas. Cada dos o tres semanas, con el sistema real, no con láminas. Ahí es donde el alcance se corrige barato.
- ▪Las dudas abiertas se cuentan y bajan. Es mejor indicador de salud que cualquier porcentaje de avance.
- ▪El dueño de producto responde en horas, no en semanas. Y tiene autoridad para hacerlo sin convocar a nadie.
- ▪Los cambios se aceptan y se costean. No se rechazan ni se aceptan gratis: se dice qué implican en tiempo y qué se recorre.
- ▪Las malas noticias llegan temprano. Un retraso avisado en el mes 2 es un ajuste; el mismo retraso descubierto en el mes 5 es una crisis de confianza.
Un proyecto que reporta 90% de avance durante seis semanas seguidas. Ese 90% eterno significa que lo que falta nunca se dimensionó, y casi siempre es la parte más difícil: integraciones, migración y los casos raros que el negocio da por obvios. Cuando lo veas, pide que te desglosen el 10% restante en tareas con horas. La conversación que sigue va a ser incómoda y necesaria.
Semáforo de tu proyecto en curso
Diez preguntas para esta semana
Imprimir o guardar como PDF- Existe un documento de alcance con criterios de aceptación por funcionalidad Y una lista explícita de lo que NO incluye esta fase
- Hay una persona con nombre que decide, no un comité que opina Pregunta: «¿quién decide si Ventas y Contabilidad no se ponen de acuerdo?»
- Sabes cuántas dudas abiertas hay hoy y cuántas había hace dos semanas Si la lista crece, el proyecto ya se está retrasando
- Alguien del área usuaria ya tocó algo funcionando Ver una demostración no cuenta: tocarlo, sí
- El plan tiene renglones para migración, capacitación y estabilización Si no están escritos, no se estimaron
- Todos los accesos y ambientes de terceros ya fueron solicitados Con responsable y fecha comprometida por cada uno
- Los cambios solicitados tienen su impacto en tiempo por escrito Aceptar sin costear es la forma silenciosa de perder la fecha
- Las demostraciones ocurren cada dos o tres semanas, sin falta Cuando se empiezan a posponer, algo se está escondiendo
- El avance se mide en funcionalidades terminadas, no en porcentaje «Ocho de veinte listas y probadas» es un dato; «60%» es una opinión
- Tu equipo dedica las horas semanales que el proyecto necesita de su lado Entre 4 y 8 horas por semana de la persona que conoce el proceso
Ocho o más: el proyecto tiene bases sanas. Cinco a siete: hay riesgo concreto y todavía es corregible. Menos de cinco: la fecha actual no se va a cumplir, y conviene renegociarla ahora y no en tres meses.
La conversación que hay que tener
Si tu proyecto ya se retrasó, la reunión útil no es la que busca responsables. Es la que responde tres preguntas: cuáles de estas seis causas están presentes, cuál es la fecha realista con lo que sabemos hoy, y qué se saca del alcance para proteger lo que de verdad importa.
Esa conversación es incómoda y casi siempre destraba el proyecto. La alternativa —seguir empujando la fecha dos semanas cada dos semanas— desgasta al equipo, quema la confianza de dirección y termina costando mucho más.
Si estás evaluando con quién construir para no repetir la historia, en el blog está también qué esperar realmente de una fábrica de software y las banderas rojas al contratar.
Los proyectos no se retrasan seis meses de golpe. Se retrasan un día a la vez, y casi siempre esperando una respuesta.
¿Tu proyecto lleva semanas en el mismo 90% de avance?
Revisamos proyectos en curso, propios y ajenos. Identificamos cuáles de estas causas están presentes, cuánto falta realmente y qué se puede recortar del alcance para proteger la fecha. Te entregamos el diagnóstico por escrito, con o sin recomendación de cambiar de proveedor.
- —Diagnóstico de proyectos de software en curso
- —Fábrica de software y desarrollo a la medida
- —Definición de alcance y acompañamiento técnico
- —Modernización de sistemas .NET heredados