Uma iniciativa digital pode estar tecnicamente implantada e, ainda assim, não estar pronta para ser aprovada pela área de negócio. Também pode acontecer o contrário: o resultado parece útil, mas deixa sem solução uma dependência, uma permissão ou uma exceção importante. A causa costuma ser as partes usarem a palavra «concluído» com significados diferentes.
Definir critérios de aceitação antes de começar permite combinar qual resultado se espera, como ele será verificado e quem terá autoridade para validá-lo. Isso não substitui a definição do escopo nem os testes técnicos: conecta a necessidade de negócio a uma decisão de aceitação observável. Essa estrutura ajuda as pessoas responsáveis por produto, negócio e tecnologia a reduzir divergências e identificar lacunas antes da entrega.
Separe objetivos, escopo e critérios de aceitação
Esses três elementos respondem a perguntas diferentes. O objetivo explica por que o trabalho está sendo realizado e qual mudança se busca. O escopo delimita o que será abordado e o que ficará de fora. Os critérios de aceitação descrevem as condições verificáveis para decidir se um resultado específico atende ao que foi acordado.
Por exemplo, um objetivo poderia ser facilitar a consulta dos clientes ao status de seus pedidos. O escopo pode incluir uma tela de consulta de pedidos ativos, mas excluir a alteração do endereço de entrega. Um critério de aceitação poderia especificar que, ao inserir um identificador válido, o status correspondente e a data de atualização sejam exibidos. O exemplo não determina como construir a tela nem define, por si só, todo o projeto: delimita uma condição que deve ser possível verificar.
Antes de redigir os critérios, confirme que o objetivo é compreensível e que o escopo tem limites explícitos. Se uma necessidade não estiver incluída, não a deixe implícita. Esclarecê-la evita que uma expectativa posterior seja interpretada como defeito em uma entrega que nunca a contemplou.
Redija condições observáveis, não soluções prescritas
Um critério útil pode ser verificado por meio de uma ação, de um resultado observável ou de uma evidência acordada. Evite expressões como «fácil de usar», «rápido» ou «funciona corretamente» se o contexto do produto não deixar claro o que significam. São intenções válidas, mas permitem interpretações incompatíveis.
Em vez de «a consulta deve ser intuitiva», defina qual tarefa a pessoa usuária deve concluir e qual resultado confirma que ela a concluiu. Se o objetivo incluir desempenho, acessibilidade ou segurança, transforme cada expectativa em uma condição relevante para o caso e estabeleça como ela será avaliada. Não invente limites por conveniência: combine os valores com quem conhece a necessidade e as restrições.
Também é recomendável evitar impor uma solução técnica quando a área de negócio precisa apenas de um resultado. «Usar um botão azul» costuma ser uma decisão de design, não uma condição funcional de aceitação. Por outro lado, «a pessoa consegue iniciar a consulta na página de pedidos» descreve uma capacidade que pode ser validada sem restringir desnecessariamente as alternativas de implementação.
Uma redação prática pode incluir quatro componentes:
- Contexto: qual situação ou tipo de usuário está sendo considerado.
- Ação: o que deve acontecer ou qual tarefa deve ser possível realizar.
- Resultado: qual resposta, mudança ou informação se espera observar.
- Verificação: qual evidência permitirá confirmar o resultado.
Nem todos os critérios precisam da mesma estrutura. O importante é que negócio, produto e tecnologia consigam interpretá-los de forma consistente e indicar como diferenciar uma aceitação de um não cumprimento.
Inclua fluxos, exceções, permissões e dependências
O fluxo principal é um bom começo, mas geralmente não basta. Uma definição que cobre apenas o caso ideal pode deixar sem resposta o que acontece diante de dados inválidos, ausência de resultados, permissões insuficientes ou indisponibilidade de um serviço externo. Inclua os casos-limite que alterem o resultado esperado, o risco ou a decisão de aprovação.
Para identificar esses casos, percorra a experiência sob a perspectiva das pessoas usuárias e da operação:
- O que acontece se faltar um dado necessário ou se ele tiver um formato não aceito?
- Quais informações cada perfil pode consultar e quais ações não pode realizar?
- Como se informa que não há resultados ou que uma operação não pôde ser concluída?
- Qual dependência externa pode impedir a validação e quem deve resolvê-la?
- Existem estados intermediários, como uma solicitação pendente, que precisam ser diferenciados de uma confirmação?
Não é necessário enumerar todas as situações imagináveis. Priorize as exceções que afetem segurança, conformidade, continuidade operacional, experiência ou escopo. Se uma dependência não estiver disponível durante a aceitação, combine antecipadamente qual evidência alternativa será admissível e qual risco continuará pendente. Uma demonstração com dados preparados, por exemplo, não equivale automaticamente à validação de uma integração real; essa diferença precisa ficar clara.
Defina responsáveis e evidências antes de começar
Um critério sem responsável pela validação pode reabrir a discussão no fim. Para cada condição, identifique quem propõe a necessidade, quem realiza ou coordena a verificação e quem toma a decisão de aceitação. Em algumas equipes, essas funções cabem a pessoas diferentes; em outras, podem coincidir. O essencial é que a autoridade para aprovar não seja ambígua.
Defina também quais evidências servirão de base para a decisão: uma revisão do comportamento, um registro, uma demonstração, um resultado de teste ou a confirmação de uma pessoa responsável. A evidência deve corresponder ao critério. Uma captura de tela pode mostrar uma página, mas talvez não prove que as permissões estejam sendo aplicadas corretamente. Um teste técnico pode confirmar uma resposta, mas não necessariamente que a informação seja compreensível para o usuário previsto.
Um modelo breve para cada critério pode incluir:
- Identificador e descrição: condição única, concreta e sem termos vagos.
- Contexto e escopo: usuário, estado ou situação contemplada; exceções excluídas.
- Responsável pela aceitação: pessoa ou função que toma a decisão.
- Método e evidência: como será feita a verificação e onde o resultado ficará registrado.
- Status e observações: aceito, pendente ou não aceito, com justificativa e próxima etapa.
O modelo não deve se transformar em documentação por si só. Se o registro não ajudar a decidir, coordenar ou guardar as evidências, simplifique-o.
Gerencie mudanças e identifique ambiguidades
Os critérios podem mudar quando surgem novas informações. Para evitar surpresas, registre o que mudou, quem aprovou a mudança e quais efeitos ela tem sobre escopo, prioridade, dependências e data prevista. Diferencie um critério esclarecido — que explicita uma expectativa já acordada — de um novo critério que acrescenta um comportamento. O segundo pode ampliar o escopo e exige uma decisão, não uma alteração silenciosa da definição de concluído.
Antes de aceitar uma entrega, procure sinais de ambiguidade. Expressões como «deve estar completo», «conforme aplicável» ou «sem erros» não indicam o que verificar. Também são sinais de alerta os critérios que misturam vários resultados independentes, não têm responsável, dependem de terceiros sem um plano ou não especificam o que fazer em caso de falha. Separe as condições misturadas, detalhe o resultado e combine como as dependências serão tratadas.
Se negócio e tecnologia discordarem sobre um critério, retome a necessidade e o risco que ele procura atender. Pergunte qual evidência mudaria a decisão e qual alternativa alcançaria o objetivo sem impor uma solução prematuramente. Se a questão não puder ser resolvida antes do início, registre-a como uma decisão pendente, atribua um responsável e estabeleça quando deverá ser concluída. Não a esconda em uma frase genérica.
Um bom critério de aceitação não garante, por si só, o sucesso de uma iniciativa, mas torna a aprovação mais previsível. Quando cada condição expressa um resultado observável, tem um responsável e conta com evidências adequadas, as equipes podem identificar divergências mais cedo, separar defeitos de mudanças de escopo e decidir com mais clareza se algo está realmente concluído.