Cuando "ya casi está" lleva semanas
Hay una frase que aparece en casi todos los proyectos de software que terminan mal: "ya casi está". La primera vez que la escuchas, parece razonable. La quinta vez, en semanas diferentes, es una señal de que algo está fundamentalmente roto.
Este artículo describe cómo identificar un proyecto en peligro antes de que el daño sea irreversible, y qué hacer al respecto.
Las señales tempranas
"Ya casi está" en semanas diferentes
Si una tarea lleva más de dos semanas en estado "casi terminado", no está casi terminada — está atascada. La causa puede ser técnica (el problema es más difícil de lo esperado) o de proceso (no hay criterios claros de qué significa "terminado"), pero el resultado es el mismo: pérdida de tiempo y de confianza.
No puedes ver el estado real sin pedir un reporte
Si tu única fuente de información sobre el proyecto es lo que te dice el PM en la reunión semanal, no tienes visibilidad — tienes una narrativa. Los proyectos saludables tienen dashboards que cualquiera puede abrir en cualquier momento y ver el estado real.
Los desarrolladores rotan sin handoff
Cada vez que un desarrollador sale del proyecto sin documentar qué hizo, qué falta, y qué decisiones tomó, el proyecto pierde contexto. Y el contexto perdido se paga con tiempo y dinero cuando el siguiente developer tiene que descubrir lo que ya se sabía.
Cada entrega viene con bugs pendientes
"Lo entregamos y lo arreglamos en el siguiente sprint" es una trampa. Crear la cultura de entregar con deuda técnica es muy fácil. Salir de ella es muy difícil.
El equipo evita revisiones técnicas
Si nadie quiere hacer una revisión del código con el cliente presente, es porque no están orgullosos de lo que tienen. Y si no están orgullosos del código que ya entregaron, imagina cómo está el que falta.
Cómo rescatar el proyecto
Paso 1: Diagnóstico técnico honesto (1-2 semanas)
Antes de cualquier decisión, necesitas saber el estado real del código: cobertura de tests, deuda técnica acumulada, arquitectura, dependencias desactualizadas. Este diagnóstico no lo hace el mismo equipo que desarrolló — los conflictos de interés son inevitables. Necesitas una revisión externa.
Paso 2: Decide: rescatar o reescribir
Con el diagnóstico en mano, la decisión es más fácil:
- Rescatar si: hay repositorio limpio, hay tests, la arquitectura es coherente, y el problema es principalmente de proceso
- Reescribir si: no hay tests, el código está acoplado sin estructura, y el tiempo para arreglarlo supera el de hacerlo bien desde cero
No hay respuesta correcta universal. Hay una respuesta correcta para tu proyecto específico.
Paso 3: Estabilización (2-4 semanas)
Si el rescate es viable, el primer objetivo es detener el sangrado: arreglar los problemas críticos que bloquean el avance, establecer un pipeline de CI/CD básico, y documentar el estado actual del sistema.
Paso 4: Normalización del proceso
El rescate técnico sin cambio de proceso no sirve. Necesitas implementar antes de continuar: criterios de aceptación por tarea, pipeline de CI/CD activo, repositorio en tu cuenta, y dashboard de progreso real.
Si el proveedor actual no puede o no quiere adoptar este proceso, la respuesta no es seguir con él — es hacer el cambio ahora, no después de otro sprint fallido.