Comunicar al negocio, del identificador de la vulnerabilidad al costo de parar

Un borrador técnico habla de la versión, el identificador y el acumulativo. A una gerencia no le sirve nada de eso para decidir. Lo que necesita es una frase con cuatro partes: qué proceso del negocio está en riesgo, qué puede pasar y cuánto cuesta, qué se propone y qué decisión se pide, con fecha. Todo lo técnico va al final, como anexo, para quien quiera comprobar.

Abre borrador-a-gerencia.txt: es el primer intento del analista, escrito de corrido y pensado para otro técnico.

Traducir un servidor a procesos es el paso que más cambia el mensaje. Un servidor de correo «da servicio» a varios procesos: algunos toleran una parada de un día, otros se resienten en dos horas. El proceso que menos tolera la parada es el que hay que nombrar primero, porque es el que mejor explica por qué importa el servidor.

Abre procesos.csv. Cada proceso trae su servidor y las horas de parada que tolera. Busca, entre los que dependen de lmr-corr01, el que menos tolera.

El costo de parar se calcula con dos datos de la tabla: lo que cuesta cada hora sin el proceso y cuántas horas dura la jornada. Es una estimación, no una factura, y así se debe presentar: con la fuente y la multiplicación a la vista. Un número sin cuenta visible genera la discusión equivocada, la de quién tiene razón y no la de qué se decide.

Calcula el costo de una jornada completa sin el proceso que identificaste, con la duración de jornada que fija leeme.txt. Escribe solo el número, sin separadores.

La primera frase del mensaje decide si se sigue leyendo. Una buena empieza por el proceso y por lo que se pide: nombra el proceso, dice el costo y pide una decisión con fecha. Una mala empieza por la sigla del defecto, por una disculpa o por una descripción del servidor.

Pedir una decisión «pronto» no es pedir una decisión. Las decisiones del comité de cambios solo se toman en sus sesiones, y la compra de un servicio exige un plazo mínimo antes del inicio del trabajo. La fecha límite para decidir se calcula hacia atrás desde el inicio previsto, y después se busca la última sesión que llega a tiempo.

Lee calendario-comite.txt y calcula en qué sesión hay que presentar la decisión.