Quando o requisito está certo e o problema continua errado
Sistemas impecáveis fracassam quando atendem ao que foi pedido e erram o que dói — requisito não é problema, e a diferença começa na escuta.
Conheço um sistema que nunca falhou.
A impressora solta a senha na entrada, o painel chama em ordem, cada atendimento fica registrado com hora de início e fim, e no fim do mês o relatório sai impecável: tempo médio dentro da meta, nenhuma pendência, todos os indicadores verdes. Pelos critérios do contrato que o trouxe ao mundo, é um sucesso completo.
E todos os dias alguém sai daquela fila sem o que veio buscar.
A pessoa esperou, foi chamada, foi atendida com educação — e descobriu no guichê que faltava um documento que nenhum aviso mencionou, que o caso dela não cabe em nenhuma das opções do formulário, que o certo é voltar outro dia. O sistema mede a espera com precisão de segundos. A viagem perdida, ele não mede — ninguém pediu que medisse.
Requisito é o que foi pedido. Problema é o que dói. Para o primeiro, a engenharia de software tem toda a cerimônia: levanta, especifica, numera, testa, audita. Para o segundo, não existe rito nenhum. É assim que nascem os sistemas impecáveis que fracassam — projetos que passam em todos os testes porque os testes conferem a resposta certa para a pergunta errada.
Na gestão pública, esse desencontro tem forma física. O formulário perfeito existe: revisado pelo jurídico, aprovado pelo controle interno, com um campo para tudo — menos para o caso da pessoa que o segura. O protocolo que atende ao processo e falha na pessoa não é acidente; é o que acontece quando o processo vira o cliente. Noutro texto desta página contei o que é estar do outro lado dessa fila — descobrir que até o sofrimento precisa preencher etapas antes de ser atendido.
A dor de verdade não se levanta em reunião de requisitos. Ela se descobre em três gestos sem glamour nenhum. Perguntar de novo, porque a primeira resposta é quase sempre a solução imaginada, não a dor. Observar o uso, porque ninguém conta o que faz de verdade — mostra, desde que alguém se disponha a ficar ao lado e olhar. E desconfiar do pedido bem formulado: não porque quem pede esteja errado, mas porque quem pede já traduziu a dor para o vocabulário que imagina que a técnica entende. Traduzir de volta é a parte do trabalho que não aparece em edital.
O conferidor de encargos que construo em COBOL nasceu dessa tradução. O pedido bem formulado seria “uma planilha melhor” — a dor era outra: todo mês, um fiscal de contrato confere no braço, funcionário por funcionário, se salários e encargos das terceirizadas batem com o que a lei manda, num trabalho lento, repetitivo e sujeito a erro justamente onde erro custa caro. A planilha melhor atenderia o pedido e deixaria a dor intacta — só que mais bem formatada.
O Observatório de Oportunidades nasceu do movimento contrário: não havia pedido nenhum. Havia editais, prêmios e emendas vencendo sem que ninguém estivesse de plantão — uma dor que não doía em ninguém específico e por isso nunca virou requisito. Dor sem dono não escreve pedido; alguém precisa escutar o silêncio por ela.
Engenharia boa começa na escuta — antes do diagrama, antes da stack, antes da primeira linha. Não porque escutar seja gentileza, mas porque é o único jeito de saber qual dor precisa desaparecer. Descoberta a dor, o método faz o resto: requisito, teste, auditoria — a cerimônia inteira, enfim apontada para o lugar certo.
O painel do guichê vai continuar chamando as senhas em ordem, e o relatório do mês vai continuar verde. Sistema bom se mede em outro lugar: na viagem que ninguém precisou repetir, na etapa que o sofrimento não precisou preencher. A fila anda. A pergunta é se, do outro lado do vidro, alguém ainda escuta.