Capacidad reservada: el porcentaje que protege tu deuda técnica, tu confiabilidad y tu plataforma
Todo el mundo está de acuerdo en que hay que atender la deuda técnica y la confiabilidad. Nadie lo hace, porque cada trimestre hay algo más urgente. La única solución que funciona es reservar capacidad de antemano y no negociarla.
Existe un consenso universal y perfectamente inútil en las organizaciones de tecnología: todos coinciden en que hay que atender la deuda técnica, mejorar la confiabilidad e invertir en la plataforma interna. Nadie lo discute. Y en la mayoría de las organizaciones no ocurre.
La razón no es mala fe ni ignorancia. Es que el mecanismo de asignación de capacidad favorece estructuralmente lo visible sobre lo estructural. Cada trimestre hay una funcionalidad comprometida con un cliente, una fecha comercial, una prioridad del directorio. Frente a eso, “mejorar el proceso de despliegue” siempre puede esperar un trimestre más. Y como siempre puede esperar, siempre espera.
La única intervención que resuelve esto de forma sostenida es la reserva explícita de capacidad.
Qué es y qué no es
Reservar capacidad significa que un porcentaje definido de la capacidad de cada equipo está asignado, de antemano y de forma no negociable, a tres categorías: deuda técnica, confiabilidad y plataforma.
No es un compromiso de intención. No es “cuando tengamos tiempo”. No es un trimestre de limpieza al año. Es una fracción constante que sale del cálculo de capacidad disponible antes de que empiece la conversación de priorización.
La distinción operativa es esta: si al planificar el trimestre la capacidad total es cien y se reserva veinte, entonces la conversación de priorización se hace sobre ochenta. La reserva no compite. Si compite, pierde.
Cuánto reservar
No hay un número universal, pero hay rangos que funcionan y señales para calibrar.
Entre quince y veinticinco por ciento es el rango que sostiene un sistema en estado estable sin degradarlo ni sobreinvertir. Por debajo de quince, la deuda crece más rápido de lo que se paga. Por encima de veinticinco de forma sostenida, generalmente hay un problema de arquitectura que no se resuelve con mantenimiento incremental.
Las señales de que la reserva es insuficiente son bastante claras: el tiempo de entrega crece trimestre a trimestre sin que aumente la complejidad del trabajo; la proporción de incidentes recurrentes sube; los equipos evitan tocar ciertas partes del sistema; el tiempo de incorporación de una persona nueva se alarga.
Las señales de que hay que subirla temporalmente por encima del rango: una migración pendiente que bloquea todo lo demás, un componente que causa la mayoría de los incidentes, una plataforma que se convirtió en cuello de botella para todos los equipos.
Las tres categorías, separadas
Conviene no mezclarlas, porque compiten entre sí y tienen dinámicas distintas.
Deuda técnica. Trabajo sobre código y estructuras existentes que hace más caro cada cambio futuro. Su síntoma es que las cosas toman más tiempo del que deberían. Se paga con refactorización, con eliminación de duplicación, con actualización de dependencias, con simplificación.
Confiabilidad. Trabajo que reduce la probabilidad o el impacto de fallas. Su síntoma son los incidentes, la indisponibilidad y las alertas nocturnas. Se paga con monitoreo, con pruebas, con redundancia, con capacidad de reversión rápida.
Plataforma. Trabajo que reduce el esfuerzo de todos los equipos para hacer lo mismo. Su síntoma es que varios equipos resuelven el mismo problema por separado. Se paga con caminos estándar, con autoservicio, con automatización de lo repetitivo.
Un equipo que dedica toda su reserva a deuda técnica durante un año va a tener código limpio y seguir sufriendo incidentes. Uno que la dedica toda a confiabilidad va a tener un sistema estable que es cada vez más caro de cambiar. La distribución entre las tres es una decisión que conviene hacer explícita y revisar cada cierto tiempo.
Cómo defenderla cuando llegue la presión
La reserva se va a poner a prueba. Va a llegar el trimestre con el compromiso imposible, y alguien va a proponer usar la reserva “solo por esta vez”.
Hay tres defensas que funcionan mejor que la apelación a los principios.
Traducir a consecuencia de negocio. No “tenemos deuda técnica” sino “el tiempo de entrega de cambios en este componente subió cuarenta por ciento en seis meses; si no lo atendemos, cada funcionalidad futura en esa área va a costar proporcionalmente más”. El primer enunciado es una queja de ingeniería. El segundo es una proyección de costo.
Mostrar el historial. Si la reserva se suspendió las últimas tres veces que hubo presión, ese dato es el argumento. “Esta sería la cuarta suspensión consecutiva” cambia la conversación mucho más que cualquier explicación técnica.
Ofrecer la alternativa real. La reserva no se suspende gratis. Se suspende a cambio de algo: postergar otra funcionalidad, aceptar explícitamente un riesgo documentado, o reponer la capacidad el trimestre siguiente con compromiso escrito. Que la decisión tenga un costo visible es lo que evita que se tome por defecto.
Cómo se elige qué hacer con la reserva
Tener capacidad reservada resuelve el problema de la asignación. Queda el segundo problema, que es menos discutido: dentro de la reserva, ¿qué se hace primero?
La respuesta por defecto —lo que más molesta al equipo— no es mala, porque la molestia suele correlacionar con la fricción real. Pero hay un criterio que rinde más y es fácil de aplicar.
Priorizar por frecuencia de contacto. El trabajo estructural rinde en proporción a cuántas veces se toca la zona afectada. Refactorizar un componente que se modifica todas las semanas libera fricción cada semana. Refactorizar uno que nadie tocó en dos años no libera nada, por feo que sea el código.
Este criterio se puede aplicar con datos que ya existen: qué archivos o componentes concentran más cambios. La intersección entre “se cambia mucho” y “es difícil de cambiar” es donde está el mayor rendimiento de la reserva, y casi nunca coincide con la lista intuitiva del equipo.
Priorizar por bloqueo transversal. Si algo obliga a varios equipos a esperar, arreglarlo rinde multiplicado. Un ambiente de pruebas compartido que se satura, una dependencia que todos consumen y que falla seguido, un paso manual que todos tienen que pedir.
Priorizar por riesgo asimétrico. Componentes cuya falla tendría consecuencias desproporcionadas respecto de su tamaño. Suelen ser piezas pequeñas y antiguas que nadie mira porque funcionan.
Y un criterio de exclusión que ahorra discusiones: no usar la reserva para trabajo que en realidad es funcionalidad con otro nombre. La reserva se erosiona con frecuencia por esta vía —“esto es deuda técnica” cuando en realidad es una mejora que alguien quiere hacer— y cuando se erosiona así, se pierde sin que nadie lo haya decidido.
Una forma simple de proteger contra eso es exigir que cada elemento de la reserva declare qué fricción concreta elimina y cómo se sabría que funcionó. Si no se puede responder, probablemente no es trabajo estructural.
Hacerla visible
Una reserva que no se mide se evapora sin que nadie lo note. Vale la pena registrar, cada período, cuánta capacidad se reservó, cuánta efectivamente se usó en las tres categorías y qué se logró con ella.
Ese registro produce dos cosas. Primero, protege la reserva, porque su ausencia se vuelve visible. Segundo, y más importante, permite demostrar retorno: cuando el tiempo de entrega baja o los incidentes se reducen después de un trimestre de inversión estructural, esa correlación es el mejor argumento disponible para el trimestre siguiente.
Sin ese registro, la inversión estructural es un acto de fe que se renegocia cada tres meses. Con él, es una decisión con evidencia, que es exactamente lo que necesita para sobrevivir a la próxima urgencia.