O que são atividades predecessora e sucessora
São termos do gerenciamento de projetos que descrevem a dependência entre tarefas. A predecessora é a atividade que precisa ser concluída antes que outra possa começar. A sucessora é aquela que depende de algo para iniciar. Simples assim.
Como identificar antecessor e sucessor atividade na prática
Na vida real, isso aparece quando você monta uma rede logicamente encadeada. Você pega cada tarefa, olha o que precisa acontecer antes dela, e anota. O resto se constrói a partir daí. Um exemplo bem concreto: você está organizando uma reforma. A predecessora da instalação do piso é a execução daargamassa de assentamento. Sem a argamassa seca, o piso não vai. A sucessora seria a colocação das rodapés, que não faz sentido antes do piso estar no lugar. Anotar isso num papel já resolve metade do problema.
Eu já me vi com problemas porque alguém marcou uma dependência FG (fim-para-início) quando, na realidade, a relação era parcial. A predecessora ainda estava 60% concluída quando a sucessora precisava entrar em campo. O cronograma foi pra trás por causa disso. A correção foi ajustar as dependências para FF com um lag, em vez de FG puro. Perdi uns três dias recalibrando o plano, mas depois ficou coerente.
Diferenças entre os tipos de relacionamento
Existem quatro tipos básicos de ligação entre atividades, e a maioria dos erros começa por confundir eles. FG (fim-para-início): a sucessora só começa quando a predecessora termina. É o mais comum, também o mais ingênuo de usar em massa sem pensar. Funciona para coisas sequenciais simples, mas estraga cronogramas quando aplicado cegamente.
FI (início-para-fim): raro de ver na prática. A predecessora só termina quando a sucessora começa. Aparece em alguns contextos muito específicos, como escalas de operação contínua onde uma turna só encerra quando a próxima entra. II (início-para-início): a sucessora começa junto com a predecessora. Bom para atividades que se sobrepõem naturalmente. Um exemplo é a análise de risco que pode começar enquanto a montagem ainda está em andamento, desde que alguma base já exista.
IF (fim-para-fim): a predecessora só termina quando a sucessora termina. Também é incomum. Costuma aparecer em contratos onde duas equipes precisam fechar juntas para encerrar um bloco de trabalho. O detalhe que ninguém conta: usar apenas FG te dá um cronograma que parece certo no papel mas que nunca reflete a realidade. Misturar II e FI com lags adequados geralmente produz melhores resultados, especialmente em projetos com múltiplas frentes de trabalho.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como montar a rede de atividades corretamente
Primeiro, liste todas as tarefas. Não pule essa parte. Tentar pular e ir direto para o software é o erro mais comum. Depois, para cada atividade, pergunte: o que precisa terminar antes? Anote. O que pode começar junto? Anote também. Em seguida, defina o tipo de dependência para cada par.
Eu costumo fazer isso em uma planilha primeiro. Colunas: tarefa, predecessora, tipo de relação, lag ou lead, e observações. Depois eu importo pro software de gerenciamento. Isso leva cerca de uma hora para um projeto de médio porte, mas evita horas de retrabalho depois. A armadilha: pessoas marcam dependências que não existem. Tipo colocar uma predecessora porque "parece lógico", quando na prática a atividade seguinte pode começar independente. Cada dependência falsa encurta o caminho crítico de forma artificial e distorce todo o cálculo de holguras. Se uma predecessora não for necessária, remova. É melhor ter uma rede sub_dimensionada do que super-restrita.
Erros comuns que eu vejo todo dia
O maior é confiar que o software vai corrigir dependências ruins. O software só processa o que você alimenta. Se a entrada estiver errada, a saída será errada com certeza, só que com aparências de confiança. Outro erro frequente: não considerar lead e lag. Um lead de dois dias numa dependência II pode mudar completamente a duração total do projeto. Um lag de cinco dias num FG pode empurrar a conclusão em semanas. Anotar esses valores na tabela inicial economiza muita dor de cabeça.
Tem também o problema das restrições. Marcar uma tarefa como "deve iniciar até tal data" quando ela tem predecessoras adequadas gera conflito no algoritmo. O software vai tentar resolver, mas o resultado muitas vezes é uma folga negativa disfarçada.
Quando esse método não funciona bem
Em projetos altamente incertos, com escopo mal definido ou mudanças constantes, a rede de predecessores e sucessores perde validade rapidamente. Você passa mais tempo atualizando o cronograma do que usando ele para tomar decisões. Nesse caso, abordagens ágeis ou gestão por marcos costumam ser mais produtivas. Também não se aplica bem quando há centenas de tarefas com dependências praticamente aleatórias. A complexidade torna a manutenção inviável e o ganho em visibilidade é baixo. Nesses cenários, manter um agrupamento macro por fases já entrega informação suficiente sem o custo de rastreamento fino.
Atividades antecessor e sucessor: resolução de casos práticos
Vou dar um exemplo real que enfrentei. Projeto de instalação de infraestrutura de TI para um hospital. Cerca de 180 atividades mapeadas. O problema estava na dependência entre a passagem de cabos e a instalação dos racks. Estava marcado como FG puro, mas na prática a passagem de cabos continuava avançando mesmo depois que os primeiros racks entraram em montagem. O cronograma mostrava uma paralisação que nunca aconteceu. A solução foi converter para II com um lead de cinco dias. Isso significava que a montagem dos racks podia começar cinco dias antes da passagem de cabos terminar completamente. O resultado foi uma redução de 14 dias na duração total, sem risco real, porque as frentes de trabalho não colidiam. O ajuste foi simples, mas exigiu conversar com os coordenadores de obra para confirmar que a sobreposição era viável. Sem essa conversa, o lead seria um palpite.
Outra situação: um empreiteiro insistiu que uma atividade de testes não tinha predecessora definida porque "sempre fizemos assim". O problema era que os testes dependiam implicitamente da calibração de equipamentos. Quando a calibração atrasou, os testes tiveram que recomeçar. Marcar essa dependência explicitamente teria dado aviso antecipado. Depende de documentação do que é implícito no senso de cada equipe. O fundamental é tratar predecessora e sucessora como ferramenta de comunicação, não como obrigação burocrática. Se a rede não ajuda ninguém a tomar decisão, ela é ruído. A regra prática que funciona é: toda dependência marcada precisa ter sido validada com quem executa. Sem essa validação, o número de erros aumenta exponencialmente com a quantidade de atividades.
