A Resposta Curta
Uma boa "story" no Salesforce descreve quem, o que ele tenta alcançar e o que estará certo após a ação – e não qual campo aparecerá em qual tela. O teste simples: se os critérios de aceitação podem ser escritos sem saber se a implementação será via Flow, Validation Rule ou Apex, a "story" está bem formulada.
A falha comum é uma "story" que já contém a solução. No momento em que se escreve "Adicionar campo Picklist à tela da oportunidade", a discussão sobre o processo é encerrada antes mesmo de começar.
Estrutura Eficiente
| Componente | Função | Teste de Qualidade |
|---|---|---|
| Contexto | Quem é o usuário e quando ele atua | Um papel real, não "usuário" |
| Intenção | O que ele tenta alcançar | Expressa na linguagem do negócio |
| Critérios de Aceitação | O que será verificado | Pode ser executado como um cenário com dados de teste |
| Casos de Canto | O que falha intencionalmente | Pelo menos um negativo |
| Fora do Escopo | O que explicitamente não está incluído | Evita discussões na aceitação |
A última linha economiza a maioria dos conflitos. Uma declaração explícita de que o que não está incluído realmente não está incluído vale mais do que três parágrafos de descrição.
Decomposição: "Vertical Slice" em vez de Camadas
A tentação em um projeto de CRM é decompor por componentes técnicos – primeiro o modelo de dados, depois as automações, por fim os relatórios. O resultado é que não há nada para mostrar até o fim, e ninguém sabe se o processo funciona.
A decomposição correta é vertical: um cenário completo, ponta a ponta, para um perfil de usuário. Uma única oportunidade que é aberta, avança, é fechada e aparece em um relatório – vale mais do que dez objetos definidos sem um processo. Posteriormente, adicionam-se perfis e cenários em torno da mesma estrutura.
Priorização Quando Tudo é Urgente
Três critérios são suficientes, nesta ordem:
- Bloqueia a entrada em produção? – Sem isso, o processo está incompleto. Não há espaço para negociação.
- Quantos usuários por dia? – A frequência supera a intensidade da reclamação. Um item que afeta 80 agentes diariamente tem prioridade sobre um pedido de um único gerente.
- Qual o custo da postergação? – O custo da implementação aumenta se fizermos isso após o lançamento? Uma mudança no modelo de dados sim, uma mudança em um relatório não.
O que não passa por esses três vai para o "Parking Lot". Essa separação impede que o Backlog se transforme em um arquivo de desejos. A profundidade da gestão de mudanças de escopo está em Desvio de Escopo (Scope Creep) e Controle de Mudanças no Salesforce.
Débito de Requisitos: A Falha Silenciosa
O débito de requisitos surge quando uma "story" é fechada sem que se decida o que acontece em um caso de canto – fica-se com "resolveremos isso depois". Após o lançamento, esses casos de canto são a maioria das chamadas de suporte.
A restrição simples: um item não é fechado sem uma decisão documentada para cada pergunta aberta registrada, mesmo que a decisão seja "intencionalmente não tratamos". A documentação da renúncia vale mais do que a ausência de documentação.
Conexão com os Testes
Critérios de aceitação bem escritos são, na verdade, os roteiros de UAT. Quando são escritos após o desenvolvimento, o UAT se torna uma demonstração do que foi construído, em vez de uma verificação do que foi solicitado. A sequência é detalhada no Guia de UAT para Salesforce.
Resumo
Um Backlog de qualidade não é longo, mas claro: cada item indica para quem se destina, o que será medido como sucesso e o que explicitamente não está incluído. Essas três perguntas, feitas antes da construção e não depois, determinam quase toda a qualidade da aceitação no final do projeto.