Dependências de Tarefas: FS, SS, FF e SF Explicadas

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Dependências de tarefas definem a ordem em que o trabalho do projeto pode acontecer. Erre nelas e seu cronograma desmorona; acerte e sua equipe sabe exatamente quando cada parte do trabalho pode começar, se sobrepor ou esperar.
Existem quatro tipos lógicos de dependência: finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) e start-to-finish (SF). Cada um descreve uma relação específica entre o fim ou o início de uma tarefa e o fim ou o início de outra. Este artigo cobre os quatro tipos, explica lead time e lag time, e percorre as quatro categorias de dependência que todo gerente de projetos precisa conhecer.
O que são dependências de tarefas?
Uma dependência de tarefa é uma relação lógica entre duas tarefas que determina quando uma pode começar ou terminar em relação à outra. Em softwares de cronograma e no diagrama de rede de gerenciamento de projetos, as duas tarefas em uma dependência são chamadas de predecessora (a tarefa que vem primeiro na relação) e sucessora (a tarefa que é restringida por ela).
Dependências não são o mesmo que sequência de tarefas. Sequência é a ordem em que as coisas acontecem. Dependência é a razão lógica pela qual acontecem nessa ordem. Essa distinção importa porque algumas tarefas podem se sobrepor, outras precisam esperar que outras terminem, e algumas situações raras exigem que uma tarefa comece antes que sua predecessora possa parar.
Principais Fatos
- O Project Management Institute relata que o sequenciamento ruim de cronograma está entre as três principais causas de estouro de prazo em projetos, contribuindo para impactos de custo em 37% dos projetos globalmente (PMI Pulse of the Profession, 2023).
- Um estudo da McKinsey constatou que grandes projetos de construção e TI ultrapassam o cronograma em uma média de 20%, com a má gestão de dependências citada como causa raiz primária (McKinsey Global Institute, 2017).
- Técnicas de compressão de cronograma como fast-tracking, que dependem de sobrepor intencionalmente tarefas dependentes, são usadas em 60% dos projetos atrasados para recuperar tempo (PMI, 2022).
Os quatro tipos de dependências de tarefas
A maioria das ferramentas de cronograma, incluindo Microsoft Project e Rework, suporta os quatro tipos de relação lógica definidos pelo Project Management Body of Knowledge (PMBOK). Aqui está cada um com um exemplo em linguagem simples.
| Tipo | Nome completo | Regra | Exemplo real |
|---|---|---|---|
| FS | Finish-to-Start | A sucessora só começa depois que a predecessora termina | Você precisa concretar a fundação (Tarefa A) antes de poder erguer as paredes (Tarefa B). A Tarefa B não pode começar até que a Tarefa A esteja concluída. |
| SS | Start-to-Start | A sucessora só começa depois que a predecessora começa | Um desenvolvedor começa a escrever código (Tarefa A), e um redator técnico pode começar a rascunhar a documentação (Tarefa B) assim que a codificação começa. Ambas rodam em paralelo a partir do mesmo ponto de início. |
| FF | Finish-to-Finish | A sucessora só termina depois que a predecessora termina | Os testes (Tarefa A) e a correção de bugs (Tarefa B) precisam terminar juntos. Você não pode encerrar os testes até que as correções finais estejam completas. |
| SF | Start-to-Finish | A sucessora só termina depois que a predecessora começa | Um segurança do turno da noite (Tarefa B) só pode sair depois que o substituto da manhã (Tarefa A) começa o turno. SF é o tipo mais raro na prática. |
FS é o padrão. A vasta maioria das relações de tarefas em um projeto típico é finish-to-start. Se você não tem certeza de qual tipo usar, FS quase sempre é a escolha certa.
SF é a exceção. SF aparece com mais frequência em manufatura just-in-time e cenários de troca de turno. Se você se encontra usando SF com frequência, isso geralmente significa que a lógica do cronograma precisa ser repensada.
Categorias de dependência e lead vs lag
Além dos quatro tipos lógicos, toda dependência também se encaixa em uma de quatro categorias que descrevem por que a relação existe. E toda dependência pode ser ajustada com tempo de lead ou lag para tornar o cronograma mais realista.
Categorias de dependência
| Categoria | Definição | Quem a controla |
|---|---|---|
| Obrigatória | Uma restrição física ou contratual que não pode ser alterada. Também chamada de "lógica dura". | Realidade externa |
| Discricionária | Uma sequência preferida baseada em boas práticas ou preferência da equipe. Pode ser alterada se necessário. Também chamada de "lógica flexível". | Equipe do projeto |
| Externa | Depende de algo fora do projeto, como uma entrega de fornecedor, aprovação regulatória ou aceite do cliente. | Terceiros |
| Interna | Depende de algo dentro do projeto ou organização. Geralmente discricionária, mas nem sempre. | Projeto + organização |
Saber se uma dependência é obrigatória ou discricionária é importante durante a compressão de cronograma. Você pode fazer fast-track (sobrepor) dependências discricionárias; você não pode fazer fast-track em dependências obrigatórias. O artigo fast-tracking vs crashing explica essa troca em detalhes.
Lead time e lag time
Lag time adiciona um período de espera entre predecessora e sucessora. Se você precisa de dois dias para o concreto curar antes que a estrutura possa começar, isso é um lag de dois dias em uma dependência FS.
Lead time permite que uma sucessora comece antes que sua predecessora termine. Se você modelar isso como lag negativo, um lead de três dias em uma dependência FS significa que a sucessora pode começar três dias antes de a predecessora terminar. É assim que a compressão de cronograma funciona na prática.
Tanto lead quanto lag são expressos nas mesmas unidades do cronograma do projeto (dias, horas ou porcentagem da duração da predecessora).
Por que as dependências de tarefas importam
Dependências são o tecido conjuntivo de um cronograma de projeto. Veja o que dá errado sem elas.
Equipes começam trabalho que não conseguem concluir. Se a Tarefa B começa antes de a Tarefa A estar concluída, a equipe trabalhando em B pode bater em uma parede no meio da tarefa e ter que esperar ou refazer o trabalho. Isso gera desperdício e frustração.
O caminho crítico se torna invisível. O método do caminho crítico só funciona se as dependências forem mapeadas corretamente. Uma dependência ausente significa que o algoritmo calcula a duração mínima do projeto errada, e seu cronograma já está errado antes mesmo de começar.
O float desaparece. Os cálculos de float e slack dependem inteiramente de uma lógica de dependência precisa. Se as dependências estiverem erradas, você não saberá quais tarefas realmente têm margem de manobra.
Mudanças se propagam de forma imprevisível. Quando uma tarefa atrasa, suas sucessoras atrasam também. Mas somente se as dependências estiverem mapeadas. Sem elas, você não verá o efeito cascata até que seja tarde demais para reagir.
Erros comuns
Estes são os erros de dependência que aparecem com mais frequência em projetos reais.
Usar FS em tudo por hábito. Nem toda tarefa é finish-to-start. Recorrer a FS por padrão quando SS ou FF seriam mais precisos cria um cronograma artificialmente longo e torna o trabalho paralelo invisível.
Pular dependências discricionárias. Às vezes as equipes modelam apenas a lógica dura e deixam de lado a lógica flexível porque "é flexível mesmo". Mas dependências flexíveis não documentadas significam que um futuro membro da equipe pode reordenar tarefas de formas que quebram a qualidade ou as boas práticas.
Ignorar dependências externas. Se um fornecedor precisa entregar materiais antes que sua equipe possa instalá-los, isso é uma dependência FS externa. Deixar isso de fora significa que o cronograma mostra a instalação começando antes mesmo de a entrega ter sido solicitada.
Adicionar dependências a recursos, não a tarefas. Uma armadilha comum é vincular tarefas porque a mesma pessoa faz ambas, não porque o próprio trabalho exige sequenciamento. Restrições de recursos devem ser tratadas por nivelamento de recursos, não pela invenção de dependências de tarefas. A fase de estrutura analítica do projeto é um bom momento para separar essas duas questões.
Não revisar dependências após mudanças de escopo. Quando o escopo muda, algumas dependências se tornam irrelevantes e novas surgem. Uma auditoria de dependências é parte padrão do seu processo de controle integrado de mudanças.
Como mapear dependências de tarefas
Passo 1: Liste todas as tarefas da sua EAP
Comece com uma estrutura analítica do projeto completa. Você não pode mapear dependências em tarefas que ainda não identificou. Todo entregável deve ser decomposto em pacotes de trabalho antes de você começar a sequenciar.
Passo 2: Identifique a predecessora de cada tarefa
Percorra sua lista de tarefas e pergunte: "o que precisa acontecer, ou pelo menos começar, antes que esta tarefa possa começar ou terminar?" Algumas tarefas não têm predecessoras (podem começar a qualquer momento). A maioria tem uma ou duas. Poucas podem ter várias.
Passo 3: Atribua o tipo de relação correto
Para cada par predecessora-sucessora, decida se a relação é FS, SS, FF ou SF. Pergunte a si mesmo: é o término ou o início da predecessora que dispara a sucessora? E é o início ou o término da sucessora que é disparado?
Passo 4: Adicione lead ou lag onde necessário
Se houver uma espera obrigatória entre tarefas (tempo de cura, período de aprovação, prazo de envio), adicione lag. Se a sucessora puder começar antes de a predecessora terminar, adicione lead. Seja honesto aqui: lag inflado esconde float real, e lead irreal prepara as equipes para retrabalho.
Passo 5: Valide com a equipe e construa o diagrama de rede
Peça para as pessoas que executam o trabalho revisarem o mapa de dependências. Elas identificarão erros de lógica mais rápido do que qualquer PM sozinho em sua mesa. Uma vez validadas, as dependências se tornam a base do seu diagrama de rede, da sua análise de caminho crítico e do seu gráfico de Gantt.
Exemplos de dependência de tarefas
Aqui estão três cenários comuns de projeto mostrando como as dependências aparecem na prática.
| Projeto | Tarefa A (predecessora) | Tarefa B (sucessora) | Tipo de dependência | Notas |
|---|---|---|---|---|
| Lançamento de software | Revisão de código concluída | Deploy começa | FS (obrigatória) | Não é possível fazer deploy de código não revisado. Nenhuma compressão possível. |
| Campanha de marketing | Redação de anúncios começa | Concepção de design começa | SS (discricionária) | Ambas podem rodar em paralelo assim que a direção do texto for definida. Lead de dois dias adicionado para o design ter uma vantagem inicial sobre os conceitos. |
| Entrega de obra | Inspeções de punch-list terminam | Certificado de ocupação emitido | FF (externa) | A autoridade certificadora não emite o certificado até que todas as inspeções estejam encerradas. Ambas terminam juntas. |
Boas práticas
Faça:
- Use o tipo de dependência que reflete a lógica real do trabalho, não apenas a conveniência do cronograma.
- Documente por que cada dependência discricionária existe. Uma breve nota no cronograma do projeto economiza horas de confusão depois.
- Revise as dependências sempre que escopo, recursos ou prazos mudarem.
- Use a análise de float e slack depois de mapear as dependências para encontrar onde o cronograma tem flexibilidade.
- Vincule seu mapa de dependências ao seu documento de planejamento do projeto para que os stakeholders entendam a lógica do cronograma.
Não faça:
- Adicionar dependências para forçar restrições de recursos. Use nivelamento de recursos para isso.
- Esquecer dependências externas. Entregas de fornecedores, aceites regulatórios e aprovações de clientes são riscos reais de cronograma.
- Presumir que todas as dependências são finish-to-start. Um cronograma construído inteiramente em relações FS quase certamente é mais longo do que precisa ser.
- Usar SF a menos que você tenha um cenário genuíno de troca de turno ou just-in-time. Isso confunde a maioria dos membros da equipe e a maioria das ferramentas de cronograma.
- Pular a revisão da equipe. A lógica de dependência que parece correta no papel muitas vezes desmorona quando as pessoas que executam o trabalho a analisam.
Perguntas frequentes
Qual é o tipo de dependência de tarefa mais comum?
Finish-to-start (FS) é de longe o mais comum. Ele reflete a sequência de trabalho mais natural: a Tarefa A precisa terminar antes que a Tarefa B possa começar. Na maioria dos cronogramas de projeto, FS representa de 70% a 90% de todas as relações de tarefas.
Qual é a diferença entre uma dependência obrigatória e uma discricionária?
Uma dependência obrigatória (lógica dura) reflete uma realidade física ou contratual que não pode mudar, como a exigência de concluir os testes antes de lançar um produto. Uma dependência discricionária (lógica flexível) reflete uma sequência preferida baseada em boas práticas ou julgamento da equipe, e pode ser alterada se o cronograma precisar de compressão.
Uma tarefa pode ter múltiplas predecessoras?
Sim. Muitas tarefas dependem de várias predecessoras terminando ou começando antes de poderem começar. Em um diagrama de rede de gerenciamento de projetos, isso aparece como múltiplas setas convergindo em um único nó de tarefa. A tarefa não pode começar (ou terminar, dependendo do tipo) até que todas as condições predecessoras sejam atendidas.
O que é lag time versus lead time?
Lag time adiciona um atraso depois que a condição da predecessora é atendida. Lead time (lag negativo) permite que a sucessora comece antes que a condição da predecessora seja totalmente atendida. Ambos são modificadores aplicados a qualquer um dos quatro tipos de dependência.
Como as dependências de tarefas se relacionam com o caminho crítico?
O caminho crítico é a sequência mais longa de tarefas dependentes na rede do projeto. Ele só pode ser calculado se todas as dependências de tarefas estiverem mapeadas corretamente. Dependências ausentes ou erradas produzem um caminho crítico que não reflete a realidade, o que significa que sua data de término projetada não é confiável. O artigo sobre método do caminho crítico aprofunda o cálculo.
O mapeamento de dependências é uma das primeiras coisas que você faz ao construir um cronograma e uma das últimas em que pensa em atualizar quando as coisas mudam. Essa lacuna é onde os prazos de projeto quebram. Mantenha sua lógica de dependência atualizada, valide-a com sua equipe e use o tipo de relação certo para o trabalho. Seu cronograma será honesto, sua análise de gerenciamento de projetos por corrente crítica será precisa, e sua equipe saberá exatamente o que depende do quê.
Para uma representação visual de como suas dependências se conectam, veja os guias de gráfico de marcos e diagrama de rede. E se o seu projeto usa um modelo de governança estruturado, a seção da metodologia PRINCE2 sobre planejamento baseado em produto explica como as dependências funcionam dentro de um framework de stage-gate.
Leitura relacionada
- Diagrama de Rede: a representação visual das dependências de tarefas em todo o seu projeto
- Método do Caminho Crítico: como usar dependências para encontrar o caminho mais longo e proteger seu prazo
- Float e Slack: entendendo a flexibilidade de cronograma depois que as dependências são mapeadas
- Fast-Tracking vs Crashing: como comprimir um cronograma ajustando dependências discricionárias
- Estrutura Analítica do Projeto: a base que você constrói antes de poder mapear qualquer dependência

Senior Operations & Growth Strategist
On this page
- O que são dependências de tarefas?
- Os quatro tipos de dependências de tarefas
- Categorias de dependência e lead vs lag
- Categorias de dependência
- Lead time e lag time
- Por que as dependências de tarefas importam
- Erros comuns
- Como mapear dependências de tarefas
- Passo 1: Liste todas as tarefas da sua EAP
- Passo 2: Identifique a predecessora de cada tarefa
- Passo 3: Atribua o tipo de relação correto
- Passo 4: Adicione lead ou lag onde necessário
- Passo 5: Valide com a equipe e construa o diagrama de rede
- Exemplos de dependência de tarefas
- Boas práticas
- Perguntas frequentes
- Leitura relacionada