O que exigir no contrato antes de fechar uma consultoria Salesforce

A proposta chega bonita, com escopo em tópicos, preço fechado e um prazo animador. Você assina aliviado por ter resolvido. Três meses depois o projeto está no ar, o consultor sumiu, e você descobre que ninguém da sua equipe consegue mexer no que foi feito, que não existe um teste sequer, e que o código está numa org que não é a sua. O contrato protegeu o fornecedor, não você. O preço estava certo. O que faltou estava nas cláusulas que ninguém leu.

Para contratar consultoria Salesforce sem virar refém, exija por escrito três coisas: que o código e o repositório sejam seus; que a entrega inclua testes automatizados que validem a regra de negócio; e uma cláusula de saída com transferência de conhecimento e devolução dos acessos. Sem essas três, você fica dependente do fornecedor mesmo depois de pagar.

As três cláusulas que eliminam a maior parte do risco

A maioria dos problemas que vejo em org de cliente não vem de código ruim, vem de contrato omisso. Existem três pontos que, se estiverem claros no papel antes de assinar, cortam quase todo o risco de você ficar preso a um fornecedor. Eles não custam nada para o consultor honesto e incomodam justamente quem depende do seu desconhecimento.

Quem executa de fato. Muita empresa vende com o consultor sênior e entrega com o estagiário. A proposta precisa nomear quem vai colocar a mão na sua org e qual a senioridade. Peça para conhecer essa pessoa antes de fechar, não só o comercial. Se a resposta for vaga, o preço está sendo cobrado por um perfil que você não vai receber.

De quem é o código e a org. Todo o trabalho, o código Apex, os componentes, a configuração e o repositório precisam ser declarados propriedade da sua empresa, versionados em um Git que é seu. Parece óbvio, mas é comum o consultor desenvolver numa org própria e só "entregar" o resultado, o que te deixa sem histórico, sem como auditar e sem como passar para outro. A cláusula certa diz que a propriedade intelectual do que foi construído para você é sua, ponto.

O que acontece na saída. Todo contrato termina, e o momento da saída é quando o lock-in aparece. Exija uma cláusula que obrigue a transferência de conhecimento, a entrega da documentação e a devolução dos acessos de administrador ao fim do projeto. Sem isso, trocar de fornecedor vira um projeto novo, e o consultor sabe disso. Quem trabalha bem não tem medo dessa cláusula, porque ela nunca vai ser acionada contra ele.

Como comparar propostas sem olhar só o preço

Duas propostas com o mesmo escopo em tópicos podem ter valor total muito diferente, e a mais barata quase nunca é a mais barata no fim. O preço fechado esconde o que não está incluso, e o que não está incluso é justamente o que segura a qualidade. A tabela abaixo mostra os critérios que mudam o custo real de um projeto, comparando o que uma proposta que te protege traz contra uma que transfere o risco para você.

Vale fazer a conta com um cenário ilustrativo, com números de exemplo só para mostrar o raciocínio. Imagine a Proposta A a R$ 40.000, preço fechado, sem testes e sem documentação, e a Proposta B a R$ 52.000, com testes, documentação e 60 dias de garantia. A A parece R$ 12.000 mais barata. Agora suponha que, seis meses depois, uma regra de comissão quebra num caso de borda que nenhum teste pegou. Um desenvolvedor precisa entender o código sem documentação, reproduzir o problema e corrigir sem quebrar o resto. São, digamos, 30 horas a R$ 180, ou seja R$ 5.400, mais o tempo da sua operação parada e a confiança da equipe abalada. Repita isso duas ou três vezes no ano e a proposta "mais barata" já custou mais, sem contar o desgaste. A conta que importa não é o preço da entrega, é o custo de conviver com o que foi entregue. Para entender melhor o que compõe esse valor, veja o que pesa no preço de um projeto Salesforce.

As bandeiras vermelhas antes de assinar

Alguns sinais aparecem já na fase de proposta e dizem mais do que qualquer apresentação de slides. Quando você reconhecer um destes, trate como um convite para perguntar mais, não como detalhe:

• Orçamento sem diagnóstico. Quem fecha preço sobre um pedido de uma linha está chutando, e chute vira aditivo. Todo escopo travado exige um levantamento antes, mesmo que curto. Sem isso, cada mudança que aparecer no meio vira discussão de dinheiro.
• Lock-in de código disfarçado. Frases como "a gente cuida de tudo, você não precisa se preocupar com o técnico" costumam significar que você nunca vai ter acesso ao que foi feito. Cuidar de tudo é ótimo, desde que o que foi construído continue sendo seu e documentado.
• Silêncio sobre teste e manutenção. São os dois itens que mais estouram prazo e mais somem das propostas. Quem não fala de teste na venda não vai priorizar teste na entrega, e a conta de manter uma org sem teste chega depois. Se quiser dimensionar esse custo recorrente, veja quanto custa manter o Salesforce por mês.
• Concordância com tudo. Um bom consultor questiona parte do seu pedido, porque parte do que você pediu quase sempre não vale o custo. Quem concorda com cada item sem contrapor está pensando em fechar o contrato, não em resolver o seu problema.

Teste, versionamento e documentação: coloque no papel

Estes três itens são invisíveis na demonstração e decisivos na vida real, por isso precisam estar escritos, não subentendidos. A Salesforce obriga 75% de cobertura de testes de Apex para subir código em produção, então todo projeto com código já nasce com algum teste por imposição da plataforma. O detalhe é que cobertura não é qualidade: dá para atingir os 75% com testes que só executam o código sem validar se o resultado está certo. O que você exige no contrato é teste que verifique a regra de negócio, aquele que falha de propósito quando o cálculo dá o número errado. Esse é o que te avisa do problema antes do cliente avisar.

Versionamento é o que garante que você tem o histórico do que foi feito e consegue voltar atrás. Trabalho sério hoje sai de uma org isolada e vai para produção por um repositório Git, não por Change Set clicado na mão. Se o termo é novo para você, o caminho está descrito em como migrar de Change Sets para a sf CLI. Documentação, por fim, é o que permite que outra pessoa continue o trabalho sem arqueologia. Não precisa ser um manual de cem páginas, precisa registrar as decisões: por que uma automação foi feita em Flow e não em código, quais campos alimentam qual regra, o que quebra se alguém mexer no lugar errado.

SLA, garantia e o custo depois do go-live

O projeto entrar no ar não é o fim, é quando a conta de manutenção começa. Uma proposta honesta separa claramente duas fases: a implantação, com preço e prazo, e a sustentação, com um acordo de nível de serviço que define tempo de resposta, canal de suporte e o que está incluso. Confundir as duas é como comprar um carro e achar que revisão e pneu vêm de graça para sempre. Pergunte diretamente: depois que entregar, quem corrige um bug? Em quanto tempo? Isso está no preço ou é à parte?

A garantia é diferente do SLA. Ela cobre defeito do que foi entregue, um erro que já estava lá no go-live e apareceu depois. Um prazo de 30 a 90 dias sem custo é razoável e mostra que o fornecedor confia no próprio trabalho. O SLA cobre a vida que continua: mudança de processo, ajuste de regra, um relatório novo. Se você ainda está decidindo se faz mais sentido manter esse custo com um fornecedor externo ou trazer alguém para dentro, vale comparar consultoria e dev interno lado a lado antes de assinar qualquer coisa de longo prazo.

O que aprendi montando a org de demonstração

A Vetra Distribuidora é a empresa fictícia que uso como org de demonstração deste portfólio, e cada peça que construí nela me mostrou onde um contrato mal feito cobra caro. Um exemplo concreto: montei uma regra de comissão por linha de produto que respeita desconto, com trigger, teste e uma interface para a operação conferir. A parte que dá trabalho não é escrever o cálculo, é escrever o teste que valida cada caso de borda e documentar por que a regra é aquela. Um fornecedor apressado entrega o cálculo, mostra numa tela que "funciona" e vai embora. O buraco aparece meses depois, num desconto combinado que ninguém previu, com o número errado indo para o pagamento. Foi montando essas peças que entendi que o teste e a documentação não são luxo de projeto grande, são o que separa uma entrega que você consegue manter de uma que você vai ter que refazer. É por isso que insisto nessas cláusulas: não é burocracia, é a diferença entre ter um ativo e ter um problema herdado. Se quiser um passo anterior, sobre escolher a pessoa e não só a empresa, veja como avaliar um consultor ou freelancer Salesforce.

Perguntas frequentes

O que exigir no contrato de uma consultoria Salesforce?

Exija por escrito três coisas: que o código, os metadados e o repositório sejam seus, que a entrega inclua testes automatizados que validem a sua regra de negócio, e uma cláusula de saída com transferência de conhecimento e devolução dos acessos de administrador. Sem essas três, você fica dependente do fornecedor mesmo depois de pagar.

Como comparar propostas de consultoria Salesforce além do preço?

Compare o que cada proposta entrega junto com o preço: diagnóstico antes do orçamento, testes e documentação inclusos, garantia após o go-live e propriedade do código. Uma proposta mais barata sem testes costuma custar mais no total, porque o retrabalho e a manutenção às cegas aparecem meses depois, quando o fornecedor já saiu.

O que é lock-in em um projeto Salesforce?

Lock-in é quando você não consegue trocar de fornecedor sem prejuízo. Acontece quando o código fica numa org ou repositório do consultor, quando nada está documentado, ou quando só ele tem os acessos de administrador. Contrato que define desde o começo que tudo é seu e fica versionado no seu Git elimina o lock-in.

Consultoria Salesforce precisa entregar testes automatizados?

Sim, e não é opcional. A Salesforce exige 75% de cobertura de testes de Apex para subir código em produção, então todo projeto com código já nasce com testes por obrigação da plataforma. O que muda é a qualidade: teste que só busca cobrir linha não protege o negócio. Exija testes que validem a regra de negócio, não só o número da cobertura.