Como escolher um parceiro de gerenciamento e arquitetura de dados: o que perguntar antes de pedir proposta

A escolha já está feita quando a proposta chega. A essa altura você conversou com três ou quatro empresas, gostou de duas, e o que resta decidir é preço e prazo. Se o parceiro errado chegou até aí, o documento não vai te avisar.

O que separa um parceiro de gerenciamento e arquitetura de dados do outro acontece bem antes, e quase sempre na primeira conversa. Só que o sinal não está no que você pergunta. Está no que eles perguntam.

A primeira conversa é um diagnóstico, não uma apresentação

Quem procura um parceiro de dados já tem uma dor. O fechamento que atrasa todo mês, o relatório que cada área calcula de um jeito, o número que chega depois da decisão que dependia dele.

Ter a dor, porém, não é o mesmo que saber descrevê-la. Isso não é falha de ninguém: a pessoa que sente o problema costuma estar dois ou três passos distante de onde ele nasce. O diretor percebe que o fechamento atrasa. A causa pode estar numa integração que falha em silêncio, num campo que três sistemas preenchem de jeitos diferentes, ou numa planilha que alguém concilia na mão desde 2019 e que ninguém nunca documentou.

É por isso que a primeira reunião não é para apresentar solução. É para descobrir qual é o problema de verdade.

E esse é o trabalho da consultoria, não seu. Você não precisa chegar com o diagnóstico pronto. Se precisasse, não precisaria da consultoria.

O que uma boa primeira conversa parece

Quem sabe conduzir um diagnóstico ouve mais do que fala. E quando fala, pergunta.

As perguntas boas costumam parecer laterais. Quem executa essa conciliação hoje, e em quanto tempo. O que acontece quando a fonte atrasa, e quem descobre primeiro. Quantas versões desse mesmo indicador existem na empresa, e qual delas vai para a diretoria. Que decisão foi tomada no ano passado com um número que depois se mostrou errado.

Nenhuma dessas pergunta sobre tecnologia. Todas mudam o desenho da solução.

Um consultor experiente também vai atrás do que você não contou, porque não parecia relevante. O relatório que uma área mantém por fora. O sistema que ninguém pode parar e que por isso ficou de fora do escopo. Aquele processo manual que virou rotina e deixou de ser percebido como problema. Em projeto de dados, é quase sempre uma dessas coisas que decide o prazo.

Toda informação conta nessa etapa, inclusive a que parece pequena demais para ser dita.

O sinal mais claro é a pressa de falar de tecnologia

Se na primeira reunião alguém já diz qual plataforma vocês vão usar, essa pessoa não está resolvendo o seu problema. Está encaixando o seu problema no que ela já vende.

Databricks, Snowflake, Fabric, BigQuery, dbt, Airflow. Todas funcionam. Existe mais de um caminho tecnicamente correto para praticamente qualquer cenário, e a diferença entre eles não é qual é o melhor no papel: é qual encaixa nas suas fontes, no seu volume, no seu time e no que você pode pagar para manter rodando daqui a dois anos.

Nada disso é conhecido na primeira hora de conversa. Quem responde antes de saber está adivinhando, ou está vendendo.

Competência técnica, aliás, separa menos do que parece. Toda empresa séria do mercado domina essas ferramentas, e todas mostram as mesmas certificações. Isso serve para descartar quem não tem, não para escolher entre quem tem.

Por que o diagnóstico decide o custo

Existe uma relação direta, e pouco falada, entre a qualidade do diagnóstico e a conta que chega no fim.

Arquitetura desenhada sobre um entendimento raso tende a ser superdimensionada, porque na dúvida se compra folga. Ou subdimensionada, e aí o custo aparece depois, em retrabalho. Os dois casos custam caro, e o segundo custa também em confiança: quando a primeira entrega não resolve o que doía, a próxima conversa já começa difícil.

Entender o problema antes não é preciosismo de método. É o que permite escolher a solução mais simples que resolve, que quase sempre é também a mais barata de operar.

O que levar para a primeira conversa

Você não precisa de material pronto, e não precisa ter tudo. Mas algumas coisas encurtam muito o caminho, mesmo incompletas:

A lista das fontes que você conhece, ainda que faltem algumas. ERP, sistemas de área, planilhas que viraram sistema. Faltar é normal, e o que falta costuma aparecer justamente na conversa.

Um exemplo concreto de decisão que travou por falta de dado. Um caso real vale mais do que qualquer descrição genérica do problema, porque ele carrega as restrições reais junto.

Quem, do seu lado, vai conviver com o resultado. Nem sempre é quem está na reunião. Saber isso desde o começo muda o desenho.

Se a consultoria não pedir nada disso, e seguir a conversa mesmo assim, é um dado sobre ela.

Três sinais de alerta

A solução chega antes das perguntas. Já tratado acima, e é o mais comum.

Ninguém fala do que pode dar errado. Projeto de dados esbarra em fonte sem dono, em campo preenchido de três jeitos, em legado que não pode parar. Quem não menciona isso na conversa inicial vai mencionar na primeira reunião de status, quando já for problema seu também.

Não há nada sobre o depois. Quem vai operar, quem documenta, quem do seu time aprende a mexer. Quando isso aparece como “treinamento” no fim do cronograma, é o que vai ser cortado quando o prazo apertar.

Quando pedir a proposta

Quando você conseguir responder três coisas sem consultar ninguém: qual problema de negócio o projeto resolve, quem no seu time vai tocar aquilo depois que a consultoria sair, e quanto a operação vai custar por mês no ano que vem.

Se a consultoria fez o diagnóstico direito, você vai saber responder as três. E, o que é mais revelador, provavelmente vai descrever o seu problema de um jeito diferente de quando a conversa começou.

Se alguma ainda estiver em aberto, mais uma conversa custa menos do que o contrato errado.

Perguntas frequentes

A consultoria deve cobrar pelo diagnóstico inicial?

A conversa de entendimento não se cobra, e isso é praxe no mercado. O que varia é o passo seguinte: o assessment técnico no seu ambiente, com levantamento de fontes, análise de qualidade de dados e desenho de alternativas. Parte das consultorias trata como projeto pago, outras absorvem como investimento comercial.

Na Integrity-UX a primeira conversa nunca é cobrada e, dependendo do projeto, o assessment no ambiente do cliente também é feito sem custo.

O que importa para você, com qualquer fornecedor, é saber antes de aceitar qual dos dois modelos está na mesa, e o que fica com você ao final: um relatório que você pode levar para outra empresa avaliar, ou uma apresentação que só faz sentido se o projeto seguir com quem a fez.

E se eu não souber explicar direito o meu problema?

É o caso mais comum, e não é impedimento. Fazer a dor virar um problema descritível é justamente o primeiro trabalho da consultoria. Se a conversa exige que você chegue com o diagnóstico pronto, o papel está invertido.

Devo escolher uma consultoria especializada no meu setor?

Ajuda, mas pesa menos do que parece. O que mais muda o projeto é o volume de dados, a quantidade e o estado das fontes e o grau de dependência de sistemas legados. Uma consultoria que resolveu um problema parecido em outro setor costuma ser melhor escolha do que uma que conhece o seu setor e nunca lidou com a sua complexidade.

Faz diferença o parceiro ter certificação do provedor de nuvem?

Faz como piso. Certificação mostra que a equipe estudou a plataforma, não que ela já operou a sua. Pergunte quantos ambientes eles mantêm hoje em produção naquele provedor, e há quanto tempo. O nível de parceria também é público: a Microsoft, por exemplo, mantém um diretório oficial de parceiros onde dá para conferir.

Vale contratar uma prova de conceito antes do projeto?

Vale quando a dúvida é técnica de verdade, por exemplo se determinada arquitetura aguenta o seu volume. Não vale como período de teste do fornecedor, porque uma PoC bem-sucedida em escopo pequeno diz pouco sobre entrega em escala.

Como evitar dependência do fornecedor?

Exigindo, em contrato, documentação em formato aberto, código em repositório seu e ao menos uma pessoa do seu time envolvida em cada entrega. Dependência raramente é imposta. Quase sempre ela se instala porque ninguém do lado de dentro acompanhou.

Quanto tempo leva um projeto de arquitetura de dados?

Depende do número de fontes e do estado delas, e qualquer prazo dado antes de ver isso é chute. O que dá para exigir é entrega incremental: alguma coisa em uso logo no início, mesmo que pequena. Projeto de dados que só mostra resultado no fim costuma não ter fim.