Los huecos y su causa

Un hueco tiene una de cinco causas, y cada una apunta a un camino distinto. Sin regla: se escribe y se prueba. Regla sin prueba: se prueba. Regla apagada: se averigua por qué se apagó (casi siempre ruido) y se afina antes de encenderla. La fuente no llega o la retención es corta: se pide a quien opera la fuente, y escribir reglas no sirve de nada hasta que se resuelva.

Detectar la causa antes de planificar evita el error de «vamos a escribir una regla» para una técnica cuya fuente nadie recibe. La nueva regla pasaría a ser otra regla de papel.

La tabla huecos trae los siete huecos con su causa y una columna se_cierra_con_regla. Cuando es «no», el primer paso lo da otro equipo o requiere una decisión de infraestructura, y la regla, si existe, espera. Es la parte del mapa que no mejora por mucho que el equipo de detección trabaje.

Cada hueco tiene dos tipos de trabajo: los días de fuente, que pone el equipo dueño del sistema (configurar, activar, ampliar), y los días de regla y prueba, que pone Detección. Planificar con la suma de los dos como si fuera un solo equipo esconde que una parte no depende de ti.

El costo de cerrar un hueco es la suma de ambos tipos de días. No es el único criterio para decidir el orden, pero sí el primero que pide cualquiera que tenga que aprobar el trabajo: cuánto cuesta y de quién son esos días.

Los huecos que no se cierran con regla se pelean con otros equipos. Una petición al mismo equipo por dos huecos distintos se hace una sola vez, con los dos motivos, y se le pide una sola ventana de cambio. La columna dueno_del_cierre dice a quién le toca cada uno.