Los proyectos estancados no se estrellan, se atascan
Quizá le resulte familiar. El proyecto no está muerto. Nadie ha tirado del enchufe, no ha habido ningún momento dramático. Simplemente lleva meses estando «casi listo». Cada actualización suena razonable, cada retraso tiene una explicación, y aun así sigue sin haber un software funcional sobre el que usted pueda hacer clic. El proyecto no se estrella: se atasca.
Eso es precisamente lo que lo hace tan engañoso. Un fallo lo obliga a actuar. El atasco no. Usted sigue esperando, confiando en el siguiente sprint, y entretanto los costes siguen corriendo y la confianza se va erosionando. El error caro casi nunca es el rescate en sí. El error caro son los meses que usted espera antes de tomar la decisión de intervenir.
Este artículo le ofrece un orden de decisión honesto: primero detectar pronto, luego diagnosticar rápido, después elegir con honestidad entre rescatar y reconstruir, a continuación reiniciar a las personas y la gobernanza, y por último asegurarse de que perdure. Sin señalar culpables, porque eso no mejora ningún proyecto. Sí una ruta sensata de vuelta hacia un software funcional, pensada para un empresario de pyme ocupado que, mientras tanto, tiene que seguir manteniendo el negocio en marcha. Nosotros pensamos en ello con soluciones alojadas en la UE y con una persona en el bucle: tecnología en la que usted puede confiar, y personas que asumen su responsabilidad.
Por qué intervenir pronto lo es todo
La primera pregunta que se hace todo empresario es: ¿cuándo intervengo? La respuesta honesta: en cuanto las señales de alarma se acumulan, no recién cuando el plazo se ha incumplido de forma definitiva. Para cuando cae la fecha de entrega, normalmente usted ya lleva meses de retraso.
Se trata de lo que llamamos latencia de decisión: el tiempo entre «algo no cuadra» y «hacemos algo al respecto». Cada semana de duda se suma. Los costes se acumulan y, lo que quizá sea lo más doloroso: la proporción de código reutilizable disminuye cuanto más tiempo se sigue construyendo en una dirección inestable. Esperar no solo encarece la intervención final, sino que la hace más drástica.
Por eso, aplique una regla práctica sencilla: dos o más señales de alarma que persistan durante más de dos sprints son el detonante para un diagnóstico. No para el pánico, no para despedir a su equipo, sino para un diagnóstico. Eso es un seguro barato. Una investigación de McKinsey & Company junto con la University of Oxford muestra que los costes de los grandes proyectos de TI crecen al mismo ritmo que su duración: cada año adicional empuja las desviaciones aún más arriba. Esas cifras se refieren a proyectos grandes, a menudo de tipo enterprise, pero la lección sigue siendo plenamente válida para la pyme: el tiempo es el enemigo. Intervenir pronto sale más barato que tener razón más tarde.
Las 7 señales de alarma de un proyecto que se está estancando
A continuación, una lista de comprobación útil. En cada señal se indica en una frase lo que realmente significa.
Uno. La planificación se aplaza una y otra vez. Lo que realmente significa: no un contratiempo puntual, sino un patrón; el equipo ha perdido el control sobre el alcance o la complejidad.
Dos. El alcance crece sin acuerdos por escrito. Lo que realmente significa: en los pasillos se promete cada vez más, y ya nadie vigila lo que «listo» realmente implica.
Tres. La deuda técnica crece más rápido que la funcionalidad. Lo que realmente significa: se dedica más energía a remendar lo de ayer que al valor de mañana.
Cuatro. Las personas clave se van. Lo que realmente significa: con cada desarrollador que se marcha, el conocimiento no documentado sale por la puerta, conocimiento que no está en la cabeza de nadie más.
Cinco. La comunicación se vuelve reactiva y defensiva. Lo que realmente significa: las actualizaciones tratan de explicar por qué algo no está terminado, no de lo que sí funciona.
Seis. Las demos muestran una y otra vez las mismas funciones. Lo que realmente significa: se sugiere movimiento, pero no hay un avance real bajo el capó.
Siete. No hay un software demostrablemente funcional sobre el que usted mismo pueda hacer clic. Lo que realmente significa: esta es la señal de mayor peso; si tras meses todavía no puede tocarlo, probablemente aún no existe.
Haga la autoevaluación: ¿cuántas de estas siete reconoce? Con una sola señal aislada, por lo general no pasa nada. Pero si reconoce dos o más, y persisten durante más de dos sprints, entonces ya no es mala suerte: es un patrón, y el momento para un diagnóstico honesto.
El diagnóstico en 48 horas: qué miramos de verdad
Un buen diagnóstico está bien acotado en el tiempo. Nosotros lo hacemos en unas 48 horas, y eso no es casualidad: un diagnóstico que él mismo se va a atascar forma parte del mismo problema. Usted no necesita un informe de seis semanas para saber que las cosas no van bien. Necesita un juicio honesto antes de gastar un euro más.
Miramos cuatro cosas. En primer lugar, el código: cómo es la estructura, hay pruebas, y está el conocimiento documentado o solo está en la cabeza de las personas. Un código que nadie se atreve a tocar es ya de por sí una advertencia.
En segundo lugar, las personas. Hablamos con los implicados por separado: desarrolladores, jefe de proyecto y usted como cliente. Por separado, porque solo así sale a la luz la diferencia entre el estado reportado y el estado real. Esa brecha suele ser el verdadero problema.
En tercer lugar, los cimientos: la arquitectura. ¿Es una casa con una mala capa de pintura, o la grieta está en los cimientos? Esa distinción determinará después casi todo.
En cuarto lugar, estimamos cuánto del código existente es realmente reutilizable. No cuánto se ha hecho, sino cuánto está bien y sigue siendo aprovechable.
El resultado es deliberadamente sencillo: una página con un juicio honesto —seguir o no— más un plan de recuperación con su precio asociado. Sin vaguedades, sin «ya lo veremos». Un diagnóstico que no toma una decisión no ha hecho su trabajo.
Rescatar o reconstruir: por qué la regla práctica no es un veredicto
Nosotros aplicamos una regla práctica que da un punto de apoyo: si es reutilizable menos de un 30 % aproximadamente del código, la balanza se inclina hacia reconstruir; si es aprovechable más de un 50 % aproximadamente, se inclina hacia rescatar. Fíjese en la palabra inclina. Esta regla es una señal de salida, no una decisión. Le dice dónde empieza la conversación, no dónde termina.
Lo que pesa más que el porcentaje es la arquitectura. Un veinte por ciento de código reutilizable sobre unos cimientos sanos suele valer más que un sesenta por ciento sobre unos podridos. Unos cimientos mal elegidos no se pueden disimular con buenos módulos por encima.
Luego está la trampa de los costes hundidos, la trampa del sunk cost. «Ya hemos invertido tanto» es un sentimiento, no un argumento. El dinero ya gastado no lo recuperará nunca, siga o se detenga. La única pregunta relevante es cuál es el camino más barato hacia un software funcional a partir de aquí.
Y no subestime los costes ocultos de empezar de nuevo. Joel Spolsky advirtió en su conocido ensayo «Things You Should Never Do» que, al reescribir desde cero, usted tira algo invisible pero enormemente valioso: años de correcciones de errores y conocimiento del dominio incorporados. Cada «if» extraño en el código antiguo suele ser una solución silenciosa a un problema que, de lo contrario, usted volverá a descubrir, con todo el daño que ello conlleva.
Frente a eso está la visión moderna e incremental: ni conservarlo todo, ni tirarlo todo. Entre «rescatar» y «reconstruir» hay un tercer camino, y es el que la mayoría de los empresarios pasa por alto.
El término medio que la mayoría de los empresarios pasa por alto: sustituir paso a paso
Ese tercer camino se llama el patrón estrangulador (strangler), nombrado y descrito por Martin Fowler. El nombre viene de la higuera estranguladora, una planta que crece lentamente alrededor de un árbol hasta que finalmente lo sustituye. En lenguaje llano de empresario: usted deja que las partes que funcionan sigan en marcha, reconstruye primero el componente peor y va desviando el tráfico hacia él poco a poco. Módulo a módulo, el sistema antiguo va desapareciendo, sin que haya nunca un gran momento de «fuera lo viejo, dentro lo nuevo».
La gran ventaja: el valor aterriza de forma continua en lugar de tras un silencio de doce meses. Usted ve cada pocas semanas un componente realmente mejorado entrar en producción, y puede ajustar el rumbo según lo que funciona en lugar de según un plan que ya tiene meses.
Este enfoque supera tanto a un rescate completo como a una reconstrucción completa cuando los cimientos están en buena parte sanos pero hay módulos concretos podridos, y también cuando usted no puede detener la actividad del negocio, lo cual para la pyme casi siempre es el caso. Sencillamente, no puede pasar meses sin sus sistemas. Al sustituir en pequeñas partes, el riesgo y el presupuesto siguen siendo manejables: si algo sale mal, sale mal en un módulo, no en toda la empresa.
No reiniciar solo el código, sino también a las personas
Esta es la parte que los manuales técnicos se saltan. Un proyecto estancado no tiene solo deuda técnica: tiene un déficit de confianza que es igual de real. El empresario está decepcionado, el equipo se siente atacado, y todos se han vuelto prudentes en lo que se atreven a prometer. Sin reparar eso, ninguna intervención técnica resuelve nada de forma duradera.
El reinicio empieza con un reconocimiento honesto sin culpables. No «quién ha hecho esto», sino «aquí estamos, y este es el camino hacia delante». A continuación, usted reinicia las expectativas frente a una nueva línea base realista: ya no fechas optimistas que vuelven a incumplirse, sino una línea base que todos puedan respaldar.
Llega un único responsable de decisión al que dirigirse. Un proyecto estancado suele tener demasiados timoneles y muy pocos capitanes; una sola persona que tome las decisiones mantiene baja la latencia. Y usted, el empresario, vuelve a ocupar activamente el timón. No como microgestor, sino como cliente comprometido que vela por el rumbo.
Por último, no olvide la señal de las personas clave que se han ido: documente el conocimiento antes de que se marche más gente. Haga que lo que está en las cabezas pase al papel, a la documentación y a acuerdos compartidos, de modo que la siguiente salida no provoque un nuevo parón.
Gobernanza que evita las recaídas
Un proyecto rescatado puede volver a atascarse igual de rápido si usted no cambia nada en el cómo dirige. Necesita gobernanza, pero a la medida de una pyme, no la pesada estructura de comités de dirección de una multinacional. Ligera, rítmica y práctica.
Empiece con un ritmo de dirección breve y fijo con usted presente. Una reunión de media hora cada semana o cada dos semanas, en la que el avance se haga demostrable, es suficiente. No se trata de la reunión, se trata del ritmo: una visibilidad regular mantiene a todos alerta.
Después, redefina el alcance hasta un MVP mínimo que recorte la expansión del alcance de vuelta al valor central. ¿Cuál es lo más pequeño que aporta valor de verdad? Constrúyalo primero, y vigílelo con firmeza. Cualquier deseo fuera de ello va a una lista para más adelante, no se cuela en silencio en el sprint.
Mantenga la toma de decisiones rápida: la baja latencia era todo el sentido y sigue siéndolo. Incorpore puertas de control de calidad (QA) para que los errores se resuelvan y no se escondan; un fallo remendado siempre vuelve. Y deje por escrito los acuerdos sobre cambios de alcance, para que nadie recuerde después algo distinto.
Por último, defina explícitamente lo que significa «recuperado», de modo que pueda reconocerlo: unas cuatro semanas o más de entrega consistente e ininterrumpida de lo acordado, software demostrablemente funcional en cada ciclo, y predictibilidad y confianza recuperadas. No un informe de estado optimista, sino un avance visible y sobre el que se puede hacer clic. Solo entonces un proyecto está realmente de vuelta en la vía.
Un ejemplo desarrollado, a grandes rasgos
¿Cómo se ve esto en la práctica? Tomemos nuestro rescate en Andes Seguridad, a grandes rasgos, porque los detalles pertenecen al cliente. El proyecto mostraba las señales conocidas: un trayecto que seguía estando «casi listo», mientras que poco demostrablemente funcional llegaba a la mesa.
Empezamos con un diagnóstico rápido y honesto: qué funciona, qué no está bien y cuánto de lo existente es realmente aprovechable. Sobre esa base tomamos una elección clara entre rescatar y reconstruir, una decisión basada en los cimientos y en la parte reutilizable, no en lo que ya se había gastado.
A continuación, devolvimos el proyecto paso a paso a sus objetivos originales, con los acuerdos de trabajo adecuados por debajo: una sola línea de responsabilidad, una línea base realista y un ritmo que devolvió al empresario el control. El orden —detectar, diagnosticar, decidir, reiniciar, consolidar— no fue teoría, sino la ruta real de vuelta. No una historia milagrosa, sino un proyecto que volvió a entregar.
Conclusión: cuándo debe pedir ayuda
El orden de decisión es fácil de recordar: detecte pronto, diagnostique rápido, decida con honestidad, reinicie a las personas y la tecnología, y consolide con una gobernanza ligera. La pregunta que debe hacerse continuamente nunca es «¿es esto perfecto?», sino «¿seguimos en rumbo hacia el objetivo original y, si no, cuándo intervenimos?».
La respuesta honesta a ese «cuándo» es casi siempre: antes de lo que ahora cree. Intervenir pronto sale más barato que tener razón más tarde.
¿Le parpadean dos o más señales a la vez, durante más de dos sprints? Entonces un diagnóstico breve y honesto es, con diferencia, el siguiente paso más barato. Después sabrá dónde está, y podrá decidir con cifras en lugar de con la intuición.