← All posts

Medir antes de declarar es la razón por la que el dashboard no dice nada

Listen · 2 min 25 s

Se abre el dashboard que la empresa usa para el tráfico de agentes (deberían tener uno armado). Sesiones, cantidad de requests, un pico el martes pasado. Ahora se le hace una sola pregunta: ¿algún agente terminó en un lugar al que la empresa no quería que llegara?

Nada está roto, no hay respuesta. El dashboard registra eventos, e “incorrecto” es un juicio.

Un juicio necesita un estándar. “Este resultado está bien, aquel no” solo significa algo cuando alguien dejó por escrito qué resultados respalda la empresa. Hasta entonces, un pedido completado con una forma extraña y uno limpio se ven idénticos: los dos son un 200 y una fila en una tabla.

El orden habitual del mercado es el inverso. Primero se instrumenta, después se averigua qué significan los números. Parece responsable porque instrumentar es barato, sale este trimestre y no necesita el permiso de nadie. Declarar exige una decisión, y las decisiones se dejan para después.

Pero solo vale la pena emitir dos señales, y las dos dependen del conjunto declarado:

→ Se produjo un resultado que no está en el conjunto.
→ Se recorrió el flujo y no se produjo ningún resultado admisible.

La segunda es la reveladora. “Ningún resultado admisible” no significa nada mientras el conjunto no existe, y no se puede alertar sobre una ausencia que no se definió. Por eso la salida silenciosa, la falla que nunca abre un ticket, es justo lo que un enfoque de medir primero no puede ver, por mucho que recolecte.

Más datos no lo arreglan. Mil eventos más son mil cosas más para clasificar contra un estándar que sigue sin existir. Se obtiene una pila más grande, no un veredicto.

El orden no se negocia: declarar, después verificar, después detectar. Puesto al revés, queda un instrumento muy preciso que apunta a nada.

Un dashboard solo puede llamar falla a algo si alguien firmó qué resultados no son aceptables. Conviene revisar el propio: si esa definición no está escrita ni tiene un responsable con nombre, se están contando eventos, no fallas.

Un dashboard puede tener una de dos utilidades: a) mostrar como se acumulan datos bajo una regla b) facilitar una mirada del resultado de una hipótesis en seguimiento activo. Esta última agrega valor, la primera solo resume datos sin un sentido último.