Comunicar a quien opera la aplicación

Una solicitud útil responde cuatro preguntas sin que el equipo tenga que llamar: qué componente está afectado, qué evidencia lo demuestra (con identificadores de pruebas y registros, no con una opinión), qué resultado se espera al corregirlo y para cuándo, según la severidad acordada.

Lo que no lleva: datos de clientes reales, una descripción alarmista, ni la acusación de que alguien fue negligente. Las solicitudes circulan por colas y correos con mucha gente, y todo lo que se escribe ahí se queda.

Cada pieza de la aplicación tiene un equipo dueño. Mandar la solicitud al equipo equivocado pierde días: el otro equipo no puede corregir lo que no es suyo y tarda en devolverla. La tabla de responsables relaciona cada componente con su equipo, su canal y su ventana de cambios.

La política de plazos no se negocia caso por caso: cada severidad tiene un número de días naturales, contados desde la fecha del reporte. La severidad la fija el pendiente según su impacto, no la urgencia que sienta quien lo reporta. La fecha límite es el día del reporte más esos días.

Se escribe en formato AAAA-MM-DD para que no haya duda del mes ni del día.

Un plazo solo se cumple si cabe en la ventana de cambios del equipo: el día y la hora en que ese equipo puede tocar producción. Si el plazo vence antes de la próxima ventana, o se pide una ventana de emergencia (que alguien tiene que aprobar) o se acepta el riesgo de que se incumpla. Por eso la solicitud nombra la ventana.

Entre varias redacciones, la correcta es la que un equipo ocupado puede ejecutar mañana: dirigida al dueño, con la evidencia por identificador, el resultado esperado, el plazo y ninguna información sensible. La más larga no es la mejor, y la más alarmista tampoco.