Cómo continuar un proyecto de software incompleto

Un proyecto que se detuvo a mitad de camino deja a la empresa en la peor posición: pagó una parte, no tiene un sistema utilizable, y no sabe cuánto falta de verdad.

La pregunta que se hace primero suele ser «¿cuánto falta?». La que conviene hacer primero es «¿qué hay?».

Primero: inventario de lo que existe

Antes de estimar nada hay que saber qué se recibió. La lista mínima:

• El código, completo y en un repositorio al que tengas acceso.
• Qué está terminado y qué está a medias. No lo que dice el informe: lo que se puede abrir y usar.
• La documentación, si existe: alcance acordado, diseños, decisiones técnicas.
• Los accesos: dominio, servidores, servicios de terceros, base de datos.
• Lo pagado y contra qué. Qué etapas se facturaron y qué se acordó que incluían.

Si el código no está en tus manos, esa es la primera gestión, y conviene hacerla mientras la relación con el proveedor anterior siga siendo cordial.

Segundo: evaluar si lo construido se rescata

Aquí hay que ser honesto en las dos direcciones. Descartar todo por comodidad desperdicia lo pagado; conservar todo por apego a la inversión puede salir más caro que empezar de nuevo.

Cinco preguntas definen la respuesta:

1. ¿Corre? Si nadie logra levantar el proyecto en un ambiente de pruebas, lo que hay es un archivo, no un sistema.
2. ¿La estructura de datos tiene sentido? Es lo más caro de cambiar después. Si está bien pensada, ya hay bastante ganado aunque el resto sea mediocre.
3. ¿Se puede cambiar algo sin romper tres cosas? Un cambio pequeño de prueba responde esto en un día.
4. ¿La tecnología tiene soporte? Continuar sobre versiones sin soporte es heredar un problema con fecha.
5. ¿Alguien puede entenderlo en tiempo razonable? Si entender cuesta más que reconstruir, la cuenta ya está hecha.

Con tres respuestas positivas de cinco, normalmente se continúa. Con una o ninguna, rehacer suele ser más barato aunque duela.

Un resultado intermedio, y el más común

Rara vez es todo o nada. Lo habitual es que una parte se rescate y otra se rehaga: la estructura de datos sirve pero las pantallas no, o el sistema base está bien y la integración está mal resuelta.

Ese resultado es bueno. Significa que lo pagado no se perdió del todo y que la continuación parte con ventaja.

Tercero: definir el alcance restante desde cero

Este es el paso que más se salta y el que más problemas evita.

El alcance original ya no sirve: fue escrito antes de saber lo que hoy se sabe, y probablemente es una de las razones por las que el proyecto se detuvo. Conviene escribirlo de nuevo, con lo que falta de verdad, y aprovechando la oportunidad para recortar lo que en el camino demostró no ser necesario.

De ahí sale una estimación confiable, que es lo que no se puede dar antes.

Cómo evitar que vuelva a ocurrir

Los proyectos se detienen por razones que casi siempre se repiten: alcance que nunca estuvo escrito, entregas que solo llegaban al final, y decisiones que quedaban esperando semanas. Está desarrollado en por qué se atrasan los proyectos.

Para la continuación, tres condiciones ayudan más que cualquier otra cosa:

• Alcance escrito y acordado antes de retomar.
• Entregas cada dos o tres semanas, con algo que puedas abrir.
• Los accesos y el código a tu nombre desde el primer día.

Cómo empezamos estos casos

Con una revisión que termina en un informe: qué hay, qué se rescata, qué se descarta, y cuánto cuesta terminarlo. Se cotiza aparte y el informe es tuyo, sigas con nosotros o con otro equipo. Es parte de la consultoría tecnológica; la continuación del desarrollo entra como software a medida.