Coleta de Requisitos: Necessidades e expectativas dos principais envolvidos em um projeto

Resumo

Sucesso está diretamente ligado ao atendimento de expectativas. Enquanto o sucesso para o negócio é medido pelo alcance dos benefícios esperados, o sucesso do gerenciamento é medido por tradicionais parâmetros de desempenho, tais como escopo, custo, tempo e qualidade.

De acordo com o Guia PMBOK® do PMI, “requisito é uma condição ou capacidade cuja presença em um produto, serviço ou resultado é exigida para satisfazer um contrato ou outra especificação formalmente imposta”. As expectativas em relação ao negócio são, portanto, requisitos.

Um dos processos do Guia PMBOK® do Project Management Institute (PMI), da área de gerenciamento de escopo, é “Coletar os Requisitos”. Este artigo tem como objetivo divulgar a interpretação do autor para esse processo, explicando também a diferença entre o escopo na visão do cliente e o escopo do projeto.

Introdução

“Eu sei que você acredita que entendeu o que você pensa que eu disse, mas eu não estou certo de que você compreendeu que o que você ouviu não é o que eu quis dizer” (Autor anônimo)

A frase acima mostra bem a dificuldade que é, para a equipe do projeto, entender as necessidades e expectativas dos principais envolvidos em um projeto. A identificação e representação dessas necessidades no Plano do Projeto, assim como seu monitoramento e controle durante a execução do projeto, de acordo com o Guia PMBOK1 do Project Management Institute (PMI), é incumbência da área de Gerenciamento de Escopo, cujos processos são:

• Planejar o gerenciamento do escopo — O processo de criar um plano de gerenciamento do escopo do projeto que documenta como tal escopo será definido, validado e controlado.
• Coletar os requisitos — O processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de atender aos objetivos do projeto.
•  Definir o escopo — O processo de desenvolvimento de uma descrição detalhada do projeto e do produto.
•  Criar a EAP — O processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
•  Validar o escopo — O processo de formalização da aceitação das entregas concluídas do projeto.
•  Controlar o escopo — O processo de monitoramento do andamento do escopo do projeto e do produto e gerenciamento das mudanças feitas na linha de base do escopo.

A Identificação dos Stakeholders do projeto

No livro “Metodologia de Gerenciamento de Projetos – Methodware®”2 os autores recomendam que, como primeiro passo do planejamento do projeto, sejam identificadas as partes interessadas (stakeholders) e montada uma equipe para o planejamento do projeto. A idéia é obter o comprometimento desses stakeholders com o projeto na medida em que eles participam do mesmo desde o seu planejamento. A tabela 1 apresenta um modelo para o registro dos stakeholders do projeto. Para efeito deste artigo, nos interessa em especial identificar aqueles que estarão envolvidos na definição, aceite e controle do escopo do projeto.

O Processo de Coletar os Requisitos
O processo de Coletar os Requisitos, segundo o PMBOK, tem o objetivo de definir e documentar as características dos produtos e serviços do projeto que irão satisfazer as necessidades e as expectativas dos stakeholders. Os Requisitos são condições ou capacidades que devem ser supridas pelo produto, serviço, ou resultado do projeto, para satisfazer a um contrato, padrão, especificação ou outro documento formal. Esses Requisitos precisam ser definidos, analisados, e reportados com detalhamento suficiente para serem medidos (aceitos) e controlados durante a execução do projeto. As informações tais como as características e funcionalidades do projeto e de seus produtos, o(s) objetivo(s) final(is) do projeto, e as expectativas das partes interessadas são fundamentais para o sucesso do projeto.

Todo o projeto possui um ou mais clientes, sejam eles internos ou externos. Na prática, a Coleta dos Requisitos estabelece os produtos e serviços que serão gerados e entregues ao cliente, o que denominamos “escopo para o cliente” ou “escopo do cliente”.

Um exemplo de escopo na visão de um cliente poderia ser:

“O desenvolvimento de uma metodologia de gerenciamento de projetos, a elaboração e aplicação de programa de treinamento nessa metodologia, assim como a análise e proposta de software e estrutura do escritório de gerenciamento de projetos (PMO) para a organização, com foco nas Diretorias de TI, Marketing e Engenharia”.

Porém, para que seja entregue o escopo para o cliente, outras entregas devem ser geradas. Por exemplo, um cliente solicita a construção de uma termoelétrica, estabelecendo todas as características que a mesma deve ter, podendo ter fornecido inclusive um projeto básico de engenharia. Para que a termoelétrica seja construída é necessária a aquisição das turbinas, transporte marítimo e terrestre, seguro e outras entregas, não solicitadas pelo cliente. A definição dessas outras entregas depende da estratégia de condução do projeto e será vista no próximo capítulo. Desta forma, o escopo do projeto é maior do que o escopo para o cliente. A figura 1 mostra graficamente que o escopo para o cliente é parte do escopo do projeto.

A coleta dos requisitos dos stakeholders (escopo na visão do cliente) irá facilitar os processos de definição do escopo do projeto e a criação da EAP (Estrutura Analítica do Projeto). Essa estrutura representa de forma hierárquica os deliverables (produtos e serviços) do projeto. Maiores informações acerca da elaboração desta estrutura podem ser vistas no livro Gerenciamento de Projetos – Como definir e controlar o escopo do projeto3.

Para iniciar a coleta do escopo do cliente, é necessário que entendamos as necessidades e expectativas do mesmo, pois o que ele está solicitando pode ou não resolver o problema que o levou a solicitar o projeto. Por exemplo, um arquiteto, antes de dar início ao planejamento da casa de um cliente, precisa saber a finalidade da casa: será a casa onde o cliente vai morar, será a casa onde o cliente abrirá o seu negócio, qual será o negócio a ser oferecido nessa casa? Esta informação acerca do objetivo do projeto é fundamental.

O arquiteto não pode, portanto, começar a elaborar o projeto da casa, nem tão pouco definir as atividades a serem executadas, sem antes saber a finalidade para a qual o cliente deseja utilizar a residência. Após esta informação, o arquiteto precisará saber mais detalhes como: qual o tamanho da casa, quantos cômodos são desejados, quantos ambientes são necessários etc. As repostas servirão como base para que o arquiteto elabore o plano da casa conforme seu cliente a deseja. Por último, informações ainda mais específicas irão ajudar na criação de uma casa perfeita para o determinado cliente, por exemplo, o cliente tem filhos, qual é a idade deles, ou então, qual será o nicho de mercado que o restaurante pretende atender, etc. Com todas essas informações em mãos, o arquiteto será capaz de elaborar uma casa que irá corresponder exatamente às expectativas de seu cliente. O arquiteto, então, terá mais chances de concluir com sucesso o seu projeto.

O quadro da figura 2 representa as entradas, técnicas e ferramentas e as saídas do Processo de Coletar Requisitos de acordo com o PMBOK®.

Figura 2 Os componentes do Processo de Coletar os Requisitos

As Entradas para o processo de Coletar os Requisitos

a) Plano de gerenciamento do escopo
O plano de gerenciamento do escopo esclarece como equipes do projeto determinarão que tipo de requisitos devem ser coletados para o projeto.

b) Plano de gerenciamento dos requisitos
O plano de gerenciamento dos requisitos fornece o processo que será usado em todo o processo de Coletar os requisitos, a fim de definir e documentar as necessidades das partes interessadas.

c) Plano de gerenciamento das partes interessadas
O plano de gerenciamento das partes interessadas é usado para entender os requisitos de comunicações das partes interessadas e o nível do engajamento das mesmas a fim de avaliá-los e adaptá-los ao nível de participação das partes interessadas nas atividades dos requisitos.

d) Termo de Abertura do Projeto (Project Charter)
O Termo de Abertura do Projeto é o documento em que se encontram os objetivos gerais e a descrição dos produtos do projeto, ambos importantes para entender as exigências dos stakeholders.

e) Registro dos stakeholders (partes interessadas)
O registro dos stakeholders é usado para identificar as partes envolvidas no projeto que podem prover informações detalhadas de suas expectativas para com o projeto.

Técnicas e ferramentas para o Processo de Coletar os Requisitos

a) Entrevistas
As entrevistas podem ser uma abordagem formal ou informal de perguntas para coletar informações relevantes sobre as características exigidas pelos stakeholders do projeto. Ao entrevistar os principais participantes do projeto, as partes interessadas, e os especialistas no tópico do projeto, o processo de identificação e definição dos requisitos desejáveis fluirá de forma rápida e acertada.

b) Grupos de discussão
Os grupos de discussão têm como objetivo juntar os principais stakeholders e os especialistas do projeto para que todos entendam melhor sobre os resultados que podem ser gerados após a conclusão do projeto. Um instrutor guia o grupo numa discussão interativa cujo objetivo é extrair, o mais naturalmente possível, o desejo final das partes interessadas.

c) Workshops / Oficinas facilitadas
Workshops são oficinas de discussão que unem as diferentes partes envolvidas no projeto. Partes com diferentes funções no projeto, experiências e objetivos, para definir de forma abrangente as especificações finais do projeto. Os workshops são uma excelente maneira de criar comprometimento, relacionamento e consenso entre os stakeholders do projeto, com isso, melhorar a comunicação entre eles, o que é fundamental para o bom andamento do projeto.

Os workshops, normalmente, começam coletando as exigências dos stakeholders e depois, objetivamente, as qualificam e priorizam. Por último são definidas as metas que garantirão o cumprimento das exigências.

d) Técnicas de criatividade em grupo
Algumas técnicas podem ser usadas para ajudar na definição das especificações, funcionalidades e objetivos dos produtos do projeto. São elas:

•  BRAINSTORMING (tempestade de ideias) – consiste na geração de ideias sem restrições. Qualquer pensamento relacionado ao projeto deve ser coletado. Uma posterior avaliação das ideias surgidas irá classificá-las;
•  CLASSIFICAÇÃO – após a coleta de ideias geradas na técnica de brainstorming, o grupo faz uma análise delas, classificando-as em grupos. A partir dessa priorização, o grupo detalhará as ideias preferidas;
•  TÉCNICA DE DELPHI – consiste em um questionário com perguntas técnicas a fim de descobrir as opiniões de especialistas sobre as especificações do projeto. O processo do método de Delphi começa com a realização de um questionário; posteriormente, as respostas são analisadas e se busca um consenso entre elas, por último agrupa-se o resultado em um resumo final; e
•  MAPA MENTAL – o mapa mental, ou mapa de ideias, é um diagrama usado para gerar e conectar ideias por meio de um arranjo que surge de uma ideia central. O resultado final é uma representação gráfica de como as ideias se organizam em torno de determinado foco de estudo.

e) Técnicas de tomada de decisões em grupo
Técnicas de tomada de decisão é um processo de avaliação das alternativas capazes de atingir o objetivo desejado do projeto. A tomada de decisão pode ser feita de diversas formas: 1. Unânime, quando todos optam por uma única alternativa; 2. Majoritária, quando mais de 50% opta por uma alternativa; 3. Consenso, quando a maioria decide e a minoria concorda em aceitar; 4. Pluralidade, quando o maior grupo opta por uma alternativa mesmo que a maioria não tenha sido atingida; e 5. Ditatorial, quando uma pessoa toma a decisão por todos.

f) Questionário e pesquisa
Técnica de questionamento e pesquisa são perguntas objetivas com a finalidade de acumular informações relevantes de forma rápida e abrangendo um grande número de participantes.

g) Observações
A observação é um meio de analisar diretamente no ambiente de trabalho o desempenho das pessoas que executam determinada tarefa. Esta técnica é usada quando o procedimento a ser analisado tem uma grande complexidade de detalhes, ou quando as pessoas que executam as tarefas têm dificuldade de definir as especificações do trabalho que realizam.

h) Protótipos
Prototipagem é um método usado para obter uma resposta mais rápida sobre os resultados do projeto. O protótipo é um modelo físico do produto final. Quando este é possível de ser realizado, facilita a análise dos resultados, tornando mais ágil o andamento do projeto, principalmente entre as fases de desenvolvimento e de construção do produto.

i) Benchmarking
O benchmarking envolve a comparação de práticas reais ou planejadas, tais como processos e operações, com as de organizações comparáveis para identificar as melhores práticas, gerar ideias para melhorias e fornecer uma base para medir o desempenho. As organizações comparadas durante o benchmarking podem ser internas ou externas.

j) Diagramas de contexto
O diagrama de contexto é um exemplo de modelo de escopo. Os diagramas de contexto descrevem visualmente o escopo do produto mostrando um sistema de negócios (processo, equipamentos, sistema computacional, etc.), e como as pessoas e outros sistemas (atores) interagem com ele. Os diagramas de contexto mostram as entradas no sistema de negócios, o(s) agente(s) que fornecem a entrada, as saídas do sistema de negócios e o(s) agente(s) que recebem a saída.

k) Análise dos documentos
Análise dos documentos é usada para obter requisitos pela análise da documentação existente e a identificação das informações relevantes aos requisitos. Existe uma ampla variedade de documentos que pode ser analisada para ajudar na obtenção dos requisitos relevantes.

Saídas do Processo de Coletar os Requisitos

a) Matriz de Rastreabilidade dos Requisitos
Matriz de Rastreabilidade dos Requisitos é uma tabela que associa cada necessidade de produto, serviço ou resultado (escopo do cliente) ao stakeholder que lhe deu origem, facilitando o acompanhamento de sua conclusão e a obtenção do aceite das entregas no processo de validação do escopo. A implementação dessa Matriz ajuda a determinar se os resultados esperados pelos stakeholders foram realmente atendidos ao gerar determinado deliverable do projeto. Essa Matriz serve, também, de suporte para gerenciar as mudanças de escopo que possam surgir ao longo do projeto. A Matriz associa os requisitos:

• À solução de problemas, ao aproveitamento de oportunidades, ao cumprimento de metas e objetivos da organização;
•  Aos) objetivo(s) do projeto;
•  `As entregas do projeto;
•  Ao desenvolvimento dos produtos finais do projeto.

A Matriz pode possuir atributos associados a cada requisito que irão ajudar no controle, tais como: um identificador único; uma descrição específica a determinado grupo de requisitos; a razão para a inclusão do requisito na lista; o dono (stakeholder solicitante); a prioridade; a versão; o status atual (ativo, cancelado, deferido, aprovado etc.); e a data de conclusão do requisito.

b) Documentação do escopo do cliente (requisitos dos stakeholders)
Essa documentação descreve os produtos, serviços e resultados que irão conduzir ao(s) objetivo(s) final(is) do projeto. As especificações precisam ser consistentes, completas, mensuráveis e testáveis para que possam ser documentadas. Alguns componentes da documentação dos requisitos dos stakeholders podem ser:

• Um problema organizacional a ser revolvido ou uma oportunidade a ser aproveitada, descrevendo as limitações da situação atual e o porquê de o projeto ter sido empreendido;
• Especificações funcionais, descrevendo o processo, as informações e as interações com o projeto;
• Especificações não funcionais, como: serviço, desempenho, segurança, conformidade etc.;
• Requisitos de qualidade;
• Regras da organização, seus princípios e valores;
• O impacto em outras áreas da organização, como call center, área comercial, tecnologia etc.;
• O impacto em outras entidades e/ou sociedades;
• Solicitação de treinamento e suporte.

Essa documentação pode estar refletida em atas de reuniões ou em documentos específicos definidos pela empresa (memorial descritivo; projeto básico; especificação funcional; especificação de serviços etc.).

Devemos tomar cuidado com o óbvio e com o implícito, no que diz respeito ao entendimento do escopo do cliente. Por exemplo:

a) É óbvio que todo treinamento deve ter coffee break, independentemente de ter sido definido como requisito pelo cliente?
b) Está implícita, no fornecimento do equipamento, a entrega do seu manual de operação?

Existe, portanto, uma área cinzenta que contém uma diferença de entendimento do escopo entre o cliente e o projeto. É papel da equipe do projeto diminuir a probabilidade de ocorrer essa diferença. Uma forma de limitar o escopo do cliente é deixar claro o que não é escopo. Por exemplo, no caso do treinamento, deixaríamos claro que não é escopo do projeto o fornecimento da infraestrutura da sala de aula. Temos, portanto, de nivelar as expectativas de escopo entre o(s) cliente(s) e a equipe do projeto. A Figura 3 apresenta um exemplo de expectativas diferentes de escopo entre o cliente e a equipe do projeto.

Figura 3 Expectativas diferentes de escopo

Conclusão
Sabemos da importância de entendermos e documentarmos as necessidades e expectativas dos principais stakeholders do projeto, em especial as do cliente. Vimos neste artigo como que o Guia PMBOK1 trata do assunto por meio de um processo de gerenciamento de escopo denominado “Coletar Requisitos”. Essa coleta de requisitos é a base para definição e estruturação do escopo do projeto, a serem realizadas pelos processos “Definir o escopo”, que gerará a Declaração do Escopo, e “Criar a EAP (Estrutura Analítica do Projeto)”.

Referências

•  PMI, Project Management Institute (Editor). PMBOK (Project Management Body of Knowledge) Guide. Fifth Edition– PMI, 2013.
•  XAVIER, Carlos Magno da Silva et al. Metodologia de Gerenciamento de Projetos – Methodware®: Abordagem prática de como iniciar, planejar, executar, controlar e fechar projetos, Rio de Janeiro, Brasport, 2014.
•  XAVIER, Carlos Magno da Silva. Gerenciamento de Projetos – Como definir e controlar o escopo do projeto, Rio de Janeiro, Editora Saraiva, 2009.

Sobre o colunista:

Carlos Magno da Silva Xavier (Doutor, PMP), Diretor do Grupo Beware – Eleito, em 2010, uma das cinco personalidades brasileiras da década na área de gerenciamento de projetos. É autor/coautor de 14 livros, Doutor em Administração pela Universidad Nacional de Rosário, Mestre pelo Instituto Militar de Engenharia (IME) e certificado Project Management Professional (PMP) pelo Project Management Institute (PMI). É sócio-diretor da Beware Consultoria Empresarial e professor do MBA em Projetos da Fundação Getúlio Vargas desde 2001. Sua experiência profissional, de mais de 20 anos em gestão de projetos, programas e portfólio, inclui a consultoria em várias organizações, como TIM, Marinha do Brasil, BR Distribuidora, Petrobras, Halliburton, SESC-Rio, Eletronuclear, Eletropaulo, Odebrecht, Shopping Iguatemi entre outras.

E-mail de contato: magno@beware.com.br – Site: http://beware.com.br

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.