Do problema de negócio à tela: como transformamos um requisito em solução

Quando um gerente nos diz “preciso controlar melhor o crédito”, ele não está pedindo uma tela. Está descrevendo um problema de negócio: clientes que não pagam, expedições que saem sem respaldo, contas a receber que crescem. Nosso trabalho é transformar esse problema em algo que o sistema possa fazer, verificar e medir.

As quatro camadas

1. Requisito de negócio (o “para quê”). O objetivo, na linguagem da empresa. “Reduzir as contas a receber vencidas sem frear as vendas.”
2. Regras de negócio (o “que se decide”). As políticas que a empresa define. “Não se expede para um cliente que ultrapassa seu limite de crédito, salvo autorização do Crédito.”
3. Requisitos funcionais (o “que o sistema faz”). Comportamentos concretos e verificáveis. “Ao confirmar um pedido a prazo, o sistema calcula a exposição do cliente e, se ultrapassar o limite, deixa o pedido retido.”
4. Critérios de aceitação (o “como sabemos que funciona”). Casos de teste escritos antes de programar.

Pular uma camada é a causa mais comum de projetos que “funcionam” mas não resolvem nada.

Como fazemos

• Ouvimos o problema, não a solução. Se o usuário pede “um botão para bloquear clientes”, perguntamos por quê. Quase sempre há uma regra mais geral por trás.
• Escrevemos a regra com a empresa. As regras são decididas pelo negócio. Nós as tornamos explícitas, com suas exceções e quem as aprova.
• Descemos ao funcional com exemplos. Cada requisito funcional traz exemplos concretos com números reais.
• Definimos a aceitação antes de programar. Com desenvolvimento guiado por testes, cada regra tem seu teste automatizado desde o início.
• Validamos com o usuário-chave no sprint. Não no fim do projeto: a cada entrega de duas a quatro semanas.
• Medimos. O requisito de negócio tinha um objetivo; depois da entrada em operação, revisamos o indicador.

Caso 1: um atacadista que vendia a prazo sem controle

Problema de negócio. Os vendedores tiravam pedidos a prazo sem saber quanto o cliente devia; as contas a receber vencidas cresciam e o Crédito ficava sabendo tarde.

Regras de negócio.

• Cada cliente tem um limite de crédito.
• A exposição é o que o cliente já deve mais o pedido que está sendo confirmado.
• Se a exposição ultrapassa o limite, o pedido fica retido; só alguém com permissão pode liberá-lo.
• Os adiantamentos do cliente são descontados ao faturar o pedido.

Requisitos funcionais.

• Ao confirmar um pedido a prazo, calcular a exposição e compará-la com o limite.
• Se exceder, marcar o pedido como retido e avisar o Crédito.
• Um pedido retido não pode ser expedido nem faturado.
• Ao faturar, aplicar automaticamente o adiantamento do cliente.

Critério de aceitação (exemplo). Dado um cliente com limite de Bs 50.000 e Bs 42.000 de dívida, quando o vendedor confirma um pedido de Bs 12.000, então o pedido fica retido, o Crédito recebe o aviso e o botão de expedição é bloqueado.

Caso 2: uma importadora que não conhecia seu custo real

Problema de negócio. O preço de venda era calculado sobre o valor da fatura do fornecedor, sem frete, seguro, alfândega nem despesas locais. Alguns produtos eram vendidos com prejuízo sem que ninguém percebesse.

Regras de negócio.

• O custo de um produto importado inclui todas as despesas da importação.
• Cada despesa é rateada entre os produtos segundo uma base definida: valor, peso, volume ou quantidade.
• O custo final é conhecido ao fechar o processo de importação.

Requisitos funcionais.

• Um processo de importação agrupa as faturas do fornecedor e todas as despesas associadas.
• Cada despesa escolhe sua base de rateio.
• Ao liquidar, o sistema calcula o custo unitário final de cada produto e atualiza o custo do estoque.
• A partir do custo final, é sugerido um preço de venda conforme a margem desejada.

Critério de aceitação (exemplo). Dado um embarque com dois produtos de mesmo valor e pesos diferentes, quando o frete é rateado por peso, então o produto mais pesado absorve mais frete e seu custo unitário reflete isso.

Por que isso importa

Um requisito bem traduzido para o funcional pode ser testado, pode ser mantido e pode ser medido. Um mal traduzido termina em personalizações que ninguém entende um ano depois.

Os dois casos deste artigo viraram fluxos do MKA; o primeiro pode ser percorrido na demo de pedidos e expedições.