Cómo rescatar un proyecto de software fallido (y cuándo empezar de cero)

Los proyectos rara vez fracasan en un día. Se desvían poco a poco, y cada señal por separado es fácil de justificar. Juntas, cuesta pasarlas por alto:

• Las fechas se aplazan una y otra vez, cada vez por un motivo nuevo.
• Cada corrección rompe otra cosa, y los mismos errores vuelven.
• Nadie sabe decir con claridad cuándo se lanzará el producto.
• El desarrollador o la agencia tarda en responder o deja de hacerlo.
• Usted no tiene acceso al código, a los servidores ni a las cuentas.
• Los desarrolladores nuevos dicen que no pueden trabajar con el código «sin reescribirlo primero».

Una de estas señales es una advertencia. Tres o más suelen significar que el proyecto necesita un rescate, no otra fecha límite.

Por ejemplo, una startup cuyo freelancer ha dejado de responder y es el único que tiene la contraseña del servidor necesita un rescate, aunque el código en sí esté bien.

La primera semana sienta las bases de todo lo demás. Antes de cualquier trabajo técnico vienen cuatro pasos:

• Pausar las funciones nuevas. Seguir construyendo sobre una base inestable encarece cada corrección posterior.
• Asegurar los accesos. Compruebe que controla el código, los servidores, el dominio y cada servicio del que depende el producto.
• Anotar qué se prometió y qué existe. Reúna la propuesta, el contrato, los diseños y una lista de lo que funciona hoy de verdad.
• Retener los pagos no vinculados a trabajo entregado. Si los pagos van por hitos, pause el siguiente hasta tener un plan claro.

No empiece buscando culpables. Quién llevó el proyecto a este punto y por qué importa mucho menos que saber qué se puede hacer ahora, cuánto costará y cuándo funcionará el producto.

Los accesos son lo que más a menudo les falta a los fundadores justo cuando más importa. Revise cada punto de esta lista y anote quién lo controla hoy:

• El repositorio de código con todo su historial, no un archivo zip de la última versión.
• Las cuentas de hosting y de servidores, incluidas bases de datos y copias de seguridad.
• El registrador del dominio y la configuración DNS.
• Las cuentas de desarrollador en las tiendas de aplicaciones, si hay una app móvil.
• Los servicios externos: pagos, correo, analítica, mapas, API de IA.
• Los archivos de diseño y cualquier documentación existente.

Si el repositorio está en la cuenta de otra persona, pida que se lo transfiera. La documentación de GitHub explica cómo una transferencia conserva el historial, las incidencias y las pull requests.

Si alguien no colabora, recupere lo que pueda desde su lado: el dominio y el hosting suelen estar pagados con su tarjeta o registrados con su correo, y ese es un camino de vuelta.

Una auditoría es una revisión estructurada del producto tal como es, no como lo describió el último proveedor. Una auditoría útil cubre estas áreas:

• Arquitectura. Cómo encajan las piezas y si la estructura puede sostener las funciones que necesita.
• Calidad del código. Legibilidad, duplicación y lo arriesgado que resulta hacer cambios.
• Seguridad. Riesgos habituales como los del OWASP Top 10, además de cómo se guardan los secretos y los datos personales.
• Infraestructura. Hosting, despliegue, copias de seguridad y monitorización.
• Pruebas y documentación. Qué existe, qué falta y cuánto costaría añadirlo.

El resultado debe ser un veredicto claro para cada parte del producto: conservar, arreglar o reescribir, cada uno con su motivo. Solo entonces alguien puede darle un precio que refleje el código tal como es.

En Sakura trabajamos exactamente en ese orden: primero la auditoría, después el presupuesto. Es la única forma de no presupuestar un rescate sobre promesas que el código no cumple.

¿Su proyecto está atascado ahora mismo? Cuéntenos qué ha pasado. Empezaremos por los accesos y la auditoría y le diremos con honestidad qué se puede salvar.

Casi siempre, arreglar. El código antiguo que funciona en producción contiene años de pequeñas correcciones para problemas reales, y reescribirlo las tira junto con las partes malas.

Joel Spolsky lo explicó en su conocido ensayo Things You Should Never Do. Llamó a reescribir el código desde cero «el peor error estratégico que puede cometer una empresa de software», con Netscape como ejemplo: la reescritura llevó casi tres años mientras la competencia se adelantaba.

Hay casos en los que reescribir es la respuesta honesta. Esta tabla muestra cómo lo valoramos:

Incluso cuando gana la reescritura, rara vez hace falta hacerla de golpe. El patrón Strangler Fig de Martin Fowler describe cómo sustituir un sistema por partes: las piezas nuevas crecen junto a las antiguas hasta que el código viejo se puede apagar.

Si el desarrollador o la agencia anterior sigue localizable, un traspaso breve y tranquilo ahorra tiempo y dinero. Pida tres cosas: acceso a todo, una lista de los problemas conocidos y una sesión de una hora sobre cómo se despliega el producto.

Mantenga la conversación en los hechos. La gente cuenta más cuando no se siente acusada, y los detalles que recuerda del código valen más que cualquier discusión sobre quién tiene la culpa.

Si el equipo anterior no colabora, no lo espere. Recupere las cuentas que controla, empiece la auditoría con lo que hay y deje por escrito qué pidió y cuándo.

Una vez que hay veredicto, trabaje en un orden estricto. Primero el lanzamiento, después las mejoras:

• Estabilizar. Corrija los errores críticos que tumban el producto, pierden datos o bloquean pagos.
• Terminar los flujos de lanzamiento. Complete solo lo que el producto necesita para salir; todo lo demás espera.
• Configurar despliegue y monitorización. Para que publicar sea rutina y los problemas se vean antes de que los usuarios los reporten.
• Lanzar. Los usuarios reales le mostrarán cuáles de los problemas pendientes importan de verdad.
• Mejorar. Trabaje el resto de la lista según su impacto en el negocio.

Las versiones semanales que usted puede probar mantienen el rescate honesto. Después de que un proyecto se torció una vez, debería ver el avance cada semana, no solo oír hablar de él.

Por ejemplo, una startup cuya agencia incumplió varias fechas puede descubrir que la mayor parte del producto funciona y que tres flujos rotos bloquean el lanzamiento. Si se arreglan esos tres primero, el producto sale, y el resto del backlog se planifica con datos de uso reales.

Depende de lo que encuentre la auditoría, por eso un presupuesto honesto llega después de la auditoría y no antes. Quien presupuesta un rescate sin mirar el código está adivinando.

Tras la auditoría, el trabajo hasta el lanzamiento suele poder presupuestarse con alcance cerrado. Así obtiene una cifra clara para llegar a producción, separada de las mejoras posteriores.

Si compara presupuestos para el propio rescate, se aplican las mismas reglas que en cualquier proyecto. Nuestra guía sobre precio cerrado o por horas explica cuándo encaja cada modelo.

Un proyecto rescatado es la ocasión de poner las protecciones que faltaron la primera vez:

• Propiedad. El repositorio, el hosting, el dominio y las cuentas de las tiendas quedan registrados a nombre de su empresa.
• Documentación. Se escribe durante el trabajo, para que el producto nunca vuelva a depender de una sola persona.
• Hitos. Los pagos siguen a resultados verificables, como una versión que funciona en un enlace de prueba.
• Un proceso de cambios. Los requisitos nuevos se estiman y se aprueban antes de que nadie trabaje en ellos.
• Soporte tras el lanzamiento. Un plan claro para correcciones y actualizaciones, como un plan de soporte mensual.

Si elige un equipo nuevo para la siguiente etapa, nuestra guía sobre cómo elegir una agencia de desarrollo recoge las preguntas que delatan a los socios débiles antes de firmar.

Si quiere que su producto vuelva a avanzar, envíenos un brief breve. Empezaremos por los accesos y la auditoría para que sepa en qué punto está antes de cualquier compromiso grande.