Como funciona a relação entre predecessores e sucessores em atividades de projeto
A dependência entre atividades é o que transforma uma lista de tarefas soltas em um cronograma que realmente reflete a sequência lógica do trabalho. Sem isso, você tem apenas uma planilha bonita que não serve para nada quando surge o primeiro imprevisto.
Antecessor e sucessor atividade na prática
Cada atividade no seu cronograma precisa ter pelo menos uma conexão com outra. O antecessor é a tarefa que deve acontecer antes, e o sucessor é aquela que segue. Isso parece óbvio, mas a complexidade real aparece quando você tenta encaixar leads, lags e os quatro tipos de relação. Os tipos básicos são quatro: Termina-Início (FI), onde uma activity só começa depois que a anterior termina; Início-Início (II), onde duas tasks podem correr em paralelo desde que ambas comecem juntas; Termina-Termina (TT), que exige que ambas terminem simultaneamente; e Início-Termina (TI), o mais raro, usado em cenários muito específicos como handoffs de turnos.
No dia a dia, mais de 80% das dependências que eu vejo em projetos são do tipo FI. O resto é distribuição entre II e TT. A relação TI praticamente não aparece fora de contextos regulatórios ou de segurança. Aqui vai algo que poucos explicam direito: o lag não é um atraso indesejado. É uma sobreposição intencional. Se você coloca um lag de menos (-3 dias) numa relação FI, está dizendo que o sucessor pode começar 3 dias antes do antecessor terminar. Isso é chamado de lead, e confundir os dois causa erros absurdos no cálculo do caminho crítico.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu tenho um caso específico que marcou muito. Num projeto de infraestrutura, precisei definir a dependência entre "escavação da fundação" e "forma de concreto". A lógica parecia simples: FI com lag zero. Mas quando olhei o cronograma real, percebi que a concretagem começava 2 dias após o início da escavação, não após o seu fim. Mudar para relação II com lag positivo de +2 dias resolveu. Se eu tivesse mantido o FI tradicional, o caminho crítico estaria distorcido e o projeto mostraria folgas que não existiam de verdade. O problema mais frequente que eu encontro é circularidade. Isso acontece quando dois supervisores ou consultores criam dependências cruzadas sem comunicação. Atividade A aponta para B como predecessora, e B aponta para A como sucessora. O software de planejamento trava ou gera um ciclo infinito no cálculo. A solução imediata é rodar uma verificação de caminhos fechados antes de finalizar qualquer plano. No MS Project, isso é a função "Auditar Dependências". No Primavera P6, o recurso equivalente é o "Logic Review". Não pule essa etapa.
Outro detalhe importante: superdependência. Começar a colocar relação entre todas as atividades só porque parece organizado é um erro comum. Cada vínculo extra consome tempo de manutenção e aumenta a superfície de erro quando há mudanças no escopo. Mantenha apenas o que é logicamente necessário, tecnicamente restritivo ou contratuaimente obrigatório. O restante pode ser gestionado livremente. Quando se trabalha com múltiplos níveis de detalhe, a granularidade das dependências muda completamente. No nível macro, você pode ligar pacotes inteiros usando relações FI agregadas. No nível operacional, cada subtarefa precisa de sua própria rede de predecessores e sucessores. Misturar os dois sem critério gera inconsistências graves na análise de impacto.
Existe ainda a questão dos recursos compartilhados. Duas atividades podem estar logicamente encadeadas, mas o gargalo real é o recurso. Nesse caso, a dependência de recursos (resource leveling) entra em jogo e pode alterar sequências que pareciam fixas. Ferramentas modernas tratam isso automaticamente, mas o resultado nem sempre é o esperado pelo planejador original. Sempre valide o cronograma após o nível de recursos. Para quem está começando, recomendo construir primeiro a rede lógica sem vincular recursos, identificar o caminho crítico inicial, aplicar os recursos e então reajustar. Esse fluxo evita surpresas desagradáveis e reduz o tempo de retrabalho em cerca de 40% comparado à abordagem inversa.
Existem exceções reais onde a dependência lógica não se sustenta. Projetos de pesquisa e desenvolvimento, por exemplo, frequentemente precisam de relacionamentos flexíveis que os softwares tradicionais de gerenciamento de projeto não suportam bem. Nesses casos, Planilhas estruturadas com validação lógica ou ferramentas de simulação como o Pert Master oferecem mais flexibilidade. A relação entre antecessor e sucessor atividade não é só uma formalidade de software. Ela determina a credibilidade do seu cronograma inteiro. Um vínculo mal posicionado pode esconder atrasos críticos por semanas até que a não conformidade se torne impossível de ignorar. Planeje com precisão, revise as conexões periodicamente e mantenha o nível de detalhe compatível com a fase do projeto.
