Asignar dueño y plazo por severidad

La severidad dice cuánto daño permite un fallo; el plazo convierte esa severidad en una fecha. Lo habitual es una tabla corta, con días naturales por nivel, aprobada por la dirección y conocida por todos los equipos, para que nadie negocie la fecha caso a caso. En otro módulo viste cómo una empresa ordena la cola cuando no le alcanza el tiempo; aquí la pregunta es más básica y se equivoca más a menudo: desde qué día se cuenta.

Abre el laboratorio y lee politica-de-plazos.txt. El punto 2 responde la pregunta, y el resto de la sala depende de él.

El dueño de un hallazgo es el equipo que puede cambiar el código que lo contiene, no el que lo reportó ni el que tiene la pantalla donde se ve. Por eso la asignación sale de un catálogo de componentes, y no de la ruta que aparece en el informe. Un componente puede verse dentro de una aplicación y ser de otro equipo: ese es el caso que más tickets rebota de una cola a otra. Cruza hallazgos-abiertos.csv con catalogo-de-componentes.txt.

Los tickets traen una columna de fecha límite que alguien calculó. Si la calculó desde la asignación, el hallazgo que tardó semanas en llegar al equipo correcto gana esas semanas de regalo, y es justo el que más tiempo lleva expuesto. La fecha buena se recalcula con la fecha de entrada y la tabla, sin mirar la del ticket.

Con la regla del punto 4, recorre los doce hallazgos: fecha límite real, comparada con el 1 de diciembre de 2026. Ninguno de estos tiene aceptación de riesgo y ninguno está cerrado. Cuidado con dos cosas: el día límite todavía está en plazo, y la columna del ticket no es la fuente de verdad.

Un vencido no se arregla moviendo la fecha. Lo que la política prevé es hacerlo visible a quien puede mover recursos, en dos escalones, sin tocar ni la severidad ni el plazo. Bajar la severidad para que el hallazgo «entre» en plazo esconde el riesgo, y reiniciar la fecha al reasignar premia al que tarda en clasificar.