El mantenimiento creció hasta consumir el 40, el 60, a veces el 80% de la capacidad del equipo. No estás solo, y el culpable tampoco es la falta de QA, seniority o herramientas. El mantenimiento es la factura que llega cuando se saltó el flow. Toda duda que no se convirtió en spec antes del código se convierte en ticket después. Todo acoplamiento que no se convirtió en plan antes del PR se convierte en incidente en producción.
Este post explica cómo el ciclo Spec, Plan, Ship redirige el trabajo a la ventana en la que un defecto todavía es barato, y qué hacer con el pasivo de mantenimiento que ya cargas hoy.
1. El mantenimiento es el pasivo de un flow ausente
Existe una ventana de tiempo en la que cada defecto cuesta entre 1x y 5x corregirlo: antes de que el código exista. Después del merge, el mismo defecto cuesta 10x. Después del deploy, 50x. Cuando se convierte en mantenimiento recurrente, se convierte en un pasivo permanente, con interés compuesto en horas-hombre.
Los equipos con mucho mantenimiento tienen una característica en común: el trabajo que debería ocurrir antes del código (especificar una regla, mapear el acoplamiento, definir la observabilidad) está ocurriendo después, en forma de ticket, incidente y refactor de emergencia. No es una falla de ejecución, es una falla de ventana. El equipo no está ejecutando mal, está ejecutando en el momento equivocado de la línea de tiempo.
La consecuencia práctica es cruel: cuanto más mantenimiento, menos tiempo queda para el flow que reduciría el mantenimiento. Es un ciclo de retroalimentación negativa, y solo se rompe con una decisión estructural de redirigir el trabajo a la ventana barata.
2. Spec: corta la ambigüedad antes de que el código exista
La spec no es un documento, es el gate que impide que una duda se convierta en bug. Una buena spec define tres cosas: invariantes (lo que siempre tiene que ser verdad), casos de error nombrados (qué hacer cuando ocurre X) y contratos (entrada, salida, side effects). Si estas tres piezas están escritas, el desarrollador no tiene espacio para 'ah, yo pensé que era así'.
Lo que NO entra en la spec: la implementación. La spec describe el problema, no la solución. Si estás escribiendo qué ORM usar o dónde poner la cache, dejaste de especificar y empezaste a diseñar. Mezclar las dos cosas acopla la regla de negocio a la tecnología, y genera retrabajo en la primera migración o cambio de stack.
Heurística práctica: si un PR abre una discusión sobre 'qué debe ocurrir si X', la spec de esa feature falló en el punto X. No es una falla personal, es un dato. Márcalo, ajusta la spec y sigue. La spec es viva, no es un entregable de auditoría que nadie relee después de aprobado.
3. Plan: ataca el acoplamiento antes del diff
El plan es el mapa del blast radius del cambio. Qué archivos se tocarán, en qué orden, qué puede romperse lateralmente, cuál es el punto de no retorno. Un buen plan responde antes del código: 'si este PR sale mal, ¿qué se viene abajo con él?'
Sin plan, un refactor es cirugía a ciegas. Con plan, es un checklist. La diferencia práctica: un refactor sin plan genera de 3 a 5 incidentes de mantenimiento en las semanas siguientes al deploy, porque se pisaron acoplamientos invisibles sin aviso. El plan hace visibles esos acoplamientos ANTES de que se conviertan en ticket, en una sesión de 20 minutos con café, no en un war room a las 3 de la madrugada.
El plan no necesita ser largo. Cinco líneas que enumeren: archivos tocados, orden del cambio, riesgos laterales, telemetría a agregar, condición de rollback. Quien no logra escribir esas cinco líneas todavía no entendió el problema, y lo va a descubrir en producción, con público.
4. Ship: es un gate, no una meta
Ship es el paso más maltratado de los tres. Ship no es 'se hizo el deploy'. Ship es la entrega con fallback, telemetría y rollback. Si no puedes apagar la feature en 2 minutos, no hiciste ship, dejaste un problema futuro con un nombre bonito.
El mantenimiento invisible nace aquí. Una feature sin flag para apagarla exige una corrección de emergencia en producción cuando algo sale mal. Una feature sin telemetría no denuncia su propio fracaso, y solo te enteras por el ticket de un usuario irritado, 3 semanas después, cuando el daño ya está distribuido. Una feature sin rollback documentado obliga al equipo a inventar un procedimiento bajo presión. Todo eso se convierte en horas-hombre de mantenimiento al mes siguiente, con pico al final del sprint.
Gate mínimo de ship: (1) flag o kill switch, (2) métrica de salud de la feature expuesta en un dashboard, (3) plan de rollback de una línea. Si falta alguno de los tres, el ship es deuda disfrazada de entrega.
5. Mitigar el mantenimiento que ya existe
El flow Spec, Plan, Ship resuelve el pasivo futuro. Pero ya tienes un pasivo en el presente, e intentar liquidarlo de una vez es lo que mata a los equipos. El mantenimiento heredado necesita triage, no un operativo masivo.
Triage en tres dimensiones: frecuencia (cuántas veces reaparece el ticket por mes), costo unitario (cuánto tiempo consume cada ocurrencia) y volatilidad (con qué frecuencia cambia el código relacionado). Los 'muros de carga' del pasivo son los que puntúan alto en las tres. Esos entran en un sprint de erradicación, con una spec retroactiva escrita ANTES del refactor. El resto se convierte en un hotfix tabulado o se acepta como costo de operación hasta la próxima revisión.
El error clásico es intentar dejar en cero el backlog de mantenimiento. No se puede, e intentarlo genera más mantenimiento (un refactor de emergencia crea nuevos bugs en código ya frágil). El objetivo es reducir el flujo de entrada, no vaciar la fila. El flujo de entrada cae cuando la spec y el plan entran en el ciclo. La fila se reduce como consecuencia, en meses, no en semanas.
6. Métricas que muestran que el flow está funcionando
Tres señales que puedes medir en cualquier equipo, sin una herramienta nueva, con una planilla:
- Bugs por entrega: bugs reportados en producción en las 2 semanas posteriores al deploy, dividido por el número de features entregadas. Una tendencia a la baja significa que la spec está funcionando.
- Porcentaje de tickets que piden una spec retroactiva: cuántos tickets revelan 'nadie sabía que tenía que ser así'. Una tendencia a la baja significa que el ciclo de spec está madurando.
- Tiempo hasta el primer fix posterior al deploy: si está cayendo, la observabilidad del ship está detectando las cosas antes de que el usuario reclame, y el mantenimiento reactivo se está volviendo proactivo.
No es vanidad de dashboard. Son los tres únicos números que dicen si el flow está recortando el mantenimiento o solo reacomodando el trabajo de lugar.
7. El reframe
El mantenimiento no desaparece. Pero deja de ser un destino. La diferencia entre un equipo que vive en modo apagar incendios y un equipo que entrega features es dónde está asignado el trabajo en la línea de tiempo: antes del código o después del deploy. No es talento, no es el stack, no es la metodología de moda. Es la ventana.
Spec, Plan, Ship no es una metodología, es una decisión de gasto: pagas ahora, con 5 líneas de spec y 5 líneas de plan, o pagas 10x después, en horas-hombre de mantenimiento. El flow es el redireccionador. Quien lo ignora sigue pagando la factura que llega todos los meses con la etiqueta 'imprevisto', y jurando que la próxima vez habrá tiempo de hacerlo bien.