A maior parte dos projetos de software que estouram prazo e orçamento não falha na programação: falha no entendimento. Requisitos vagos produzem sistemas que fazem o que foi pedido e não o que era necessário, e a diferença entre as duas coisas só aparece quando alguém tenta usar. O levantamento é a etapa mais barata para descobrir problemas e a mais cara para pular. Este artigo trata de como conduzi-lo: que perguntas fazer, como registrar as respostas e como reconhecer os sinais de que ainda falta informação.
Comece pelo processo, não pela tela
A conversa costuma começar errada: o cliente descreve telas e botões, e o fornecedor anota. Isso produz um sistema que reproduz a imaginação de alguém, não o trabalho real.
O caminho é entender o processo antes de qualquer interface:
- Como esse trabalho é feito hoje, passo a passo?
- Quem faz cada etapa?
- O que dispara o início do processo?
- Onde a informação está guardada hoje?
- O que acontece quando algo dá errado no meio?
- Quais são as exceções, e com que frequência ocorrem?
Vale observar o trabalho acontecendo, não apenas ouvir a descrição. A diferença entre o processo descrito e o processo executado é onde moram os requisitos que ninguém menciona.
As perguntas que revelam o escopo real
Sobre volume
- Quantos registros por dia, mês, ano?
- Quantas pessoas usam ao mesmo tempo?
- Existe pico sazonal?
- Qual o histórico que precisa ser mantido?
Sobre regras
- Quem pode fazer o quê? Existe aprovação?
- O que é obrigatório e o que é opcional?
- Como os cálculos são feitos, exatamente?
- Existe alguma regra que muda por cliente, por região ou por período?
Sobre integração
- De onde vêm os dados que entram?
- Para onde precisam ir depois?
- Alguma informação é digitada duas vezes hoje?
Sobre exceções
- O que acontece quando o cliente cancela no meio?
- Como se corrige um lançamento errado?
- Existe caso que é resolvido "na mão" hoje?
Essa última pergunta costuma revelar metade dos requisitos escondidos.
Como registrar de forma útil
Requisito escrito de forma vaga não protege ninguém. "O sistema deve ser rápido" não é requisito; "a busca de pedidos deve retornar em até dois segundos com base de cem mil registros" é.
Um formato que funciona bem: descrever o que cada tipo de usuário precisa conseguir fazer e por quê, seguido dos critérios objetivos que permitem dizer que está pronto.
Exemplo de critério objetivo:
- É possível filtrar por período, cliente e situação
- O resultado pode ser exportado
- Apenas usuários com perfil gerencial veem valores de custo
- Um lançamento cancelado permanece visível no histórico com a marcação de cancelado
Critérios assim eliminam a discussão de "não era isso que eu queria" na entrega, porque tornam o acordo verificável.
Priorizar: nem tudo entra na primeira versão
Toda lista de requisitos cresce durante o levantamento. Priorizar é o que mantém o projeto viável.
Uma classificação simples e eficaz:
- Sem isso não funciona — o núcleo. Sem esses itens o sistema não pode entrar em uso.
- Importante, mas contornável — melhora bastante, existe alternativa temporária
- Desejável — fica para versões seguintes
- Fora de escopo — registrado explicitamente para não voltar como suposição
Essa última categoria evita muito atrito. O que foi discutido e deliberadamente deixado de fora precisa estar escrito, ou reaparece como expectativa frustrada.
Sinais de que o levantamento ainda está incompleto
- Ninguém consegue explicar o que acontece quando o processo dá errado
- As pessoas que executam o trabalho não foram ouvidas, só os gestores
- Há requisitos com "etc." e "entre outros"
- Não existe estimativa de volume
- Ninguém sabe dizer quem pode aprovar o quê
- Não se sabe de onde vêm os dados iniciais
- O que está fora do escopo não foi escrito
O levantamento foi feito com a diretoria e descreveu um fluxo linear de ordem de serviço. Ao acompanhar os técnicos em campo, apareceram três situações frequentes que o fluxo não previa: atendimento sem ordem prévia, troca de peça não orçada e visita improdutiva. Nenhuma delas havia sido mencionada nas reuniões, e todas as três representavam uma fatia relevante dos atendimentos.
Mudanças durante o projeto são normais
Nenhum levantamento captura tudo, e usar o sistema revela necessidades que não apareceriam em reunião. O objetivo não é eliminar mudanças, e sim ter um processo para tratá-las.
- Registre toda solicitação nova, mesmo as pequenas
- Avalie impacto em prazo e custo antes de aceitar
- Decida conscientemente: entra agora, entra depois, ou não entra
- Mantenha o documento atualizado com o que foi decidido
Projetos sem esse processo acumulam pedidos informais que ninguém orçou — e é isso, não a complexidade técnica, que faz o cronograma estourar.
Conclusão
O levantamento é onde o custo do projeto é realmente definido. Uma hora bem gasta entendendo o processo economiza dias de desenvolvimento em direção errada.
Comece pelo processo real, converse com quem executa e não apenas com quem gerencia, escreva critérios verificáveis, priorize com honestidade e registre explicitamente o que ficou de fora. É a etapa menos glamourosa e a que mais determina se o sistema vai ser usado.
Perguntas Frequentes
Como referência, uma fração relevante do projeto — não algo resolvido em uma reunião de uma hora. Para um sistema de porte médio, algumas semanas entre entrevistas, observação do trabalho, redação e validação costumam ser adequadas. Reduzir essa etapa não economiza tempo: transfere o custo para o desenvolvimento, onde ele é muito maior.
Quem executa o processo diariamente, obrigatoriamente, porque conhece as exceções que ninguém documentou. Além deles, quem gerencia, para dar a visão de objetivo e prioridade, e quem cuida de tecnologia, para tratar integrações e restrições. Ouvir apenas a gestão produz um sistema que descreve o processo idealizado, não o real.
Protótipos navegáveis ajudam muito, porque as pessoas conseguem reagir a algo concreto de forma que não conseguem diante de um documento. Descobrir na tela que faltou um campo custa muito menos do que descobrir com o sistema pronto. Para projetos simples, esboços de tela já cumprem boa parte desse papel.