A morte do dashboard

Um dashboard com doze gráficos pode estar brilhando verde e ainda estar mentindo para você. Não porque um número está errado, porque ninguém estava olhando para o que se moveu. A métrica que importava cruzou a linha às 14h14 da tarde, enquanto a pessoa que precisava saber estava numa reunião, depois no almoço, depois em outra reunião. Quando alguém finalmente abriu a aba, o gráfico tinha um pequeno entalhe vermelho que explicava, muito calmamente, algo que agora estava quatro horas tarde demais para corrigir.

Construímos uma ferramenta que segura a verdade perfeitamente e a entrega nunca. Então chamamos a disciplina de abri-la de “ser data-driven.”

Aqui está o problema inteiro numa linha, e é a linha em torno da qual este post orbita: o dashboard era uma interface de pull para um problema de push. O número que importa deveria te encontrar no momento em que se move, não esperar, educadamente, atrás de um login, você se lembrar de que ele existe.

A coisa que um dashboard de fato é

Tire os gráficos e a cor e um dashboard é uma query que você tem que lembrar de rodar.

Esse é o design inteiro. Alguém coletou os dados, construiu as views, e então te entregou uma tarefa de casa: cheque isto, regularmente, para sempre. O dashboard sabe tudo. Ele não diz nada. Ele fica ali, totalmente informado, esperando ser perguntado. Toda a inteligência dele está trancada atrás de uma precondição, que um humano, sem ser solicitado, decida que este é o momento de ir olhar.

Para um certo tipo de trabalho, isso é tranquilo. Se você genuinamente quer explorar, fazer uma nova pergunta, fatiar uma coisa de seis jeitos, seguir um palpite, um dashboard é a ferramenta certa, e puxar é o verbo certo. Exploração é uma atividade de pull. Você não quer um sistema empurrando cortes exploratórios em você o dia todo.

Mas exploração é talvez um décimo de por que dashboards existem. Os outros nove-décimos é observar. “Me avise se a receita cair.” “Me avise se os erros dispararem.” “Me avise se um cliente grande ficar quieto.” Nenhuma dessas é uma pergunta que você quer fazer repetidamente. Cada uma é uma instrução permanente, observe isto para mim e fale. E respondemos cada uma delas com o mesmo artefato: uma página que você tem que lembrar de abrir.

O descasamento é a história inteira. O dashboard era uma interface de pull para um problema de push. Observar é um trabalho de push. Demos a ele uma ferramenta de pull e então nos culpamos por não checar com frequência suficiente.

A correção ingênua que só move o gargalo

Então você sente o gap, e busca o patch óbvio: alertas.

Você define thresholds. Se a receita cai abaixo de uma linha, me pingue. Se os erros cruzam um número, me chame. Isso parece a cura, agora o sistema fala primeiro!, e por cerca de uma semana é. Aí a segunda doença se instala, e é pior que a primeira.

Thresholds não conhecem contexto, então disparam em tudo ou em nada. Defina-os apertados e você é chamado às 3h da manhã porque um batch job brevemente dobrou a taxa de erro e então se recuperou sozinho. Defina-os frouxos e você perde o sangramento lento que nunca dispara uma única linha mas silenciosamente te custa o trimestre. De qualquer jeito você aprende a lição que todo engenheiro de on-call aprende: um alerta que grita lobo é silenciado, e um alerta silenciado é só um dashboard com um mecanismo de entrega pior.

Aí vem a parte que ninguém admite. Imagine um time que cabeia cinquenta alertas pelas suas ferramentas, um número nada incomum. A maioria dispara numa única métrica cruzando um único número fixo, sem ideia do que mais era verdade naquele momento. Então os alertas que sobrevivem a serem silenciados ainda não conseguem responder a única pergunta que importa quando um dispara: isso é de fato um problema, ou é ruído? Você voltou a puxar. Você recebe o ping, então abre o dashboard para descobrir se o ping significou alguma coisa. O alerta não substituiu a tarefa de casa. Ele só adicionou uma interrupção na frente dela.

O gargalo nunca desaparece. Ele se move. De “você esqueceu de checar” para “você foi chamado e agora tem que investigar.” Ambas as versões terminam num humano encarando gráficos, reconstruindo contexto que a máquina já tinha e jogou fora.

Nosso jeito: um watcher, não uma janela

A correção não é um gráfico mais esperto. É inverter o verbo.

Pare de construir um lugar para onde o humano vai puxar a verdade. Construa um processo que observa a verdade e empurra a parte que mudou. O dashboard é uma janela, uma coisa em que você fica parado e olha através. O que observar de fato precisa é de um watcher: algo que nunca pisca, segura a instrução permanente na cabeça, e fala no momento em que a instrução é disparada. Não “aqui estão seus números.” Em vez disso: este número se moveu, aqui está por que acho que se moveu, e aqui está o que ele toca.

A diferença entre essas duas mensagens é a diferença entre dado e um colega.

Vale explicar por que isso é difícil, porque se fosse fácil já teríamos. A razão de “me avise se importa” ser tão mais difícil que “me avise se cruza 100” é que importar é um julgamento, não uma comparação. Uma queda de 10% na receita é uma catástrofe num mês plano e um erro de arredondamento durante uma promoção planejada. Um spike de signups é maravilhoso a menos que seja uma única fazenda de bots, caso em que é um problema vestido de comemoração. O número sozinho nunca carrega o próprio significado. Significância vive em tudo ao redor do número, a estação, o lançamento que você fez ontem, o cliente por trás da linha, as três outras métricas que se moveram com ele.

Um threshold joga tudo isso fora por design. Ele compara um número a uma linha e dispara. Um watcher que vale a pena faz o oposto: quando um número se move, ele vai e reúne, lê as métricas relacionadas, verifica o que mudou a montante, olha quem ou o que está por trás do movimento, e só então decide se você precisa ouvir sobre isso afinal. Na maioria das vezes a resposta honesta é não, isso é ruído, fique calado. A contenção é a feature. Um agent que te pinga sobre tudo é só o pager das 3h da manhã com gramática melhor.

Então o formato da coisa é: uma instrução permanente, um processo que observa contra ela sem cansar, o julgamento de separar sinal de ruído, e, quando é real, um único push que chega já explicado. Você não abre nada. O número que importa te encontra no momento em que se move.

Por que isso precisa de um brain, não de um webhook

Aqui é onde a maioria das tentativas para curto, e vale nomear a armadilha.

Você pode construir uma versão fina disso com um webhook e uma mensagem de Slack: métrica cruza linha, bot posta “receita caiu 10%.” Parabéns, você automatizou o ruído. A mensagem não tem contexto porque o bot não tem contexto. Ele sabe o número e nada mais, então não pode te dizer se vale se importar, e você está puxando o dashboard de novo noventa segundos depois.

A razão de um watcher de verdade conseguir fazer o reunir, ler os sinais relacionados, saber que o lançamento de ontem aconteceu, reconhecer o cliente por trás da queda, é que ele não é um webhook parafusado num único gráfico. É um agent sentado em cima de um company brain compartilhado: o lugar onde as métricas, o calendário, o histórico do cliente e os eventos recentes todos vivem juntos e podem ser lidos de uma vez. O webhook vê um único número através de um buraco de fechadura. O agent vê a sala.

Esse é o unlock, e é por que a morte do dashboard esteve esperando por algo específico. Não conseguíamos matar a interface de pull até termos um sistema que pudesse fazer o puxar por você, reunir o contexto, pesá-lo, e decidir. Por décadas a única coisa capaz desse julgamento era uma pessoa, então construímos ferramentas para a pessoa puxar, e puxar era o melhor que podíamos fazer. No momento em que um sistema consegue segurar a instrução permanente e o contexto ao redor e o julgamento de separar sinal de ruído, a razão inteira do dashboard-como-torre-de-vigia evapora. Você para de alocar um humano para encarar a janela, porque o watcher é melhor em encarar e nunca cansa.

O que sobrevive, e o que não

Vale ser preciso sobre o que morre, porque “o dashboard está morto” é o tipo de obituário que é metade hipérbole.

O gráfico não morre. O gráfico é um jeito ótimo de olhar para um número uma vez que você decidiu olhar. O que morre é o segundo trabalho do gráfico, o que ele nunca fez bem, de ser a coisa que você deveria lembrar de checar para não perder o movimento. Esse trabalho pertence a um watcher agora. O gráfico se torna o que sempre deveria ter sido: um lugar para onde você vai depois do push, para explorar a coisa sobre a qual você já foi avisado. Pull volta a ser o verbo da exploração, onde pertence, e push assume o verbo de observar, onde sempre deveria ter vivido.

Então a versão honesta da manchete é mais estreita e mais verdadeira. O dashboard era uma interface de pull para um problema de push, e a metade do push é a parte que está terminando. Você ainda vai abrir gráficos. Você só não vai depender de abri-los para descobrir que algo quebrou. A dependência é o que morre. O explorar sobrevive.

Há um sinal de se um time fez essa mudança, e é pequeno. Pergunte a eles o que acontece quando um número-chave se move mal durante a noite. No mundo antigo a resposta é uma história sobre quem por acaso checou, e quando, e quão longo foi o gap. No mundo novo a resposta é chata: “recebemos uma mensagem naquela manhã com o movimento e a causa provável.” Chato é o objetivo. O drama de quem pegou é em si um sintoma, significa que pegar dependia de um humano estar acordado e curioso no minuto certo. Tire o drama e você tirou o gargalo.

A virada: pare de ser o watcher

Aqui está a parte que não é sobre software.

Agora mesmo, na maioria das empresas, alguém é o dashboard. Um founder que abre seis abas toda manhã e uma sétima antes de dormir. Um operador que mantém os thresholds reais na cabeça porque as ferramentas não conseguem, e que sente um zumbido baixo de pavor nos dias em que está ocupado demais para olhar. Um líder de time que sabe, no fundo, que a métrica que deveria estar observando é a que tem menos tempo para observar. Essa pessoa não está sendo diligente. Está sendo um polling loop feito de carne.

E o custo não são os minutos gastos checando. O custo é o que essa vigilância expulsa. Cada fragmento de atenção gasto observando caso algo se mova é atenção não gasta no trabalho que só um humano pode fazer, decidir o que vale observar em primeiro lugar, o que o número que se move significa para onde a empresa está indo, o que de fato fazer a respeito. Você se tornou o watcher porque nenhum sistema observaria por você. Isso nunca foi um bom uso da pessoa mais capaz do prédio.

A promessa não é um dashboard mais bonito. É que você para de ter que ser um. O observar se move para algo que nunca pisca e nunca se cansa de conter, e a pessoa que costumava alocar a janela passa a ser a que decide o que vale uma janela afinal.

---

É isso que estamos construindo na Apollo, não um lugar melhor para ir puxar a verdade, mas um watcher que lê o contexto inteiro da sua empresa e te empurra o único número que se moveu, já explicado, no momento em que importa. O melhor dashboard é o que você nunca tem que abrir, porque a coisa que você teria ido procurar já te encontrou.