¿Cómo sabremos que sigue funcionando después del lanzamiento?

Qué cambia después del lanzamiento

Tres cosas se mueven solas. El proveedor actualiza el modelo, a veces sin cambiar de versión, y las respuestas cambian de tono o de largo. Tus datos derivan: productos nuevos, políticas nuevas, documentos que contradicen a otros más viejos. Y tus usuarios aprenden lo que el sistema puede hacer y empiezan a preguntar cosas que el conjunto de evaluación nunca imaginó.

Ninguna de estas se anuncia. El sistema sigue respondiendo, con seguridad, y la primera señal de problema suele ser un cliente o un colega que se da cuenta. Un sistema en producción necesita algo que lo vigile y que no sea una persona leyendo cada respuesta.

Reglas que verifican cada respuesta

Antes de mostrar una respuesta, pasa por un conjunto de verificaciones escritas durante la construcción. Algunas son simples: la respuesta cita un documento fuente, no contiene un precio a menos que venga del catálogo, no promete una fecha. Otras son un segundo modelo al que se le hace una pregunta estrecha sobre la respuesta del primero. Una respuesta que falla no se muestra. El usuario recibe una alternativa y la falla queda registrada.

Estas verificaciones son la razón por la que el modelo pequeño de la nota anterior es seguro de usar. También producen el número más útil de todo el sistema: con qué frecuencia se bloquean respuestas, y por qué razón. Cuando ese número se mueve, algo cambió río arriba.

Una muestra semanal, calificada

Cada semana se toma una muestra de solicitudes reales y sus respuestas de los registros y se califica contra tu conjunto de evaluación, con los mismos criterios que tu equipo escribió antes del lanzamiento. Los casos nuevos de la muestra que el conjunto no cubría se agregan, para que el conjunto crezca con el uso real y no con nuestras suposiciones.

La calificación es una tendencia, no un veredicto. Una semana mala después de una actualización del proveedor es una señal para mirar. Tres semanas bajando son una señal para actuar. Como el mismo conjunto se corre desde el prototipo, la tendencia es comparable a lo largo de toda la vida del sistema.

Alertas para lo que no puede esperar

Algunos cambios no deben esperar a la muestra semanal. El costo por solicitud subiendo, la latencia cruzando el límite que tu producto tolera, la tasa de bloqueo saltando, la recuperación devolviendo nada para una clase de preguntas. Estos levantan alertas dentro de tu nube, en tus canales, con una línea en el manual que dice qué revisar primero.

Las alertas se ajustan para ser raras. Una alerta que suena todos los días se ignora a la segunda semana, y entonces también se ignora la que importa.

El reporte mensual

Una página, en lenguaje llano, para la persona dueña del sistema que no lee registros. La tendencia de las calificaciones semanales. Qué se bloqueó y por qué. Los incidentes, qué los causó y qué cambió como resultado. El costo. Qué recomendamos cambiar el mes siguiente, y qué recomendamos dejar como está.

Está escrito para poder reenviarse a un director sin una llamada que lo explique. Si necesita una llamada, no está terminado.

Nuestro o no

Esta rutina no depende de quién construyó el sistema. Un equipo con un asistente que hoy funciona y nadie que lo vigile mañana puede empezar aquí: una auditoría de lo que existe, un conjunto de evaluación escrito con el equipo si no hay ninguno, monitoreo en su nube, y el primer reporte un mes después.