O objetivo deste artigo é fornecer a você tudo o que você precisa saber sobre Estruturas Analíticas de Projeto (EAP) ou em inglês, Work Breakdown Structure (WBS) para que você possa melhorar a maneira como planeja, gerencia e controla seus projetos e programas, caso seja essa sua atribuição nesse momento.
O PMBOK define uma EAP como:
“Uma decomposição hierárquica orientada a entregas do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do projeto e portanto, criar as entregas necessárias. A EAP define o escopo total do projeto.”
Uma maneira mais fácil de pensar em EAP / WBS, é semelhante a uma árvore genealógica, ou seja, uma estrutura em árvore que mostra a subdivisão dos componentes necessários para entregar um projeto ou programa. Esse tipo de estruturas analíticas são muito úteis para estabelecer um acordo entre as partes interessadas e os membros da equipe do projeto quanto ao escopo do projeto.
Em um sentido geral, podemos pensar na WBS da seguinte forma:
Como começar?
Se pensarmos em iniciar um projeto, começamos com um termo de abertura do projeto (TAP) , ou project charter, e uma declaração de escopo preliminar. Isso define os objetivos de alto nível e as entregas do projeto. Em seguida, iniciamos o documento de escopo do projeto que define melhor essas entregas em uma lista de todas as entregas e os requisitos de cada uma. O próximo passo é usar esta lista abrangente de entregas para construir a EAP/WBS.
A EAP/WBS detalhará todo o escopo do trabalho necessário para concluir o projeto. A EAP pode então ser usada para estimar o custo do projeto, programar recursos e planejar os sistemas de garantia da qualidade. Essencialmente, a WBS permitirá que você gerencie melhor seu projeto.
Alguns exemplos de WBS
A melhor maneira de entender as estruturas analíticas do projeto é por meio de alguns exemplos. Veremos dois exemplos, um que analisa os componentes que compõem um carro e outro que analisa os componentes que compõem um projeto. Em primeiro lugar, vamos olhar para os componentes que compõem um carro.
No topo da WBS está o nome do projeto ou programa, neste caso, Carro. O nível mais baixo de qualquer WBS é sempre chamado de nível do pacote de trabalho. Assim, no exemplo acima, o Chassis 4.0 é um pacote de trabalho para entregar o Chassis em sua totalidade para o carro.
Agora vamos considerar a WBS para o Projeto:
Aqui podemos ver que o projeto é composto de quatro fases: Planejamento e Requisitos, Design, Construção e Entrega (meramente ilustrativo, apenas para fins de explicação).
Uma maneira de pensar sobre esses dois exemplos é que o exemplo Carro está mostrando o “o quê” (os componentes do carro), e o exemplo Projeto está mostrando o “como” (os componentes necessários para entregar um projeto genérico).
Chegando a um ponto onde podemos começar a planejar
Fazemos isso usando o processo de decomposição. A decomposição é composta por um processo de 5 etapas:
- Identifique todas as principais entregas do projeto . Uma maneira de fazer isso é envolver a equipe do projeto como um time para identificar todas as principais entregas da declaração do escopo do projeto.
- Organize a EAP / WBS (vamos abordar a seguir)
- Defina os componentes EAP / WBS . Aqui decompomos as principais entregas definidas na etapa 1 em componentes de nível inferior.
- Atribuir códigos de identificação . Isso pode ser feito simplesmente anexando um número a cada um dos componentes da WBS. Todos os exemplos que usei têm códigos de identificação anexados.
- Verifique a EAP / WBS . Aqui validamos a EAP quanto à exatidão. Faça a si mesmo e à equipe perguntas como “todos as entregas estão claras?” Todos os componentes estão completos? Cada entrega é absolutamente necessária? A decomposição descreve suficientemente a entrega que precisa ser realizada?
É muito trabalhoso fazer isso, mas é realmente benéfico se você estiver nos estágios iniciais de gerenciamento de seu projeto ou programa. Ao desdobrar as entregas, você pode identificar áreas que, de outra forma, não teria notado até mais tarde na execução do projeto. Isso aumenta a probabilidade de você acertar as coisas com antecedência e impede que as equipes fiquem frustradas porque você não pedirá que elas mudem as coisas várias vezes durante o projeto.
Organizando a WBS
O PMBOK afirma que você pode organizar a WBS de várias maneiras:
- Principais entregas e subprojetos: aqui as principais entregas do projeto ou programa são usadas como o primeiro nível de decomposição. Esta é a abordagem que usamos para o exemplo Car acima.
- Subprojetos executados fora da equipe do projeto: você pode pensar nisso como fluxos dentro de um programa. Por exemplo, se em um fluxo for lançar o produto globalmente, o gerente de projeto de distribuição poderá definir a EAP para esse componente. Muitas vezes, um subprojeto será terceirizado.
- Fases do projeto: usando esta técnica, cada fase do projeto seria listada no primeiro nível de decomposição, com as entregas de cada fase listadas no próximo nível. Esta é a abordagem que usamos para o exemplo do Project anteriormente.
- Abordagem de combinação: esta é uma combinação dos métodos organizacionais, por exemplo, você pode ter subprojetos listados no primeiro nível, com as principais entregas de cada um listado no segundo nível.
Quando parar?
Não enlouqueça ao criar suas estruturas analíticas de projeto. O que você está tentando fazer é definir o trabalho do projeto ou programa para que você possa planejar, gerenciar e controlar mais facilmente esse trabalho. Você só deve decompor o plano em um nível que permita atingir esse objetivo.
EAP/WBS e Ágil
Tendo lido até aqui, você pode estar pensando que as EAPs são muito antiquadas e não se aplicam aos metódos ágeis. No entanto, a WBS também se aplica ao Agile. Uma WBS ágil é organizada em torno da funcionalidade do usuário final. Aqui, os recursos são decompostos em épicos (epics), os épicos em histórias de usuários (user stories) e as histórias de usuários são decompostas em funcionalidades (backlog) que podem ser implementadas em uma única iteração. Como uma user story individual é atômica, os stories podem ser adicionadas ou removidos da WBS, desde que a soma do trabalho ainda possa ser implementada em um sprint (considerando o método Scrum).
Identificadores exclusivos da WBS
É uma boa prática atribuir um identificador exclusivo a cada nível da WBS. Por exemplo, podemos usar o seguinte com base no exemplo Car que vimos anteriormente:
Pacotes de trabalho (Workpackages)
Como mencionado anteriormente, o nível mais baixo em uma WBS é um pacote de trabalho. Pacotes de trabalho são componentes que podem ser facilmente entregues a uma pessoa, equipe ou subcontratado, que então tem responsabilidade e responsabilidade pela entrega do pacote de trabalho.
Em programas ou grandes projetos, um pacote de trabalho pode estar em um nível que exija decomposição adicional em sua própria estrutura analítica do trabalho. O detalhamento do pacote de trabalho pode ser feito pela equipe do projeto para esse pacote de trabalho ou até mesmo por um fornecedor externo.
Dicionário WBS
É aqui que todas as descrições dos componentes de trabalho são documentadas. Cada componente dentro do dicionário deve incluir o seguinte:
- O código-identificador
- Declaração de trabalho, descrevendo o trabalho que compõe o componente
- Milestones
- Pessoa/Organização responsável por completar o componente
Linha de base do escopo (Scope Baseline)
Agora que você criou a Estrutura Analítica do Projeto, você está pronto para definir a linha de base do escopo do projeto ou programa que está gerenciando. A linha de base do escopo do seu projeto ou programa é definida como a declaração de escopo do projeto aprovada, a estrutura analítica do projeto e o dicionário da EAP.
Princípios de design ao construir estruturas de analíticas de projeto
Ao construir estruturas de divisão de trabalho, há algumas regras gerais que você precisa saber para mantê-lo no caminho certo:
- A Regra 100%: A WBS deve definir o escopo total do projeto. Se isso não acontecer, os planos que você criar a partir da WBS, por inferência, terão lacunas e entregas faltantes.
- Exclusividade Mútua: não deve haver sobreposição entre quaisquer dois elementos em uma WBS. Se houver, você corre o risco de duplicar o trabalho na execução do projeto
- Inclua entregas, não ações: não vou entrar em detalhes (você já fez bem em ler até aqui), mas essa é uma das melhores maneiras de seguir a regra dos 100%
- Use o bom senso: como mencionado anteriormente, não entre em muitos detalhes. O que você procura são detalhes suficientes para planejar, gerenciar e controlar o projeto.
Conclusão
Espero que este artigo tenha dado a você tudo o que você precisa saber sobre estruturas de divisão de trabalho (WBS), que você possa ver o valor nelas e que fique claro para você como aplicar essas informações ao seu próximo projeto ou programa. Lembre-se de que o maior benefício de uma estrutura analítica do projeto é estabelecer um entendimento comum de todo o trabalho necessário para entregar o projeto ou programa. Sinta-se à vontade para entrar em contato comigo se tiver alguma dúvida.
Acompanhe-nos em todas as plataformas sociais:
—- Sobre NX2IN, Joel Junior, MsC, PMP é um profissional da área de gestão com carreira desenvolvida em empresas multinacionais desde a posição de estagiário até a gerência.
Com mais de 19 anos de experiência, é apaixonado pela proposta de profissionais ACIMA DA MÉDIA com ampla experiência em consultoria empresarial, transformação digital e no treinamento e mentoria para jovens e profissionais experientes do mercado.
A partir de 2021, se dedicando a compartilhar através da web suas ideias para profissionais que desejam experimentar uma carreira ACIMA DA MÉDIA.
—-
Você precisa fazer login para comentar.