Por qué se atrasan los proyectos de software

Resumen:

• Cuatro causas explican casi todos los retrasos; tres son del lado del cliente.
• La lentitud de las decisiones es la causa número uno, y la más barata de arreglar.
• Los datos de origen siempre están peor de lo que el cliente cree.
• Una demostración funcionando cada dos semanas es el único control real.
• Dividir en entregas de dos meses convierte un riesgo grande en tres chicos.

Un proyecto estimado en catorce semanas entregó en veintidós. Al revisar la bitácora después, el reparto del retraso fue este: cuatro semanas esperando decisiones, dos semanas de trabajo que no estaba en el alcance original, una semana limpiando datos que llegaron peor de lo prometido, y una semana esperando que un banco habilitara un ambiente de pruebas.

Semanas de programación mal estimadas: cero. Esa es la proporción típica.

Causa 1: las decisiones tardan

La más frecuente y la más invisible. El equipo llega a un punto donde hace falta una definición de negocio: qué pasa si un pedido se cancela después de facturado, quién puede autorizar un descuento, qué se hace con los clientes sin RFC. Manda la pregunta y espera.

Si la respuesta tarda cuatro días, se perdieron cuatro días. No necesariamente completos —el equipo trabaja en otra cosa— pero el cambio de contexto cuesta, y la pieza bloqueada suele ser la que otras dependen.

En el proyecto del ejemplo hubo once preguntas con un promedio de tres días de espera. Treinta y tres días naturales. Casi cinco semanas.

Lo que lo arregla: una persona del lado del cliente con autoridad real para decidir y una ventana fija de treinta minutos al día o una hora dos veces por semana. No un comité. El comité es la forma más cara de tomar decisiones pequeñas.

¿Por qué se atrasan los proyectos de software?

Las cuatro causas que explican casi todos los retrasos son: decisiones del cliente que tardan días en llegar, alcance que crece sin ajustar la fecha, datos de origen que están peor de lo que se creía, y dependencias de terceros que nadie puso en el plan. Programar más lento de lo estimado es la causa menos frecuente.

Causa 2: el alcance crece y la fecha no

Esta no es mala fe de nadie. Es que el cliente ve el sistema funcionando y entiende cosas que no entendía en la junta inicial. Las peticiones que salen de ahí suelen ser buenas peticiones.

El problema es cuando entran sin ajustar nada. Cada petición es «un detallito», cada detallito son dos días, y quince detallitos son un mes que nadie puso en el calendario. Llega la fecha original, el proyecto no está, y las dos partes tienen razón.

Lo que lo arregla: contestar cada petición con dos números, no con un sí. «Esto son tres días y mueve la entrega al 14 de marzo. ¿Lo hacemos?» El cliente decide con información. En la mitad de los casos dice que no, que mejor después, y eso también es un buen resultado.

Causa 3: los datos de origen

Si el proyecto migra información de un sistema anterior, de hojas de cálculo o de un sistema que alguien hizo hace ocho años, los datos están peor de lo que el cliente cree. Siempre.

Lo que se encuentra: clientes duplicados con variantes de nombre, campos de fecha con texto libre, RFC inválidos, productos con el precio en el campo de descripción, códigos que se reutilizaron para cosas distintas en épocas distintas. Nada de eso aparece hasta que alguien intenta cargarlo.

Lo que lo arregla: una revisión de los datos reales en la primera semana, no en la última. Dos días de alguien mirando una exportación completa cambian la estimación del proyecto entero, y es la inversión con mejor retorno que conocemos en esta etapa.

Causa 4: los terceros

Todas estas se pueden iniciar en la primera semana del proyecto, mientras se programa. La causa del retraso no es que tarden: es que se piden cuando ya hacen falta.

¿Cuánto retraso es normal en un desarrollo?

Entre un 10 y un 20 por ciento sobre el plazo original es lo habitual en un proyecto bien dirigido, y conviene presupuestarlo desde el principio. Retrasos del 50 por ciento o más casi siempre indican un alcance que creció sin renegociar la fecha, no un equipo lento.

El único control que funciona

Los reportes de avance en porcentaje no sirven. Un proyecto puede estar al «80 por ciento» durante dos meses, porque el 80 por ciento es una opinión.

Lo que sirve es una demostración cada dos semanas, en un ambiente al que tú puedas entrar con tu usuario y hacer clic. No una presentación de pantallas: el sistema, funcionando, con tus datos.

Si cada quince días hay algo nuevo que puedes usar, el proyecto va bien aunque la fecha se mueva. Si las demostraciones se vuelven explicaciones —«esta parte ya está pero falta conectarla»— el proyecto ya va tarde, y acabas de enterarte cuatro meses antes de lo que te habrías enterado.

¿Cómo sé si mi proyecto va tarde antes de que sea obvio?

Pide una demostración funcionando cada dos semanas, en un ambiente al que tú puedas entrar. Un proyecto que va bien tiene algo nuevo que mostrar cada quince días. Cuando las demostraciones se convierten en explicaciones de avance, el proyecto ya va tarde aunque nadie lo haya dicho.

¿Quién es responsable de que un proyecto llegue a tiempo?

Las dos partes, y conviene decirlo sin rodeos. El proveedor responde por estimar bien y avisar temprano; el cliente responde por decidir rápido, entregar los datos y los accesos, y asumir que cada cambio mueve la fecha. Un proyecto donde el cliente tarda una semana en contestar no puede cumplir el plazo.

¿Conviene dividir el proyecto en entregas más chicas?

Casi siempre sí. Un proyecto de seis meses dividido en tres entregas de dos meses, cada una útil por sí misma, reduce muchísimo el riesgo: si la primera se atrasa, lo sabes al mes dos y no al mes cinco. Y lo entregado ya está produciendo valor mientras se construye el resto.

Las primeras dos semanas

Si solo vas a hacer cinco cosas para proteger el plazo, son estas: nombrar a la persona que decide y poner su ventana en el calendario, mirar una exportación real de los datos, iniciar todos los trámites de terceros, acordar que cada cambio viene con días y fecha nueva, y agendar las demostraciones quincenales antes de que empiece la programación.

Ninguna cuesta dinero. Las cuatro causas del retraso quedan cubiertas.