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 é dividido em dois polos pouco úteis. De um lado você tem firmas grandes com decks polidos, onde o sócio sênior que te vende o engajamento não vai ser a pessoa que faz o trabalho. Do outro, uma cauda longa de freelancers com boa habilidade individual mas sem nenhuma estrutura real de engajamento, eles constroem a coisa, mandam a nota, e somem.

Os dois polos falham de jeitos diferentes, e a maioria das empresas assinando contratos de consultoria de dados não percebe o modo de falha em que está entrando até seis meses depois. Esse é o guia de comprador que eu queria que mais clientes tivessem lido antes da nossa primeira conversa.

Seis perguntas para fazer a qualquer consultoria de dados

1. Quem especificamente vai fazer o trabalho?

Não "como é o nosso time", peça os nomes. Se as pessoas te apresentando a proposta não são as que vão implementar, pergunte por quê e como o handoff acontece. Para um engajamento pequeno, "a pessoa com quem você está falando é a pessoa que vai fazer" é o arranjo mais simples e de menor risco.

2. Como é o engajamento na semana 1, na semana 4, e na semana 8?

Uma boa consultoria de dados deve conseguir descrever entregáveis específicos em checkpoints concretos. Se a resposta for vaga, "vamos nos alinhar nas prioridades e iterar", isso é um discovery que você vai pagar para viver, 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 organizacional. Quem já fez consultoria de dados de verdade tem uma forma reprodutível de expor, documentar e decidir definições canônicas. Se não tem, nunca esteve na sala quando financeiro e growth discordaram sobre churn.

4. O que acontece quando o engajamento termina?

Pergunte explicitamente: documentação, runbooks, treinamento do time interno, transferência de propriedade, o que acontece se um modelo quebrar dois meses depois do handoff. Uma consultoria que não consegue responder isso em termos concretos ou é inexperiente, ou está planejando te manter 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 que estava errada para ele. Se todo mundo é fit, ninguém é.

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

Escolha algo com controvérsia, dbt Cloud vs Core, Looker vs Metabase, Snowflake vs BigQuery. Um praticante de verdade tem uma opinião e defende com raciocínio. Um vendedor tem "depende".

Projeto, retainer, ou staff aug, escolhendo a estrutura

Para além da firma em si, a estrutura do engajamento importa mais do que a maioria dos compradores percebe. Três formas comuns, com modos de falha diferentes:

• Projeto com escopo fechado. "Construa um warehouse em 12 semanas por R$ X." Melhor quando o escopo é genuinamente bem entendido. Modo de falha: scope creep do seu lado encontra rigidez do deles, e o projeto termina atrasado com os dois lados se sentindo enganados.
• Retainer mensal. "Pagamos R$ Y por mês por Z horas de atenção sênior." Melhor para parcerias contínuas e problemas ambíguos. Modo de falha: as horas vão sendo cobradas sem entregáveis claros sendo rastreados, e em seis meses nenhum lado consegue articular o que foi construído.
• Staff augmentation. "Aloque um engenheiro no nosso time por seis meses." Melhor quando você tem liderança mas nenhum IC sênior. Modo de falha: o engenheiro embedded adota os hábitos ruins do seu time em vez de corrigi-los, porque é recompensado por se encaixar.

Os meus engajamentos 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 para continuidade. A forma muda os incentivos, escopo fechado para o trabalho onde você quer entrega decisiva, retainer para as decisões lentas que compõem ao longo do tempo.

Sinais vermelhos em propostas

Uma lista curta de coisas numa proposta de consultoria de dados que deveriam te fazer ir embora:

1. Nenhum indivíduo nomeado. "Um time de analytics engineers" sem currículos é um imposto de anonimato que você vai pagar em qualidade depois.
2. Sem fase de discovery. Quem cota um build de 6 meses antes de conversar com o seu time está te vendendo um template, não um projeto.
3. Pensamento centrado em ferramenta. "Somos certificados em [ferramenta]" nunca deveria ser a manchete. Ferramentas são downstream do problema.
4. Sem métricas de sucesso. Uma proposta sem definições explícitas de "pronto" e "bem-sucedido" é incobrável na entrega e irresponsabilizável no resultado.
5. Propriedade de código e dados pouco clara. Se o contrato não diz claramente que você é dono de tudo que é entregue, vá embora.

Leituras relacionadas

Depois que você escolheu um parceiro, a primeira coisa que ele deveria te ajudar a fazer é descobrir quais métricas no seu stack se contradizem. E se ele é uma firma pequena ou consultor solo, vale também ler o que é um data concierge, é uma descrição mais honesta de como engajamentos que de fato terminam costumam ser estruturados.