Porque eu odeio dashboards
Da série: coisas que tiveram seu propósito desvirtuados
Um cientista de dados é tão bom quanto o resultado que ele entrega, e seu habitat natural está em resolver problemas complexos, sair da zona de conforto e hackear soluções. Se quisermos que essa frase seja o lema de um data scientist, o primeiro passo é não deixarmos que pensem que ciência de dados é um BI 2.0.
Motivação
Um dashboard é uma solução rápida e bonita de se entregar. Seu cliente fica feliz, porque recebeu um negócio colorido e cheio de gráficos para brincar; você fica feliz porque deixou seu cliente feliz; e seu chefe ficou feliz, porque pessoas estão usando gráficos e dados para tomada de decisão — é data-driven que se chama, né?
E por ser tão simples, banalizamos seu uso e negligenciamos seu verdadeiro propósito. Na verdade, a chance do resultado ser outro é maior: seu cliente provavelmente olhou uma vez para o dashboard e desistiu; você gastou tempo e recursos para criá-lo, ou pior, decisões erradas foram tomadas por má interpretação dos resultados. Mas, será que isso tudo podia ter sido evitado?
No artigo de hoje quero levantar alguns pontos que me fazem pensar duas vezes ao criar um novo dashboard para uma área, além de sugerir algumas outras abordagens que entregam — muitas das vezes — mais valor.
Muitos dashboards, nenhum acompanhamento
Desde os anos 80 há referências a sistemas que criam dashboards para ajudar na tomada de decisão. A priori, a definição básica de um painel é de ser uma ferramenta que permita entender e acompanhar KPI — Key Performance Metrics, ou Indicadores-chave de performance, em tradução livre. Na teoria, isso é lindo; na prática, a teoria é outra.
Quando sua empresa ou time possui dezenas de dashboards para acompanhar diferentes indicadores, na verdade ela está acompanhando nada. Fazendo uma analogia, é como se os indicadores do seu carro estivessem sendo mostrados no painel frontal, nas rodas, no porta-malas e nos pedais: você nunca irá conseguir monitorar todos.
O usuário que consome um dashboard deve ser capaz de entender como essas KPI estão indo assim que abrir o painel, além do dashboard precisar obedecer uma série de requisitos para ser considerado útil, como: ser simples e comunicar-se facilmente; ter o mínimo de distrações possíveis; aplicar a percepção visual humana para apresentar os dados e; não menos importante, ser prazeroso de se ver. Se quiser entender um pouco mais sobre como criar bons dashboards, recomendo a leitura desse artigo escrito por Victoria Hetherington.
Não deixe Dashboards definirem o papel da área
O problema de muitas empresas é ver uma área de Data Science como uma área que junta dados, e não como uma que resolve problemas. E se permitirmos que isso continue, continuarão a ter essa visão reduzida de uma área que tem muito mais potencial.
O problema de muitas empresas é ver uma área de Data Science como uma área que junta dados, e não como uma que resolve problemas.
Ao criar um dashboard, você está dizendo para seu usuário tirar suas próprias conclusões a partir dos gráficos que ele ver, e isso é muito perigoso, principalmente em painéis que oferecem opções self-service. É inviável descrever uma narrativa para contextualizar seu usuário sobre o dado que ele está vendo, principalmente devido dashboards serem algo dinâmico.
Defendo a ideia de que um dashboard deve ser criado apenas quando os dados que serão apresentados ali estão diretamente ligados aos drivers do negócio, quando há um indicador que realmente precisa ser acompanhado e, principalmente, que sua definição seja clara e alinhada para todos os membros que consumirem ele — você não vai querer que o time de Marketing tenha uma definição de receita diferente do time de Finanças, por exemplo.
Não use seus dashboards como relatório, e vice-versa
Que tipo de papel você exerce?
Dito isso, reflita: o meu time de Data Science serve apenas e exclusivamente para coletar dados e fazer dashboards? Se a resposta for sim, recomendo parar de seguir esse post e ler o livro Data Science: Create Teams That Ask the Right Questions and Deliver Real Value para ver se sua percepção muda. Criar um time de Data Science para apenas criar queries e dashboards é como utilizar uma bazuca para matar uma barata. E bazucas são caras.
Agora, se você acredita que esse time tem um potencial muito maior, acho que você irá concordar comigo ao dizer que nunca iremos conseguir mostrar valor se nos limitarmos a esses tipos de entregas. Não quero demonizar a criação de dashboards nesse post, mas acho que é nosso dever nos policiar e entender se aquela pergunta que o cliente quer responder está realmente ligada a uma métrica de negócio, e se ela realmente precisar estar em um dashboard.
Ferramentas te ajudam a fazer um trabalho mediano
Aplicações como Microsoft PowerBI, Qlik, Tableau, e até o nosso amado Metabase (doi meu coração dizer isso) são excelentes para facilitar e automatizar o processo de criação de um dashboard, mas elas se resumem a isso. Embora algumas dessas ferramentas permita que você inclua markdowns ou outros elementos de texto para enriquecer seu dashboard , elas limitarão seu trabalho a explicar o que significa um gráfico, ao invés de descrever hipóteses e sugerir conclusões. A boa notícia é que há soluções surgindo no mercado como a Arria: uma aplicação que utiliza Natural Language Generation para gerar storytelling de seus dados.
Como a gente resolve isso?
Seu cliente não sabe o que quer. Pelo menos na maioria das vezes. Eles sempre irão te pedir para “tirar a média” disso, fazer um dashboard daquilo, etc., mas, isso não é culpa deles. Eles não sabem que opções há disponíveis para resolver o problema deles e foram “educados” dessa forma. Como diz o ditado: para quem tem apenas martelo, tudo se torna prego.
Parafraseando Henry Ford: “Não encontre defeitos, encontre soluções. Qualquer um sabe queixar-se”. Sendo assim, vou deixar aqui meus dois centavos sobre entregas que, na minha opinião, entregam muito mais valor.
Entenda o problema
Se demandas vem de diferentes formas em sua empresa — aquela conversa de corredor ou um e-mail, por exemplo— tire um tempo para conversar com seu cliente. Entenda o que ele quer medir, por que ele precisa desse resultado, se está ligado a algum indicador de negócio, e por aí vai. Não tenha medo de perguntar, vai ser a melhor forma de entender o que fazer e usar para responder ao que ele está pedindo. A partir desse esclarecimento, você terá uma ideia melhor se um dashboard será realmente a melhor sugestão (spoiler: muitas das vezes, não é).
Análise de Dados + Storytelling
Storytelling é a arte de contar história. No contexto de data science, é a forma como conduzimos uma análise na forma de uma história e engajamos o leitor em nossa linha de pensamento enquanto nós definimos hipóteses e a validamos ou não por meio de dados. Há um tempo atrás, fiz um post sobre o que é e como criar seus próprios storytelling, onde menciono uma ferramenta muito famosa no arsenal de um cientista de dados: o Jupyter Notebook.
Se storytelling é melhor, por que quase ninguém usa?
Criar uma boa narrativa depende da sua análise; e criar uma boa análise leva tempo. Você precisa coletar dados, garantir que estão integros e consistentes, realizar análise exploratória, levantar hipóteses, testar essas hipóteses, e muitas outras etapas que demandam mais tempo e esforço que uma query ou a criação de um dashboard.
Conclusão
Utilize dashboards para acompanhar indicadores-chave do negócio; crie análises para resolver problemas complexos, testar hipóteses e explorar uma nova visão sobre o problema/solução. Embora trabalhosa, o valor entregue por uma boa análise é muito melhor que qualquer dashboard colorido. Imagina perceber durante seu estudo que um usuário que se cadastra na plataforma após ver um vídeo no Youtube tem uma retenção muito maior que outros clientes? Será que essa informação está atrelhada a algum indicador do negócio? Se sim, faz todo sentido tê-la em um dashboard; se não, você garantiu uma nova visão ao seu cliente, no mínimo.
