O que é o método do caminho crítico?

O método do caminho crítico, também conhecido como Critical Path Method ou CPM, é uma técnica utilizada para analisar a sequência de atividades de um projeto e identificar quais delas determinam sua duração. Para isso, precisamos conhecer as atividades, suas durações e, principalmente, as relações lógicas existentes entre elas.

O PMI explica essa construção de forma bastante clara em materiais sobre planejamento de cronograma. Em Moving from the WBS to a Critical Path Schedule , por exemplo, o instituto mostra a sequência lógica que parte dos entregáveis do projeto, passa pela identificação das atividades, pelas dependências entre elas e pelas estimativas de duração até chegar ao caminho crítico.

Isso significa que um cronograma não deveria ser apenas uma lista como esta:

• Atividade A — 1 a 5 de maio;
• Atividade B — 6 a 10 de maio;
• Atividade C — 11 a 15 de maio.

As datas são importantes, mas elas contam apenas parte da história. Eu também preciso saber por que B está depois de A, se B realmente depende de A e o que acontece com C caso B não termine na data prevista.

Em outro material, o Critical Path Method Calculations , o PMI entra mais profundamente na lógica do CPM e mostra como relações entre atividades, durações, datas de início e término e valores de folga são utilizados para calcular o caminho crítico.

É aqui que aparece uma das primeiras conclusões importantes: uma tarefa estar atrasada não significa automaticamente que o projeto está atrasado. Da mesma forma, uma tarefa estar dentro do prazo não significa automaticamente que o projeto está saudável. Tudo depende da posição daquela atividade dentro da rede do projeto e do impacto que uma variação nela pode provocar nas atividades seguintes.

Antes do caminho crítico, precisamos entender as dependências entre tarefas

Para identificar um caminho crítico minimamente confiável, precisamos primeiro entender as dependências entre as atividades. Uma dependência existe quando o início ou o término de uma atividade está relacionado ao início ou término de outra.

É um conceito simples, mas extremamente importante. Pense, por exemplo, em uma equipe que precisa concluir o desenvolvimento de uma API para que outra equipe consiga começar uma integração. Enquanto a API não estiver disponível, a segunda atividade pode simplesmente não ter condições de avançar.

O guia de dependências de projetos da Atlassian trata exatamente dessa relação entre tarefas e mostra como dependências podem afetar sequência de trabalho, recursos e cronograma. A Asana também possui um guia bastante completo sobre dependências em projetos , incluindo dependências lógicas, de recursos, preferenciais e externas.

Embora as classificações possam variar dependendo do contexto utilizado, existe uma estrutura técnica clássica para representar as relações de precedência entre atividades. Nela encontramos quatro tipos principais: Finish-to-Start, Finish-to-Finish, Start-to-Start e Start-to-Finish.

Os quatro tipos de dependência entre atividades

A relação mais comum é a Finish-to-Start — Término para Início. Uma atividade precisa terminar para que outra possa começar. É o exemplo do desenvolvimento que precisa ser concluído para que determinado teste possa ser iniciado.

Em uma relação Finish-to-Finish — Término para Término, o término de uma atividade está relacionado ao término de outra. Já em uma relação Start-to-Start — Início para Início, o início de uma atividade depende do início de outra. A quarta possibilidade, Start-to-Finish — Início para Término, é menos comum e ocorre quando uma atividade não pode terminar até que outra atividade tenha começado.

A própria documentação da Asana sobre tipos de dependência utiliza essas relações para explicar como tarefas podem bloquear ou depender umas das outras.

Para mim, porém, mais importante do que decorar os quatro nomes é entender o princípio por trás deles: uma atividade pode alterar o momento em que outra atividade consegue começar ou terminar. E, quando várias dessas relações são encadeadas, um problema aparentemente pequeno pode se propagar por uma parte significativa do projeto.

Como identificar o caminho crítico de um projeto?

Não quero transformar este artigo em uma aula de cálculo de cronograma, porque não é esse o objetivo. Mas precisamos entender minimamente como chegamos ao caminho crítico.

Primeiro, precisamos conhecer as atividades necessárias para produzir as entregas do projeto. Depois identificamos as dependências entre essas atividades e estimamos suas durações. Com essas informações, conseguimos montar uma rede lógica, identificar os diferentes caminhos que levam do início ao fim do projeto e calcular quanto tempo cada sequência necessita.

Em termos simplificados, imagine que temos três caminhos possíveis:

• A → B → C → entrega = 20 dias;
• D → E → entrega = 12 dias;
• F → G → H → entrega = 16 dias.

Se nada mais interferir no planejamento, a sequência A → B → C merece atenção especial porque é ela que está determinando a duração da entrega. O PMI explica que as atividades do caminho crítico possuem nenhuma ou pouca margem para sofrer atrasos sem afetar o término do projeto. Em Moving from the WBS to a Critical Path Schedule , essa relação entre dependências, duração, folga e caminho crítico é tratada de maneira bastante didática.

Isso não significa que podemos simplesmente ignorar todas as outras atividades. Uma atividade que hoje possui folga pode começar a consumi-la e eventualmente se tornar crítica. Além disso, projetos reais possuem recursos compartilhados, fornecedores, mudanças de escopo, decisões técnicas, aprovações, equipes diferentes e dezenas de outras variáveis capazes de modificar aquilo que havíamos planejado.

É justamente por isso que eu não gosto de enxergar o cronograma como uma fotografia. O cronograma é um modelo que precisa ser acompanhado durante a execução porque a realidade do projeto continua mudando.

Uma dependência não é necessariamente um risco

Aqui existe uma distinção que considero muito importante: dependência e risco não são a mesma coisa.

Imagine novamente que uma equipe precise terminar uma API antes que outra consiga começar uma integração. A dependência existe. Mas, se a API está avançando normalmente, possui uma estimativa confiável, existe capacidade suficiente na equipe e ainda temos folga antes do início da integração, talvez aquela dependência não represente uma ameaça relevante naquele momento.

Agora imagine que a API deveria estar praticamente concluída, mas sua estimativa já foi alterada duas vezes. Existem subtarefas que ainda não foram estimadas, a pessoa responsável está envolvida em várias outras entregas, a sprint está entregando abaixo do planejado e a integração que depende da API praticamente não possui folga.

A dependência continua sendo exatamente a mesma. O risco associado a ela mudou completamente.

Esse é um dos pontos em que a discussão sobre dependências começa a se aproximar da gestão de riscos. Um material particularmente interessante do PMI é Project Interdependency Management . O trabalho apresenta uma prática para identificar, validar, analisar, acompanhar e reportar interdependências externas entre projetos e as trata como parte do universo de riscos do projeto.

O que considero mais interessante nessa abordagem é que a dependência não é simplesmente identificada no início do projeto e esquecida. Ela precisa continuar sendo acompanhada, porque aquilo de que dependemos também muda ao longo do tempo.

O problema não é apenas a dependência. É o efeito em cadeia.

Talvez uma das coisas mais perigosas na gestão de projetos seja analisar atividades individualmente. Imagine que A permita começar B. B permita começar C e D. C precise terminar para E começar, enquanto D precisa terminar para F começar. No final, E e F são necessárias para uma entrega importante ao cliente.

Se A atrasar, a informação “A está dois dias atrasada” não é suficiente para que eu entenda o problema. Eu quero saber até onde esses dois dias conseguem se propagar. Quero saber quanta folga existe depois dela, quais atividades serão impactadas, quais equipes dependem da entrega e se o atraso possui capacidade de chegar até a data final.

Esse é um dos motivos pelos quais considero perigoso avaliar a saúde de um projeto simplesmente contando quantas tarefas estão atrasadas. Dez tarefas atrasadas podem ter pouco impacto sobre uma entrega. Uma única atividade crítica atrasada pode comprometer o projeto inteiro.

O próprio PMI, em Scheduling High-Tech Projects , discute uma limitação importante do caminho crítico calculado de maneira determinística: quando existe incerteza nas estimativas, diferentes caminhos podem acabar se tornando críticos. Ou seja, aquilo que hoje parece ser a principal sequência do projeto não deveria ser analisado sem considerar também o risco existente nas atividades.

O risco deveria ser percebido antes do atraso

É aqui que, para mim, a discussão fica ainda mais interessante. O PMI publicou um material chamado Risk-Based Scheduling and Analysis , que propõe analisar risco no nível individual das atividades, ajustar o cronograma considerando essas incertezas e então verificar como o risco pode modificar o próprio caminho crítico.

O princípio continua extremamente atual: não deveríamos esperar o atraso acontecer para começar a olhar para o risco daquela atividade.

Só que muitas vezes fazemos exatamente o contrário. Primeiro uma tarefa atrasa. Depois alguém percebe que outra tarefa não conseguiu começar. Em seguida aparece um desvio no cronograma, o projeto passa de verde para amarelo, alguém registra um risco e então começamos a discutir uma mitigação.

Existe um problema óbvio nessa sequência: quando uma atividade que dependia da anterior já não conseguiu começar, talvez aquilo não seja mais apenas um risco. O problema já começou a acontecer.

Então, como descobrir antecipadamente que uma atividade pode atrasar?

É aqui que acredito que precisamos sair um pouco da visão puramente estática do cronograma e começar a observar o comportamento real do projeto. Se uma atividade crítica deveria terminar daqui a duas semanas, eu não quero esperar essas duas semanas para descobrir se teremos um problema. Quero procurar sinais durante a execução.

Posso começar verificando se a atividade está parada há tempo demais, se o esforço consumido já está muito próximo ou acima da estimativa, se a estimativa mudou durante a execução ou se existem atividades importantes que nem sequer foram estimadas. Também posso observar se o volume de trabalho em andamento aumentou demais, se existem bloqueios, se uma única pessoa está concentrando trabalho excessivo ou se a velocidade da equipe está se deteriorando.

Em equipes ágeis, existem ainda outros sinais interessantes. O planejado da sprint pode estar cada vez mais distante do realizado. Atividades semelhantes podem estar demorando consistentemente mais do que o previsto. Bugs e regressões podem aumentar, provocando retrabalho. Determinados tipos de atividade podem estar consumindo muito mais esforço do que costumavam consumir.

Nenhum desses indicadores, isoladamente, prova que a atividade irá atrasar. Mas vários sinais acontecendo ao mesmo tempo podem começar a contar uma história.

É o mesmo princípio que utilizo quando falo de produtividade. Como expliquei no artigo Como medir a produtividade do seu time e como melhorá-la , olhar para um único KPI normalmente não é suficiente para entender o comportamento de uma equipe. Precisamos analisar o contexto e a combinação dos dados.

Algumas dependências deveriam ser descobertas antes da tarefa começar

Existe ainda outro problema: muitas dependências são descobertas tarde demais porque a atividade começou sem que alguém tivesse analisado se ela realmente estava pronta para ser executada.

Imagine descobrir durante o desenvolvimento que precisamos de uma API que ainda não existe, de uma aprovação que ninguém solicitou, de uma definição do cliente que nunca foi obtida ou de outra equipe que nem sequer sabia que dependíamos dela. Tecnicamente, encontramos uma dependência. Na prática, porém, encontramos tarde demais.

É por isso que, quando trabalho com uma Definition of Ready, uma das perguntas que considero importantes é justamente se as principais dependências da atividade já foram identificadas. Esse é um dos pontos que aprofundo no artigo DoR e DoD no Scrum: entenda Definition of Ready e Definition of Done .

Quanto mais cedo uma dependência relevante é conhecida, mais opções temos. Podemos mudar a sequência de execução, conversar com outra equipe, solicitar a aprovação antes, preparar uma alternativa técnica ou até decidir que aquela atividade ainda não deveria entrar na sprint.

Dependency mapping ajuda a enxergar o que normalmente fica escondido

Uma prática interessante para tornar essas relações mais visíveis é o dependency mapping. A Atlassian possui um exercício específico de Dependency Mapping cuja proposta é identificar fatores que podem impedir o sucesso de uma iniciativa, entender como o trabalho de uma equipe afeta outras partes da organização e criar ações antes que esses problemas aconteçam.

A ideia é importante porque uma dependência não existe apenas entre dois tickets. Podemos depender de outra equipe, de uma pessoa específica, de uma aprovação, de um fornecedor, de uma API, de uma infraestrutura, de uma decisão arquitetural, de uma definição do cliente, de outro projeto ou até de uma decisão executiva.

A Asana, em seu material sobre dependências , também chama atenção para dependências de recursos e externas, além das puramente lógicas. Isso é relevante porque nem todos os riscos aparecem simplesmente desenhando uma seta entre duas atividades dentro de um board.

Mapear essas relações melhora bastante a visibilidade do projeto, mas ainda deixa uma segunda pergunta sem resposta: como saber quais dessas dependências estão começando a ficar perigosas?

Uma dependência pode ser tratada como risco antes de virar um problema

Essa é uma abordagem que aparece também fora do PMI. Em How to Manage Dependencies and Assess Risks , a Tempo propõe justamente olhar para dependências como possíveis riscos, permitindo que o time trabalhe sobre elas antes que se transformem em problemas concretos.

Eu gosto dessa lógica porque ela muda nossa postura. Em vez de simplesmente registrar “Equipe B depende da entrega da Equipe A”, começamos a perguntar qual é a situação da Equipe A, quando aquela capacidade precisa estar disponível, que sinais indicam uma possível dificuldade e qual será o impacto sobre nossa entrega caso ela não aconteça como esperado.

É uma mudança pequena na maneira de fazer a pergunta, mas enorme na capacidade de gestão. Uma dependência deixa de ser apenas uma linha ligando duas atividades e passa a ser algo cuja saúde precisa ser acompanhada.

O board conhece as tarefas. Mas quem está olhando o projeto?

Jira, Azure DevOps, Asana, Monday.com e ClickUp cumprem um papel extremamente importante. É nessas plataformas que as equipes registram atividades, responsáveis, estimativas, sprints, status, datas, dependências e grande parte da execução do trabalho.

O desafio aparece quando o projeto cresce. Podemos ter centenas ou milhares de atividades distribuídas entre várias equipes, projetos e tipos de trabalho. Nesse cenário, encontrar uma tarefa atrasada não é necessariamente difícil. A pergunta difícil é outra:

“O que está acontecendo hoje que pode fazer minha entrega atrasar daqui a três semanas?”

Para responder a isso, eu não quero olhar apenas para a data final de uma tarefa. Quero entender como aquela atividade está evoluindo, como atividades semelhantes se comportaram, se o time está entregando aquilo que planejou, se existem problemas nas estimativas, se o trabalho está concentrado em poucas pessoas, se existem sinais de retrabalho e se começam a aparecer desvios relevantes de esforço, produtividade ou custo.

Em outras palavras, o board continua sendo fundamental para organizar o trabalho. Mas existe uma diferença entre acompanhar tarefas e interpretar o que os dados dessas tarefas estão dizendo sobre a saúde do projeto.

É aqui que entra o Saint Jude Project Intelligence

Esse é justamente um dos motivos pelos quais criamos o módulo de riscos do Saint Jude Project Intelligence .

O Saint Jude não foi criado para substituir Jira, Azure DevOps, Asana, Monday.com ou ClickUp. Essas plataformas continuam sendo o lugar em que as equipes organizam e executam o trabalho. O Saint Jude trabalha em uma camada diferente: ele utiliza os dados desses projetos para ajudar gestores, PMOs e lideranças a interpretar o que está acontecendo e encontrar sinais que merecem atenção.

No módulo de riscos, o gestor pode estruturar e acompanhar os riscos do projeto e manter um histórico de sua evolução. Mas existe uma parte que considero ainda mais interessante: a inteligência artificial do Saint Jude pode analisar o progresso real do projeto para gerar riscos e sugerir planos de ação baseados nas informações encontradas.

Isso significa que sinais como uma sprint entregando abaixo do planejado, atividades sem estimativas, problemas na qualidade da escrita das atividades, diferenças relevantes entre esforço e entrega ou outros padrões encontrados durante a execução podem deixar de ser informações espalhadas entre dezenas ou centenas de tickets e passar a fazer parte de uma análise de risco.

O gestor continua tendo autonomia para criar seus próprios riscos e planos de ação, porque nem todo risco está dentro de um board. Existem decisões políticas, mudanças estratégicas, informações de clientes, negociações comerciais e fatores externos que nenhuma integração consegue descobrir sozinha.

O objetivo não é retirar o gerente da decisão. É dar a ele mais informação e, principalmente, mais tempo para decidir.

A diferença entre identificar um risco e explicar um atraso

Para mim, existe uma diferença enorme entre dizer “seu projeto atrasou porque a atividade X terminou oito dias depois do esperado” e dizer “a atividade X está apresentando sinais de que pode comprometer a próxima entrega”.

A primeira frase é útil. Ela explica o passado e pode nos ajudar a evitar que o mesmo problema aconteça novamente. Inclusive, esse é o tipo de análise que trato em Como encontrar a causa raiz dos problemas do seu projeto .

Mas a segunda frase tem uma característica diferente: ela ainda permite uma decisão antes da consequência. Talvez eu consiga mudar uma prioridade, realocar uma pessoa, dividir o escopo, conversar com outra equipe, renegociar uma dependência ou informar o stakeholder antes que aquilo se transforme em uma surpresa.

Project Intelligence não elimina riscos. Ela aumenta o tempo que você tem para reagir.

Eu não acredito que exista plataforma, metodologia ou gerente capaz de eliminar todos os riscos de um projeto. Projetos envolvem incerteza. Pessoas mudam, estimativas erram, fornecedores atrasam, prioridades são alteradas, clientes mudam de opinião e tecnologias falham. Dependências continuarão existindo independentemente da ferramenta que utilizamos.

A diferença está em quando descobrimos que alguma coisa está indo na direção errada.

Se eu descubro um problema no momento em que a entrega deveria acontecer, tenho poucas opções. Se descubro algumas semanas antes, talvez consiga mudar uma prioridade, realocar profissionais, reduzir ou dividir o escopo, renegociar uma dependência, alterar a sequência do trabalho, envolver outra equipe ou criar um plano de mitigação.

No final, gestão de riscos também é gestão do tempo disponível para tomar decisões.

E talvez essa seja uma das principais diferenças entre acompanhar um cronograma e realmente entender um projeto. O método do caminho crítico ajuda a identificar quais sequências de atividades determinam nossas entregas. As dependências mostram como essas atividades estão conectadas. A gestão de riscos procura entender o que pode impedir que aquilo que planejamos realmente aconteça.

Project Intelligence adiciona uma quarta camada a essa equação: usar os dados que o projeto já produz para procurar sinais de que alguma coisa está começando a sair do esperado.

Porque o objetivo não deveria ser apenas descobrir por que uma entrega atrasou. Isso continua sendo importante, mas já é passado.

O objetivo deveria ser perceber, enquanto ainda existe tempo para fazer alguma coisa, o que pode fazer essa entrega atrasar.

E, muitas vezes, a resposta começa em uma tarefa aparentemente pequena que outra tarefa está esperando terminar.

E você? No seu projeto, você sabe quais atividades realmente podem comprometer a data final ou só descobre quando elas já estão atrasadas?

Até mais!

Erik Scaranello