Quando um projeto entrega algo que ninguém queria, a conversa costuma virar procura de culpado. Mas boa parte desses casos nasce na primeira reunião, quando o cliente descreve a solução que imaginou em vez do problema que tem. "Preciso de uma tela onde o vendedor lança o pedido" é uma tela. Não é o problema.
O fornecedor constrói a tela, ela funciona como pedida, e o problema continua lá. Ninguém mentiu, ninguém errou, e mesmo assim o dinheiro foi gasto na coisa errada.
Por que pedir a solução dá errado
Quando você descreve a tela, três coisas se perdem no caminho.
O motivo. Sem saber para que serve, o fornecedor não consegue sugerir um caminho melhor. Ele vira executor de pedido, e você perde justamente a experiência que estava comprando.
As exceções. A tela que você imaginou funciona para o caso comum, porque foi ele que você tinha na cabeça. Os casos estranhos aparecem depois da entrega, e viram aditivo.
A medida de sucesso. Se o combinado é uma tela, ela fica pronta e o projeto "terminou". Se o combinado é um resultado, dá para verificar se aconteceu.
Vale dizer o óbvio: isso não é falha sua. Ninguém tem obrigação de saber descrever necessidade em linguagem de projeto. Tanto é assunto sério que existe norma técnica sobre isso, a ISO/IEC/IEEE 29148, e ela trata a definição de requisitos como trabalho conjunto entre quem pede e quem constrói. Nenhum dos dois lados consegue fazer sozinho, e é por isso que fornecedor que só anota pedido entrega o que foi pedido em vez do que era preciso.
O que um bom pedido precisa ter
Quatro elementos, e nenhum deles exige conhecimento técnico.
A situação de hoje, com números. "Três pessoas gastam duas horas por dia conferindo pedido, e passam cerca de dez erros por mês." Isso é mais útil que qualquer descrição de tela.
O que precisa ser verdade depois. "O pedido entra sem ninguém redigitar" ou "o número de margem existe até o dia 2". Resultado, não funcionalidade.
As exceções que você conhece. Cliente com tabela própria, produto que segue regra diferente, o caso que sempre trava. Esta é a parte que mais muda o preço e o prazo, e a que mais fica de fora.
O que não pode acontecer. Não pode parar o faturamento, não pode exigir que o vendedor use computador em campo, não pode depender do sistema antigo ser desligado. Restrições valem tanto quanto requisitos.
Com esses quatro, qualquer fornecedor decente consegue propor um caminho. Sem eles, cada um propõe uma coisa diferente, que é exatamente o que gera aquelas propostas incomparáveis.
Como levantar isso sem saber de tecnologia
O material bruto está na sua operação, e o método é conversa.
Acompanhe o processo uma vez, do começo ao fim. Não pergunte como funciona: sente do lado e veja. O que as pessoas descrevem e o que elas fazem raramente é igual, e não é má vontade. É costume.
Pergunte pelo que dá errado, não pelo que funciona. "O que costuma travar aqui?" traz mais informação que "me explica o processo". A dor lembra melhor que a rotina.
Anote as palavras exatas de quem executa. Quando a pessoa diz "aí eu tenho que conferir se o cliente é dos antigos", isso é uma regra de negócio disfarçada de comentário. Traduzir isso cedo demais faz perder a informação.
Pergunte o que acontece quando foge do padrão. É onde moram as exceções, e elas nunca aparecem na descrição inicial.
Nada disso é levantamento técnico. É prestar atenção na própria operação, e é o trabalho que mais determina se o projeto vai dar certo.
O sinal de que o pedido está bom
Existe um teste simples: dois fornecedores diferentes conseguiriam propor caminhos parecidos lendo o que você escreveu?
Se sim, você descreveu o problema. Se cada um entendeu uma coisa, você descreveu vagamente e cada um preencheu a lacuna do seu jeito, o que explica preços que não conversam.
Um segundo teste, mais duro: daqui a seis meses, dá para dizer se funcionou? Se a resposta depende de opinião, falta a medida de sucesso.
O que esperar de um bom fornecedor
Vale saber o que não é sua responsabilidade sozinha.
Fornecedor bom pergunta mais do que você esperava, e algumas perguntas são incômodas: quantas exceções existem, quem decide quando dá conflito, o que acontece se o dado vier errado. Quem só anota o que você pediu e manda o orçamento no dia seguinte não entendeu o problema. Entendeu o pedido.
E ele deve devolver o entendimento por escrito, com as suas palavras, antes de orçar. Se o que voltou não parece com o que você disse, o desalinhamento apareceu na hora certa, que é antes de começar.
É esse trabalho que a gente faz no diagnóstico da AXIS: transformar o que a sua operação vive em um documento que qualquer fornecedor consegue orçar, inclusive outro. Veja as soluções da AXIS ou agende seu diagnóstico, sem compromisso.
Dúvidas comuns
Preciso saber de tecnologia para pedir um sistema?
Não. Precisa descrever a situação atual com números, o que deveria ser verdade depois, as exceções que você conhece e o que não pode acontecer. A parte técnica é trabalho de quem constrói.
Qual a diferença entre pedir uma tela e pedir um resultado?
A tela é a solução que você imaginou. O resultado é o que precisa acontecer na operação. Pedindo resultado, o fornecedor pode sugerir um caminho melhor que o seu, que é o que você está pagando para ele fazer.
O que mais fica de fora do pedido inicial?
As exceções. Cliente com regra própria, caso que sempre trava, situação que acontece duas vezes por ano. É o que mais muda preço e prazo depois que o projeto começou.
Como saber se descrevi bem o que preciso?
Teste com dois fornecedores. Se os dois propuserem caminhos parecidos, o pedido está claro. Se cada um entender uma coisa, faltou informação e cada um preencheu do seu jeito.
De quem é a responsabilidade de definir os requisitos?
Dos dois lados. A norma técnica de engenharia de requisitos trata isso como trabalho conjunto: nem o cliente nem o fornecedor conseguem escrever bons requisitos sozinhos.