.png){kind=logo}
A escolha da metodologia certa de gerenciamento de projetos é essencial. Aqui estão as 20 metodologias de gerenciamento de projetos mais populares na prática hoje.
Com a metodologia certa de gerenciamento de projetos, os escritórios de gerenciamento de projetos (PMOs) podem ajudar suas organizações a melhorar os resultados de negócios - mas isso requer mais do que reconhecer as prioridades organizacionais. Para a maioria das empresas, forças externas recentes, como COVID-19 e interrupções da indústria causadas pelo ritmo da mudança digital mudaram as metas e prioridades da empresa, tornando necessário reavaliar se as metodologias de projeto que eles têm em vigor podem alcançar com eficácia e eficiência novos objetivos de negócios enquanto reduz os riscos
Com tantas abordagens diferentes - e em alguns casos, sobrepostas - para gerenciar as complexidades de qualquer projeto, como você pode saber qual metodologia de gerenciamento de projetos é a melhor? Aqui, descrevemos as metodologias de gerenciamento de projetos mais populares na prática hoje, comparando seu foco e princípios.
20 principais metodologias de gerenciamento de projetos
Ao considerar essas metodologias de gerenciamento de projetos, é importante observar que nem sempre há uma solução única em todos os casos, mesmo dentro da mesma organização. A tabela a seguir fornece um breve resumo do foco das 20 metodologias de gerenciamento de projeto mais populares, com os benefícios - e desvantagens - de cada uma definida de forma mais ampla a seguir.
Cascata/Waterfall
Cascata é reconhecida como uma metodologia sequencial tradicional e tem sido a metodologia de gerenciamento de projeto principal por muitos anos. É usado em muitos setores, mas mais comumente no desenvolvimento de software. Inclui fases estáticas (análise de requisitos, design, teste, implementação e manutenção) que são executadas em uma ordem linear específica.
A metodologia Cascata permite maior controle em cada fase. Ele oferece um estágio de planejamento mais formal que pode aumentar as chances de capturar todos os requisitos do projeto antecipadamente. Ele reduz a perda de quaisquer informações e requisitos importantes nos estágios iniciais. Uma desvantagem é que a cascata pode ser altamente inflexível se o escopo de um projeto mudar depois de já estar em andamento.
Ágil/Agile
O Ágil tem uma abordagem significativamente diferente para o gerenciamento de projetos. Ele foi desenvolvido inicialmente para projetos que requerem flexibilidade e velocidade significativas, e tem como foco fornecer melhorias contínuas para entregar soluções de melhor qualidade. Para conseguir isso, o Ágil é composto de ciclos de entrega curtos, também conhecidos como "sprints". O Ágil pode ser mais adequado para projetos que requerem menos controle e mais comunicação em tempo real em configurações de times multifuncionais, auto-organizados e empoderados.
Como metodologia de gerenciamento de projetos, o Ágil é altamente interativo, permitindo ajustes rápidos ao longo de um projeto. É comumente usado em projetos de desenvolvimento de software - mas também pode ser aplicado em outras disciplinas - em grande parte porque torna mais fácil identificar problemas rapidamente e fazer modificações no início do processo de desenvolvimento, em vez de ter que esperar até que o teste seja concluído. O Ágil oferece processos contínuos, reduz o risco, permite feedback imediato, fornece resposta rápida e reduz a complexidade. As desvantagens do Ágil incluem um maior comprometimento de tempo necessário das partes interessadas ao passar por cada iteração e potencialmente menos documentação em comparação com a metodologia Cascata.
Cascata e Híbrido Ágil
Enquanto muitas equipes preferem cascata ou ágil, os benefícios de ambas as abordagens podem criar um caso para uma solução de metodologia de gerenciamento de projeto híbrido, em que a fase de planejamento e requisitos é realizada sob uma abordagem em cascata e o design, desenvolvimento, implementação e as fases de avaliação seguem a metodologia ágil.
Método da corrente crítica (Critical path method - CPM)
CPM é uma metodologia passo a passo usada para projetos com atividades interdependentes. Ele está focado em maximizar as atividades do projeto e encontrar o caminho mais curto (linha do tempo) para o sucesso da tarefa e do projeto usando uma estrutura analítica do projeto (EAP) e uma linha do tempo para concluir, bem como dependências, marcos e resultados finais. Ele descreve atividades críticas e não críticas calculando o tempo “mais longo” (no caminho crítico) e “mais curto” (folga) para concluir tarefas para determinar quais atividades são críticas e quais não são. Uma desvantagem do CPM é que algumas equipes nem sempre reconhecem o caminho crítico, especialmente em projetos maiores e mais complexos.
Gestão de projetos por Corrente Crítica (Critical Chain Project Management - CCPM)
O CCPM difere do CPM por focar no uso de recursos dentro de um projeto em vez das atividades do projeto. Para resolver possíveis problemas com recursos, pulmões (buffers) são integrados para garantir que os projetos sejam pontuais e que a segurança não seja comprometida. É necessário garantir que todos estejam atualizados sobre a cadeia crítica e esforço para obter a adesão de todas as partes interessadas a essa metodologia.
Six Sigma
Six Sigma foi originalmente desenvolvido pela Motorola para eliminar desperdícios e melhorar processos e lucros. É orientado por dados e tem três componentes principais:
DMAIC: Definir, medir, analisar, melhorar e controlar
DMADV: Definir, medir, analisar, projetar e verificar
DFSS: Design for Six Sigma, que pode incluir as opções anteriores, bem como outras, como o IDOV (identificar, desenhar, otimizar e verificar).
Six Sigma às vezes é debatido como uma metodologia na comunidade de gerenciamento de projetos. Esta metodologia adiciona alguma rigidez potencial que pode sufocar a criatividade ou atrasar a entrega do projeto.
Scrum
Batizado com o nome de uma formação de jogo no rugby, Scrum faz parte da estrutura ágil e também é interativo por natureza. “Sessões de Scrum” ou “Sprints de 4 semanas” são usados para determinar tarefas priorizadas. Um Scrum Master é usado como facilitador em vez de um gerente de projeto. Pequenos times podem ser montados para focar em tarefas específicas de forma independente e então se reunir com o Scrum Master para avaliar o progresso ou resultados e priorizar as tarefas acumuladas. Equipes maiores podem ter problemas para se adaptar ao Scrum e pode falhar ou estar sujeito a aumento de escopo, especialmente se todos os membros da equipe não estiverem totalmente engajados e comprometidos. Para evitar duplicação e confusão, as funções precisam ser bem definidas.
Desenvolvimento Lean
Projetado originalmente pela Toyota, o Lean foi desenvolvido para focar na redução do desperdício, maximizando a produção e aumentando o valor para as partes interessadas. Embora o Lean tenha seu início na indústria de manufatura, ele é aplicado em vários setores hoje porque seu foco não é específico do setor. O Lean segue sete princípios-chave: reduzir o desperdício, melhorar a qualidade, compartilhar conhecimento com os outros, permanecer em um estado de melhoria contínua, entregas rápidas, adiar decisões e manter um ambiente de respeito. O Lean depende do comprometimento total das partes interessadas, o que pode ser problemático quando as partes interessadas estão relutantes em mudar ou com medo da mudança. Isso pode resultar em inconsistências na entrega.
Lean Six Sigma
Este híbrido de Lean e Six Sigma enfoca o cliente com o objetivo de melhorar a eficiência e eficácia do negócio na identificação e compreensão de como o trabalho é feito (o fluxo de valor). Lean Six Sigma se esforça para melhorar os processos, remover desperdícios desnecessários e reduzir defeitos, mas pode ser caro e demorado para as empresas implementarem internamente.
Kanban
Kanban se concentra na colaboração contínua e promove um ambiente de aprendizado e aprimoramento contínuos. Ele usa placas visuais e cartões para ajudar as equipes a ver as tarefas que estão concluídas, em andamento e pendentes. Todas as atividades são baseadas na capacidade de visualizar as tarefas diárias, equilibrar cuidadosamente o trabalho em andamento e gerenciar o backlog. Placas sobrecarregadas ou desatualizadas, entretanto, podem criar confusão ou resultar em falha.
Scrumban
Scrumban fornece desenvolvimento de produto e equipes de suporte com os melhores recursos do Scrum e Kanban. Ao combinar o sistema do Kanban e a priorização e ciclos curtos do backlog do Scrum, as equipes não só são capazes de concluir o trabalho de forma rápida e eficaz, mas também melhorar os processos, expondo áreas de fraqueza. Aproveitando os benefícios de ambas as estruturas, as equipes eventualmente reduzem o desperdício, encurtam o tempo de espera, o tempo de resposta e fornecem produtos e serviços de alta qualidade. Voltado para equipes maiores, o sucesso do Scrumban depende de um fornecimento estável de produtos ou componentes e as funções da equipe precisam ser bem definidas.
Metodologia da cadeia de eventos (ECM)
Como uma opção adicional ao CPM ou CCPM, o ECM está focado na identificação, análise e gerenciamento de quaisquer riscos potenciais no início de um projeto. O objetivo é determinar a chance de um risco se tornar realidade, quando pode ocorrer e qual pode ser o impacto no projeto. Existem seis princípios principais que orientam o ECM: identificar uma cadeia de eventos, identificar seu tempo e status, identificar eventos críticos, mapear ou diagramar a cadeia de eventos, monitorar o desempenho da cadeia de eventos e quantificar o impacto. Algumas equipes podem não reconhecer que um evento pode desencadear uma oportunidade em vez de apenas um problema potencial.
Programação extrema (XP)
Esta metodologia visa melhorar a qualidade e a funcionalidade do software conforme as necessidades das partes interessadas mudam. XP usa ciclos de desenvolvimento curtos e requer colaboração constante, devido a lançamentos frequentes. Vantagens: o XP pode fazer maravilhas para a produtividade de uma equipe de projeto que precisa de um alto nível de produção. As equipes são mantidas em alerta e consideram o XP menos focado e estruturado.
Crystal
Como uma abordagem ágil, o Crystal foi desenvolvido pela IBM como uma forma de melhorar os resultados do projeto, concentrando esforços no lado das pessoas dos projetos. Especificamente, o foco é colocado nas especialidades, habilidades e colaboração dos membros da equipe. O Crystal é baseado em duas crenças básicas.
As equipes tendem a identificar e desenvolver melhorias no fluxo de trabalho
Os projetos são únicos, tornando mais provável que as equipes de projeto sejam as mais adequadas para determinar como fazer o trabalho com mais eficácia.
O Crystal pode não ser adequado para algumas equipes remotas devido à necessidade de comunicação próxima e frequente e de brainstorming.
Desenvolvimento orientado a recursos (FDD)
Desenvolvido para projetos de grande escala, mas aplicável a projetos de qualquer tamanho, o FDD ajuda a resolver algumas das complexidades que projetos maiores podem representar, desenvolvendo processos rápidos e contínuos que podem ser realizados em intervalos menores de tempo por várias equipes em uma organização. Essa abordagem segue alguns processos-chave que incluem desenvolver um modelo geral, compilar uma lista de recursos, planejar com base em cada um dos recursos identificados, projetar os recursos e construir os recursos. O FDD pode não funcionar melhor para equipes menores e a documentação escrita limitada das partes interessadas pode se tornar um problema.
Método de desenvolvimento de sistemas dinâmicos (DSDM)
Desenvolvido como uma forma de se alinhar aos objetivos estratégicos de toda a empresa, o DSDM se concentra na entrega de benefícios comerciais comprovados. Esta abordagem se concentra em oito princípios-chave:
A necessidade de permanecer focado nos requisitos de negócios
Entrega dentro do prazo
A colaboração é essencial
Qualidade como prioridade máxima
Construindo de forma incremental com base em pilares sólidos
Usando uma abordagem de desenvolvimento iterativa
Usando comunicação clara e contínua
Mantendo o controle
Implementações caras usando DSDM o tornam menos adequado para empresas menores.
Desenvolvimento de software adaptativo (ASD)
Essa abordagem funciona para ajudar as equipes a se tornarem mais ágeis ao lidar com mudanças. As equipes são incentivadas a permanecer em um estado de aprendizagem contínua para melhorar o desenvolvimento. ASD é construído em três fases: especulação, colaboração e aprendizagem. O ASD requer uma quantidade significativa de recursos e custos mais altos, tornando-o mais adequado para organizações maiores.
Desenvolvimento rápido de aplicações (RAD)
O RAD se concentra na entrada do usuário com base em testes e no quão bem um produto está funcionando em comparação com seus objetivos pretendidos. O RAD primeiro identifica os requisitos, cria protótipos rapidamente e obtém informações do usuário. Em seguida, com base na entrada, identifica requisitos e constrói protótipos novamente. O teste do usuário é então conduzido e o produto final é entregue. O RAD é mais complexo e requer membros de equipe experientes e qualificados que buscam entregar em prazos mais curtos.
Processo Racional Unificado (RUP)
O RUP ajuda as equipes a simplificar o desenvolvimento de produtos e ajuda a reduzir os riscos. Funciona bem em projetos de desenvolvimento de software. É semelhante ao método Cascata, mas o RUP tem quatro fases iterativas: iniciação, elaboração, construção e transição. Cada estágio envolve feedback regular e frequente das partes interessadas enquanto explora ideias e define requisitos. Um problema potencial é que o RUP depende do processo e depende muito do feedback das partes interessadas.
Espiral
Combina a metodologia Cascata e um modo iterativo para facilitar a adaptação das equipes. A espiral é dividida em quatro estágios: análise, avaliação de risco, execução e planejamento. Ele funciona melhor para projetos de longo prazo e de alto risco. Em cada estágio, existem várias avaliações de risco e processos de revisão. A espiral é cara e menos adequada para projetos menores.
Artigo publicado por Moira Alexander e traduzido e adaptado por Esdras Eliwan.