Cerrar el bucle: de los datos a decisiones y de los fallos a prioridades

Un equipo con telemetría y sin proceso de decisión está peor que uno sin telemetría, porque paga todos los costes y no cobra ningún beneficio, y además desarrolla la ilusión reconfortante de estar guiado por datos mientras sigue decidiendo por intuición y volumen de voz. El síntoma es siempre el mismo: existen paneles, existen alertas, existe un grupo con cientos de fallos agrupados, y sin embargo cuando alguien pregunta qué se arregla esta semana la respuesta la da quien más insistió en la última reunión. El bucle no se cierra porque falte información, se cierra mal porque nadie definió qué convierte una observación en una prioridad, quién es responsable de mirar, cada cuánto, y qué se hace exactamente después de mirar. Esta lección es sobre esa maquinaria, que es organizativa tanto como técnica, y que sin ella todo lo anterior queda en instrumentación decorativa.

Priorizar fallos por impacto, no por recuento

El recuento bruto de informes es la peor métrica posible para ordenar el trabajo y es, casi universalmente, la que ofrece por omisión cualquier herramienta. Falla por tres motivos que se acumulan. Cuenta informes y no personas, de modo que un solo dispositivo en un ciclo de reinicio puede generar miles de entradas y colocarse arriba. Ignora dónde ocurre, tratando igual un fallo en una pantalla de ajustes visitada una vez al mes que uno en el paso de pago. Y no considera la recuperabilidad: un fallo del que se vuelve con una pérdida de trabajo de treinta segundos y otro que corrompe la base de datos local aparecen con el mismo peso.

La alternativa razonable es una puntuación explícita con pocos factores y todos observables. Personas únicas afectadas en la ventana reciente, no informes. Criticidad del recorrido interrumpido, en una escala corta y acordada con producto. Recuperabilidad, entendida como qué pierde la persona cuando ocurre. Tendencia, porque un fallo que crece en cada versión merece atención antes de que sea grande. Y coste estimado de arreglo, que entra dividiendo porque a igualdad de impacto se atiende primero lo barato. Que la fórmula sea imperfecta importa mucho menos de lo que parece: su valor está en hacer explícito el criterio y en trasladar la discusión de quién grita más a qué factor estamos valorando mal.

struct GrupoDeFallo {
    let personasAfectadas: Int
    let usuariosActivos: Int
    let criticidadDelRecorrido: Int   // de 1 a 5, acordada con producto
    let recuperabilidad: Int          // 1 sin perdida, 5 perdida de datos
    let factorDeTendencia: Double     // 1.0 estable, mayor si crece
    let costeEstimado: Double         // en jornadas

    var prioridad: Double {
        let alcance = Double(personasAfectadas) / Double(usuariosActivos)
        let gravedad = Double(criticidadDelRecorrido * recuperabilidad)
        return alcance * gravedad * factorDeTendencia / max(costeEstimado, 0.5)
    }
}

Junto a la ordenación hace falta un indicador de salud agregado, y el que mejor funciona es la proporción de personas sin ningún fallo en un periodo, no la proporción de sesiones sin fallo. La diferencia parece sutil y no lo es: la métrica por sesiones se diluye con el uso intenso y puede mejorar simplemente porque la gente abre más veces la aplicación, mientras que la métrica por persona responde a la pregunta que importa, cuánta gente se está encontrando con un fallo. Conviene además publicar el mismo indicador para bloqueos prolongados, porque una aplicación que no se cierra nunca y se congela con frecuencia produce la misma insatisfacción y no aparece en ningún cuadro de fallos.

De la anomalía a la hipótesis

Ver un número moverse no es un hallazgo, y tratarlo como tal es el error más caro del análisis de producto. Antes de construir cualquier explicación hay que descartar en orden tres causas que no tienen nada que ver con el producto. La primera es la variación normal: toda métrica oscila, y sin una noción de cuánto oscila habitualmente es imposible saber si un movimiento es señal. La segunda es el defecto de medición, que ya apareció en la lección tercera y que produce caídas espectaculares por un evento que dejó de emitirse. Y la tercera es el cambio de composición, que ocurre cuando la métrica no se mueve porque nadie cambie de comportamiento sino porque cambió la mezcla de quién está midiéndose.

Ese tercer caso merece detenerse porque es el que engaña a más gente con más formación. Si una campaña trae de golpe muchas personas nuevas, la retención media baja aunque ningún segmento haya empeorado, simplemente porque los nuevos retienen menos que los veteranos y ahora pesan más. La única defensa fiable es no analizar nunca un agregado sin partirlo primero por antigüedad, canal de adquisición, versión, país y familia de dispositivo. La regla mnemotécnica es que cualquier movimiento agregado es una pregunta sobre segmentos hasta que se demuestre lo contrario.

flowchart TD
a[Anomalia observada] --> b{Es variacion normal}
b -->|Si| z[Ignorar y anotar el rango]
b -->|No| c{Cambio de instrumentacion}
c -->|Si| d[Arreglar la medicion]
c -->|No| e{Cambio de composicion}
e -->|Si| f[Analizar por segmento]
e -->|No| g[Hipotesis falsable]
g --> h[Experimento con criterio previo]
h --> i[Decision registrada]

Superados esos filtros, lo que queda es una hipótesis, y para que sirva debe ser falsable y específica. La gente abandona porque la aplicación es confusa no es una hipótesis, es una queja. La gente abandona en el paso de permisos porque se pide la ubicación antes de haber mostrado ningún valor sí lo es, porque predice un resultado concreto de un cambio concreto y puede resultar falsa. La calidad de la hipótesis determina la calidad de todo lo que viene después, y es el punto donde la observación cualitativa aporta más que ningún panel: los números localizan dónde ocurre la pérdida, mirar a cinco personas usar la aplicación explica por qué.

Del experimento a la decisión

Un experimento sin criterio de parada previo no es un experimento, es una búsqueda de justificación. Antes de exponer a nadie hay que escribir cuatro cosas: la métrica principal, el tamaño de efecto mínimo que justificaría el cambio, la duración necesaria para detectarlo y las métricas de contrapeso que abortarían el ensayo aunque la principal mejore. Escribirlas después es lo que produce el patrón conocido de mirar hasta que dé significativo, que garantiza encontrar efectos donde no los hay porque cada mirada adicional es otra oportunidad de que el ruido cruce el umbral.

La duración tiene además una restricción de dominio que la estadística no captura: hay que cubrir al menos un ciclo semanal completo, porque el comportamiento del lunes y el del sábado son distintos en casi cualquier producto. Y en aplicaciones móviles hay una restricción adicional que los equipos que vienen de la web no esperan: la actualización no es instantánea. La población que tiene la versión nueva durante los primeros días no es representativa, porque quienes actualizan pronto son sistemáticamente los más comprometidos. Comparar la versión nueva con la anterior en la primera semana compara dos poblaciones distintas y produce conclusiones espectacularmente equivocadas.

// El experimento tambien es un evento: sin exposicion registrada no hay analisis
struct Exposicion {
    let experimento: String
    let variante: String
    let momento: Date
}

func variante(para experimento: Experimento) -> Variante {
    let asignada = asignador.variante(de: experimento, semilla: identificadorSeudonimo)
    analitica.registrar(.expuesto(experimento: experimento.nombre,
                                  variante: asignada.nombre))
    return asignada
}

Registrar la exposición en el momento en que la persona ve realmente la variante, y no en el momento en que se calcula la asignación, es un detalle técnico con consecuencias enormes. Si se registra en el arranque, el denominador incluye a todo el mundo, también a quien nunca llegó a la pantalla del experimento, y el efecto se diluye hasta volverse indetectable. Este error es probablemente la causa más común de experimentos que salen planos en productos donde el cambio sí funcionaba.

Queda el final del proceso, que es donde el bucle se rompe con más frecuencia: la decisión debe registrarse por escrito con su fecha, su responsable, la evidencia que la sustentó y lo que se espera observar si fue acertada. Sin ese registro, en seis meses nadie recuerda por qué se retiró aquella funcionalidad, alguien la vuelve a proponer con los mismos argumentos y el equipo repite el experimento. Un archivo de decisiones de producto, con el mismo espíritu que un registro de decisiones de arquitectura, cuesta quince minutos por entrada y evita años de trabajo repetido.

El ritual que cierra el bucle

Todo lo anterior se disuelve si depende de que alguien se acuerde. Lo que sostiene el circuito es una cadencia corta, con propietarios nombrados y con un resultado obligatorio en forma de acciones, no de observaciones. El patrón que mejor funciona en equipos de aplicaciones combina tres ritmos de frecuencia decreciente y profundidad creciente, y ninguno de ellos ocupa más de una hora.

El ritmo diario es de vigilancia y lo ejecuta una sola persona rotatoria: mirar fallos nuevos y en crecimiento tras cada publicación, comprobar que no hay grupos emergentes y confirmar que la instrumentación sigue emitiendo. El ritmo semanal es de triaje: revisar la lista priorizada por la puntuación de impacto, asignar responsable a los tres primeros, cerrar los que ya no reproducen y revisar el consumo del presupuesto de error. Y el ritmo mensual o por versión es de aprendizaje: mirar la evolución de los percentiles de arranque y bloqueo, las cohortes de activación y los experimentos concluidos, y decidir qué se retira, qué se dobla y qué hipótesis se prueban a continuación.

Merece la pena hacer explícito el circuito completo porque cada tramo tiene un modo de fallo característico y reconocerlo ahorra diagnósticos largos. La instrumentación falla por silencio, cuando deja de emitir sin avisar. La agregación falla por mezcla, cuando junta causas distintas bajo la misma firma. La lectura falla por composición, cuando se interpreta un cambio de mezcla como un cambio de comportamiento. La priorización falla por recuento, cuando ordena por informes en lugar de por personas. Y la decisión falla por amnesia, cuando no se registra y se vuelve a tomar. Un equipo que conoce los cinco modos de fallo detecta en qué tramo está roto su bucle sin necesidad de rehacerlo entero.