Costo y decisión
Me hicieron un sistema y quedó a medias: qué hacer con lo que tienes
Antes de tirarlo o de pagar otra vez, hay que saber qué hay: si existe el código y a nombre de quién, si la base de datos se puede recuperar, y qué parte del proceso sí quedó funcionando. Con eso se decide entre tres caminos: continuar, rescatar solo los datos o empezar de nuevo con lo aprendido. Los tres son legítimos.
Publicado el · 8 minutos · César Barreto
Pasa más de lo que se cuenta. El proveedor dejó de contestar, o entregó algo que funciona a medias y nadie sabe cómo continuarlo. Lo primero es bajar la temperatura: casi siempre hay más rescatable de lo que parece, y casi nunca conviene la decisión que se toma con enojo, que es tirar todo y volver a empezar con otro que prometa lo mismo.
¿Qué se hace primero?
Un inventario de lo que existe, y en este orden. Son cinco preguntas y ninguna es técnica; las respuestas se piden por escrito, aunque sea por mensaje.
- 01
¿Dónde está el código y a nombre de quién?
Repositorio, o al menos un archivo comprimido con la última versión. Si el proveedor no lo entrega, eso ya es una respuesta y cambia el resto de las decisiones.
- 02
¿Puedes entrar a la base de datos?
Es lo más importante de todo. Los datos son tuyos aunque el código no se pueda continuar: clientes, saldos, catálogo, historial. Con los datos en la mano, ningún camino queda cerrado.
- 03
¿Dónde corre y quién paga el servidor?
Si la cuenta está a nombre del proveedor, el sistema puede apagarse el día que él deje de pagar. Sacar de ahí una copia es urgente, aunque después no se use.
- 04
¿Qué parte del proceso sí quedó funcionando?
No lo que dice la propuesta: lo que la gente usa todos los días. Pregúntale a quien captura. A veces el módulo que el dueño da por muerto es el único que se usa.
- 05
¿Hay algo escrito?
Manual, modelo de datos, correos con acuerdos, la propuesta original. Cualquier cosa que diga qué se pactó sirve para saber qué falta y para la conversación que venga.
Si de las cinco solo puedes contestar la cuarta, el problema no es que el sistema quedó a medias: es que nunca fue tuyo. Recuperar los datos pasa a ser lo único urgente.
¿Cómo se sabe si lo que hay se puede continuar?
Con una revisión que toma unas horas y que cualquier equipo serio puede hacerte, incluido uno que no sea el que lo construyó. Lo que se mira no es si el código es bonito, sino cinco cosas que deciden el costo de seguir.
- Si hay pruebas automatizadas. Sin ellas, cada cambio es una apuesta y el costo de continuar se dispara, porque hay que probar todo a mano cada vez.
- Si el modelo de datos tiene sentido. Es lo más caro de arreglar y lo que más determina si conviene seguir: un esquema razonable aguanta código feo encima.
- Si las reglas del negocio están en un solo lugar o repartidas. Repartidas significa que un cambio de precio hay que hacerlo en cuatro sitios y que uno se va a olvidar.
- Si la tecnología sigue viva. Un sistema sobre algo que ya nadie mantiene se puede continuar, pero cada mes que pasa cuesta más encontrar quién.
- Si los permisos existen. Si cualquier usuario puede ver o cambiar cualquier cosa, no es un detalle a mejorar: es un riesgo abierto mientras el sistema esté encendido.
Los tres caminos, y cuándo conviene cada uno
| Camino | Cuándo conviene | Qué implica |
|---|---|---|
| Continuar sobre lo que hay | El modelo de datos aguanta, la gente ya lo usa y lo que falta son módulos, no cimientos | Primero pruebas sobre lo que ya funciona, después los módulos nuevos. Nunca al revés |
| Rescatar los datos y reconstruir | Los datos son buenos pero el código no se puede tocar sin romperlo | Se migra el catálogo, los clientes y los saldos, y se construye encima con el proceso ya aprendido |
| Empezar de nuevo | Ni los datos ni el código sirven, o el proceso cambió tanto que el sistema resolvía otro negocio | Lo aprendido no se tira: la lista de lo que falló es la mejor definición de requisitos que vas a tener |
El error que se comete casi siempre
Contratar al siguiente proveedor para que termine lo que falta, sin haber revisado lo que hay. Entonces pasa una de dos: el nuevo dice que hay que empezar de cero porque es más cómodo para él, o acepta continuar sin conocer el terreno y a las cuatro semanas descubre que el cimiento no aguanta. En los dos casos el que paga la sorpresa es el dueño.
La revisión previa es barata comparada con eso, y se puede pedir con una condición sana: que quien la haga esté dispuesto a decirte que lo que hay se puede continuar, aunque eso signifique un proyecto más chico para él.
Cómo evitar que vuelva a pasar
Un sistema queda a medias por razones que casi siempre se ven antes, y las tres más comunes no son técnicas.
- 01
Alcance sin fases
Un proyecto de seis meses con un solo pago al final es una apuesta. Por fases de dos a cuatro semanas, cada una con algo que puedes ver funcionando, el riesgo se corta en pedazos.
- 02
Pagar por calendario y no contra entrega
Si el pago va contra fechas, se paga aunque no haya nada que ver. Si va contra un entregable aceptado, el proyecto no puede quedarse a medias sin que se note el mismo mes.
- 03
No pedir la entrega documental desde el principio
Manual técnico, respaldo probado y las cuentas a tu nombre no son un extra del final: son lo que hace que el proyecto sobreviva a cualquier proveedor, incluido el actual.
Y una cuarta que vale por las tres: pedir ver algo funcionando cada dos semanas, con tus datos. No una presentación de avance. Un sistema que se puede enseñar cada quince días difícilmente queda a medias sin que alguien se dé cuenta a tiempo.
Cuándo no conviene rescatarlo
- Cuando no tienes acceso a la base de datos ni forma de conseguirlo. Sin los datos, continuar es construir de nuevo con más pasos.
- Cuando el sistema resolvía un proceso que ya cambiaste. No es un problema de código: lo que se construyó ya no es lo que necesitas.
- Cuando lo que falta es más de la mitad. Ahí continuar suele costar más que empezar, porque hay que entender lo hecho antes de poder añadir nada.
- Cuando el sistema maneja dinero o datos de clientes y no tiene permisos ni respaldo. Antes de decidir nada, eso se apaga o se cierra: el riesgo corre mientras esté encendido.
Quién escribe
César Barreto, fundador de riel. Ingeniería industrial y desarrollo: mira la operación antes que el código.
Construyó el ERP de Distribuidora del Golfo, 19 módulos entregados en 6 fases con 1,148 pruebas automatizadas.
Conocer a riel →Preguntas frecuentes
El proveedor no me entrega el código. ¿Qué puedo hacer?
Pedir por escrito el código, la base de datos y las credenciales, citando lo que diga la propuesta o el contrato sobre la propiedad. Si no hay respuesta, lo urgente es sacar una copia de los datos, que sí suelen estar a tu alcance desde el propio sistema. Sin código se puede reconstruir; sin datos, no.
¿Cuánto cuesta rescatar un sistema a medias?
Depende de qué se rescate. Una revisión para saber en qué estado está toma unas horas. Continuar sobre lo que hay cuesta menos que construir de nuevo solo cuando el modelo de datos aguanta; cuando no, sale más caro y se paga en cuotas, que es lo que lo hace difícil de ver.
¿Otro proveedor puede continuar lo que hizo alguien más?
Sí, si existen el código, la base de datos y algo escrito sobre cómo se levanta. Lo que hace imposible continuar casi nunca es el lenguaje de programación: es que nadie sepa cómo se pone en marcha ni por qué se tomó cada decisión.
¿Conviene volver a contratar al mismo proveedor?
A veces sí, y no es una mala señal por sí sola. Conviene si el problema fue de alcance o de calendario y hay disposición a trabajar por fases con entregables aceptados. No conviene si el problema fue que nadie sabía qué se estaba construyendo.