El proyecto que se extendió tres meses más de lo planeado. Lo que aprendí de ese error.
Los proyectos de software no fallan por el código. Fallan por conversaciones que no se tuvieron a tiempo. Esta es la historia más incómoda que he contado sobre ProjectApp.
Project App
Equipo de Ingeniería
Voy a contar algo que los fundadores de empresas de servicios raramente cuentan en público: la historia de un proyecto que salió mal. No porque el equipo fuera malo. No porque la tecnología fallara. Sino porque hubo decisiones que no se tomaron a tiempo, conversaciones que se pospusieron para evitar incomodidad, y un alcance que fue creciendo silenciosamente hasta que el proyecto ya no terminaba. Ese proyecto se extendió tres meses más de lo planeado. Fue una de las experiencias más duras de ProjectApp. Y fue la que más nos enseñó.
Cómo empezó bien y fue cambiando
El proyecto arrancó con buen diagnóstico, alcance definido y fechas claras. Las primeras semanas fueron bien. Pero en algún punto del camino empezó a pasar algo que es uno de los patrones más comunes y más silenciosos en desarrollo de software: el scope creep. El alcance fue creciendo. Una funcionalidad que 'no estaba en el plan original pero era pequeña'. Un módulo nuevo que 'tenía lógica, porque íbamos a necesitarlo de todas formas'. Una integración que 'era fundamental y no se había contemplado'. Cada adición, por separado, parecía razonable. Juntas, triplicaron el alcance original sin que nadie tomara una decisión explícita de hacerlo.
"El scope creep no llega de golpe. Llega en pequeñas dosis, cada una suficientemente razonable como para no decir que no."
— La lección más cara que pagamos en ese proyecto
La conversación que no tuve a tiempo
Aquí está la parte que más me costó aceptar: el proyecto no se extendió porque el cliente pidió cosas imposibles. Se extendió porque yo no tuve la conversación difícil a tiempo. Cada vez que aparecía una nueva solicitud fuera del alcance original, la respuesta correcta era: 'Esto no está en el alcance. Lo podemos hacer, pero significa ajustar el tiempo o el precio.' Esa conversación la evité más veces de las que debí. Por no querer generar fricciones. Por creer que lo podíamos absorber. Por optimismo sobre los tiempos. El resultado fue un proyecto que nunca terminaba, un equipo agotado, y un cliente que también perdió claridad sobre qué esperaba exactamente.
La señal de alerta más importante
Cuando un proyecto lleva más de dos semanas sin una demo funcional nueva, o cuando el equipo dice 'casi está' por tercera semana consecutiva, hay algo que no está funcionando en la gestión del alcance. Ese es el momento de tener la conversación difícil — no de esperar.
Lo que cambió en ProjectApp después de eso
Ese proyecto fue el punto de inflexión que nos hizo formalizar algo que antes hacíamos de forma inconsistente: la gestión del alcance como parte explícita y visible del proceso. Lo que implementamos después:
- Documento de alcance firmado antes de arrancar cualquier sprint, con lista explícita de lo que está dentro y lo que está fuera.
- Protocolo de cambio de alcance: toda solicitud nueva genera un análisis de impacto en tiempo y costo antes de ser aceptada.
- Demos semanales como checkpoint obligatorio — si no hay demo, hay un problema que hay que nombrar.
- Conversaciones de expectativas al inicio de cada semana, no solo al final cuando el daño ya está hecho.
- La regla que más nos costó adoptar: decir que no con claridad y sin culpa cuando algo no estaba en el alcance original.
Por qué los proyectos de software realmente fallan
Después de esa experiencia y de muchos proyectos más, tengo una convicción muy clara: los proyectos de software no fallan por problemas técnicos. Fallan por problemas de comunicación. Específicamente, por estas cuatro razones:
Alcance indefinido o que nadie defendió
Un proyecto sin alcance claro y defendido activamente es un proyecto sin fecha de finalización. El alcance no es un documento que se firma y se olvida — es el contrato vivo del proyecto.
Expectativas que no se alinearon al inicio
El cliente tiene en su cabeza una versión del sistema que nadie validó explícitamente. Cuando el sistema entregado es diferente a esa versión mental, hay decepción aunque técnicamente todo esté correcto.
Feedback que llegó tarde
Cuando el cliente ve el sistema por primera vez al final del proyecto, los cambios que pide son caros. Cuando lo ve cada semana, los cambios son baratos. La diferencia entre esos dos modelos es la diferencia entre un proyecto exitoso y uno que nunca termina.
Conversaciones difíciles que se pospusieron
Cada vez que alguien evita una conversación incómoda en un proyecto de software, esa conversación se hace más costosa. El problema crece, la tensión acumula, y cuando finalmente se tiene — tarde — el daño ya es mayor.
Lo que me llevo de todo esto
Lo que me llevo de todo esto
- 1Los proyectos de software no fallan por el código. Fallan por conversaciones que no se tuvieron a tiempo.
- 2El scope creep llega en dosis pequeñas y razonables. Cada adición parece inocente hasta que sumadas triplicaron el alcance original.
- 3La conversación difícil sobre alcance y expectativas siempre es más barata cuando se tiene temprano.
- 4Un proyecto con demos semanales y gestión activa del alcance termina. Un proyecto sin eso no tiene fecha de finalización real.
Ese proyecto que se extendió tres meses fue caro en tiempo, en energía, y en la confianza que hubo que reconstruir con el cliente. Pero fue el que más claramente nos mostró dónde estaban los huecos en nuestra metodología. Hoy, cada proyecto en ProjectApp tiene alcance explícito, demos semanales obligatorias, y un protocolo de cambios que protege tanto al cliente como al equipo. No porque seamos perfectos. Sino porque aprendimos de primera mano lo que cuesta no tenerlo.
Si tienes un proyecto de software que sientes que no avanza o que está perdiendo el rumbo, esa conversación me interesa. A veces un diagnóstico externo identifica en días lo que internamente lleva semanas sin verse claro.