Dependências de atividades em cronogramas: o que funciona na prática
Você já tentou montar um cronograma onde as atividades dependem umas das outras e acabou com um caminho crítico que não faz sentido? O problema mais comum não é a teoria, é a execução. Quando você define atividade antecessor e sucessor, precisa entender como o software realmente processa isso, não apenas o conceito básico.
O básico que todo mundo explica mal
Antecessor é a atividade que deve ser concluída (ou iniciada) antes que outra possa começar. Sucessora é a que vem depois. Existem quatro tipos de relacionamento no método de caminho crítico: Final-Início (FS), Início-Início (SS), Final-Final (FF) e Início-Final (SF). FS é o mais comum. SF é o que menos se vê e causa confusão. Aqui está algo que poucos ensinam: o tipo de relacionamento escolhido altera drasticamente o caminho crítico, mesmo quando os tempos das atividades permanecem iguais. Eu já vi projetistas escolherem SS entre duas tarefas que deveriam ser FS simplesmente porque "parecia mais flexível". O resultado foi um cronograma otimista demais e um atraso real de três semanas na entrega. O software mostrou tudo certo no plano. Só na execução apareceu o problema.
Como configurar na prática
A maioria das ferramentas segue o mesmo padrão. Você adiciona atividades, define suas durações e depois estabelece as dependências. No MS Project, isso fica na aba Atribuir Recursos, campo Antecessores. No Primavera P6, é a aba Atividades com a coluna Dependências. O que as pessoas erram é o delay. Delay é o ajuste fino entre antecessor e sucessor. Um delay positivo atrasa a sucessora. Um delay negativo adianta. Muita gente esquece que delay funciona de forma diferente conforme o tipo de relacionamento. Em FS, um delay de +2 dias significa que a sucessora começa 2 dias após o fim da antecessora. Em SS, o mesmo delay significa que a sucessora inicia 2 dias após o início da antecessora. Isso muda completamente a lógica.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Meu processo habitual é o seguinte. Primeiro, listo todas as atividades sem pensar em dependências. Depois, defino as lógicas manualmente, uma a uma, justificando cada escolha. Só então deixo o software fazer o cálculo automático. Pular esse passo gera dependências espúrias que inflacionam o caminho crítico e criam folgas ilusórias.
Um caso real que quebra todo mundo
Trabalhei num projeto de infraestrutura onde tínhamos uma atividade de fundação (antecessora) e uma de superestrutura (sucessora). A lógica era FS com lag negativo de 5 dias, porque a supervisão queria que a montagem começasse antes da cura total do concreto. O software processou tudo corretamente, mas o caminho crítico passou a conectar atividades que, na prática, não tinham restrições reais entre si. A folga total das atividades intermediárias caiu a zero, e qualquer variação mínima travava o cronograma inteiro. A solução foi inserir uma restrição de início mais cedo na atividade de superestrutura e quebrar a relação direta com a fundação. Assim, o software recognheceu a sobreposição real sem inflacionar artificialmente o caminho crítico. O cronograma voltou a refletir a situação real em vez de uma artefato matemático.
Erros que vejo sempre
O erro número um é definir todas as dependências como FS. Nem toda atividade precisa esperar o fim da anterior para começar. Às vezes, basta o início. O erro número dois é ignorar dependências externas. Se uma aprovação governamental precisa vir antes de uma licitação, isso precisa constar como antecessora, mesmo sendo uma atividade de dummy ou de marco. O erro número três é o mais sutil: aplicar atividade antecessor e sucessor de forma circular. O software normalmente rejeita o ciclo, mas quando a rede é grande o suficiente, dependências implícitas se formam e o cálculo do caminho crítico fica comprometido. Verifique sempre se existe algum loop antes de apresentar o cronograma para approval.
Quando o método não serve
Dependências de atividade funcionam bem para projetos de construção, desenvolvimento de software e engenharia clássica. Elas falham em contextos onde as tarefas são altamente dependentes de variáveis externas imprevisíveis, como mudanças regulatórias, condições climáticas sazonais ou aprovações de terceiros sem prazo definido. Nesses casos, o cronograma baseado em antecessor e sucessor dá uma sensação falsa de controle. A alternativa é usar estimativas baseadas em simulação de Monte Carlo, que mostram intervalos de probabilidade em vez de datas fixas. Outro ponto fraco é a sensibilidade a mudanças. Uma alteração na duração de uma atividade no início do projeto pode recalibrar todo o caminho crítico e exigir revisão completa de todas as dependências subsequentes. Isso consome tempo e gera atrito com stakeholders que acham que o cronograma é estável. Mantenha um log de alterações e justifique cada mudança de lógica, porque a documentação é o que diferencia um profissional de alguém que apenas preenche campos em software.
