Voltar ao blog
7 de junho de 20265 min de leitura

Como Dar Aula Me Ensinou a Construir Dashboards Melhores

dadoseducaçãoengenharia de dadosproduct thinking

Você já parou pra pensar que um bom professor e um bom engenheiro de dados fazem essencialmente a mesma coisa? Os dois pegam algo absurdamente complexo e transformam numa narrativa que faz sentido pra quem está do outro lado.

Passei alguns anos em sala de aula antes de migrar completamente pra tecnologia, e essa conexão entre ensino e dados só ficou mais clara com o tempo. Quando eu preparava uma aula sobre estruturas de dados, meu trabalho não era mostrar a implementação de uma árvore B+ — era fazer o aluno entender por que o banco de dados dele ficava lento quando a tabela passava de 1 milhão de registros. A implementação era meio. A compreensão era fim.

É a mesma distinção que separa um dashboard que as pessoas abrem todo dia de um que ninguém olha depois do primeiro acesso.

A sala de aula invisível

Quando você está na frente de uma turma, existe um ciclo que se repete toda aula: você observa os rostos, percebe onde a confusão aparece, ajusta a explicação em tempo real. Se o aluno não entendeu com analogia A, você tenta a B. Se a B não funcionou, você desenha. Se o desenho não bastou, você pega o notebook dele e mostra rodando. Esse ciclo — observar, adaptar, traduzir é contínuo e quase automático depois de alguns anos de prática.

É exatamente esse ciclo que a maioria dos dashboards corporativos não tem. Alguém com conhecimento técnico profundo constrói um painel cheio de métricas corretas, mas que não conversa com a realidade de quem vai usar. É como dar uma aula de cálculo integral usando apenas notação formal pra alunos de primeiro semestre: o conteúdo está lá, mas a ponte não foi construída.

A diferença crítica é que o professor recebe feedback imediato o rosto confuso do aluno é dado em tempo real. O engenheiro de dados precisa antecipar essa confusão antes de ela acontecer, porque depois que o dashboard vai pro ar, você raramente está na sala quando alguém tenta usá-lo. Isso exige um trabalho de empatia cognitiva que não aparece em nenhuma documentação técnica: você precisa se colocar no lugar de alguém que nunca viu o modelo de dados, nunca entendeu o que é granularidade, e mesmo assim precisa tomar uma decisão de negócio até o fim do dia.

O paradoxo da complexidade acessível

Na pedagogia existe um conceito de Vygotsky chamado zona de desenvolvimento proximal o espaço entre o que o aluno já sabe e o que ele consegue aprender com um empurrão. Ensinar abaixo dessa zona é perda de tempo. Ensinar acima é frustração. O professor experiente passa a aula inteira navegando esse espaço estreito, calibrando o nível de desafio a cada interação.

Em dados, esse conceito tem uma tradução direta e pouco explorada: o insight precisa estar um passo à frente do que o usuário já entende, mas não dois. Se você mostra um gráfico de regressão logística pra um gerente de vendas sem contexto, ele fecha a aba. Se mostra só o número de vendas do mês, ele já sabia disso antes de abrir o painel. Nos dois casos, você falhou por excesso ou por falta.

O ponto ideal é quando o dashboard mostra algo que o usuário quase já sabia, mas não tinha conseguido articular. "Ah, então é por isso que terça-feira vende menos!" Esse momento eureka não acontece por acaso. Ele é resultado de uma escolha deliberada sobre quais dados mostrar, em que ordem, com qual contexto. Um gerente de vendas que acompanha campanhas precisa ver o dado de terça junto com o dado de promoções ativas não porque você achou bonito o cruzamento, mas porque você entendeu o modelo mental de quem usa.

Isso é pedagogia aplicada a produto.

Padrões conectivos: onde dados viram história

O trabalho mais difícil em engenharia de dados não é técnico. Não é otimizar query, não é escolher entre modelo estrela ou floco de neve, não é configurar pipeline de ingestão. O trabalho mais difícil é descobrir as conexões que importam e descartar as milhares que não importam.

Você tem 47 tabelas num banco. Cada uma com dezenas de colunas. As possibilidades de cruzamento são combinatorialmente explosivas, e a maioria delas é ruído. Mas dessas milhares de combinações possíveis, talvez 5 ou 6 contem uma história relevante pro negócio. O problema é que você não descobre quais são essas 5 analisando o schema. Você descobre conversando com quem usa, entendendo o que as pessoas precisam decidir, e às vezes observando como elas tentam (e falham) em encontrar a resposta que precisam nos relatórios que já existem.

É exatamente o trabalho de um professor preparando aula para uma turma nova: você precisa conhecer profundamente o assunto (os dados), conhecer profundamente o público (o usuário), e construir a ponte entre os dois sem deixar que o seu próprio conhecimento técnico contamine a simplicidade necessária do outro lado. Quanto mais você domina o assunto, mais difícil fica não assumir que o outro sabe o que você sabe. Os professores chamam isso de "maldição do conhecimento". Os engenheiros de dados deveriam ter um nome pra isso também.

O problema que ainda não foi resolvido

Digamos que você construiu um dashboard excelente. Contextualizado, com os cruzamentos certos, contando a história que o negócio precisava. Mas então o negócio muda e ele sempre muda. Surgem perguntas que você não previu. O usuário precisa de um insight que está nos dados, mas não no painel que você construiu.

A saída convencional é abrir um chamado pro time de dados, esperar alguns dias, e receber um novo relatório. Isso escala mal e cria dependência. A saída ideal seria permitir que o próprio usuário explore novos caminhos sem precisar entender a estrutura do banco mas isso é um problema muito mais difícil do que parece.

Ferramentas como Tableau Ask Data e Power BI Q&A tentam resolver isso com interface de linguagem natural. O problema é que elas ainda exigem que o usuário saiba formular a pergunta certa. "Mostre vendas por região no último trimestre" funciona. Mas o usuário raramente sabe o que perguntar ele sabe qual decisão precisa tomar, e espera que o sistema o ajude a chegar lá. Essa é uma diferença fundamental que essas ferramentas ainda não atravessam.

O que falta é o equivalente digital da sensibilidade do professor: um sistema que percebe o que o usuário está tentando entender antes de ele conseguir verbalizar. Tecnicamente, isso exige três camadas que raramente coexistem. A primeira é semântica: o banco precisa saber não só que uma coluna se chama valor_venda, mas que ela representa receita bruta da operação comercial, atualizada diariamente, sensível a sazonalidade de fim de mês, metadados que descrevem o dado em linguagem de negócio, não em linguagem de schema. A segunda é contextual: o sistema precisa modelar o que aquele usuário específico já explorou, quais perguntas ele fez antes, qual é o domínio de atuação dele. A terceira é propositiva: cruzar as duas camadas anteriores e sugerir explorações relevantes de forma proativa "você está olhando para ticket médio; pode ser interessante ver como ele se comporta por canal de aquisição nesse mesmo período" sem exigir que o usuário saiba que essa correlação existe.

É um problema que une NLP, modelagem de grafos semânticos e UX research de um jeito que ainda não vi ninguém resolver de forma elegante. E enquanto não for resolvido, o engenheiro de dados continua sendo o intermediário insubstituível que é exatamente o papel que um bom professor ocupa numa sala de aula onde o material didático ainda não chegou lá.

Considerações finais

A ponte entre ensinar e construir produtos de dados é mais curta do que parece, e mais exigente do que a maioria dos job descriptions sugere. Nos dois casos, o trabalho real não é dominar o conteúdo é dominar a tradução. Saber transformar uma árvore B+ em intuição sobre performance, saber transformar 47 tabelas em 5 histórias que importam, saber antecipar a dúvida antes de ela aparecer.

Se você trabalha com dados e nunca deu aula, considere experimentar. Não porque vai te ensinar SQL mas porque a experiência de explicar algo complexo pra alguém sem contexto expõe, de forma brutal, todos os atalhos cognitivos que você tomou sem perceber ao construir seu último dashboard.

E se você é professor pensando em migrar pra dados: a sensibilidade que você desenvolveu em sala de aula perceber onde a confusão aparece, calibrar o nível de complexidade, construir a ponte entre o que você sabe e o que o outro consegue receber essa sensibilidade é o trabalho mais difícil dessa área, e ela não aparece em nenhum currículo de bootcamp. O resto é SQL e infraestrutura. Isso você aprende. A outra parte, ou você tem ou passa anos tentando desenvolver.

Leituras que informaram esse texto:

Voltar ao blog