Resumo executivo: a maior parte dos projetos de software não fracassa por escolha errada de tecnologia. Fracassa porque ninguém entendeu o processo antes de começar a construir. Levantamento de requisitos é a etapa mais barata de fazer bem e a mais cara de fazer mal.
O que realmente acontece quando o projeto estoura
O sintoma. Prazo estendido, orçamento revisado, clima ruim entre cliente e fornecedor, e um sistema que faz o que foi pedido mas não o que era necessário.
A causa quase sempre é a mesma. O requisito foi coletado como uma lista de desejos, não como um processo. Alguém pediu “uma tela de cadastro de clientes”, ninguém perguntou o que a empresa faz com aquele cadastro, quem decide o que, e o que acontece quando o dado está errado.
O custo de descobrir tarde. Corrigir um requisito mal entendido na fase de levantamento custa uma conversa. Na fase de desenvolvimento, custa retrabalho. Depois de o sistema estar em produção com dados reais, custa migração, retreinamento e credibilidade.
Os cinco erros que se repetem
1. Perguntar o que a pessoa quer, em vez de observar o que ela faz
Usuário descreve o processo idealizado; o processo real tem exceções, atalhos e um caderno na gaveta. Requisito bom nasce de observação somada a entrevista, não de entrevista sozinha.
2. Falar apenas com o gestor
O gestor conhece o processo desenhado. Quem opera conhece o processo executado. Sistema construído só a partir da visão gerencial costuma ignorar exatamente as exceções que consomem o tempo da equipe.
3. Confundir funcionalidade com resultado
“Preciso de um relatório de estoque” é funcionalidade. “Preciso saber, toda segunda, quais itens vão faltar em 15 dias” é resultado. A segunda formulação permite soluções melhores — e frequentemente mais simples.
4. Deixar as exceções para depois
É nas exceções que mora a complexidade: o pedido que volta, o cliente com regra diferente, a nota que precisa ser cancelada. Levantar só o caminho feliz garante retrabalho.
5. Não definir quem decide
Quando duas áreas discordam sobre uma regra, alguém precisa decidir. Se esse papel não estiver nomeado antes do projeto começar, cada divergência vira semanas de espera.
Como fazemos o levantamento
Etapa 1 — Mapear o processo como ele é
Objetivo: entender a operação real, incluindo os contornos.
Ação: acompanhar a execução no local, entrevistar quem opera e quem gere, coletar os artefatos que já existem — planilhas, formulários de papel, mensagens trocadas.
Resultado esperado: fluxo documentado com atores, decisões, exceções e pontos de retrabalho.
Como validar: apresentar o fluxo a quem opera e verificar se a pessoa se reconhece nele. Se ela disser “mas quando acontece X a gente faz diferente”, faltou levantamento.
Etapa 2 — Separar problema de solução
Objetivo: não congelar em código uma solução improvisada.
Ação: para cada pedido, perguntar três vezes “para quê?” até chegar ao resultado de negócio.
Resultado esperado: lista de problemas a resolver, com o impacto de cada um quantificado em tempo, custo ou risco.
Como validar: cada item da lista precisa ter uma métrica associada. O que não tem métrica não tem prioridade defensável.
Etapa 3 — Priorizar com critério explícito
Objetivo: decidir o que entra na primeira entrega.
Ação: classificar cada item por impacto na operação e por esforço técnico; escolher o que tem alto impacto e baixo esforço para a fase 1.
Resultado esperado: escopo da primeira fase fechado, com o restante visível e ordenado.
Como validar: a diretoria consegue explicar por que um item ficou de fora sem recorrer a “não deu tempo”.
Etapa 4 — Especificar o suficiente, e só
Objetivo: documentar o necessário sem transformar o projeto em produção de documento.
Ação: para cada funcionalidade da fase 1, registrar o objetivo, as regras, as exceções conhecidas e os critérios de aceite.
Resultado esperado: especificação que cabe em poucas páginas por funcionalidade e que qualquer pessoa da equipe consegue ler.
Como validar: um desenvolvedor que não participou das entrevistas consegue implementar sem inventar regra.
Critérios de aceite: o item mais subestimado
O que é. A descrição objetiva do que precisa ser verdade para a funcionalidade ser considerada pronta. Sem eles, “pronto” é opinião.
| Requisito vago | Critério de aceite verificável |
|---|---|
| O sistema deve ser rápido | A listagem de pedidos abre em até 2 segundos com 50 mil registros |
| Deve ter controle de acesso | Usuário do perfil Operação não visualiza valores de custo em nenhuma tela nem relatório |
| Precisa avisar o responsável | Ao ultrapassar o prazo, o sistema notifica o responsável e registra a notificação no histórico do chamado |
| Tem que funcionar no celular | O técnico consegue registrar uma ordem de serviço com foto e assinatura sem conexão, com sincronização automática ao reconectar |
Efeito colateral positivo. Critérios de aceite bem escritos viram roteiro de teste e roteiro de homologação. O documento trabalha três vezes.
Um formato de requisito que funciona
Curto, verificável e centrado no resultado. Para cada funcionalidade, quatro blocos bastam.
- Contexto: quem usa, em que momento do processo e com que frequência.
- Resultado esperado: o que precisa ser verdade depois que a pessoa usar.
- Regras: as condições que o sistema precisa respeitar, incluindo as exceções conhecidas.
- Critérios de aceite: a lista objetiva do que será verificado na homologação.
Exemplo aplicado. Contexto: o técnico encerra a ordem de serviço no local, muitas vezes sem sinal. Resultado esperado: a OS fica encerrada com evidência, mesmo sem conexão. Regras: exige foto e apontamento de horas; se houver peça utilizada, baixa do estoque ao sincronizar. Critérios de aceite: encerrar sem rede, reconectar e verificar que a OS aparece encerrada no servidor, com foto e sem duplicidade.
Por que funciona. Cabe em meia página, qualquer pessoa da operação consegue validar e o desenvolvedor sabe exatamente quando terminou.
Quanto tempo dedicar ao levantamento
A regra que usamos. Quanto mais crítico o processo e mais integrações envolvidas, mais levantamento. Um sistema de apoio interno pode ser levantado em dias. Um sistema que participa do faturamento exige semanas — e ainda assim é a parte barata do projeto.
O sinal de que já foi suficiente. Quando novas entrevistas param de revelar exceções novas. Enquanto cada conversa traz uma regra inédita, o mapa está incompleto.
O sinal de excesso. Documentação que ninguém lê, diagramas que ninguém atualiza e três meses sem uma linha de código. Levantamento é meio, não entregável final.
O papel do cliente — que não é opcional
- Disponibilizar quem conhece o processo. A pessoa mais ocupada da operação costuma ser a que mais sabe. Sem agenda dela, o projeto avança no escuro.
- Nomear um responsável por decisão. Uma pessoa com autoridade para resolver divergência entre áreas, em prazo curto.
- Validar o que foi entendido. Ler o fluxo documentado e apontar o que está errado é o investimento de maior retorno em todo o projeto.
- Aceitar priorizar. Tudo prioritário significa nada prioritário — e o resultado é uma fase 1 que nunca termina.
Perguntas frequentes
Metodologia ágil dispensa levantamento? Não. Muda a forma: em vez de um documento fechado no início, o entendimento é construído e revisado a cada ciclo. O que não muda é a necessidade de entender o processo antes de implementar cada parte dele.
E se o processo ainda não existe? Aí o trabalho é desenhá-lo junto, e o risco é maior. Nesses casos vale muito começar por um piloto pequeno em produção real, para descobrir o processo na prática antes de construir o sistema definitivo.
Quem escreve os requisitos, o cliente ou o fornecedor? O fornecedor escreve, o cliente valida. Cliente escrevendo especificação técnica sozinho costuma produzir uma lista de telas; fornecedor escrevendo sem validação produz um sistema elegante para o processo errado.
Requisito pode mudar no meio do projeto? Pode e vai. O que precisa existir é um processo para isso: registro da mudança, reavaliação de prazo e decisão explícita sobre o que sai para o novo item entrar.
Riscos e pontos de atenção
- Levantamento feito só por videoconferência. Processos operacionais precisam ser vistos. O que a pessoa não conta é justamente o que ela faz no automático.
- Documento longo demais. Especificação de cem páginas não é sinal de rigor; é sinal de que ninguém vai ler.
- Ausência de quem opera. Sistema desenhado só com a gerência gera resistência na adoção — e adoção é o que determina o retorno.
- Regras não escritas. “Todo mundo sabe que nesse caso é diferente” é a frase que antecede o retrabalho.
- LGPD deixada para o fim. Definir quais dados pessoais o sistema trata, com que base legal e por quanto tempo é requisito, não ajuste posterior.
Próximos passos práticos
- Escolha o processo que mais gera reclamação interna e acompanhe uma execução completa dele, do início ao fim, tomando nota.
- Liste as exceções que apareceram. Elas são o verdadeiro escopo.
- Para cada dor, escreva o resultado esperado e como você saberia que ele foi atingido.
- Nomeie quem decide quando as áreas discordarem — antes de o projeto começar.
Quer o processo mapeado antes de decidir construir? A Brazuca Informática faz levantamento e desenvolvimento de sistemas corporativos em MT, GO e em todo o Brasil. Fale com nosso time.
Premissas assumidas: as afirmações sobre causas de fracasso em projetos de software refletem padrões recorrentes observados em projetos corporativos e em literatura de engenharia de software, não um levantamento estatístico próprio; prazos e proporções citados são referências de projeto e variam com a complexidade do processo.
Deixe um comentário