Evidencia posterior al cambio

El equipo nuevo cuenta los aciertos de cada regla, igual que el viejo. Poner lado a lado los de la semana anterior al corte y los de la semana posterior es la comprobación más barata y más reveladora. Una regla que antes era de las más activas y después está en cero no está funcionando: algo cambió en la regla, en un objeto o en la ruta del tráfico.

Un cero que ya existía antes no significa lo mismo: la regla estaba sin uso y lo sigue estando. Lo que se busca es la caída, no el cero a secas.

Cada regla del equipo viejo tiene su equivalente nuevo en la tabla de aciertos. Una de las del equipo nuevo cayó a cero tras el corte, aunque su equivalente era de las que más tráfico recibían. Hay otra con cero antes y después, que es un caso distinto y no debe confundirse.

Abre la consola y consulta los aciertos de las dos semanas.

Tras el corte se repite la matriz de pruebas sobre el equipo nuevo, con los mismos casos de antes. La tabla de pruebas posteriores trae lo esperado y lo observado. Las filas que coinciden quedan como evidencia de que el comportamiento se mantuvo; la que no coincide es una incidencia en potencia, y debe explicarse antes de cerrar el cambio.

Compara las dos columnas.

La evidencia se cruza. Una incidencia que reporta un usuario («las cámaras de la planta baja no tienen imagen») se explica con una regla sin aciertos y con una prueba que falla. Cuando tres fuentes independientes apuntan al mismo punto, la causa deja de ser una hipótesis; y así se justifica el cambio correctivo y se deja constancia en el cierre.

Cruza las incidencias con la regla que cayó a cero.

El cambio no se cierra el día del corte. El equipo viejo se conserva apagado o en espera, con su configuración respaldada, durante un periodo de observación fijado en el plan, para poder volver o consultar cómo se comportaba. Al terminarlo, el cierre documenta los resultados, las excepciones aceptadas y quién retiró el equipo viejo y cuándo.