Como contratar uma consultoria de dados: um guia honesto

Contratar uma consultoria de dados em 2026 é mais difícil do que deveria ser. O mercado se divide em dois polos, e nenhum dos dois ajuda muito. De um lado, firmas grandes com apresentações impecáveis, onde o sócio sênior que te vende o projeto não é quem vai botar a mão na massa. Do outro, um monte de freelancers com talento individual, mas sem nenhuma estrutura de verdade por trás: constroem, mandam a nota e somem.

Os dois falham de jeitos diferentes, e a maioria das empresas que assina um contrato de consultoria de dados só percebe em que tipo de furada entrou seis meses depois. Esse é o guia que eu queria que mais clientes tivessem lido antes de falar comigo pela primeira vez.

Seis perguntas para fazer a qualquer consultoria de dados

1. Quem especificamente vai fazer o trabalho?

Não vale "como é o nosso time", peça os nomes. Se quem te apresenta a proposta não é quem vai implementar, pergunte por que e como funciona o handoff. Num projeto pequeno, "a pessoa com quem você está falando é a pessoa que vai fazer" é o arranjo mais simples e de menor risco.

2. Como anda o trabalho na semana 1, na semana 4 e na semana 8?

Uma boa consultoria de dados consegue descrever entregas específicas em pontos de controle concretos. Se a resposta for vaga, "a gente alinha as prioridades e vai ajustando no caminho", isso é um discovery que você vai bancar no meio do projeto, não um plano de projeto.

3. Como vocês lidam com definições de métricas quando os times internos discordam?

É uma pergunta de processo. Definir uma métrica é 20% SQL e 80% política interna. Quem já fez consultoria de dados de verdade tem um jeito reprodutível de trazer o conflito à tona, documentar e bater o martelo numa definição canônica. Se não tem, nunca esteve na sala quando o financeiro e o time de growth brigaram sobre o que conta como churn.

4. O que acontece quando o projeto termina?

Pergunte na lata: documentação, runbooks, treinamento do time interno, passagem de bastão, o que acontece se um modelo quebrar dois meses depois do handoff. Uma consultoria que não responde isso de forma concreta ou é inexperiente, ou está planejando te deixar dependente.

5. Você consegue me mostrar um projeto em que disse "não"?

Um consultor de dados sênior já recusou trabalho: escopo ruim, orçamento irreal, uma ferramenta que o cliente insistia em usar e que era errada pro caso dele. Se todo cliente serve, nenhum serve.

6. Qual sua opinião sobre [ferramenta X]?

Escolha algo que gera discussão: dbt Cloud vs Core, Looker vs Metabase, Snowflake vs BigQuery. Quem é da área de verdade tem uma opinião e defende com argumento. Vendedor responde "depende".

Projeto, retainer ou staff aug: como escolher a estrutura

Além da firma em si, a estrutura do contrato pesa mais do que a maioria das empresas imagina. São três formatos comuns, cada um com seu jeito de dar errado:

• Projeto com escopo fechado. "Construa um warehouse em 12 semanas por R$ X." Melhor quando o escopo é mesmo bem definido. Como dá errado: o escopo incha do seu lado e esbarra na rigidez do lado deles, o projeto atrasa e os dois lados saem com a sensação de terem sido passados pra trás.
• Retainer mensal. "Pagamos R$ Y por mês por Z horas de atenção sênior." Melhor para parcerias contínuas e problemas mais nebulosos. Como dá errado: as horas vão sendo cobradas sem ninguém acompanhar entregas claras, e em seis meses nenhum dos dois sabe dizer o que foi construído.
• Staff augmentation. "Aloque um engenheiro no nosso time por seis meses." Melhor quando você tem liderança, mas nenhum sênior na execução. Como dá errado: o engenheiro que entra no time acaba pegando os vícios dele em vez de corrigir, porque o que rende elogio ali é se encaixar.

Meus projetos costumam começar com um diagnóstico de escopo fechado (1–2 semanas), seguir com um build de escopo fechado (6–12 semanas) e terminar num retainer pra continuidade. O formato muda os incentivos: escopo fechado pro trabalho em que você quer uma entrega firme, retainer pras decisões lentas, daquelas que vão somando resultado com o tempo.

Sinais de alerta numa proposta

Uma lista curta do que, numa proposta de consultoria de dados, deveria fazer você levantar e ir embora:

1. Ninguém com nome e sobrenome. "Um time de analytics engineers" sem currículo é um anonimato que você vai pagar lá na frente, em qualidade.
2. Sem fase de discovery. Quem orça um build de 6 meses antes de conversar com o seu time está vendendo um template, não um projeto.
3. Foco na ferramenta, não no problema. "Somos certificados em [ferramenta]" nunca deveria ser o destaque. A ferramenta vem depois do problema, não antes.
4. Sem métrica de sucesso. Uma proposta sem definir, na lata, o que é "pronto" e o que é "deu certo" não dá pra cobrar na entrega nem responsabilizar ninguém pelo resultado.
5. Sem deixar claro de quem é o código e os dados. Se o contrato não diz com todas as letras que você é dono de tudo que sai do projeto, vá embora.

Leituras relacionadas

Depois de escolher um parceiro, a primeira coisa que ele deveria te ajudar a fazer é descobrir quais métricas no seu stack se contradizem. E, se for uma firma pequena ou um consultor solo, vale ler também o que é um data concierge: é uma descrição mais honesta de como costumam ser montados os projetos que realmente chegam ao fim.