Contratas software creyendo que vas a pagar para construir y después usar. En la práctica, la mayor parte del dinero se va manteniendo funcionando lo que ya fue entregado. Es común que el 40%, 60%, a veces 80% de la capacidad del equipo de tecnología esté ocupada arreglando, ajustando, rehaciendo algo que ya existe. Sobra poco para lo nuevo. Y ese ‘poco’ se vuelve ‘nada’ en el mes en que hay un incendio.
Esto no es mala suerte, no es falta de buena gente, y rara vez es un problema de herramienta. Es el resultado de decisiones que nadie tomó al comienzo. Este artículo explica en lenguaje claro dónde está la fuga y cómo cerrar la llave antes del próximo presupuesto.
1. Qué es el ‘mantenimiento’ y por qué crece solo
El mantenimiento, en el mundo del software, es todo el trabajo que el equipo gasta para mantener funcionando lo que ya fue entregado: arreglar un error que apareció, ajustar una regla que ‘no era bien así’, rehacer una parte que dejó de aguantar el uso, atender un ticket de cliente. No es construir lo nuevo. Es sostener lo que existe.
Piensa en una obra: el albañil entregó la casa, y todas las semanas vuelve para arreglar una filtración que él mismo hizo. Pagas su hora de nuevo, y la casa sigue sin ampliarse. En el software ocurre lo mismo, pero es invisible, porque el cliente final no ve al albañil volviendo, solo ve que ‘todavía no salió la función nueva’.
El resultado aparece en reuniones así: ‘no tenemos capacidad para la función nueva’, ‘el equipo está apagando incendios esta semana’, ‘apareció un problema crítico y trabó todo’. Esa es la factura llegando. Y crece sola, porque cada arreglo hecho a las apuradas por lo general crea el siguiente.
2. Dónde está la fuga: el trabajo se hizo en el momento equivocado
Existe una regla simple y cruel: cada problema cuesta mucho menos resolverlo antes de que el sistema exista que después. En números aproximados que se repiten en el mercado: lo que cuesta 1 hora resolver antes de programar, cuesta 10 horas después de que el sistema está listo, y 50 horas después de que está en el aire con usuarios.
Cuando ves a un equipo viviendo en mantenimiento, es casi seguro que el trabajo que debía haberse hecho antes (acordar reglas, prever casos de error, planear el impacto del cambio) se está haciendo después, en forma de ticket y corrección de emergencia. El equipo no está ejecutando mal. Está ejecutando en el momento equivocado de la línea de tiempo.
Analogía de obra: descubrir que faltó un enchufe en la cocina después de que el azulejo ya está colocado. El enchufe existe, va a existir, pero el costo de hacerlo aparecer ahora es diez veces mayor que si hubiera sido marcado en el plano.
3. Acordar antes: el plano del sistema
Antes de programar una línea, tres cosas necesitan estar escritas, en un lenguaje que el dueño del negocio entienda:
- Las reglas innegociables: lo que el sistema DEBE hacer siempre. Ejemplo: ‘toda venta genera una factura’, ‘ningún cliente puede ver el pedido de otro cliente’, ‘el inventario nunca puede quedar negativo’.
- Qué hacer cuando haya un problema: cada caso de error necesita una respuesta acordada. ‘¿Si el pago falla, en qué estado queda el pedido?’ ‘¿Si el cliente cancela después de enviado, a quién se le avisa?’
- Quién habla con quién: qué sistemas intercambian información, en qué momento, y qué espera recibir cada uno.
Es el equivalente al plano firmado de la obra. Sin eso, toda duda que aparezca durante la construcción se vuelve improvisación. La improvisación en la construcción se vuelve ticket después de entregado. El ticket después de entregado se vuelve mantenimiento. El mantenimiento se vuelve la factura que vuelve todos los meses.
Quien escribe estas tres piezas no es solo el equipo técnico, es el dueño del negocio junto a él. Un buen software empieza con una decisión de negocio bien acordada, no con una tecnología elegida.
4. Planear antes de tocar: ver el daño posible
Cada vez que se va a cambiar algo en un sistema que ya está funcionando, existe un riesgo: qué más puede romperse junto. El software está lleno de partes conectadas que no siempre son obvias. Tocar una puede detener otra que nadie estaba mirando.
Antes de cualquier cambio, el equipo debería poder responder, en cinco líneas escritas: qué partes van a ser tocadas, en qué orden, qué más puede romperse junto, cuál es la manera de volver atrás si sale mal. Quien no logra escribir esto todavía no entendió el cambio que va a hacer. Y va a descubrir lo que faltó en producción, con el cliente reclamando.
Analogía: reformar una sala sin apagar el disyuntor. Puede salir todo bien. Pero el día en que el electricista toque el cable equivocado, se detiene el piso entero. La pregunta ‘¿cuál es el disyuntor que necesito apagar?’ toma dos minutos. No hacer esa pregunta puede detener el edificio por horas.
5. Entregar con botón de apagado y panel para mirar
‘Entregar’ en el mercado del software suele significar ‘se subió al aire, salió bien, siguiente’. Ese entendimiento es caro. La entrega de verdad tiene tres componentes que separan el arreglo de 5 minutos del incidente de 5 horas:
- Botón para apagar la función: si la funcionalidad nueva da problema, el equipo puede desactivar solo esa, sin rehacer el sistema, sin detener el resto. Sin ese botón, todo problema nuevo se vuelve una corrección de emergencia bajo presión.
- Panel para acompañar: la función nueva necesita ‘denunciar’ si está funcionando bien o mal. Sin panel, el equipo solo descubre el problema cuando el cliente llama reclamando. Y entre que el problema aparece y alguien se da cuenta, pasan días.
- Plan para volver atrás: si nada de eso lo resuelve, cómo volver a la versión anterior, en cuánto tiempo, y quién lo acciona. Una línea escrita. Quien improvisa esto en el momento improvisa mal.
Sin esos tres, toda entrega es una apuesta. Cuando la apuesta sale mal, se vuelve una fila de mantenimiento invisible: el problema queda en el aire, nadie lo ve, y cuesta en ventas perdidas, cliente irritado, horas de gente trabajando de noche para arreglarlo.
6. Qué hacer con el mantenimiento que ya tienes
Los pasos anteriores resuelven el pasivo futuro. Pero ya tienes un pasivo en el presente, e intentar matarlo todo de una vez es lo que destruye equipos. El mantenimiento acumulado necesita triaje, no una cruzada.
Mira la lista de problemas que vuelven todas las semanas y clasifica cada uno por tres preguntas: ¿con qué frecuencia reaparece?, ¿cuánto tiempo consume cada vez?, ¿con qué frecuencia cambia esa parte del sistema?. Los ‘muros de carga’ del pasivo son los que puntúan alto en las tres. Esos entran en una temporada de corrección planeada, con las reglas escritas antes (aunque sea tarde). El resto se vuelve un arreglo rápido con precio fijo o se acepta como costo de operación hasta la próxima revisión.
El error clásico es decidir ‘vamos a dejar todo en cero’. No se puede, e intentarlo genera más problemas (un arreglo a las apuradas en código ya frágil rompe algo nuevo). El objetivo es reducir lo que entra nuevo en la fila, no vaciar la fila. La fila se reduce por consecuencia, en meses, cuando el método de acordar y planear antes se va volviendo un hábito.
7. Tres números que muestran si el método está funcionando
No hace falta un panel sofisticado. Tres números, en una planilla, cuentan la historia:
- Cuántos problemas aparecen en los primeros 15 días después de cada entrega, divididos por la cantidad de cosas entregadas. Si está bajando, es señal de que acordar antes está funcionando.
- Cuántos tickets revelan ‘nadie acordó que era así’. Si está bajando, es señal de que el plano del sistema se está escribiendo mejor.
- Cuánto tiempo hasta que el equipo descubre un problema. Si está bajando, es señal de que el panel lo está detectando antes de que el cliente reclame.
Esos tres bajando juntos significan que el costo invisible se está cortando de raíz, no solo reacomodando de lugar.
8. El punto principal
El mantenimiento no desaparece. Pero deja de ser el destino del presupuesto. La diferencia entre un equipo que vive arreglando y un equipo que entrega cosas nuevas es dónde se colocó el trabajo en la línea de tiempo: antes de que el código existiera, o después de que el sistema estuviera en el aire.
Cinco líneas acordadas antes cuestan una reunión. Cinco horas de mantenimiento después cuestan un día perdido, un cliente irritado, y la entrega del mes que no salió. El método no es una metodología de moda, es una decisión sobre dónde gastar. Quien decide gastar antes, paga menos. Quien lo ignora, sigue recibiendo la factura todos los meses con la etiqueta ‘imprevisto’, y prometiendo que la próxima vez habrá tiempo de hacerlo bien.