O poder do 'por quê?': requisitos que prescrevem soluções em vez de necessidade

Requisitos como decisões disfarçadas

Jason Gorman, fundador da Codemanship, argumenta que a maioria dos requisitos de software que desenvolvedores recebem não descreve uma necessidade real, mas sim uma decisão prévia sobre como resolver um problema. Quando alguém especifica que "o usuário selecionará o número da casa em uma lista suspensa", está impondo uma solução antes que a necessidade subjacente seja compreendida. Cada decisão desse tipo restringe as opções futuras e reduz o espaço de soluções disponíveis.

A árvore de decisões e o poder do "por quê?"

Gorman propõe visualizar decisões de design como uma árvore. É possível percorrê-la em três direções: para baixo, perguntando "como?" (execução); lateralmente, explorando alternativas no mesmo nível (exploração); e para cima, perguntando "por quê?" até chegar à raiz da decisão. No exemplo do endereço, subir na árvore revela que a necessidade real é garantir entregas em endereços válidos - não necessariamente usar uma lista suspensa. Segundo o autor, em 99% das vezes em que questionou requisitos sob pressão de prazo, descobriu que existiam opções mais rápidas e baratas, frequentemente sem envolver código.

Especificações como "algemas"

A frequência com que requisitos se revelaram decisões prematuras levou Gorman a adotar uma política pessoal: questionar todo requisito em uma especificação e rejeitar qualquer especificação em que a equipe de desenvolvimento não tenha participado diretamente. Ele passou a chamar documentos de requisitos de "algemas" (handcuffs), por limitarem a capacidade do time de encontrar soluções melhores.

Feedback, optionality e práticas ágeis

O modelo da árvore de decisões se conecta ao conceito de latência de feedback. Big Design Up-Front (BDUF) é caracterizado por alta latência: gasta-se muito tempo subindo na árvore errada antes de obter qualquer sinal do mundo real. Extreme Programming, por outro lado, adia decisões - especialmente as difíceis de reverter - o máximo possível, mantendo a optionality aberta. Gorman destaca que a prática de criar e liberar software em fatias finas, obtendo feedback contínuo, é compatível com preservar opções por mais tempo.

Abstrações e mock objects como ferramenta de design

Uma forma concreta de manter opções abertas é esconder o "como" atrás de abstrações. Interfaces descrevem o que um módulo deve fazer, permitindo adiar ou substituir a implementação. O processo de design orientado a testes outside-in, descrito no livro Growing Object-Oriented Software Guided By Tests de Steve Freeman e Nat Pryce, usa mock objects para definir contratos antes de comprometer-se com implementações. Gorman reforça que mocks foram originalmente concebidos como ferramenta de design, não de teste. Ele encerra observando que desenvolvedores tendem a ser orientados ao "como", mas é mito que não consigam subir na árvore de decisões e compreender as necessidades reais que impulsionam o design.