Planejamento, Cronograma e Custos
Coleta de requisitos do projeto: técnicas e passo a passo
A coleta de requisitos é a etapa em que o projeto descobre, com as pessoas certas, o que a entrega precisa fazer e quais condições ela precisa cumprir para ser aceita. Quando ela é feita às pressas, o problema aparece na homologação: o sistema funciona, a obra está pronta, o evento aconteceu, mas alguém com poder de veto diz que "não era isso". O custo de corrigir nessa hora é muito maior do que o de perguntar no começo.
Coletar requisitos não é anotar pedidos. É escolher quem ouvir, com que técnica, como separar necessidade de solução sugerida e como registrar cada requisito de um jeito que permita testar se ele foi atendido. O guia cobre as técnicas, um passo a passo em sete etapas com um exemplo de implantação de sistema e os cuidados para escrever requisitos que não geram discussão no aceite.
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
O que é coleta de requisitos e para que ela serve
Requisito é uma condição ou capacidade que a entrega precisa ter para atender a uma necessidade de negócio ou de uma parte interessada. "Os técnicos de manutenção precisam abrir um chamado pelo celular em menos de um minuto" é um requisito. "Usar o aplicativo X" é uma solução, que pode ou não ser a melhor forma de atender a ele.
A coleta de requisitos tem um objetivo principal: produzir uma lista completa, validada e priorizada do que as partes interessadas precisam para que os objetivos do termo de abertura sejam atingidos. Dessa lista saem três coisas que o restante do planejamento usa:
- O escopo. A declaração de escopo decide quais requisitos o projeto vai atender e quais ficam de fora. O artigo sobre o que é escopo do projeto mostra como essa decisão é registrada.
- A EAP. As entregas da Estrutura Analítica do Projeto (EAP) existem para atender aos requisitos.
- Os critérios de aceite. Cada requisito precisa dizer como será verificado. Sem isso, o aceite vira questão de opinião.
Coleta de requisitos no PMBOK
No Guia PMBOK, do Project Management Institute (PMI), a coleta de requisitos aparece na 6ª edição como o processo "Coletar os requisitos", dentro do gerenciamento do escopo, logo depois do planejamento do escopo e antes da definição do escopo. As edições seguintes mudaram a estrutura do guia, que passou a ser organizado por princípios e domínios de desempenho, mas as técnicas e as saídas continuam sendo a referência de mercado e das provas de certificação.
O processo, na 6ª edição, tem esta lógica:
| Elemento | O que entra |
|---|---|
| Entradas principais | Termo de abertura, plano de gerenciamento do escopo e dos requisitos, registro das partes interessadas, business case, acordos e contratos |
| Ferramentas e técnicas | Opinião especializada, coleta de dados (brainstorming, entrevistas, grupos focais, questionários, benchmarking), análise de documentos, tomada de decisão (votação, análise multicritério), representação de dados (diagrama de afinidades, mapa mental), técnica de grupo nominal, observação, facilitação, diagrama de contexto e protótipos |
| Saídas | Documentação dos requisitos e matriz de rastreabilidade dos requisitos |
O guia também classifica os requisitos em tipos (de negócio, das partes interessadas, de solução, de transição, do projeto e de qualidade), o que ajuda a perceber lacunas: se a lista só tem requisitos de solução, provavelmente ninguém perguntou como será a transição do processo antigo para o novo.
Técnicas de coleta de requisitos: qual usar em cada situação
Nenhuma técnica resolve sozinha. A escolha depende de duas perguntas: quantas pessoas você precisa ouvir e quanto elas conseguem descrever o que precisam sem ver algo concreto.
| Técnica | Funciona melhor quando | Cuidado |
|---|---|---|
| Entrevista individual | Poucas pessoas com muito conhecimento ou poder de decisão | Consome tempo; prepare roteiro e registre na hora |
| Oficina facilitada (workshop) | Áreas diferentes precisam chegar a um acordo | Sem facilitador neutro, vence quem fala mais alto |
| Grupo focal | Você quer a percepção de um perfil de usuário | Não serve para decidir, só para entender expectativas |
| Questionário | Muitas pessoas, dispersas, com perguntas fechadas | Mostra o que está acontecendo, raramente o porquê |
| Observação | O usuário faz o trabalho no automático e não sabe descrevê-lo | Avise antes e observe o processo real, não o "oficial" |
| Análise de documentos | Existem normas, contratos, manuais ou sistema antigo | Documento desatualizado vira requisito errado |
| Benchmarking | Outras organizações já resolveram problema parecido | Copiar a solução sem entender o contexto |
| Protótipo | As pessoas só sabem dizer o que querem quando veem | O protótipo pode virar compromisso de entrega |
| Brainstorming e grupo nominal | Gerar e depois priorizar muitas ideias com um grupo | Precisa de uma etapa de votação para fechar |
Para as oficinas, que costumam ser a técnica mais produtiva quando várias áreas dividem a mesma entrega, o guia sobre como conduzir workshops de alinhamento de escopo traz o roteiro de preparação e condução.
Como fazer a coleta de requisitos passo a passo
O exemplo que acompanha os passos é ilustrativo: a implantação de um sistema de chamados de manutenção numa indústria com três turnos, que hoje registra os pedidos em papel e por mensagem.
Passo 1: parta do objetivo e da lista de partes interessadas
Releia o termo de abertura e anote o objetivo mensurável. No exemplo: reduzir o tempo entre a quebra de um equipamento e o início do atendimento. Depois, liste quem usa, quem decide, quem é afetado e quem pode vetar: operadores de máquina, técnicos de manutenção, supervisores de turno, planejamento de manutenção, TI, segurança do trabalho e o gerente industrial.
Passo 2: combine como os requisitos serão registrados e aprovados
Antes da primeira conversa, decida o formato do registro, quem aprova a lista final e como uma mudança de requisito será tratada depois da aprovação. No PMBOK, essas regras ficam no plano de gerenciamento dos requisitos. Num projeto pequeno, meia página resolve.
Passo 3: escolha a técnica para cada grupo
No exemplo, a escolha ficou assim:
- Gerente industrial e planejamento: entrevistas individuais, porque têm as metas e o poder de decisão.
- Técnicos de manutenção: observação de dois turnos completos, porque o trabalho real inclui atalhos que ninguém descreve numa reunião.
- Operadores dos três turnos: questionário curto, com cinco perguntas, porque são mais de cem pessoas.
- Supervisores, TI e segurança: uma oficina conjunta para conciliar regras de prioridade, acesso e bloqueio de equipamento.
Passo 4: prepare roteiros que busquem a necessidade
Pergunte pelo problema, não pela solução. Em vez de "que campos você quer na tela?", pergunte "o que você precisa saber para decidir qual chamado atender primeiro?". Quando alguém propuser uma solução, pergunte "o que isso resolveria?" até chegar à necessidade.
Passo 5: conduza e registre na hora
Registre cada requisito com quem pediu, a data e a fonte (entrevista, oficina, documento). Ao fim de cada sessão, leia em voz alta o que foi anotado. A correção feita na mesma reunião custa minutos; a feita na homologação custa semanas.
Passo 6: analise, resolva conflitos e priorize
Junte os registros, elimine duplicidades e agrupe por tema. Conflitos aparecem aqui: no exemplo, a produção queria que qualquer operador pudesse classificar o chamado como urgente, e o planejamento queria que só o supervisor pudesse. A decisão cabe a quem o plano definiu como aprovador, não à equipe do projeto. Para priorizar, classifique cada requisito em obrigatório, importante ou desejável, ou use MoSCoW (must, should, could, won't).
Passo 7: documente, valide e rastreie
Escreva a versão final, valide com os aprovadores e registre a aprovação. Em seguida, ligue cada requisito ao objetivo que o justifica e à entrega que vai atendê-lo. A matriz de rastreabilidade de requisitos faz essa ligação e mostra, depois, o que é afetado quando alguém pede uma mudança.
Como escrever um requisito que dá para testar
Um bom requisito é claro, tem um único assunto, é verificável e tem dono. Compare:
| Mal escrito | Bem escrito |
|---|---|
| O sistema deve ser rápido | O operador abre um chamado em até 60 segundos, pelo celular, com no máximo quatro campos obrigatórios |
| Os chamados devem ser priorizados | O chamado classificado como "parada de linha" aparece no topo da fila do técnico de plantão e gera aviso no celular dele |
| Relatórios gerenciais | O planejamento consulta, por equipamento, o tempo médio entre a abertura e o início do atendimento, por mês e por turno |
Três testes rápidos ajudam. Se duas pessoas podem discordar sobre se o requisito foi atendido, ele está vago. Se ele usa "e" para juntar duas coisas, provavelmente são dois requisitos. Se ninguém sabe dizer quem pediu, ele pode não ser necessário.
Coleta de requisitos em projetos ágeis
Em projetos ágeis, a coleta não acontece uma vez só, no começo. Os requisitos viram itens de backlog, muitas vezes escritos como histórias de usuário com critérios de aceite, e são detalhados aos poucos, no refinamento, perto do momento em que vão ser construídos. As técnicas são as mesmas: entrevista, observação, oficina e protótipo continuam sendo a forma de entender o usuário.
O que muda é o momento do detalhe. Em vez de documentar tudo antes de começar, a equipe documenta o suficiente para estimar e priorizar e completa o restante a cada ciclo, com a entrega anterior servindo de protótipo para a conversa seguinte. Em projetos híbridos, é comum fazer a coleta completa para as partes com contrato ou norma (integrações, requisitos legais, segurança) e a coleta incremental para as telas e funções de uso.
Erros comuns na coleta de requisitos
- Ouvir só quem pediu o projeto. O patrocinador conhece o objetivo, mas raramente conhece o trabalho de quem vai usar a entrega.
- Esquecer quem pode vetar. Segurança do trabalho, jurídico, auditoria e TI aparecem tarde e com exigências que mudam o desenho.
- Registrar soluções como se fossem requisitos. Isso fecha alternativas mais baratas antes de alguém avaliá-las.
- Não priorizar. Uma lista em que tudo é obrigatório não ajuda a decidir o que cortar quando o prazo apertar.
- Coletar e não validar. Sem aprovação formal da lista, qualquer pedido novo vira "estava combinado".
Depois da coleta, o próximo passo é decidir o que entra no escopo e controlar as mudanças, que é o assunto do artigo sobre gerenciamento do escopo do projeto. O guia de planejamento de projetos mostra como os requisitos alimentam a EAP, o cronograma e o orçamento.
Para começar hoje, liste as partes interessadas do seu projeto, escolha a técnica para cada grupo com a tabela acima e marque as primeiras entrevistas. Quando a lista estiver aprovada, registre o escopo, a EAP e os demais artefatos no plano do projeto da Projeto Diário, que reúne num documento só o que você preenche nas ferramentas gratuitas do site e gera o plano em Word.
