Critérios de aceitação: como um fundador não-técnico define o pronto
Critérios de aceitação, reescritos para quem paga pelo software, não para quem o constrói. Uma forma em linguagem simples de definir o “pronto” de cada funcionalidade que você encomenda, acordada antes de o trabalho começar, para que o dia da entrega seja uma inspeção e não uma discussão.
Uma fundadora com quem trabalhei no ano passado tocava uma firma boutique de contabilidade. Ela pagava um estúdio para construir um portal do cliente, e a especificação dizia, por inteiro: “Clientes conseguem subir as notas fiscais do mês.” Todos concordaram. Três semanas depois a funcionalidade estava “pronta”. O cliente conseguia subir um arquivo. Um arquivo. Sem jeito de saber a que mês ele pertencia, sem confirmação de que tinha chegado, sem limite de tamanho, e um PDF acima de dez megabytes falhava em silêncio. Ela achava que tinha comprado uma caixa de entrada de notas. Tinha comprado um seletor de arquivos. Ninguém mentiu. A frase que ela aprovou simplesmente não era uma definição de pronto.
Critérios de aceitação são as condições que um software precisa cumprir antes de você concordar que ele está terminado e correto. Eles transformam um pedido vago de funcionalidade numa lista curta de coisas que são verdadeiras ou falsas no dia da entrega. Em times ágeis, costumam ser escritos por product managers numa sintaxe rígida. Para um fundador não-técnico comprando um desenvolvimento sob medida, esse enquadramento é o errado. Você não está escrevendo tickets para um time que gerencia. Está definindo o que está pagando, para pessoas que não gerencia, de modo que “pronto” signifique a mesma coisa para elas e para você.
Por que “pronto” é a palavra mais cara do seu projeto
A lacuna que pegou minha fundadora da contabilidade é a lacuna entre o que uma funcionalidade parece numa reunião e o que ela precisa de fato fazer por uma pessoa real. “Clientes conseguem subir as notas do mês” é um desejo. Soa completo porque você consegue imaginar. Mas um desenvolvedor não constrói uma imagem. Ele constrói a instrução literal, e onde a instrução para, ele faz um palpite razoável. O palpite razoável dele é moldado pelo que é mais rápido de entregar, porque ele também tem prazo. O seu palpite razoável é moldado pelo que o seu cliente precisa. Esses dois palpites quase nunca são o mesmo, e a diferença aparece no pior momento possível: quando o trabalho é “entregue” e o pagamento é devido.
Essa é a discussão de dia de entrega que todo fundador não-técnico acaba tendo. Você diz “não era isso que eu queria”. O estúdio diz “isso é o que estava escrito”. Os dois estão certos, e agora você está negociando um retrabalho sem nenhuma vantagem, porque a coisa para a qual você aponta nunca foi escrita de uma forma que alguém pudesse checar. Critérios de aceitação são como você evita essa conversa. Eles movem a discordância para o começo, quando ela custa um e-mail em vez de um marco de pagamento.
O que critérios de aceitação não são
Eles não são o documento de requisitos. O documento de requisitos diz o que construir e por quê. Os critérios de aceitação dizem como você vai saber que cada parte foi construída corretamente. O primeiro é o pedido; o segundo é o recibo contra o qual você confere.
Eles também não são o teste de aceitação do usuário, embora os dois sejam confundidos o tempo todo. Os critérios de aceitação são escritos antes do desenvolvimento, como uma definição. O teste de aceitação do usuário é o processo no fim, em que você senta e verifica se os critérios foram cumpridos. Você escreve os critérios uma vez; roda o teste contra eles depois. Sem os critérios, o teste é só você clicando por aí torcendo para notar o que está errado, que é como fundadores aprovam software que quebra na primeira semana em que um cliente real encosta.
E eles não substituem decidir o que construir, antes de tudo. Se você não fez o trabalho de priorização de features, escrever critérios de aceitação para quarenta funcionalidades só produz quarenta coisas bem especificadas que você não pode pagar. Critérios vêm depois de você ter decidido que uma funcionalidade vale a pena, não no lugar dessa decisão.
As quatro perguntas que transformam um desejo em critério
Você não precisa de Gherkin, de “Given-When-Then” nem de nenhuma sintaxe formal que os blogs de ágil vão te empurrar. Essa sintaxe existe para ajudar engenheiros a automatizar testes, e você não está automatizando testes. Você precisa de critérios que consiga ler e checar sozinho. Aqui está o teste que dou a todo fundador não-técnico antes de ele aprovar uma funcionalidade. Passe cada critério proposto por quatro perguntas.
Um: é sobre uma pessoa fazendo algo, e não uma qualidade que o software tem? “O portal é amigável” não é verificável. “Um cliente consegue subir uma nota e achar de novo no mês seguinte” é. Escreva critérios como ações que um usuário real faz, com um resultado que ele consiga ver. Qualidades como rápido, limpo e intuitivo são opiniões; ações são fatos.
Dois: você consegue checar sozinho, sem o desenvolvedor na sala? Se verificar um critério exige que a pessoa que o construiu explique por que aquilo conta como pronto, não é um critério. É a opinião dela vestida de critério. O ponto inteiro é que você consiga sentar sozinho e dar o veredito: passou ou não passou. Se não consegue, reescreva até conseguir.
Três: é binário? Um critério tem exatamente dois resultados: passou ou não passou. “Ficou bom” tem infinitos resultados e, portanto, não vale nada no dia da entrega. “Uma nota subida mostra o mês em que foi arquivada, e um arquivo acima de dez megabytes mostra um erro em vez de falhar em silêncio” acontece ou não acontece. No momento em que um critério precisa de um julgamento, quebre-o nas coisas específicas que você estava de fato julgando.
Quatro: foi acordado antes do desenvolvimento? Um critério inventado na entrega é uma renegociação, não um padrão. Toda a vantagem dos critérios de aceitação vem de acordá-los na frente e prendê-los ao que você está pagando. Um critério que você adiciona depois de o trabalho estar pronto é um favor que você está pedindo, e você vai pagar por ele como tal.
A regra de bolso por trás das quatro: um bom critério de aceitação é aquele que você poderia entregar a um estranho, e ele conseguiria te dizer passou ou não passou sem fazer uma única pergunta. Se um estranho precisaria perguntar “o que significa pronto aqui”, o seu desenvolvedor também vai precisar, e ele vai responder por você do jeito que entregar mais rápido.
Como critérios de aceitação ficam na prática
Pegue a funcionalidade de notas que começou isto. “Clientes conseguem subir as notas do mês” é o desejo. Passe pelas quatro perguntas e ele vira uma lista curta e verificável:
- Um cliente logado consegue subir uma nota em PDF ou imagem e marcá-la a um mês específico.
- Depois de subir, o cliente vê a nota numa lista daquele mês, com o nome do arquivo e a data.
- Um arquivo maior que dez megabytes é recusado com uma mensagem visível, não com uma falha em silêncio.
- O cliente consegue apagar uma nota que subiu por engano, e ela some da lista.
- A equipe da firma consegue ver as notas de todos os clientes de um dado mês numa única tela.
Nenhuma dessas frases menciona código. Cada uma delas é algo que a fundadora consegue sentar e checar em cinco minutos, sozinha, no dia da entrega. Esse é o teste inteiro. Repare que a lista também fez algo mais silencioso: ela trouxe à tona decisões que ninguém tinha tomado ainda. A equipe deve ver as notas numa tela só? O cliente pode apagar? Essas perguntas são muito mais baratas de responder agora, por escrito, do que depois que um desenvolvedor já chutou as respostas.
Cinco frases simples não são trabalho extra. São o trabalho que você ia fazer de qualquer jeito, movido para o único ponto do projeto em que ainda é barato.
Onde os critérios de aceitação encontram o dinheiro
Esta é a parte que os blogs de ágil nunca cobrem, porque os leitores deles não são quem assina a fatura. Para um fundador, critérios de aceitação não são um capricho de documentação. São a definição de quando um pagamento é devido.
Um contrato de desenvolvimento de software bem estruturado prende os pagamentos por marco à aceitação, não a datas de calendário. “A fase dois é paga quando o módulo de notas passa nos seus critérios de aceitação” é uma frase limpa e exequível. “A fase dois é paga em 30 de junho” paga por tempo, funcione a coisa ou não. Se os seus critérios são vagos, os seus marcos são vagos, e você está efetivamente pagando por atividade em vez de resultados. Critérios apertados são o que deixa você pagar por resultados sem microgerenciar o desenvolvimento, que é a razão inteira de um fundador não-técnico contratar um parceiro em vez de um time que ele tem de ficar vigiando.
É por isso, também, que um estúdio competente vai receber bem os seus critérios em vez de resistir a eles. Aceitação vaga é tão perigosa para quem constrói quanto para você: a pessoa nunca sabe quando terminou, e o “pronto” fica se mexendo. Critérios claros protegem os dois lados. Um parceiro que reluta em escrever o que “pronto” significa está te dizendo algo sobre como ele pretende definir isso mais tarde.
Onde os fundadores erram nos critérios de aceitação
O primeiro erro é escrever critérios demais. Você não precisa de critério para todo comportamento concebível. Precisa para o punhado de coisas que, se saíssem erradas, deixariam a funcionalidade inútil ou vergonhosa. Cinco critérios afiados no módulo de notas valem mais que cinquenta que ninguém vai checar. Critérios de aceitação que você não verifica não são critérios; são decoração.
O segundo erro é esconder requisitos dentro deles. Um critério descreve uma condição que a funcionalidade acordada precisa cumprir. Não é o lugar de contrabandear funcionalidade nova que você esqueceu de pedir. Se “clientes recebem um e-mail quando a nota é aprovada” nunca esteve no escopo, isso é uma mudança, e pertence a uma conversa sobre escopo, não a um checklist de aceitação apresentado na entrega.
O terceiro, e mais comum, é aceitar “ficou bom” de você mesmo. O fundador que passa o olho numa demo, vê o caminho feliz funcionar uma vez e dá o aval é o fundador que descobre a falha silenciosa de dez megabytes quando um cliente real esbarra nela. Aceitação é uma inspeção. Rode cada critério, inclusive os feios, sobre o que acontece quando algo dá errado. Os critérios sobre falha costumam ser os que separam um software que você pode pôr na frente de um cliente pagante de um software que só fica bonito na demo.
Perguntas frequentes
Qual é um exemplo de critério de aceitação?
Para uma funcionalidade como “clientes conseguem subir notas”, um critério de aceitação útil é: “Um cliente logado consegue subir um PDF, marcá-lo a um mês e vê-lo na lista daquele mês depois; um arquivo acima de dez megabytes é recusado com uma mensagem visível.” Ele nomeia uma ação real de usuário e um resultado que você verifica sozinho, com dois desfechos claros: funciona ou não funciona.
Quais são exemplos de critérios de aceitação para um fundador não-técnico?
Bons exemplos são sempre frases simples sobre uma pessoa fazendo algo e vendo um resultado: um usuário consegue redefinir uma senha esquecida e entrar com a nova; um admin consegue exportar os pedidos do mês para uma planilha; um cliente que digita um cartão inválido vê um erro e não é cobrado. Evite exemplos escritos em sintaxe de código. Você precisa de critérios que consiga ler e checar, não de critérios feitos para automação de testes.
Quais são os três C’s dos critérios de aceitação?
Na prática ágil, os três C’s são Card, Conversation e Confirmation (cartão, conversa e confirmação): a funcionalidade num cartão, a discussão sobre o que ela significa e a confirmação de que funciona. Para um fundador comprando um desenvolvimento, a tradução útil é: escreva a funcionalidade, converse sobre o que “pronto” significa antes de o trabalho começar e confirme contra essa definição na entrega. O passo da confirmação é o que os fundadores pulam, e é o que custa caro.
Quem escreve os critérios de aceitação, o fundador ou o desenvolvedor?
Rascunhe-os você mesmo, com as suas palavras, porque eles codificam o que o seu cliente precisa e só você sabe disso. Depois entregue-os ao seu parceiro de desenvolvimento e deixe que ele afine as arestas técnicas e sinalize qualquer ambiguidade. Critérios escritos só por quem constrói tendem a descrever o que é fácil de construir; critérios escritos só pelo fundador tendem a perder os casos de borda. A versão acordada, fechada antes do desenvolvimento, é a que protege você.
Critérios de aceitação são o seguro mais barato de um desenvolvimento sob medida. Um punhado de frases simples, acordado antes de alguém escrever código, é o que fica entre você e a discussão de dia de entrega em que você já pagou e perdeu a sua vantagem. Defina o “pronto” enquanto ele ainda custa um e-mail. O estúdio que leva os seus critérios a sério é o que vale a pena manter.