Coletar Requisitos: O novo processo de gerenciamento de escopo proposto no Exposure draft

Resumo: O Project Management Institute (PMI) divulgou, em fevereiro deste ano, para comentários da comunidade mundial de gerenciamento de projetos, o rascunho da 4ª edição do PMBOK, a ser lançado no quarto trimestre de 2008. Uma das alterações propostas, em relação à edição anterior, é a criação de um processo de gerenciamento de escopo denominado “Coletar os Requisitos”, tradução livre para “Collect Requirements”. 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, é incumbência da área de Gerenciamento de Escopo. Em fevereiro o Project Management Institute (PMI) divulgou, para comentários da comunidade mundial de gerenciamento de projetos, o rascunho da 4ª edição do PMBOKÒ, a ser lançado no último trimestre deste ano. Esse documento continha os seguintes processos para o Gerenciamento do escopo do projeto: 

• • Coletar os requisitos – define e documenta as características dos produtos e serviços do projeto que irão satisfazer as necessidades e as expectativas dos stakeholders, assim como gera o Plano de Gerenciamento de Requisitos.
  • Definir o escopo – desenvolve uma declaração detalhada do escopo do projeto.
  • Criar a EAP (Estrutura Analítica do Projeto)- é o processo necessário para subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
  • Verificar o escopo – formaliza a aceitação das entregas concluídas do projeto.
  • Controlar o escopo – consiste em monitorar o status do escopo do projeto e controlar as suas mudanças.

Na figura 1 podemos verificar a interação desses processos e as principais informações de entrada e saída dos mesmos.

Figura 1 – Os processos de gerenciamento de escopo em um projeto

Uma das alterações propostas em relação à edição anterior foi a criação de um processo de gerenciamento de escopo denominado “Coletar Requisitos”, tradução livre para “Collect Requirements”. 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.

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.

Tabela 1 – Registro dos stakeholders do projeto

O Processo de Coletar os Requisitos

 O primeiro processo de planejamento do escopo é o Processo de Coletar os Requisitos. Este processo, 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. A visão que eles têm do escopo do projeto é o que o PMBOK chama de requisitos. 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 2 mostra graficamente que o escopo para o cliente é parte do escopo do projeto.

Figura 2 – Escopo do projeto X Escopo para o cliente

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 projeto³.

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 3 representa as entradas, técnicas e ferramentas e as saídas do Processo de Coletar Requisitos de acordo com o rascunho do PMBOK.

Figura 3 – Os componentes do Processo de Coletar os Requisitos

As Entradas para o processo de Coletar os Requisitos

O Processo de Coleta dos Requisitos dos Stakeholders começa com a análise das informações contidas no Project Charter (Termo de Abertura do Projeto) e no Registro dos Stakeholders.

Project Charter (Termo de Abertura do Projeto)

O Termo de Abertura do Projeto é onde se encontra os objetivos gerais e a descrição dos produtos do projeto, ambos importantes para entender as exigências dos Stakeholders.

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. Um modelo foi visto anteriormente neste artigo.

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

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.

Grupo de foco

O grupo de foco tem 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 onde o objetivo é extrair, o mais naturalmente possível, o desejo final das partes interessadas.

Workshops

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 excelentes maneiras de criar comprometimento, relacionamento, e consenso entre osstakeholders do projeto, com isso, melhorar a comunicação entre os mesmos, 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.

Técnicas criativas de 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 Idéias) – Consiste na geração de idéias sem restrições. Qualquer pensamento relacionado ao projeto deve ser coletado. Uma posterior avaliação das idéias surgidas irá classificá-las;
• CLASSIFICAÇÃO – Após a coleta de idéias geradas na técnica de Brainstorming, o grupo faz uma análise das mesmas, classificando-as em grupos. A partir dessa priorização o grupo detalhará as idéias 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 das mesmas, sendo por último agrupado o resultado em um resumo final; e
• MAPA MENTAL – O mapa mental, ou mapa de idéias, é um diagrama usado para gerar e conectar idéias através de um arranjo que surge de uma idéia central. O resultado final é uma representação gráfica de como as idéias se organizam em torno de um determinado foco de estudo.

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.

Técnicas de questionamento 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.

Técnicas de Observação

A observação é um meio de analisar diretamente no ambiente de trabalho o desempenho das pessoas que executam uma 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.

Protótipos

Prototipação é um método usado para se 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.

As Saídas do Processo de Coletar os Requisitos

Plano de Gerenciamento do Escopo (requisitos do cliente)

Nesse documento ficará definido o processo como os requisitos dos stakeholders (escopo para o cliente) serão analisados, documentados, e gerenciados no decorrer do projeto. Alguns componentes do Plano de Gerenciamento do Escopo podem ser:

• Como as atividades de coleta de requisitos serão planejadas, controladas e reportadas;
• Quem po­de so­li­ci­tar al­te­ra­ções no es­co­po do cliente.
• De que ma­nei­ra (via for­mu­lá­rio pa­drão ou soft­wa­re) o pe­di­do de­ve ser fei­to.
• Quem irá ava­liar o im­pac­to des­sas al­te­ra­ções e, se for o ca­so, sua re­per­cus­são nos pro­je­tos que pos­suam in­ter­de­pen­dên­cia.
• Quem au­to­ri­za ou não es­sas al­te­ra­ções.
• Os ní­veis de au­to­ri­za­ção, de acor­do com o im­pac­to das al­te­ra­ções (se for o ca­so).
• Fre­quên­cia de ava­lia­ção do es­co­po do pro­je­to.
• Fre­quên­cia de atua­li­za­ção do pla­no de ge­ren­cia­men­to de es­co­po.

 Por exem­plo, em um pro­je­to de soft­wa­re, vo­cê po­de­rá de­ter­mi­nar que, se o clien­te so­li­ci­tar uma al­te­ra­ção de de­sign que cus­ta­rá me­nos de R$ 500,00, o ge­ren­te do pro­je­to po­de­rá apro­var o tra­ba­lho, mas, se a al­te­ra­ção cus­tar mais, so­men­te o che­fe do de­par­ta­men­to co­mer­cial po­de­rá fa­zê-lo.

Ca­so uma pro­pos­ta de mu­dan­ça al­te­re o es­co­po es­ta­be­le­ci­do no pro­ject char­ter ou na Matriz de Rastreabilidade de Requisitos, a au­to­ri­za­ção de­ve ser con­ce­di­da por quem as­si­nou o do­cu­men­to cor­res­pon­den­te. O pla­no de ge­ren­cia­men­to de es­co­po de­ve ser as­si­na­do pe­lo ge­ren­te do pro­je­to e pe­los prin­ci­pais sta­ke­hol­ders, no ní­vel de ge­rên­cia, que es­ta­rão en­vol­vi­dos na so­li­ci­ta­ção, ava­lia­ção ou au­to­ri­za­ção de al­te­ra­ções.

Matriz de Requisitos

Matriz de Requisitos é uma tabela que associa cada necessidade de produto, serviço ou resultado (escopo do cliente) ao stakeholder que deu origem à mesma, facilitando o acompanhamento de sua conclusão e a obtenção do aceite das entregas no processo de verificação de escopo. A implementação dessa matriz ajuda a determinar se os resultados esperados pelos stakeholders foram realmente atendidos ao gerar um 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, aproveitamento de oportunidades, cumprimento de metas, e objetivos da organização;
• Ao(s) objetivo(s) do projeto;
• Ás 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 para um 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.

Um modelo de Matriz de Requisitos consta da tabela 2.

Tabela 2 – Matriz de Requisitos

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ê que o projeto foi empreendido;
• Especificações funcionais, descrevendo o processo, as informações, e as interações com o projeto;
• Especificações não funcionais, como por exemplo, 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:

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

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 infra-estrutura da sala de aula. Temos, portanto de nivelar as expectativas de escopo entre o(s) cliente(s) e a equipe do projeto. A Figura 4 apresenta um exemplo de expectativas diferentes de escopo entre o cliente e a equipe do projeto.

Figura 4 – 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 rascunho da 4ª edição do PMBOK 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)” os outros dois processos de planejamento do PMBOKÒ.

Referências

1. PMI, Project Management Institute (Editor). PMBOK (Project Management Body of Knowledge) Guide Fourth Edition Exposure Draft – PMI, 2008.
2. 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, 2005.
3. XAVIER, Carlos Magno da Silva. Gerenciamento de Projetos – Como definir e controlar o escopo do projeto, Rio de Janeiro, Editora Saraiva, 2005.

Sobre o Colunista:

Carlos Magno da Silva Xavier foi eleito em 2010 uma das cinco personalidades brasileiras da década na área de gerenciamento de projetos, sendo autor / coautor de onze (11) livros. É 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 da CMX Capacitação Profissional, sendo professor do MBA em Projetos da Fundação Getúlio Vargas desde 2001. Sua experiência profissional, de mais de vinte anos em gerenciamento de projetos, inclui consultoria e treinamento em várias Organizações (TIM, BR Distribuidora, Petrobras, Halliburton, SESC-Rio, Eletronuclear, Eletropaulo, Odebrecht, Shopping Iguatemi e 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.