Projetos preditivos, ágeis e híbridos: como escolher a abordagem certa

Escolher entre projeto preditivo, ágil ou híbrido não é escolher uma religião de gestão. É decidir quanto do trabalho pode ser definido antes, quanto precisa ser descoberto durante a execução e como a empresa vai controlar as consequências.

Já vi equipe competente perder tempo porque adotou cerimônias ágeis em um trabalho com escopo regulatório fechado. Também vi projeto tratado como plano imutável quando o cliente ainda não sabia explicar o produto que precisava. Em ambos os casos, o problema não estava na capacidade técnica. Estava na escolha da abordagem.

Este é o quinto artigo da série PMBOK sem Burocracia. O índice central está em PMBOK sem Burocracia: série com 40 artigos sobre gestão de projetos.

TL;DR

• A abordagem preditiva funciona melhor quando o escopo pode ser definido com antecedência e mudanças precisam passar por controle formal.
• A abordagem ágil funciona melhor quando o produto será descoberto e refinado por ciclos curtos, com feedback frequente.
• A abordagem híbrida combina estratégias, mas não significa misturar práticas sem critério.
• Em software e ERP, o melhor caminho costuma ser decidido por incerteza, risco, dependências, governança e frequência de feedback.
• O teste mais útil é escolher a abordagem para cada parte do trabalho, não para agradar uma preferência metodológica.
• Antes de iniciar, registre as premissas, os limites de mudança, a cadência de entrega e quem decide quando a realidade divergir do plano.

~ 10 min de leitura · 1649 palavras

🤖 Peça a uma IA resumir e discutir este texto: ChatGPT • Claude.

🎧 Ouvir resumo (30s) — voz gerada por IA, narração dos pontos principais do post.

O problema real: a metodologia virou identidade

O erro começa quando a empresa pergunta “somos ágeis ou tradicionais?” em vez de perguntar “que tipo de incerteza este projeto contém?”. A primeira pergunta cria uma identidade. A segunda ajuda a tomar uma decisão.

Um projeto de implantação de ERP pode ter uma fase preditiva para adequação fiscal, uma fase iterativa para telas operacionais e uma janela de entrada em produção com controle rígido. Uma migração de sistema pode usar ciclos curtos para descobrir regras escondidas no legado, mas exigir um plano detalhado para backup, corte, reconciliação e retorno.

A etiqueta não resolve o problema. O desenho do trabalho resolve.

A abordagem errada produz sinais conhecidos. No modelo preditivo mal aplicado, a equipe passa meses detalhando requisitos que ainda não foram validados. Quando o usuário finalmente vê o sistema, descobre que a interpretação estava errada. No modelo ágil mal aplicado, a equipe entrega incrementos sem uma decisão clara sobre arquitetura, segurança, integração ou operação. O produto cresce, mas a solução fica difícil de sustentar.

Eu prefiro começar por cinco perguntas:

• O resultado pode ser descrito com precisão antes do desenvolvimento?
• O custo de mudar depois é baixo, alto ou proibitivo?
• Existe uma autoridade capaz de dar feedback rápido?
• As dependências externas permitem entregas frequentes?
• A organização precisa demonstrar conformidade, rastreabilidade ou aprovação formal?

As respostas não escolhem tudo sozinhas, mas mostram onde a abordagem precisa ser mais planejada e onde precisa ser mais adaptativa.

Conceito e importância: três respostas para três tipos de incerteza

No PMBOK, a escolha da abordagem de desenvolvimento depende do contexto do projeto. A abordagem preditiva trabalha com planejamento mais detalhado antecipadamente e controle de mudanças ao longo da execução. A abordagem adaptativa, frequentemente associada a métodos ágeis, trabalha com ciclos curtos, aprendizado e refinamento progressivo. A abordagem híbrida combina elementos das duas conforme o trabalho exige.

Isso não significa que um projeto preditivo não possa aprender, nem que um projeto ágil dispense planejamento. A diferença está em onde o planejamento acontece e como a equipe reage a informação nova.

Na abordagem preditiva, a pergunta principal é: como executar com segurança um resultado que já conseguimos definir? O plano, a linha de base, as dependências, os marcos e o processo de aprovação têm peso alto. Ela é adequada quando há requisitos estáveis, sequência de atividades conhecida, contratos fechados, restrições regulatórias ou custo elevado para alterar o resultado.

Na abordagem adaptativa, a pergunta muda: como aprender rapidamente qual solução gera valor? A equipe trabalha com objetivos claros, mas aceita que detalhes serão descobertos. O feedback do usuário modifica a próxima entrega. O escopo pode ser ordenado por valor e risco, em vez de ser completamente congelado no início.

Na abordagem híbrida, a pergunta é: quais partes precisam de previsibilidade e quais partes precisam de aprendizado? O híbrido não é uma licença para juntar cronograma, Scrum, kanban, comitê e planilha sem um modelo coerente. Ele exige fronteiras explícitas. Cada parte do trabalho precisa ter uma forma de decidir, entregar, medir e mudar.

O ponto importante é separar incerteza do produto de incerteza da execução. Um produto ainda desconhecido pede ciclos de descoberta. Uma execução tecnicamente conhecida, mas dependente de uma data regulatória, pede controle de marcos. Confundir os dois gera reuniões, mas não melhora a decisão.

Aplicação prática: um método para escolher sem fazer guerra metodológica

Eu aplicaria a escolha em quatro passos.

Primeiro: dividir o projeto em blocos de resultado. Não avalie apenas “o projeto do ERP”. Separe fiscal, vendas, estoque, compras, integrações, dados, treinamento, infraestrutura e entrada em produção. Cada bloco pode ter nível de incerteza diferente.

Segundo: classificar cada bloco por quatro fatores. Estime a clareza do resultado, a volatilidade dos requisitos, o custo de mudança e a dependência de terceiros. Não é necessário inventar uma escala sofisticada. Baixo, médio e alto já ajudam, desde que a equipe justifique a classificação.

Terceiro: definir o mecanismo de feedback. Um bloco adaptativo sem usuário disponível é apenas improviso. Quem revisará a entrega? Em quanto tempo? Qual evidência será usada? O que acontece se o feedback não vier? A cadência precisa caber na operação real do cliente.

Quarto: estabelecer os limites de decisão. O que pode mudar dentro do ciclo? O que exige aprovação do patrocinador? O que não pode mudar por causa de legislação, contrato, segurança ou operação? Sem esses limites, a abordagem adaptativa vira expansão de escopo disfarçada.

Um quadro simples pode conter: bloco, resultado, abordagem, cadência, responsável pelo aceite, dependências, limite de mudança e indicador de conclusão. Esse quadro é mais útil do que uma discussão abstrata sobre qual método é moderno.

Para escolher entre as alternativas, uso uma regra objetiva:

• Preditivo quando aprender tarde é aceitável, mas mudar tarde é caro.
• Adaptativo quando aprender cedo é essencial e o resultado pode evoluir.
• Híbrido quando essas duas condições aparecem em partes diferentes do mesmo projeto.

A decisão deve ser revisada quando as premissas mudarem. Escolher uma abordagem no início não obriga a mantê-la quando o projeto revela uma realidade diferente.

Exemplo em ERP e software: modernizar sem perder controle

Imagine uma empresa que precisa modernizar um módulo de pedidos de um ERP. O objetivo comercial é reduzir erros de digitação, permitir aprovação por alçada e integrar o pedido ao faturamento. A direção quer a solução em quatro meses.

A parte fiscal e a integração com o faturamento têm dependências e consequências que tornam a mudança cara. Ali eu começaria com uma abordagem mais preditiva: mapear regras, identificar CFOPs envolvidos, definir contratos de integração, documentar critérios de reconciliação e aprovar o plano de corte.

A tela de pedidos e o fluxo de aprovação podem seguir ciclos adaptativos. O usuário pode testar protótipos, comparar a experiência com o processo atual e ajustar campos, filtros e mensagens. Não preciso fingir que sei todos os detalhes antes de o usuário operar a tela.

A entrada em produção exige ainda outro tratamento. Backup, migração, validação de saldos, janela de indisponibilidade, monitoramento e plano de retorno precisam de um checklist com responsáveis e evidências. Uma reunião diária não substitui a comprovação de que o retorno foi testado.

Esse desenho é híbrido porque o trabalho é híbrido. A interface se beneficia de feedback frequente. A integração fiscal exige definição e rastreabilidade. A transição para produção exige controle operacional. Aplicar o mesmo ritual a tudo seria mais simples de explicar, mas pior de executar.

No Posseidom, uma modernização de Web Forms para APIs e Angular teria o mesmo tipo de divisão. Eu não trataria a descoberta das regras do legado como uma lista fechada de telas. Primeiro faria fatias de negócio pequenas, com leitura do código antigo, comparação de comportamento e validação do usuário. Para contratos de API, segurança, migração de dados e observabilidade, estabeleceria padrões antes de ampliar o volume.

A entrega iterativa não elimina uma arquitetura coerente. O planejamento preditivo de uma dependência não impede que a experiência do usuário seja refinada em ciclos. O critério é proteger o que custa caro mudar e aprender cedo onde ainda existe dúvida.

Erros frequentes e como evitá-los

Usar ágil para esconder falta de direção. Sprint não transforma objetivo indefinido em produto útil. Antes do ciclo, defina o resultado esperado, o usuário que valida e a condição de aceite.

Usar preditivo para produzir uma falsa certeza. Um documento detalhado não prova que o requisito foi entendido. Valide o resultado com protótipo, exemplo de dados e conversa com quem trabalha no processo.

Chamar qualquer mistura de híbrida. Se ninguém sabe qual parte é preditiva, qual é adaptativa e quem decide a transição, não há modelo híbrido. Há práticas acumuladas.

Confundir mudança controlada com resistência à mudança. Controle não significa rejeitar toda alteração. Significa medir impacto em custo, prazo, risco, qualidade e valor antes de aprovar.

Ignorar a capacidade do cliente de participar. Feedback frequente exige pessoas disponíveis e com autoridade. Sem isso, o projeto acumula pendências e chama o atraso de adaptação.

Medir atividade em vez de resultado. Número de reuniões, histórias encerradas ou documentos produzidos não prova valor. Relacione a medição a comportamento do usuário, qualidade, risco reduzido e resultado operacional.

Escolher uma abordagem para o projeto inteiro por conveniência. A empresa pode querer uma regra única para simplificar governança. Ainda assim, vale separar blocos quando o custo da simplificação for maior que o benefício.

Reflexão final e próxima ação

Eu não escolheria uma abordagem para parecer atualizado, nem para preservar uma tradição. Escolheria olhando para a natureza do trabalho, para o custo da mudança e para a velocidade com que a organização consegue aprender. A decisão precisa ser visível, revisável e ligada a um resultado.

A próxima ação é prática: pegue um projeto ativo, divida-o em cinco a dez blocos de resultado e registre, para cada um, clareza, volatilidade, custo de mudança, dependências e mecanismo de feedback. Se a equipe não conseguir explicar por que um bloco é preditivo, adaptativo ou híbrido, ainda não entendeu o trabalho.

É assim que eu uso o PMBOK: não como uma coleção de rótulos, mas como uma forma de tornar decisões de projeto mais explícitas. A abordagem correta não elimina a incerteza. Ela impede que a empresa finja que a incerteza não existe.

Leitura relacionada

• O que é PMBOK e por que todo profissional deveria conhecê-lo — a abertura da série.
• Por que projetos fracassam mesmo com profissionais competentes — a diferença entre domínio técnico e gerenciamento.
• O gerente de projetos na era da inteligência artificial — decisão humana em projetos apoiados por IA.

A série continua no próximo artigo com integração: como coordenar um projeto inteiro sem transformar o plano em uma coleção de tarefas isoladas.