"Hay que hacerlo todo de nuevo": la pregunta antes de tirar un sistema

“Hay que hacerlo todo de nuevo” es de las frases que más se escuchan en tecnología. A veces la dice el dueño, cansado de los reclamos. Muchas veces la dice el propio equipo de desarrollo, o el proveedor que acaba de heredar un sistema ajeno.

Y suena razonable. El sistema actual tiene problemas a la vista: es lento, falla, cada cambio cuesta más que el anterior. El nuevo todavía no tiene ninguno, porque todavía no existe. Contra algo que todavía no existe, el sistema actual pierde siempre.

El sistema que estaba “imposible”

Hace un tiempo llegó una empresa que daba su sistema por perdido. Sus clientes le decían que estaba “imposible”, y la decisión parecía tomada: hacerlo de nuevo.

Lo primero que le pedimos fue que cronometrara las operaciones de las que se quejaban sus clientes. Tardaban minutos.

Después medimos el resto del sistema, y la demora estaba en todas las pantallas. En las consultas simples eran segundos, y por eso nadie se quejaba. Eran muchos síntomas y una sola causa, que estaba en la base de datos. Se corrigió en medio día de trabajo, y el sistema volvió a tiempos normales de uso.

La misma medición mostró algo más: dos o tres procesos que sí necesitaban una intervención puntual. Lo que siguió, en una segunda etapa, fue corregir esos procesos, no rehacer el sistema.

Es lo que muchas veces pasa con el principio de Pareto: una parte chica del esfuerzo resuelve la mayor parte del problema. Acá, la mejora grande salió de una fracción mínima de lo que costaba rehacer, y el resto de ese presupuesto habría comprado poca mejora adicional. Todos conocen el principio. Lo difícil es saber cuál es esa parte chica, y para eso primero hay que medir. Cómo tomar esa medición antes de decidir lo cuento en Sin línea base no hay decisión fundada.

El sistema anterior también empezó de cero

Claro que no siempre alcanza con medio día. Pero aun cuando el sistema tenga problemas de fondo que impliquen soluciones más costosas, hay una pregunta que conviene hacerse antes de rehacerlo.

El sistema que hoy se quiere tirar también fue, alguna vez, el sistema nuevo. Se empezó de cero, muchas veces con el mismo equipo, y con la misma promesa de hacerlo bien esta vez. Si terminó así, algo en el camino lo llevó hasta acá.

Y ese camino casi nunca es solo técnico. Muchas de las decisiones apuradas que lo complicaron vinieron del negocio: plazos que no se podían mover, prioridades que cambiaban a mitad de camino, funciones que había que tener para ayer. La responsabilidad casi siempre es compartida.

Por eso la pregunta no es qué hizo mal el equipo. Es otra: ¿qué va a ser distinto esta vez en cómo se decide? Si nadie la puede contestar, empezar de cero es volver a recorrer el mismo camino, con el costo de meses de trabajo y un sistema que, mientras tanto, hay que seguir manteniendo.

Es una pregunta que quien decide le puede hacer al equipo, y hacerse a sí mismo, sin que suene a reproche.

Hay una segunda pregunta, para cuando lo que se propone es cambiar de tecnología. Muchas veces ese impulso nace del equipo de desarrollo o de perfiles técnicos de la propia empresa. La tecnología avanza rápido, y es común que, al evaluar un sistema existente, lo primero que se escuche sea que “no sirve” porque no está hecho con lo último.

La pregunta es: ¿qué va a poder hacer quien usa el sistema que hoy no puede? Al usuario no le cambia nada con qué está hecho. Le cambia lo que puede hacer y cómo eso mejora su operatoria. Si la respuesta es “nada, pero va a estar hecho con algo más moderno”, el cambio puede tener sentido técnicamente, pero hay que decidirlo sabiendo que el negocio no lo va a notar.

Cuándo rehacer sí es la decisión correcta

Nada de esto quiere decir que nunca haya que rehacer un sistema. A veces es la decisión correcta, por ejemplo:

• Cuando la medición muestra que llegó a su límite. Se corrigió lo que se podía corregir, y el sistema sigue sin dar lo que el negocio necesita.
• Cuando la tecnología ya no tiene soporte, y eso deja de ser una incomodidad para ser un riesgo de seguridad.
• Cuando el negocio cambió tanto que el sistema ya no lo representa. Se diseñó para una empresa que ya no existe, y cada adaptación es un parche sobre algo pensado para otra cosa.

En esos casos, rehacer es una decisión con razones. Y aun así la pregunta de antes sigue valiendo, porque el sistema nuevo también va a enfrentar plazos y prioridades que cambian.

Que la próxima vez se sepa qué pasó

Buena parte del problema es que las decisiones que llevaron a un sistema a su estado actual no quedaron escritas. Nadie recuerda por qué se hizo así, qué se postergó, ni qué se sabía en ese momento. Entonces el diagnóstico se reemplaza por una impresión: “está mal hecho”.

Por eso, cuando trabajo con una empresa, cada decisión queda en una Hoja de Ruta: qué se decidió, por qué y qué se esperaba. La próxima vez que alguien diga “hay que hacerlo todo de nuevo”, hay algo contra qué comparar, y se puede saber qué salió mal.