Como Resgatar um Projeto Salesforce Travado? Metodologia de Diagnóstico e Resgate

A Resposta Curta

A maioria dos projetos Salesforce que emperram não o fazem por conta de um código ruim. Eles emperram porque ninguém parou a tempo para questionar o que realmente muda na rotina dos usuários, quem é o responsável por cada decisão e o que acontece quando algo não sai conforme o planejado. O resultado são Sprints sucessivos que adicionam funcionalidades, mas sem melhoria na visão geral.

Salvar um projeto Salesforce emperrado significa, em primeiro lugar, estancar o sangramento, e só então decidir o que fazer com aquilo que já foi construído. Essa ordem é crucial: muitas organizações pulam direto para a fase de correção sem antes diagnosticar por que o processo anterior falhou, repetindo o mesmo erro pela segunda vez. Quem deseja entender como priorizar a dívida acumulada no caminho, pode aprofundar-se em Priorização de Dívida Técnica Salesforce.

Sinais de Paralisação: Como Identificar que o Projeto Não Está no Caminho Certo

Há uma diferença entre um projeto que avança lentamente e um projeto que já não se move. Os seguintes sinais se repetem em quase todos os salvamentos que realizamos:

• Discussões de Status se Transformam em Explicações: Reunião de status semanal que vira uma justificativa para algo ainda não estar pronto, sem uma nova data de entrega confiável.
• O Backlog Cresce Mais Rápido que a Taxa de Conclusão: Novos itens são adicionados a cada semana, mas o número de itens concluídos permanece constante ou diminui.
• Nenhuma Versão Testada com um Usuário Real no Último Mês: Apenas um Demo interno da equipe técnica, sem contato com quem realmente usará o sistema.
• Mudanças Frequentes de Requisitos Sem Documentação: Cada conversa gera "mais uma pequena alteração" que não é incorporada a um Scope Document organizado.
• Desconfiança Explícita: Os usuários já estão construindo planilhas Excel paralelas "para garantir", e isso é um sinal de que pararam de acreditar que o sistema funcionará a tempo.

Quando quatro dos cinco sinais ocorrem simultaneamente, trata-se de um projeto paralisado e não de um projeto lento, e essa diferença muda toda a estratégia de tratamento.

Diagnóstico em 10 Dias: O Que Verificar e em Qual Ordem

Um bom diagnóstico não requer dois meses. Dez dias úteis, com alocação adequada, são suficientes para obter um panorama confiável o bastante para a tomada de decisão. Uma divisão recomendada:

Dias 1-2: Entrevistas e Mapeamento Inicial. Conversas rápidas com o Sponsor, o proprietário do processo, dois ou três usuários finais e o chefe da equipe de desenvolvimento. O objetivo é coletar diferentes versões do "que deu errado", sem chegar a uma conclusão ainda.

Dias 3-5: Verificação Técnica Direta. Acesso ao próprio Org: estrutura de dados, automações existentes, permissões, logs de erro e consultas lentas. Aqui se verifica se o problema é arquitetônico ou operacional.

Dias 6-7: Comparação entre o Prometido e o Construído. Leitura dos documentos originais (SOW, User Stories, Design Docs, se existirem) em comparação com o estado atual no Sandbox ou Production.

Dias 8-10: Consolidação de Descobertas e Decisão Inicial. Um documento conciso que classifica cada problema encontrado como Scope, arquitetura ou confiança, e apresenta uma primeira recomendação: Reset, Refactor ou continuação em ritmo corrigido.

Três Camadas do Problema: Scope, Arquitetura e Confiança

O erro mais comum é tratar cada falha como se fosse um único problema. Na prática, quase sempre é uma combinação de três camadas diferentes, cada uma exigindo uma abordagem distinta.

Problemas de Scope manifestam-se quando ninguém realmente sabe o que entra na primeira versão. Isso ocorre quando a definição original era muito geral ("gerenciar todo o processo de vendas no Salesforce") e não foi decomposta em cenários concretos. A solução não é mais uma reunião de planejamento, mas sim a criação de uma lista clara de Must/Should/Later, com um Owner para cada item.

Problemas de Arquitetura manifestam-se em escolhas técnicas que não se sustentam em escala: modelo de dados que não suporta o volume de registros, automações que rodam em ordem incorreta, integração que falha silenciosamente. Aqui, é necessária uma verificação técnica aprofundada e, às vezes, o envolvimento de uma atualização do sistema Salesforce como infraestrutura paralela para a correção.

Problemas de Confiança são geralmente o resultado dos dois primeiros, mas criam vida própria: os usuários param de reportar problemas porque "não são corrigidos de qualquer forma", e a gestão para de financiar mudanças porque "já tentamos". Um problema de confiança não é resolvido com declarações, mas apenas com pequenas e repetidas provas.

Tabela de Diagnóstico: Sintoma, Causa Raiz e Primeira Ação

Reset vs. Refactor: Como Decidir

Esta é a decisão central e também a mais custosa, portanto, deve ser baseada em critérios e não em pressentimentos. Três testes ajudam:

1. Escopo da Dívida Técnica versus Escopo do que já Funciona. Se 70% da funcionalidade funciona razoavelmente e apenas partes específicas falham, é um Refactor. Se o problema está no modelo de dados básico, um Reset parcial quase sempre é preferível.
2. Custo de Explicação versus Custo de Reconstrução. Se levar mais de uma semana para a nova equipe entender por que algo foi construído de uma certa maneira, é provável que o custo de manutenção futura exceda o custo de uma construção limpa.
3. Estado de Confiança dos Usuários. Quando a confiança é muito baixa, um Reset focado e transparente (com a declaração "estamos iniciando uma nova versão corrigida") às vezes gera mais cooperação do que uma correção silenciosa que os usuários não percebem.

Na prática, a maioria dos salvamentos bem-sucedidos são híbridos: Reset para o componente central problemático (por exemplo, o modelo de Opportunity ou o processo de aprovação), juntamente com um Refactor para o restante do sistema. Uma comparação organizada entre as abordagens aparece em Reconstruir Salesforce, que detalha os critérios para cada cenário.

Plano de 90 Dias para Resgate

É importante planejar a fase do "primeiro ciclo" em torno de um único processo que os usuários sentirão em semanas, e não em torno do componente tecnicamente mais interessante. Projetos que falham pela segunda vez geralmente falham porque retornaram ao mesmo erro: começaram pela funcionalidade impressionante em vez da dor real. Esta fase também está diretamente relacionada ao desempenho real, e quem enfrenta problemas de tempo de resposta é convidado a ler Otimização de Desempenho do Salesforce.

Reconstruindo a Confiança com os Usuários

A confiança não retorna por causa de uma apresentação; ela retorna por um padrão consistente de uma pequena promessa que é cumprida. Alguns princípios que funcionaram na prática:

• Anuncie pequenas vitórias explicitamente. Ao corrigir um erro recorrente, envie uma mensagem concisa dizendo exatamente o que foi corrigido e quem solicitou. Essa transparência constrói mais confiança do que uma lista geral de conquistas.
• Convide usuários para testes antecipados, não apenas para UAT no final. Quem vê uma versão provisória e sente que suas observações foram consideradas, torna-se um embaixador do projeto para o resto da equipe.
• Não prometa uma data da qual não tem certeza. Uma data adiada pela terceira vez prejudica a confiança mais do que um cronograma realista, mas menos otimista.
• Documente falhas publicamente também. Quando algo não funciona, uma breve explicação do que aconteceu e o que muda constrói mais credibilidade do que um silêncio ignorante.

O processo de reconstrução da confiança geralmente leva mais tempo do que a correção técnica em si, por isso, é aconselhável planejá-lo como um caminho paralelo ao plano de 90 dias e não como um resultado automático dele. Organizações que desejam um acompanhamento estruturado para este processo, incluindo o acompanhamento direto da equipe e da gerência, podem utilizar o serviço de Salesforce Health Check como uma estrutura de trabalho completa.

Cenário Organizacional de Exemplo

Uma empresa de serviços financeiros conduziu um projeto Salesforce por nove meses sem um Go Live. Na auditoria, verificou-se que o Scope havia aumentado três vezes em relação ao planejamento original, que a equipe técnica havia construído três versões diferentes do mesmo processo de aprovação sem documentar o porquê, e que os usuários-chave já haviam migrado para gerenciar o relatório mensal em uma planilha separada.

O plano de diagnóstico de dez dias revelou que o problema principal não era técnico: a equipe técnica recebeu requisitos contraditórios de dois gerentes diferentes sem que ninguém coordenasse entre eles. A decisão foi por um Refactor parcial, não um Reset completo, porque a maior parte do código estava correta. A primeira fase focou apenas no processo de aprovação, que era a principal fonte de frustração, e em cinco semanas uma versão estável que os gerentes aprovaram em conjunto foi lançada. Somente então a expansão dos demais processos continuou.

A lição principal: a paralisação não foi resultado de uma falha técnica pontual, mas da ausência de uma única entidade que detivesse o mapa completo das decisões. Esse papel, mesmo que temporário, geralmente faz a diferença entre um projeto que é bem-sucedido pela segunda vez e um que volta a estagnar.

Checklist Antes de Tomar uma Decisão de Resgate

• ☐ Diagnóstico de 10 dias realizado com entrevistas, revisão do Org e comparação com documentos originais
• ☐ Problemas claramente classificados em Scope, arquitetura ou confiança
• ☐ Decisão documentada de Reset/Refactor com justificativas
• ☐ Um processo único selecionado para o primeiro ciclo com base em uma dor real dos usuários
• ☐ Change Freeze definido para o período de diagnóstico e decisão
• ☐ Métricas de Baseline estabelecidas antes do início da correção
• ☐ Plano de comunicação contínua para usuários e direção existente
• ☐ Um Owner único nomeado que detém o mapa de todas as decisões
• ☐ O plano de 90 dias inclui marcos mensuráveis e não apenas uma data de conclusão
• ☐ Processo definido para entrega de Governança e manutenção ao final do resgate

Fontes Profissionais

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
• HPI Pro – Suporte e Acompanhamento — https://hpi.pro/support