Como Ler Esta Lista
As dez falhas a seguir não estão organizadas por frequência, mas sim pela ordem cronológica de sua ocorrência no ciclo de vida de um projeto. Para cada uma, apresentamos três elementos: o sinal precoce que pode ser identificado em tempo real, a ação preventiva e o estágio a partir do qual a correção se torna significativamente mais cara. A ideia é simples — a maioria dessas falhas custa muito pouco se abordada nas duas semanas certas.
1. Começar com uma Lista de Funcionalidades em Vez de um Processo
O Sinal: O documento de requisitos é estruturado como uma tabela de capacidades desejadas, e nenhuma linha descreve um resultado de negócio.
O Que Acontece na Prática: O projeto gera um sistema que atende à lista, mas não altera a forma de trabalho. Um ano depois, a gerência pergunta o que mudou, e não há uma resposta mensurável.
Prevenção: Para cada requisito, associe o processo que ele atende e a métrica que ele deve impactar. Requisitos sem resposta para essas duas perguntas são movidos para uma lista de espera. O conjunto de entregáveis que evita esse padrão está detalhado no Guia de Descoberta de CRM.
2. Não Ter um Único Dono de Processo (Process Owner)
O Sinal: Quatro pessoas do mesmo departamento comparecem às reuniões, e nenhuma delas está autorizada a dizer "assim será".
O Que Acontece na Prática: Cada decisão é resolvida por um compromisso que tenta agradar a todos, resultando na construção de dois caminhos em vez de um. O sistema se torna duas vezes mais complexo do que o necessário.
Prevenção: Para cada processo, atribua o nome de uma única pessoa. A divisão de papéis recomendada está detalhada no Guia de Papéis da Equipe de Projetos Salesforce.
3. Empurrar Decisões Arquitetônicas para o Final
O Sinal: A equipe avança na construção de telas enquanto a pergunta "qual é a fonte de verdade para o cliente" ainda está em aberto.
O Que Acontece na Prática: Quando a decisão finalmente é tomada, ela contradiz o que foi construído. Parte do trabalho é descartada, e a estimativa inicial do projeto já não é relevante.
Prevenção: Identifique no início do projeto as três a cinco decisões mais caras de mudar — modelo de dados central, fonte de verdade, modelo de permissões — e estabeleça uma data de decisão para elas antes de iniciar a construção.
4. Importar a Dívida Técnica do Sistema Legado
O Sinal: A especificação de migração contém todos os campos do sistema anterior, incluindo aqueles cujo nome termina em "_old_2".
O Que Acontece na Prática: A nova plataforma nasce com duzentos campos que ninguém mantém, relatórios que dependem de dados não confiáveis e usuários que concluem que o novo sistema também não é sério.
Prevenção: Cada campo a ser migrado deve ter um proprietário e um uso comprovado no último ano. O restante vai para um arquivo legível, não para o sistema ativo.
5. Medir o Progresso por Histórias Concluídas
O Sinal: O relatório semanal mostra altas porcentagens de conclusão, mas ninguém conseguiu executar um processo completo de ponta a ponta.
O Que Acontece na Prática: O projeto parece um sucesso no gráfico até a semana anterior ao Go Live, quando se descobre que todas as partes funcionam individualmente, mas ninguém testou a conexão entre elas.
Prevenção: Defina um marco de "primeiro processo completo de ponta a ponta" o mais cedo possível, mesmo que cubra apenas um cenário. Até que isso seja alcançado, as porcentagens de conclusão não são informações relevantes.
6. Campos Obrigatórios como Substitutos para Disciplina de Dados
O Sinal: A tela de criação de registro inclui doze campos obrigatórios, sendo que três deles ninguém sabe quem deveria conhecer seus valores.
O Que Acontece na Prática: Os usuários selecionam o primeiro valor da lista para prosseguir. Os relatórios recebem dados completamente preenchidos, mas também completamente incorretos.
Prevenção: A obrigatoriedade é imposta apenas a campos necessários para uma decisão no ponto em que são solicitados. Campos necessários em etapas posteriores do processo são tornados obrigatórios nessas etapas.
7. Construir Automação Antes que o Processo Seja Estável
O Sinal: Existem três mecanismos de automação operando no mesmo objeto, e ninguém sabe a ordem de execução entre eles.
O Que Acontece na Prática: Efeitos colaterais inesperados, loops de atualização e, principalmente, incapacidade de alterar um processo sem o medo de que algo se quebre.
Prevenção: Execute um processo manual ou semi-manual por várias semanas antes de automatizá-lo. A automação fixa uma decisão — é importante que a decisão seja correta.
8. UAT Realizado por Quem Construiu
O Sinal: Os roteiros de teste foram escritos pela mesma equipe que desenvolveu, e cobrem principalmente o caminho feliz.
O Que Acontece na Prática: Os defeitos que chegam à produção são justamente os casos excepcionais — cancelamentos, estornos, cliente duplicado, usuário que saiu no meio de um processo.
Prevenção: Os testes são realizados pelas pessoas que executam o processo, com dados semelhantes aos dados reais, e com responsabilidade definida para aprovar ou rejeitar.
9. Treinamento como Evento Único
O Sinal: O plano de implementação inclui dois workshops na semana anterior ao Go Live, e nada depois disso.
O Que Acontece na Prática: Os usuários aprendem telas, e não o processo, esquecem em duas semanas e recorrem a colegas ou a uma planilha Excel. A taxa de uso diminui gradualmente sem que ninguém perceba.
Prevenção: Treinamento por função, o mais próximo possível do momento em que o funcionário realmente realizará a ação, com um ponto de suporte disponível nas primeiras semanas.
10. Falta de Proprietário Após o Go Live
O Sinal: No plano do projeto, não há uma linha que descreva quem gerencia o sistema no terceiro mês.
O Que Acontece na Prática: Solicitações de mudança se acumulam sem resposta, pequenos defeitos se transformam em trabalho alternativo e o sistema se torna obsoleto rapidamente.
Prevenção: Defina a propriedade operacional, um mecanismo de recepção de solicitações e um ritmo de liberação regular antes do Go Live, e não depois. Em grandes organizações, isso geralmente é feito através de um modelo de governança estruturado, conforme descrito no Guia de Implementação do Salesforce em Organizações Enterprise.
Custo da Correção por Estágio
| Falha | Correção na Descoberta | Correção na Construção | Correção Após o Go Live |
|---|---|---|---|
| Modelo de dados incorreto | Alteração no diagrama | Reconstrução do objeto | Migração interna e retrabalho completo |
| Ausência de Proprietário de Processo | Nomeação | Paralisações e decisões repetidas | Processo duplicado, mantido indefinidamente |
| Dívida técnica do sistema legado | Filtragem da lista de campos | Limpeza antes do carregamento | Limpeza em sistema ativo |
| Campos obrigatórios desnecessários | Decisão no planejamento da tela | Alteração na configuração | Limpeza de dados incorretos acumulados |
| Ausência de Proprietário Operacional | Definição no plano | Recrutamento ou treinamento | Recuperação da confiança dos usuários |
Exemplo Ilustrativo: Uma Companhia de Seguros de Médio Porte
O cenário é hipotético e serve para ilustração. Uma companhia de seguros lançou o Salesforce para gerenciamento de agentes. Três meses depois, descobriu-se que a taxa de atualização dos registros dos agentes era baixa. A investigação não encontrou um único defeito técnico: foram encontradas três das falhas acima simultaneamente — campos obrigatórios desnecessários na tela de criação, ausência de um proprietário para o processo de recrutamento de agentes e treinamento realizado dois meses antes de os primeiros novos agentes entrarem no sistema.
A correção não foi técnica. Seis campos obrigatórios foram removidos, um único proprietário de processo foi nomeado do departamento de operações, e o treinamento foi dividido em segmentos curtos enviados na semana em que cada grupo começou a trabalhar. A única mudança arquitetônica necessária foi adiar a obrigatoriedade de dois campos para uma fase posterior do processo.
O Que Fazer Com Esta Lista
Revise as dez falhas e marque para cada uma se o sinal precoce existe atualmente em seu projeto. Três ou mais sinais em um projeto que ainda não foi lançado são um motivo para uma breve pausa e correção, não para aceleração. Os mesmos três sinais em um sistema que já está no ar justificam um diagnóstico sistemático antes de adicionar novas funcionalidades sobre uma base instável.