Como O Modelo OSCAR Pode Transformar Sua Carreira
- Opening : Mon-Fri 08:00 - 17:00
Menu
Fechar
O Guia PMBOK® define em seu glossário:
“Requisito / Requirement. Uma condição ou capacidade que deve ser atendida ou possuída por um sistema, produto, serviço, resultado ou componente para satisfazer um contrato, uma norma, uma especificação ou outro documento impostos formalmente. Os requisitos incluem necessidades, desejos e expectativas quantificados e documentados do patrocinador, do cliente e de outras partes interessadas.” (PMI, p. 442)
“Critérios de aceitação / Acceptance Criteria. Os critérios, inclusive requisitos de desempenho e condições essenciais, que devem ser atendidos antes que as entregas do projeto sejam aceitas.” (PMI, p.425)
Requisitos são “necessidades, desejos e expectativas quantificados e documentados”. Ou seja, as expectativas das partes interessadas só são consideradas no plano do projeto quando tiverem sido quantificadas e documentadas na forma de requisitos aprovados para serem incluídas no escopo do projeto (supus “necessidades” e “desejos” incluídos no termo “expectativas”).
Ou seja, nem toda expectativa será quantificada ou aprovada, portanto, atendida pelo escopo do projeto ou fase. É de fundamental importância, portando, que a Matriz de Rastreabilidade de Requisitos documente quais expectativas se tornaram requisitos de fato, e que o Patrocinador e outras partes interessadas relevantes confirmem a lista de requisitos aprovada.
Alguns requisitos serão satisfeitos pela realização de entregas e por isso devem ser mapeados na Matriz de Rastreabilidade de Requisitos aos critérios de aceitação e entregas que os satisfarão.
Outras expectativas e requisitos não são “mapeáveis” em entregas e critérios de aceitação. Exemplo: “o projeto deve terminar em menos de seis meses”. O leitor conhecedor do Guia PMBOK® dirá: “Mas isto é uma restrição”, e de fato o Guia PMBOK ® define em seu glossário:
“Restrição / Constraint [Entradas]. O estado, a qualidade ou o sentido de estar restrito a uma determinada ação ou inatividade. Uma restrição ou limitação aplicável, interna ou externa, a um projeto, a qual afetará o desempenho do projeto ou de um processo. Por exemplo, uma restrição do cronograma e qualquer limitação ou condição colocada no cronograma do projeto que afeta o momento em que uma atividade do cronograma pode ser agendada e geralmente esta na forma de datas impostas fixas.” (PMI, p. 442)
Ocorre que mesmo uma restrição nasce como uma expectativa (p.ex., “terminar rapidamente” que precisa ser quantificada (“em 6 meses”) e que pode ou não ser aprovada quando analisada em conjunto com as outras expectativas e requisitos. Documentar o processo de avaliação de requisitos incluindo as (potenciais) restrições no mesmo processo de “Coletar requisitos” é a sugestão do autor deste blog para os colegas gerentes de projeto.
Em alguns casos, um critério de aceitação pode ser mais facilmente gerenciado se for representado também como uma restrição. P.ex., uma entrega pode ter como critério de aceitação ser entregue até uma data limite, caso contrário, a entrega será rejeitada, pois não tem mais utilidade. Uma restrição adicionada ao cronograma sobre o marco que representa a entrega fará com que o cálculo das datas e do caminho crítico já considere esta restrição e, portanto, facilite o gerenciamento da realização do critério de aceitação associado a esta restrição. Incluir na Matriz de Rastreabilidade de Requisitos todos os relacionamentos entre expectativas, requisitos, critérios de aceitação e restrições que forem representados nas linhas de base de escopo, prazo, custo e qualidade.
E as premissas? As premissas manifestam expectativas da equipe de gerenciamento do projeto, que também é parte interessada no projeto. As premissas podem então ser representadas na Matriz de Rastreabilidade de Requisitos como expectativas e requisitos da equipe de gerenciamento. Acrescentar as premissas na Matriz de Rastreabilidade de Requisitos não é prática mencionada no Guia PMBOK®, nem é prática comum hoje, porque também não é prática comum reconhecer a equipe de gerenciamento do projeto como parte interessada com direito (ou seja, fonte) de requisitos. No entanto, relacionar as premissas com os requisitos de outras partes interessadas será útil quando for necessário abandonar alguma premissa (p.ex., “o projeto pode ser concluído no prazo limite definido como restrição desde que tais e tais premissas sejam satisfeitas”), e usar a Matriz de Rastreabilidade de Requisitos para este relacionamento evita a criação de mais um documento. Para o leitor, fica o exercício de (re)ler a descrição do processo 5.1 Coletar os Requisitos no Guia PMBOK® 4.a edição, imaginando a inclusão da equipe de gerenciamento entre as partes interessadas que fornecem premissas como requisitos.
A seguir: “Até onde descer na EAP (WBS)?”
Conheça melhor Fernando Dias e veja seus outros artigos e contribuições para nossa Comunidade de GPs.
MONTES, Eduardo. Introdução ao Gerenciamento de Projetos, 1ª Ed. São Paulo; 2017.
Dias, F. R. T. Gerenciamento dos Riscos em Projetos. Rio de Janeiro: Elsevier, 2014
Fundamentos sobre riscos de projetos
Entradas e Saídas dos Processos do Guia PMBOK®
Verifique nas entradas seus Modelos/Templates e exemplos
Ferramentas de Riscos do Guia PMBOK®
Artigos sobre gerenciamento dos riscos
Grupos de interesse em projetos
Compartilhar :
