O futuro dos dados:
a pergunta ficou fácil,
a definição continua difícil

1.1 O erro de diagnóstico que se repete desde os anos 1990

Cada geração de ferramenta de dados foi vendida como o fim da dependência do analista: as primeiras camadas de relatório, os cubos de análise multidimensional, as ferramentas de visualização por arrastar-e-soltar, os painéis de autosserviço. Todas melhoraram alguma coisa. Nenhuma acabou com a fila na porta da equipa de dados.

O motivo é sempre o mesmo, e é a tese deste documento: essas ferramentas resolveram a tradução da pergunta para a consulta, e o gargalo nunca esteve aí. O gargalo está na tradução da pergunta para o significado — o que conta como cliente, o que conta como ativo, em que fuso horário fecha o dia, se devolução entra na receita, se o teste interno entra na contagem. Isso não é um problema de sintaxe. É um problema de acordo entre pessoas.

1.2 As três camadas: sinal, tendência, incerteza

1.3 Delimitação de escopo

1.4 Horizonte e confiança

Horizonte: ~6 anos (2032), com confiança declarada em cada projeção. Caps. 2 a 7 são descritivos; o 8 é assumidamente especulativo; o 10 é o que continua a valer em qualquer cenário. Com 20 minutos, leia o 4, o 8 e o 10.

2.1 Na consulta e na análise

• Tradução de pergunta em linguagem natural para consulta ficou amplamente disponível e funciona bem em esquemas pequenos, limpos e bem nomeados.
• A qualidade degrada acentuadamente com a complexidade do esquema — muitas tabelas, nomes históricos, colunas ambíguas, regras de negócio implícitas. O que descreve a maior parte dos ambientes reais.
• O trabalho braçal encolheu de verdade: escrever a primeira versão de uma consulta, montar um gráfico, limpar um conjunto de dados e documentar código são hoje tarefas de minutos.
• A revisão do resultado não encolheu — continua a exigir alguém que conheça o dado e desconfie do número.

2.2 Na camada semântica e na governança

• Camadas semânticas e catálogos de métricas ganharam adoção — a tentativa de definir "receita", "cliente ativo" e "churn" num lugar só, com linhagem rastreável.
• A adoção é muito desigual: organizações que já tinham disciplina de definição avançaram; as que não tinham, compraram a ferramenta e mantiveram o problema.
• Linhagem e contratos de dados saíram do discurso para a prática em parte das organizações maiores.
• A divergência de números entre áreas continua a ser a queixa mais comum em qualquer organização de porte — e é anterior a qualquer tecnologia recente.

2.3 Na confiabilidade

• Consultas geradas erram de forma silenciosa: a junção errada, o filtro esquecido, a granularidade trocada — nada disso lança erro. Devolve um número plausível.
• A confiança do utilizador leigo é alta e mal calibrada — a resposta vem com fluência, e fluência é lida como competência.
• Verificação automática de resultados (testes de dados, limites esperados, reconciliação entre fontes) ganhou importância relativa pelo mesmo motivo.

2.4 Nos dados de origem

• Coleta comportamental sob restrição crescente por privacidade e consentimento — parte dos dados de uso simplesmente deixou de existir.
• Cresceu a proporção de conteúdo gerado no material disponível publicamente, com efeito sobre qualquer análise que dependa de raspagem ou de dados públicos.
• Dado próprio, de primeira parte, valorizou-se justamente por ser o que resta confiável e exclusivo.

3.1 As duas traduções

Uma linha de cinco barateou. É um ganho real — a etapa que sumiu era genuinamente chata e consumia tempo. Mas quem conclui daí que o trabalho de análise acabou está a olhar para a única linha que se moveu.

3.2 A consequência que quase ninguém antecipa

Quando produzir um número fica trivial, o número de números produzidos explode — e como a definição não foi acordada, eles divergem. O resultado não é uma organização melhor informada: é uma organização com mais números em circulação, todos com aparência de autoridade, muitos incompatíveis entre si, e ninguém com tempo de reconciliar.

É o mesmo padrão de baratear-e-inundar que aparece na apostila de Engenharia de Software (mais código do que capacidade de o entender) e na de Descoberta e Marketing (mais conteúdo do que atenção disponível). Projeção (confiança alta): o volume de análises produzidas cresce muito mais rápido que a capacidade organizacional de as reconciliar — e a reconciliação passa a consumir uma fatia crescente do tempo das equipas de dados.

3.3 O que fica escasso

4.1 O exemplo que resolve o argumento

4.2 Por que é um problema político, não técnico

Uma definição de métrica distribui reconhecimento e responsabilidade dentro da organização. Quem define "cliente ativo" define quem bateu a meta. Ferramentas de catálogo e camada semântica dão o lugar onde registar a definição — o que é genuinamente útil — mas não produzem o acordo. Comprar a ferramenta sem fazer o acordo produz um catálogo bonito com três definições concorrentes lá dentro, que é o desfecho mais comum.

4.3 O que faz a diferença quando funciona

4.4 A incerteza crítica

Incerteza crítica nº 2: as organizações resolvem a definição de métrica — ou continuam com cada área a manter a sua? Há razões para otimismo (a dor aumenta com o volume; as ferramentas de catálogo maduraram; e a pressão de auditoria e de relato regulado ajuda) e para pessimismo (o obstáculo é político e o incentivo de cada área para manter a sua definição favorável não mudou). Confiança sobre a resposta: baixa — e é por isso que é um eixo. Note que ela é independente da tecnologia de consulta: uma organização pode resolver a semântica sem nenhuma ferramenta nova, e pode adotar todas as ferramentas novas sem resolver nada.

5.1 A assimetria com a engenharia de software

Na apostila de Engenharia de Software, o problema é que o volume de código cresce mais que a capacidade de o revisar. Aqui o problema é pior numa dimensão específica: não há sinal de falha. Um programa com defeito lança exceção, falha um teste, quebra em produção. Uma consulta com a junção errada devolve 47.213 — e 47.213 parece exatamente com a resposta certa.

5.2 O catálogo dos erros silenciosos

5.3 O que escala como verificação

Projeção (confiança média-alta): a competência de desconfiar de um número plausível cresce em valor relativo até 2032, e passa a ser o que distingue o analista do utilizador de ferramenta — precisamente porque produzir o número deixou de distinguir.

6.1 O que está a encolher

• Dados comportamentais entre sites e aplicações — restrição por privacidade, consentimento e bloqueio técnico. Parte do que se media deixou de existir, e não de forma aleatória: quem recusa consentimento não é uma amostra representativa de quem aceita.
• Identificadores estáveis de pessoa — sem eles, unir o comportamento da mesma pessoa entre canais fica difícil ou impossível.
• Dados de terceiros comprados — sob pressão regulatória e de qualidade.

6.2 O que está a crescer — e a contaminar

• Conteúdo gerado no material público — qualquer análise que dependa de raspagem, de avaliações públicas ou de texto aberto passou a incluir uma fração crescente de material sintético, muitas vezes indistinguível.
• Dados sintéticos usados deliberadamente — úteis para privacidade e para completar amostras, e arriscados quando reproduzem apenas os padrões que já estavam nos dados originais, incluindo os enviesados.
• Tráfego automatizado — uma fração relevante e crescente de interações medidas não é de pessoas.

6.3 A consequência

Projeção (confiança média-alta): até 2032 a vantagem competitiva em dados desloca-se de "quem analisa melhor" para "quem tem dado próprio confiável" — porque a capacidade analítica ficou acessível e o dado bom não.

7.1 A escada que organiza o trabalho

Repare que a camada que barateou é a de baixo, e o valor de decisão está nas de cima. Uma organização que produz mil descrições e nenhuma inferência causal está a gerar atividade, não conhecimento.

7.2 O que produz resposta causal

• Experimento com grupo de controlo — o padrão-ouro, e o mais subutilizado fora de produto digital. Ver Experimentação, Feature Flags & A/B Testing.
• Desenhos quase-experimentais — comparação antes-depois com grupo de comparação, descontinuidade, variáveis instrumentais. Úteis quando o experimento é impossível.
• Explicitar o modelo causal — desenhar o que se acredita que causa o quê antes de olhar os dados. É o que impede a análise de confirmar o que já se pensava.
• Testes geográficos e de desligamento — a versão prática e barata do experimento para o que não se pode aleatorizar por pessoa.

Projeção (confiança média-alta): a competência que mais se valoriza na função de dados até 2032 é o desenho de medição e de inferência causal — não porque virou moda, mas por eliminação: é o que resta depois que descrever barateou.

7.3 A ressalva honesta

8.1 Os dois eixos de incerteza

8.2 Cenário 1 — O status quo cansado

O que acontece: a tradução automática continua a falhar em esquemas reais e a organização nunca acorda as definições. Tudo continua como está: fila na porta da equipa de dados, painéis que discordam, e uma fatia grande do tempo dos analistas gasta a explicar por que dois números diferentes estão ambos certos. Não é catástrofe — é desperdício crônico.

Sinais precoces: ferramentas de consulta em linguagem natural com adoção que estagna após o entusiasmo inicial; nenhum avanço em catálogo de métricas com dono nomeado.

O que fazer: resolver a semântica de forma unilateral no seu perímetro — mesmo sem mandato organizacional, definir e documentar as métricas da sua área já elimina metade da dor.

8.3 Cenário 2 — A resposta rápida e errada

O que acontece: a tradução automática funciona bem o suficiente para qualquer pessoa a usar, e a definição continua por acordar. Toda a gente pergunta, toda a gente recebe um número imediato e fluente, e os números divergem — agora em escala e em velocidade. É o cenário mais perigoso e, na minha leitura, o mais provável por defeito, porque exige apenas que a tecnologia avance e que a organização não faça nada. O acesso democratizou-se; o erro também.

Teria de ser verdade: adoção ampla de consulta conversacional sem investimento correspondente em definição e verificação.

Sinais precoces: aumento no número de painéis e relatórios sem aumento correspondente em métricas com dono; discussões de reunião que passam a ser sobre qual número está certo em vez de sobre o que fazer; decisões tomadas com base em números que ninguém verificou.

O que fazer: é o cenário que torna urgentes o cap. 4 (definição com dono) e o cap. 5 (verificação que não depende de ler a consulta). Nenhum dos dois exige tecnologia nova.

8.4 Cenário 3 — A camada bem construída

O que acontece: a organização resolve a definição — por dor acumulada, por exigência de auditoria ou por liderança competente — mas a tradução automática continua a falhar em esquemas complexos. O analista continua necessário como tradutor, e passa a ser dono do modelo semântico: a pessoa que sabe o que as coisas significam e mantém esse acordo vivo. Confortável e produtivo.

Sinais precoces: catálogos de métricas com dono nomeado e uso real; linhagem consultada no dia a dia; queda mensurável no tempo gasto em reconciliação.

O que fazer: investir em modelagem e em governança — a competência central deste cenário, e a mais transferível para o cenário 4.

8.5 Cenário 4 — O autosserviço que funciona

O que acontece: as duas coisas se resolvem. A pergunta em linguagem natural é traduzida contra uma camada semântica acordada e governada — que é, aliás, a única forma de a tradução automática ser confiável, porque ela deixa de adivinhar o significado e passa a consultá-lo. O autosserviço prometido desde os anos 1990 finalmente acontece. E o analista não desaparece: sobe para o que nunca automatizou — decidir que pergunta vale a pena fazer, desenhar a medição, estabelecer causalidade e interpretar.

Teria de ser verdade: a camada semântica primeiro; a tradução confiável depois. A ordem importa — e é a razão pela qual o cenário 4 tem um caminho e o cenário 2 é o atalho que não leva lá.

Sinais precoces: ferramentas de consulta que se ligam ao catálogo de métricas em vez de ao esquema cru; queda real na fila de pedidos simples sem aumento de divergência.

O que fazer: desenvolver as competências das camadas de cima da escada do cap. 7.1 — que servem também nos outros três.

10.1 As constantes

10.2 O histórico das promessas

• Cubos e análise multidimensional (anos 1990) — prometeram que o gestor exploraria os dados sozinho. Entregaram relatórios que a equipa de dados construía.
• "Big data" (anos 2010) — prometeu que volume suficiente dispensaria teoria e modelo. Entregou custo de armazenamento e a redescoberta de que perguntas mal formuladas não melhoram com mais linhas.
• Painéis de autosserviço — prometeram o fim dos pedidos ad hoc. Entregaram muitos painéis e a mesma fila.
• "Cientista de dados, a profissão mais sexy" — a expectativa de que o cargo transformaria organizações esbarrou, em muitos casos, na ausência de dados confiáveis e de perguntas bem postas. O gargalo era organizacional.

O padrão: cada onda resolveu um problema técnico real e foi vendida como solução para um problema organizacional. Aplique o mesmo desconto às projeções desta apostila, incluindo ao cenário 4.

"Uma resposta aproximada à pergunta certa, que é frequentemente vaga, vale muito mais do que uma resposta exata à pergunta errada, que sempre pode ser tornada precisa."

10.3 As ações robustas

12.1 Plano de treino — 30 dias, ~15 min/dia

12.2 Como montar a sua antena

12.3 Como não cair no hype

• Pergunte sempre qual tradução a ferramenta resolve. Se for a de sintaxe, ela não resolve o seu gargalo.
• Um problema organizacional não tem solução técnica. Definição de métrica é disputa de interesse, e nenhum catálogo negocia por você.
• Fluência não é acerto. A resposta que chega bem escrita e imediata não é por isso mais provável de estar certa.
• Desconfie do número plausível. O erro perigoso não é o absurdo — é o que parece razoável.
• Desagregue antes de concluir. Sempre.
• Melhore a origem antes de sofisticar a análise. Rende mais e quase ninguém faz.

12.4 Onde continuar

• Fundamento: "The Future of Data Analysis" (John Tukey, 1962) — o artigo que ainda descreve o problema · "How to Lie with Statistics" (Darrell Huff) · "O Sinal e o Ruído" (Nate Silver)
• Causalidade: "The Book of Why" (Judea Pearl & Dana Mackenzie) · "Mostly Harmless Econometrics" (Joshua Angrist & Jörn-Steffen Pischke), para quem quiser o lado técnico
• Nesta casa: Análise de Dados com Python e SQL & Administração de Bancos de Dados (a prática) · Engenharia de Dados (a origem e o pipeline) · Comunicação de Dados (apresentar o resultado) · Experimentação, Feature Flags & A/B Testing (a resposta causal) · Pensamento Crítico e Previsão Calibrada · O Futuro da Engenharia de Software (o paralelo, e a diferença do cap. 5)