Projeto de dados raramente estoura orçamento por causa da tecnologia escolhida. Estoura por cinco erros de execução que se repetem com regularidade: escopo definido pela plataforma em vez da pergunta de negócio, ingestão sem regra de qualidade na entrada, métrica sem dono único recalculada em cada camada, identidade de entidades adiada para o fim, e governança tratada como etapa final. Os cinco têm o mesmo padrão de custo: são baratos de resolver na fase de desenho e caros de corrigir depois que o pipeline está em produção, porque a correção exige reprocessar dado, refazer relatório e renegociar com áreas que já receberam número errado. Este guia detalha cada erro, o mecanismo pelo qual ele consome orçamento e o que evita cada um na prática.

Por que o estouro quase nunca aparece no relatório de custo da plataforma

Quando um projeto de dados fura o orçamento, a primeira suspeita costuma cair sobre o consumo da plataforma: cluster que rodou demais, licença dimensionada errado, armazenamento acima do previsto. Esses custos existem e são visíveis, o que os torna alvo fácil. O problema é que raramente são a causa principal.

O custo que de fato estoura o projeto é o retrabalho, e ele não aparece como linha de infraestrutura. Aparece como semanas adicionais de engenharia, como o terceiro ciclo de reconciliação de um relatório que não fecha, como o pipeline reprocessado do zero porque a regra estava errada desde a primeira carga. É custo de gente e de tempo, disfarçado de “ajuste de escopo”, e ele nasce de decisões de desenho tomadas nas primeiras semanas do projeto.

A tese deste guia: os cinco erros abaixo têm o mesmo formato econômico. O custo de evitá-los na fase de desenho é uma conversa de dias. O custo de corrigi-los depois da produção é reprocessamento, retrabalho e perda de confiança das áreas de negócio, que é o mais caro dos três porque não se resolve com engenharia. Projeto de dados é uma das poucas disciplinas em que a decisão barata e a decisão cara acontecem no mesmo momento, com poucos meses de distância entre a escolha e a fatura.

Os cinco erros em uma tabela

Erro 1 · Definir o escopo pela plataforma em vez da pergunta de negócio

O sintoma é reconhecível no kickoff: a reunião começa discutindo arquitetura, camadas e ferramentas, e a pergunta de negócio aparece como contexto, não como requisito. O projeto então é desenhado em torno do que a plataforma faz bem, e a entrega é tecnicamente correta e comercialmente irrelevante. A diretoria recebe um ambiente sofisticado que não responde a pergunta que motivou o investimento.

O mecanismo de custo é o mais silencioso dos cinco, porque só se revela no fim. Todo o esforço de engenharia foi gasto, e a conversa recomeça: “mas o que eu precisava saber era outra coisa”. Como evitar: começar pela lista de perguntas que a diretoria quer responder, com dono e critério de sucesso por pergunta, e desenhar o pipeline de trás para frente a partir delas. Na prática, isso define quais tabelas ouro existem, e a arquitetura medalhão documentada pela Databricks é explícita nesse ponto: a camada ouro é organizada por consumo, com projeto dirigido ao caso de uso, não pelo que a fonte oferece.

Erro 2 · Ingerir sem regra de qualidade na entrada

Conectar a fonte e ver o dado chegar dá uma sensação boa de progresso. O erro é confundir dado que chegou com dado que serve. Sem regra de validação na porta de entrada, campos preenchidos por obrigação, registros incompletos e valores impossíveis entram no pipeline e se espalham por tudo o que é construído em cima.

O custo aqui é de propagação. Descobrir na camada de consumo que o dado da origem estava ruim implica reprocessar as camadas intermediárias, refazer os agregados e revalidar os relatórios que já circularam. Como evitar: declarar expectativas de qualidade no próprio pipeline. A Databricks documenta as expectations de pipeline como regras declarativas que validam o dado na ingestão, permitindo barrar ou colocar em quarentena o registro que não passa, em vez de deixá-lo contaminar as camadas seguintes. Do lado da origem, a mesma lógica vale para o Jira: workflow e campos que refletem o processo real reduzem, na fonte, o volume de regra que a quarentena precisa cobrir.

Erro 3 · Deixar a métrica sem dono único

Este é o erro que mais consome tempo de time sênior. “Concluído” é definido de um jeito no relatório operacional, de outro no dashboard executivo e de um terceiro no notebook de análise. Nenhuma das três definições está errada isoladamente. Juntas, produzem três números para o mesmo indicador, e a reunião de diretoria vira sessão de reconciliação em vez de decisão.

O custo é recorrente, não pontual: cada novo relatório reabre a discussão, e o time gasta ciclos explicando divergência em vez de produzir análise. Como evitar: definir a métrica uma vez, com dono nomeado, e materializá-la na camada que serve todo mundo. No Power BI, é exatamente o papel do modelo semântico, que a Microsoft descreve como a camada onde métricas e regras de negócio são definidas uma vez e aplicadas de forma consistente em todos os relatórios. No Lakehouse, é a tabela ouro com definição única. O ponto comum: a definição precisa morar em um lugar só, e mudança de definição precisa ser decisão explícita, não efeito colateral de um cálculo novo.

Erro 4 · Adiar a resolução de identidade para o fim do projeto

Identidade de entidades (cliente, produto, fornecedor) tem fama de tema chato de cadastro, e por isso costuma ficar para depois. O problema aparece no primeiro cruzamento sério: o relatório que junta dados de duas fontes não fecha, porque a mesma empresa aparece com grafias diferentes, o mesmo produto tem códigos divergentes, e o total não bate com nenhuma das fontes originais.

O custo é de refação estrutural. Resolver identidade depois que a modelagem foi construída sobre chaves inconsistentes implica redesenhar as tabelas de consumo e reprocessar o histórico. Como evitar: tratar identidade como requisito de arquitetura desde o desenho, decidindo cedo qual fonte é canônica para cada entidade e quais são as regras de sobrevivência de atributo. É o trabalho de dados mestres que detalhamos no artigo sobre MDM no Databricks, e a decisão central dele não é técnica: é o acordo de negócio sobre qual versão vale, que precisa de dono antes de virar pipeline.

Erro 5 · Tratar governança como etapa final

Governança costuma entrar no cronograma como item de encerramento, junto com documentação e treinamento. Funciona até a primeira pergunta séria de compliance ou até alguém notar que dado sensível está acessível para quem não deveria. Aí a governança deixa de ser item de checklist e vira requisito bloqueante, com o pipeline já construído.

O custo é de redesenho sob pressão, o pior cenário possível: refazer estrutura de acesso com prazo curto, sem poder parar a operação que já depende do ambiente. Como evitar: desenhar governança junto com a arquitetura, não depois. No Databricks, o Unity Catalog governa acesso, linhagem e auditoria de forma centralizada, com as mesmas permissões valendo para analistas, notebooks e modelos, o que permite decidir desde o início quem enxerga o quê e em qual granularidade. A pergunta que vale fazer na semana 1: quando a auditoria pedir a linhagem deste número, de onde ela sai?

O padrão comum aos cinco (e o que ele diz sobre o custo real de consultoria)

Olhando os cinco juntos, o padrão é evidente: todos são decisões de desenho que parecem adiáveis e não são. Escopo, qualidade na entrada, definição de métrica, identidade e governança são baratos enquanto ainda são conversa, e caros a partir do momento em que viram código em produção com áreas de negócio consumindo o resultado.

A conclusão prática para quem orça projeto de dados: a fase de desenho parece a mais dispensável e é a que mais protege orçamento. Consultoria que começa a codificar na primeira semana está economizando na etapa errada. O trabalho consultivo que evita os cinco erros acontece antes do primeiro pipeline, e é o que separa projeto que entrega do projeto que entra em ciclo de correção. Quem já viveu um estouro reconhece o padrão: o dinheiro não foi embora na plataforma, foi embora refazendo o que poderia ter sido decidido em duas semanas de desenho.

Como reconhecer se o seu projeto está caminhando para o estouro

•     O kickoff discutiu arquitetura antes de listar as perguntas de negócio. Sinal do erro 1. Peça a lista de perguntas com dono e critério de sucesso antes de aprovar a próxima etapa.

•     Ninguém sabe dizer o que acontece com um registro inválido. Sinal do erro 2. Se a resposta é “ele entra e a gente vê depois”, a quarentena não existe.

•     Duas pessoas dão definições diferentes para a mesma métrica. Sinal do erro 3, e ele só piora com o número de camadas.

•     O plano trata cadastro como “ajuste posterior”. Sinal do erro 4. Pergunte qual fonte é canônica para cliente; se não houver resposta, o cruzamento vai falhar.

•     Governança aparece no cronograma depois do go-live. Sinal do erro 5. Antecipe a pergunta de auditoria para a semana 1.

Quando o rigor completo é exagero

•     Prova de conceito de escopo fechado. Um experimento com fonte única e caso de uso isolado pode rodar com rigor reduzido e ressalva explícita. O erro não é o atalho, é promover o atalho a produção sem revisitar as cinco decisões.

•     Fonte única e volume pequeno. Sem múltiplas origens, o erro 4 praticamente desaparece e o erro 3 fica muito mais simples de controlar. O rigor deve ser proporcional à complexidade real, não ao tamanho da ambição.

•     Ambiente sem dado sensível nem exigência regulatória. O peso do erro 5 muda bastante. Governança continua importando, mas o custo de errar é menor e a sequência pode ser mais flexível.

Perguntas frequentes

Por que projetos de dados estouram orçamento com tanta frequência?

Porque o custo principal não é de plataforma, é de retrabalho, e o retrabalho nasce de decisões de desenho tomadas nas primeiras semanas: escopo definido pela ferramenta, ingestão sem validação, métrica sem dono, identidade adiada e governança tratada como etapa final. Todas são baratas de resolver enquanto são conversa e caras depois que viram pipeline em produção.

Qual dos cinco erros é o mais caro?

Depende do estágio em que é descoberto, mas os erros 3 e 4 costumam consumir mais orçamento em projeto de porte. A métrica sem dono gera custo recorrente de reconciliação a cada novo relatório, e a identidade adiada exige refazer modelagem já construída. O erro 1 é o mais silencioso: só aparece na entrega, quando todo o esforço já foi gasto.

Como validar se a consultoria contratada evita esses erros?

Pelo que ela faz nas primeiras semanas. Consultoria que começa a codificar antes de mapear perguntas de negócio, regras de qualidade, definição de métricas, identidade canônica e modelo de permissões está economizando na etapa que mais protege orçamento. Peça esses cinco artefatos como entregável da fase de desenho, antes do primeiro pipeline.

Já estamos no meio do projeto e vejo esses sinais. Precisamos recomeçar?

Raramente é preciso recomeçar. O caminho usual é uma revisão de arquitetura que identifica quais das cinco decisões ainda podem ser corrigidas com custo baixo e quais já exigem reprocessamento, priorizando pelo que trava a próxima entrega. Corrigir no meio é mais caro que no desenho, e bem mais barato que descobrir na auditoria.

Próximo passo

Se você reconheceu dois ou mais dos sinais no seu projeto atual, o custo de corrigir agora é uma fração do custo de corrigir depois do go-live. Solicite uma revisão de arquitetura do seu projeto de dados com a CSP Tech e receba o diagnóstico das cinco decisões: quais já estão resolvidas, quais ainda dá para corrigir barato e quais precisam de decisão do negócio antes de mais uma linha de pipeline.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. Revisão técnica por especialistas Atlassian, Microsoft e Databricks da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).

Fontes (oficiais, verificadas nas peças deste cluster): Databricks Documentation, arquitetura medalhão, expectations de qualidade em pipelines e Unity Catalog (docs.databricks.com); Microsoft Learn, modelo semântico do Power BI (learn.microsoft.com/power-bi); Atlassian Support, boas práticas de workflow no Jira (support.atlassian.com).