Como levantar os requisitos antes de contratar um sistema
"Quero um sistema para controlar as ordens de serviço." É um pedido legítimo e, ao mesmo tempo, impossível de orçar. Duas empresas podem ler essa frase e entregar propostas que diferem em duas, três vezes o valor, e as duas estarão corretas: cada uma imaginou um sistema diferente.
Levantar requisitos é o trabalho de transformar esse pedido numa descrição que duas pessoas diferentes entendam da mesma forma. Não é uma etapa técnica nem burocrática. É a conversa que decide se o sistema vai resolver o problema ou apenas existir.
Este artigo acompanha um exemplo do começo ao fim. O caso é ilustrativo; não se refere a nenhum cliente real. Uma oficina que conserta equipamentos e hoje controla tudo em planilha e mensagens quer um sistema de ordens de serviço.
Comece pelo processo de hoje, não pelo sistema de amanhã
O primeiro erro é descrever telas. O primeiro passo certo é descrever o trabalho. Peça para quem faz o trabalho contar, na ordem, o que acontece desde que o cliente entra em contato até o equipamento voltar para ele. Na oficina do exemplo:
- O cliente traz o equipamento ou liga pedindo retirada.
- A recepção anota defeito, cliente e telefone numa planilha.
- O técnico faz o diagnóstico e manda o valor do conserto por mensagem.
- O cliente aprova (ou não) por mensagem.
- O técnico conserta e avisa a recepção.
- A recepção avisa o cliente, recebe o pagamento e entrega o equipamento.
Desenhe isso num papel ou quadro, com os nomes de quem faz cada coisa. Duas descobertas costumam aparecer já aqui: etapas que ninguém lembrava (por exemplo, "esperar peça chegar") e pontos em que a informação passa de mão em mão de um jeito frágil. É nesses pontos que o sistema vai gerar mais valor.
Pergunte a quem usa, não só a quem decide
O dono da oficina sabe o que quer ver nos relatórios. O técnico sabe que a bancada não tem espaço para um computador e que o único aparelho à mão é o celular. A recepcionista sabe que o cliente quase nunca lembra o número do pedido, só o sobrenome. Cada um conhece restrições que o outro não conhece, e todas elas viram requisitos.
Liste os perfis que vão usar o sistema (recepção, técnico, financeiro, dono) e converse com pelo menos uma pessoa de cada um. É também o que mais reduz a resistência na hora de adotar: ninguém rejeita com tanta facilidade o que ajudou a desenhar.
Troque "o sistema deve ser fácil" por algo que dê para testar
Requisito vago não pode ser conferido na entrega, e vira discussão. O trabalho de verdade está em reescrever cada pedido de modo que alguém consiga dizer "sim, funciona" ou "não, não funciona". Alguns exemplos da oficina:
| Pedido vago | Requisito verificável |
|---|---|
| "Quero saber em que etapa está cada conserto." | Cada ordem de serviço tem um status (recebido, em diagnóstico, aguardando aprovação, em conserto, pronto, entregue), e a recepção consegue consultar pelo nome do cliente ou pelo telefone. |
| "O cliente precisa ser avisado." | Quando o status muda para "pronto", o cliente recebe uma mensagem automática no WhatsApp com a ordem de serviço e o valor. |
| "Tem que ter controle de acesso." | O técnico enxerga apenas as ordens atribuídas a ele; só o dono vê valores e relatórios financeiros. |
| "Precisa ser rápido." | A tela de consulta de uma ordem abre em até três segundos com a conexão de internet da oficina. |
| "Quero relatórios." | O dono consegue ver, por mês, quantas ordens foram abertas e concluídas, o tempo médio entre abertura e entrega e o valor faturado. |
Uma boa regra: se o requisito contém "fácil", "rápido", "moderno" ou "intuitivo", ainda falta número, exemplo ou tarefa.
Registre as regras que estão na cabeça das pessoas
Todo negócio tem regras que ninguém escreveu. Na oficina: "se o conserto passar de R$ 300, o dono precisa aprovar antes", "equipamento parado há mais de 60 dias na prateleira vai para a lista de descarte", "cliente antigo tem 10% de desconto na mão de obra". Se essas regras não forem escritas agora, uma de duas coisas acontece: o sistema é entregue sem elas, e a equipe volta a usar a planilha para contornar, ou o programador as inventa e erra.
Pergunte sempre pelas exceções: o que acontece quando o cliente não aprova o orçamento? E quando a peça não chega? E quando o equipamento volta com o mesmo defeito em 30 dias? Os fluxos "felizes" são fáceis de descrever; é nas exceções que sistemas costumam falhar.
Liste o que precisa conversar com outros sistemas
Integração costuma pesar no prazo e no custo, e é a coisa que mais se esquece de perguntar no início. Mapeie com quem o sistema precisa trocar informação: emissão de nota fiscal, contabilidade, meio de pagamento, WhatsApp, e-mail, site, planilhas que ainda vão existir. Para cada um, descubra se há uma forma oficial de integrar (uma API, um arquivo de exportação) e o que acontece se ela mudar ou ficar fora do ar.
Separe o essencial do desejável
Quase tudo parece essencial no início. Uma forma prática de organizar é dividir cada pedido em quatro grupos, conhecidos pela sigla em inglês MoSCoW:
- Precisa ter: sem isso o sistema não serve (abrir uma ordem de serviço, mudar o status, consultar);
- Deveria ter: importante e logo depois (aviso automático ao cliente);
- Poderia ter: bom, se couber no prazo e no orçamento (relatório de produtividade por técnico);
- Não terá agora: decidido que fica para depois (aplicativo para o cliente acompanhar o conserto).
Esse último grupo é o mais subestimado. Escrever o que não entra evita que ele volte, mais tarde, como "mas eu achei que estava incluído".
Combine como será o "pronto"
Para cada requisito do primeiro grupo, escreva um critério de aceite em uma frase: "dado que existe uma ordem em diagnóstico, quando o técnico a marca como 'aguardando aprovação', o cliente recebe o valor por mensagem". Ao final de cada etapa, a equipe consegue testar com o roteiro na mão. Sem isso, o "pronto" depende de memória e da boa vontade de quem entrega.
O que levar para a conversa com o fornecedor
Você não precisa de um documento técnico de cem páginas. Duas ou três páginas já mudam a qualidade das propostas:
- o desenho do processo atual e o que mais incomoda nele;
- os perfis de usuário e o que cada um precisa fazer;
- a lista de requisitos, já separada por prioridade;
- as regras de negócio e as exceções que você lembrou;
- os sistemas com os quais o novo precisa se conectar;
- uma ideia honesta do que não pode mudar (por exemplo, a emissão de nota continua sendo feita no sistema do contador).
Com esse material, as propostas passam a ser comparáveis, e a conversa começa num patamar mais alto.
Requisitos mudam, e tudo bem
Nenhum levantamento antecipa tudo. Quando a equipe usa a primeira versão, aparecem coisas que ninguém previu. O que protege o projeto é combinar entregas em etapas curtas, em que a primeira já pode ser usada de verdade, e um jeito claro de tratar as mudanças: o que entra, o que sai e o que isso muda no prazo e no valor. Quanto menor o salto entre uma versão e outra, mais barato é corrigir o rumo.
Se o seu pedido ainda está na fase do "quero um sistema para controlar...", a conversa de escuta é o ponto de partida. É o que fazemos no início dos projetos da Stringari: entender o processo, quem usa e o que não pode falhar, antes de falar de tecnologia. Se você ainda não decidiu se vale um sistema sob medida ou uma ferramenta pronta, leia antes Sistema sob medida ou sistema pronto: como decidir. Se quiser começar a conversa, o formulário de briefing é o caminho.
