Compartilhar!

A gestão do escopo é fundamental para qualquer tipo e porte se projetos. Essa área de conhecimento permeia qualquer método de gerenciamento de projetos, incluindo os baseados nos conceitos ágeis. Mas o escopo toma uma dimensão ainda maior no contexto waterfall, onde o planejamento de cada um dos pontos da gestão de projetos se desdobra a partir de uma boa definição do que será produzido.

Planejamento em ondas sucessivas

Normalmente há criticas de que no contexto waterfall 100% dos detalhes precisam estar definidos antes de se iniciar o projeto. Esse erro de conceito é muito comum e começou a ganhar força a partir da proliferação dos métodos ágeis. Quem ainda acha isso não conhece a fundo as características do waterfall e nem do agile. Também não conhece ou nem mesmo ouviu falar do Roling Wave Planing, ou planejamento em ondas sucessivas. Neste conceito os detalhes são incluídos no planejamento em momentos oportunos, conforme as informações são disponibilizadas ou acessíveis.

Um exemplo típico é o da construção civil. Para um bom planejamento é preciso ter a planta do imóvel a ser construído para o cálculo estrutural. Importante saber o número de andares, tipo de construção, quantidade e divisão dos cômodos etc. Mas dá para se fazer um ótimo planejamento desse projeto mesmo sem saber ainda que revestimento será utilizado, que tipo de piso, quantas tomadas, que padrão de janelas etc. É possível começar o projeto e ir definindo os detalhes conforme a obra avança, incluído as informações no planejamento.

Estrutura Analítica do Projeto

A ferramenta mais importante da gestão de escopo é, sem dúvida alguma, a WBS ou Work breakdown Structure. Em português a tradução ficou EAP ou Estrutura Analítica do Projeto, e não expressa, em minha opinião, tudo o que essa ferramenta representa.

Trata-se de uma visão estruturada do escopo do projeto, subdividindo o produto ou serviço em entregas menores e mais gerenciáveis. Essa definição é importante para a o que sempre falo em meus artigos sobre a gestão descomplicada de projetos. A subdivisão tem que produzir entregas MENORES e MAIS GERENCIÁVEIS.

Ou seja, não adianta quebrar o projeto em uma infinidade de entregas menores. Se isso não facilitar a gestão e o controle do que está sendo produzido, terá sido apenas um esforço desnecessário.

Menos é mais também na Gestão do Escopo

Estudos de neurociência indicam que nosso cérebro só consegue lidar com quatro ou cinco coisas simultaneamente. Portanto se a WBS estiver repleta de entregas sendo executadas ao mesmo tempo, pode ter certeza que alguma coisa vai escapar do controle. Mantenha no máximo cinco entregas principais, cada uma com três ou quatro pacotes de trabalho. Com certeza essa estrutura será suficiente para a maioria dos casos.

Baixe um modelo padrão de WBS para ser preenchido com post its.

A Gestão do Escopo e a entrega que não pode faltar

Como afirmei no artigo sobre WBS, uma entrega que é normalmente negligenciada é justamente a gestão do projeto. Essa entrega principal possui entregas intermediárias ou pacotes de trabalho, representando o ciclo de vida com os ritos indispensáveis. Como exemplo temos: Termo de Abertura, Plano do Projeto, ações de Monitoramento e Controle, gestão de mudanças, aceitações e finalização do projeto.

A importância de se registrar essas entregas vai além do respeito ao documento WBS. Essas entregas demandam tarefas, além de consumirem recursos para sua execução. Portanto ao esquecer de registrá-las na EAP o gerente do projeto irá esquecer também de prever as atividades no cronograma. As horas da gestão do projeto e outros recursos como veículos, passagens aéreas para as reuniões etc. também serão esquecidos. Assim, o orçamento do projeto também estará incompleto, pois os custos dessas necessidades não estarão previstas. Não prever as necessidades da própria atividade é talvez o erro mais grosseiro que um gerente de projetos pode fazer.

Dividir para conquistar

A grande maioria dos projetos se encaixa perfeitamente na estrutura enxuta sugerida neste texto. Mas em casos específicos, os projetos maiores e mais complexos deveriam ser divididos em projetos menores e acomodados em programas.

Os projetos grandes que são executados em fases podem, por exemplo, ter cada fase tratada como um projeto separado. Essa simples providencia propicia o aumento de foco naquilo que está sendo executado no momento. Além disso, facilita o controle, uma vez que serão menos entregas para gerenciar.

Para projetos com muitas entregas executadas simultaneamente, o ideal é encontrar uma maneira de quebrá-los em dois ou mais projetos. As entregas podem ser separadas segundo algum critério como por equipe dedicada, área de implantação etc. Por exemplo, para um grande projeto de implantação de ERP, uma possibilidade é quebrar por módulo do sistema. Uma grande reforma pode ser quebrada por área ou departamento e assim por diante. Colocando esses projetos em um programa, o gerente do projeto será o mesmo, porém cada um poderá ter sua equipe. Alguns membros pode ser exclusivos, alguns stakeholders podem ter interesses no programa como um todo, mas outros podem focar em um projeto específico. Assim todos se beneficiam dessa divisão de escopo, tornando cada projeto mais gerenciável e com mais chances de sucesso.

A eterna questão dos requisitos

Uma questão sempre muito esquecida quando se fala em escopo é a gestão de requisitos. Primeiro é preciso entender que quem define os requisitos são os stakeholder. O time de engenharia pode sugerir características e funcionalidades, mas são os principais interessados no produto ou serviço do projeto quem de fato assina embaixo, formalizando o que vai fazer parte do projeto ou não.

Como expliquei em meu artigo “Gestão de projetos – Como descomplicar para obter melhores resultados”, é preciso garantir a rastreabilidade. Para não se perder, o gerente do projeto precisa criar alguma forma de conexão entre os requisitos e seus demandantes. Além disso, requisitos e stakeholders precisam estar conectados às entregas ou pacotes de trabalho que irão produzi-los. Essa conexão inclui os padrões de qualidade, as restrições, premissas e riscos envolvidos na sua execução. A rastreabilidade é importante tanto para se produzir corretamente o que é esperado quanto para garantir que a entrega adequada. O mesmo stakeholder que demandou algum requisito ou alguém formalmente delegado por ele deve participar da aceitação na entrega. Neste momento, independente de ser uma entrega final ou intermediária, as especificações são verificadas e a qualidade é atestada. Assim, há a formalização da entrega para que não haja dúvida quanto a sua finalização.

A gestão do escopo no contexto Ágil

Um gestão do escopo eficaz é fundamental em qualquer situação. No contexto ágil o escopo vai sendo definido e produzido de forma iterativa e as partes finalizadas vão sedo colocadas em funcionamento. É preciso aceitar, no entanto, que nem todo projeto possui características que permitam entregas parciais e funcionais. Não é possível iniciar a execução de uma ponte sem saber o seu projeto todo. Também não dá para entregar um pilar para o cliente ir utilizando, enquanto se produz o restante da ponte. Mas nos projetos onde as entregas parciais são possíveis, essa metodologia é imbatível. O cliente pode se beneficiar comercialmente da antecipação ou mesmo validar o projeto pelo teste parcial.

Já no contexto waterfall, embora os detalhes possam ser definidos ao longo do projeto, o produto só entra em funcionamento após a finalização do mesmo.

Produzindo mais do que o escopo

O mais importante é entender que tanto faz se o escopo é para produzir um produto ou serviço. O que importa é o alinhamento com as expectativas de valor por parte dos clientes e a realização dos resultados de negócio esperados pelos patrocinadores. Assim é possível agradar a todos os principais interessados.

Agora quero saber sua opinião

Você tem gerenciado bem o escopo de seus projetos?

Aplica corretamente e oportunamente os conceitos de escopo iterativo dos métodos ágeis e planejamento em ondas sucessivas dos métodos waterfall?

Consegue discernir e aplicar corretamente cada um dos métodos, entendendo que são ferramentas diferentes para necessidades distintas?

Deixe seu comentário e compartilhe com a gente a sua opinião

Artigo publicado originalmente em 29 de janeiro de 2017 

Bons Projetos e bons negócio!

Paulo Mei

Compartilhar!