Erros de requisito são os mais caros de corrigir, e o custo sobe a cada etapa em que passam despercebidos. Na leitura de Jean Pierre Lessa e Santos Ferreira, especialista em tecnologia e software, a falha de escopo raramente nasce de um documento mal escrito.
A falha nasce de uma conversa que terminou cedo demais. Todo mundo sai da reunião com a sensação de acordo, cada um levando uma versão diferente do que seria entregue, e a diferença só aparece quando o software já está pronto.
O caso a seguir é fictício, mas o desenho se repete em empresas de qualquer porte. Ele vale menos pelo desfecho e mais pelo ponto exato em que o escopo se perdeu, que quase nunca é onde a discussão sobre responsabilidade costuma parar.
O pedido que parecia claro
Uma varejista pede ao time interno um módulo de devolução parcial: o cliente devolve dois itens de um pedido com cinco e recebe o valor proporcional. O requisito cabe em uma linha, foi aprovado em uma reunião e entrou na fila de desenvolvimento.
Três meses depois, o módulo funciona exatamente como descrito. E não pode ser usado. O financeiro precisa emitir nota de crédito parcial, algo que o cadastro fiscal não previa, e o estoque precisa separar item avariado de item revendável antes de dar baixa.
Jean Pierre Lessa e Santos Ferreira observa que casos assim raramente têm um culpado isolado. O pedido estava correto do ponto de vista de quem o escreveu: descrevia o comportamento visível na tela, que era tudo o que aquela área conhecia do processo.
Quando o pedido já vem com a solução?
Devolução parcial não é uma necessidade, é uma solução. A necessidade estava atrás dela: reduzir o volume de trocas totais, voltando ao centro de distribuição. Quem recebe a solução pronta não pergunta pelo problema, e é no problema que moram as regras fiscais e de estoque.
A correção é banal e quase nunca feita: perguntar o motivo antes do formato. Uma pergunta sobre o que acontece hoje sem o recurso, e outra sobre quem mais toca aquele processo depois, teriam trazido o financeiro e o estoque para a mesma mesa.
Critério de aceite é o que transforma texto em teste
Requisito sem critério de aceite é opinião. Jean Pierre Lessa e Santos Ferreira explica que o critério descreve, em linguagem verificável, o que precisa acontecer para a entrega ser considerada pronta, incluindo os casos que ninguém quer discutir na reunião de abertura, como a devolução de um item em promoção ou de um pedido já faturado.
Ainda assim, o critério abstrato não protege ninguém. Ele funciona quando vem com exemplo concreto, com valores reais, mostrando o que o sistema deve fazer diante de um pedido específico e de uma devolução específica.
Exemplos assim expõem divergência antes do código. Quando o time escreve o caso da devolução de dois itens com nota fiscal já emitida, alguém do financeiro contesta o valor esperado, e a discussão acontece em uma tarde, não em três meses.
Mudança de escopo não é descoberta de escopo
Nem toda alteração no meio do projeto é falha de planejamento. Existe mudança de escopo quando o negócio decide algo novo, e existe descoberta de escopo quando aparece uma regra que sempre existiu e ninguém havia enunciado até ali.
Tratar as duas do mesmo jeito produz o pior dos mundos. A descoberta vira negociação de contrato, o time passa a esconder o que aprendeu para não abrir discussão, e o requisito segue incompleto até o momento em que quebra em produção.
Escopo é acordo entre pessoas, não anexo de contrato
Documento de requisito não cria entendimento, apenas registra o entendimento que já existe. Duas áreas que não conversaram assinam o mesmo texto e seguem com leituras diferentes dele, porque cada uma completa as lacunas com o que conhece do próprio processo.
Reduzir falha de escopo é reduzir a distância entre quem pede e quem constrói. É por isso que Jean Pierre Lessa e Santos Ferreira conclui que é mais útil perguntar, ainda na primeira reunião, quem mais depende daquele recurso funcionar. A resposta costuma trazer duas áreas que ninguém havia convidado.
