Qué hizo bien y mal cada parte

El sesgo de retrospectiva es la tentación de considerar evidente lo que solo se ve claro después. Un balance honesto pregunta qué sabía cada parte cuando decidió, qué efecto consta en los registros y qué alternativa tenía a su alcance con sus medios.

Con esos tres criterios, una decisión puede ser mala aunque el resultado haya sido bueno, y buena aunque el resultado haya sido malo. Lo que se evalúa es la calidad de la decisión con la información disponible.

El tiempo entre confirmar y cortar es uno de los pocos datos objetivos del balance. Cada minuto entre ambos es una oportunidad de que otra persona descargue la versión. Se mide en minutos restando la hora de inicio de la hora de fin de la acción.

Una cifra así no dice por sí sola si fue rápido o lento: se compara con lo que el proveedor tenía que hacer en ese tiempo, que es verificar, decidir y ejecutar.

Un error frecuente en clientes con buena intención es limpiar el equipo antes de reportar: desinstalar, borrar carpetas, reiniciar. Lo hacen para cortar el problema, pero destruyen lo que habría permitido saber qué hizo el programa. La contención correcta aísla el equipo y preserva sus registros.

En el balance, esa acción se anota como mala decisión con su efecto medible: lo que ya no se puede saber.

Cuando un proveedor confirma que su servicio de firma se usó con un paquete alterado, la clave con la que firmó ya no se puede considerar de confianza. Mantenerla en uso un tiempo hace que cualquier paquete firmado en ese lapso siga pareciendo legítimo. Revocarla o rotarla es una decisión costosa, porque también invalida lo publicado antes, pero es la que corta el canal.

Aquí hay una consideración de retrospectiva: ¿qué sabía el proveedor el 3 de marzo? Sabía que el paquete se firmó con la clave, y eso bastaba.