10 Dicas para Coleta de Requisitos

Os requisitos do projeto são uma parte de fundamental importância para a definição não só do escopo, mas também dos objetivos do projeto. Quando os requisitos não são claros, a chance do projeto não ter sucesso ou ter apenas sucesso parcial (por que deixou de atender a necessidade do cliente, por exemplo) é muito maior. Os requisitos são determinados pelas partes interessadas do projeto, todas elas ou as mais importantes e ativas.

1. Use questionários para coletar os requisitos. Gere perguntas sobre os aspectos do projeto, de forma a conseguir das partes interessadas a maior quantidade de informações possíveis. As perguntas devem começar com aspectos gerais e abordar mais e mais detalhes ao decorrer do questionário. Esta forma de coleta é muito boa para partes interessadas que não tem muita disponibilidade para reuniões ou estão em ambientes virtuais;
2. Colete requisitos para o escopo do projeto. O escopo do projeto é o que o projeto precisa/almeja  realizar. Alguns exemplos: Projeto A – Otimização do setor financeiro, Projeto B – Curso de Elaboração de Projetos. Seu patrocinador e partes interessadas internas são os alvos nesta etapa;
3. Colete requisitos para o escopo do produto. O escopo do produto é o que o projeto vai entregar ao cliente ao final da sua duração. Exemplos: Projeto A – Processos Financeiros otimizados, Projeto B – Planos de Curso, Apostila de Elaboração de Projetos. Seu cliente e o  usuário final são os alvos desta vez.
4. Elabore uma matriz de rastreabilidade de requisitos. Nesta tabela você deve associar os requisitos às partes interessadas, recursos, atividades, entregas, pacotes de trabalho e quaisquer outras informações que você achar pertinentes, de forma a facilitar o acompanhamento e assegurar que os requisitos estão sendo observados, respeitados e cumpridos;
5. Leve em consideração que os requisitos mais importantes podem não vir dos stakeholders mais importantes. Em um exemplo bruto, o faxineiro do prédio pode saber de uma coisa que nenhum dos membros da diretoria sabe. Procure sempre ao menos perguntar aos stakeholders de menor impacto ou não diretamente envolvidos sua percepção do projeto (mesmo que de uma forma que não revele que se trata de fato de uma coleta de requisitos).
6. Round 1… Fight! Se em algum momento, dois ou mais stakeholders decidirem que é um bom momento para brigar sobre requisitos e isso atrapalhar as reuniões, não tenha medo de encerrar a reunião e utilizar a técnica Delphi para chegar a uma decisão comum sem sacrificar as reuniões de planejamento.
7. Jogos de Poder. Existem situações onde a parte interessada A passa requisitos, mas é a parte interessada B quem tem poder de decisão para aprovar se o requisito entra ou não no projeto. Defina bem cedo uma matriz de priorização de partes interessadas, de forma a identificar quem tem prioridade sobre quem, bem como elabore o mais cedo possível um plano de gerenciamento de requisitos onde deve constar o processo a ser adotado quando um requisito crítico é identificado por uma parte interessada de menor importância. Se valer de opiniões especializadas nessa hora é sempre uma boa idéia;
8. Escreveu não leu… Exercite a técnica da retroalimentação no processo de comunicação para validar os requisitos. Inclua no seu plano de gerenciamento de comunicações o processo de que sempre que um pacote de trabalho estiver para ser iniciado ou concluído, o processo de comunicação deve revisar os requisitos com as partes interessadas envolvidas e com o cliente/usuário final. Desta forma, requisitos que não estão aderentes com o objetivo e o escopo podem ser identificados a tempo.
9. Informal. Muitos requisitos não podem ser coletados dentro do ambiente formal de trabalho. Marque um almoço com algumas partes interessadas e converse sobre o projeto de maneira aberta e despretensiosa. Muito da visão daquela parte interessada vai surgir desta forma e você vai poder conferir se os requisitos estão batendo.
10. Pesquisa! Recorra aos famosos ativos de processos organizacionais! Dependendo do nível de maturidade da empresa, lá você pode encontrar não só as lições aprendidas geradas para projetos anteriores como uma base de dados de requisitos… Ou um PMO que possa lhe informar onde encontrar essa informação… Ou um grupo de gerentes de projetos que podem lhe dar uma dica… Ou um punhado de técnicos que trabalharam em um projeto parecido… Ou nada. Mas procure lá!

Técnica Delphi: “Um grupo seleto de especialistas responde questionários e fornece comentários a respeito das respostas de cada rodada de coleta de requisitos.” (PMBoK 4ª Edição, pg. 108). Esta técnica permite que as idéias sejam expostas sem a interferência dos outros participantes e que posteriormente, quando reunidos, as mesmas sejam avaliadas com mais imparcialidade uma vez que ninguém sabe o certo quem deu cada idéia em específico.

Ativos de Processos Organizacionais: Os ativos de processo são todos os documentos, arquivos, processos e conhecimento disponível para uso da instituição. O PMBoK diz: “[…] incluem qualquer um ou todos os ativos relacionados a processos, de quaisquer ou todas as organizações envolvidas no projeto e que podem ser usados para influenciar o sucesso do projeto. Estes ativos incluem planos formais e informais, políticas, procedimentos e diretrizes, […] bases de conhecimento das organizações, como lições aprendidas e informações históricas.” (PMBoK 4ª Edição, pg. 32).

Até a próxima!