Dependencias entre tarefas: que son, os catro tipos e como organizalas con claridade

Unha dependencia entre tarefas é a relación lóxica que vincula o inicio ou o remate dunha actividade co estado doutra previa. Se tes que redactar un informe e despois traducilo, a tradución depende da redacción: non é posible traducir páxinas que aínda non existen. Esta relación determina a orde real de execución nun calendario de traballo e evita que as persoas dun equipo comecen tarefas sen ter os materiais necesarios preparados.

Cando un proxecto ten dúas ou tres actividades, memorizar a orde resulta sinxelo. En canto a lista medra e varias persoas comparten responsabilidades, tentar coordinar as entregas de memoria xera bloqueos silenciosos, esperas innecesarias e datas de entrega pouco realistas. Comprender as dependencias axuda a manter a planificación baixo control sen converter a xestión nun labirinto técnico.

Cales son os catro tipos de dependencias entre tarefas?

A teoría clásica da xestión de proxectos e ferramentas tradicionais recollidas polo soporte de Microsoft Support clasifican as relacións entre dúas actividades en catro combinacións posibles de comezo e fin:

1. Fin a comezo (FC ou Finish-to-Start): A tarefa B non pode comezar ata que remate a tarefa A. É a relación máis habitual e natural no traballo diario. Por exemplo, non podes pintar unha parede ata que remate a aplicación da capa de imprimación.
2. Comezo a comezo (CC ou Start-to-Start): A tarefa B non pode comezar ata que comece a tarefa A. Non require que A estea terminada para traballar en B, senón que ambas poden avanzar en paralelo unha vez iniciadas. Por exemplo, as tarefas de corrección ortográfica dun libro moi longo poden comezar en canto comece a fase de maquetación dos primeiros capítulos.
3. Fin a fin (FF ou Finish-to-Finish): A tarefa B non pode rematar ata que remate a tarefa A. Poden desenvolverse de forma simultánea, pero a segunda depende do resultado final da primeira para dar o seu peche definitivo. Por exemplo, as probas de control de calidade dun desenvolvemento non poden dar por pechada a súa revisión ata que o equipo técnico remate de programar a última función.
4. Comezo a fin (CF ou Start-to-Finish): A tarefa B non pode rematar ata que comece a tarefa A. É a relación máis infrecuente e difícil de interpretar nun cronograma. Un caso típico dáse nas quendas de traballo: o vixilante da quenda de noite non pode marchar (rematar a súa tarefa) ata que o vixilante da quenda de mañá chegue ás instalacións e inicie a súa garda.

Na práctica profesional cotiá, a inmensa maioría dos proxectos resólvense unicamente co tipo «fin a comezo». O exceso de relacións complexas adoita xerar diagramas fráxiles nos que calquera pequeno imprevisto rompe toda a lóxica temporal.

Por que a relación fin a comezo resolve case todo o traballo diario?

A maioría dos problemas nun equipo xorden cando alguén tenta comezar unha tarefa sen que os pasos previos estean resoltos. Un deseño web require un esquema previo de contidos, unha peza mecánica necesita un plano aprobado e un envío comercial precisa ter os prezos pechados. Nestes casos, a única relación que reflicte o mundo real é «fin a comezo».

Cando un fluxo de traballo parece necesitar un vínculo de tipo «comezo a comezo» ou «fin a fin», case sempre se debe a que as tarefas son demasiado grandes. Se divides unha entrega xigante en partes máis pequenas e manexables, as dependencias complexas desaparecen por si soas. Por exemplo, en lugar de ter unha tarefa chamada «Escribir manual» e outra «Deseñar maquetación» vinculadas de forma paralela, resulta máis limpo dividir o proxecto en «Redactar capítulos 1 e 2» e «Maquetar capítulos 1 e 2». Así, a maquetación agarda a que remate a redacción dese bloque concreto mediante un vínculo estrito de fin a comezo.

Na guía de boas prácticas da administración pública estadounidense, a U.S. Government Accountability Office advirte que o uso indiscriminado de dependencias pouco intuitivas e axustes artificiais distorsiona a secuencia de traballo e dificulta identificar o camiño de tarefas que realmente marca a duración total dun proxecto.

Que son os adiamentos e os retrasos nas relacións?

No ámbito da planificación técnica existen dous conceptos asociados ás dependencias: os retrasos (lag) e os adiamentos (lead):

• Retraso ou tempo de espera (lag): É un período de tempo obrigatorio que debe transcorrer despois de rematar a primeira tarefa antes de poder comezar a seguinte. O exemplo máis claro é o tempo de secado: se aplicas formigón no chan (tarefa A), debes agardar corenta e oito horas antes de poder colocar o pavimento (tarefa B). A tarefa B está agardando por un proceso físico pasivo, non polo traballo activo dunha persoa.
• Adiamento ou solapamento (lead): Permite que a tarefa seguinte se adiante e comece uns días antes de que a anterior termine por completo. Por exemplo, comezar a empaquetar produtos cando a produción está ao noventa por cento.

Aínda que poidan parecer útiles, os adiamentos (lead) adoitan xerar erros nas estimacións porque converten unha dependencia nunha adiviñanza: se a primeira tarefa se atrasa, o adiamento pode provocar que o traballo seguinte comece cando aínda faltan pezas esenciais. Por este motivo, as metodoloxías limpas recomendan evitar os solapamentos negativos e optar por subdividir as tarefas.

O acceso a estas opcións tamén varía segundo as ferramentas do mercado. Por exemplo, un anuncio oficial en Microsoft Tech Community confirmou con data do 29 de setembro de 2026 que en Planner a edición de adiamentos e retrasos (lead e lag) esixe dispor do Plan 3.

Como xestiona as dependencias tokidu?

En tokidu, o xestor de proxectos de Sinergia Barcelona, a filosofía baséase na claridade e na sinxeleza. Para evitar cálculos opacos e cronogramas crebados, tokidu só utiliza a dependencia «fin a comezo». Isto materialízase na función chamada «Empeza cando remate…», dispoñible en todos os plans, incluído o plan Gratis.

Cando configuras unha tarefa con «Empeza cando remate…», a actividade agarda a que rematen as outras tarefas seleccionadas do mesmo proxecto. A tarefa queda bloqueada e desbloquéase soa, enviando un aviso á persoa responsable, xusto cando remata a última tarefa á que agarda. Se a tarefa anterior se reabre por calquera motivo, a tarefa dependente volve bloquearse de xeito automático. Ademais, o sistema rexeita calquera intento de crear dependencias circulares, impedindo situacións nas que a tarefa A agarda por B e B agarda por A.

No plan Pro de tokidu (que aínda non está á venda, cun prezo previsto de 4 € por persoa ao mes ou 40 € por persoa ao ano co IVE incluído), a función «Empeza cando remate…» permite engadir días de espera pasiva («e pasen 2 días»). A tarefa desbloquéase e avisa cando remata a anterior e transcorre ese tempo de repouso configurado. En tokidu non existen os adiamentos (lead): unha tarefa nunca pode programarse para comezar antes de que remate a anterior.

Esta lóxica compleméntase coa vista «O seguinte», dispoñible tamén de balde, que mostra unicamente as tarefas que se poden executar hoxe mesmo, mantendo oculto todo o que estea bloqueado por outras actividades pendentes.

Exemplo práctico: cálculo real de datas con dependencias

Para comprobar como interactúan as dependencias, as xornadas laborais e a asignación de persoas, vexamos un exemplo concreto xestionado co motor de «Datas que se calculan soas». Imaxinemos a preparación dun catálogo comercial sinxelo.

Un folleto para unha imprenta

Neste exemplo, o calendario laboral abrangue de luns a venres con seis horas de tarefas ao día (o calendario por defecto de tokidu), onde «1 día» equivale exactamente a seis horas de traballo efectivo. O proxecto comeza o luns 12 de outubro de 2026 e cada persoa realiza unha soa tarefa á vez.

Fixémonos na secuencia lóxica que determina o calendario:

1. Ana comeza co deseño da portada o luns 12 de outubro pola mañá e remata o martes 13 de outubro ao pechar a súa xornada de seis horas diarias.
2. A segunda tarefa («Maquetar o folleto») require que a portada estea rematada. Polo tanto, Ana non pode tocala ata o mércores 14 de outubro. Ao ter unha duración dun día e medio (nove horas de traballo), Ana dedica as seis horas do mércores e as primeiras tres horas do xoves 15 de outubro.
3. A revisión de textos agarda pola maquetación. Dado que Ana remata a maquetación a metade do xoves, Luis pode asumir a súa revisión (que require tres horas, é dicir, medio día) durante a segunda metade desa mesma xornada do xoves 15 de outubro.
4. Finalmente, o envío á imprenta agarda pola revisión de Luis. Como Luis pecha o seu traballo o xoves á tarde, a tarefa final pasa directamente á primeira hora dispoñible do venres 16 de outubro. O proxecto completo conclúe con éxito o venres 16 de outubro de 2026.

Se en calquera momento xorde unha dúbida sobre por que unha entrega queda situada nun día determinado, a función «Por que esa data?» de tokidu amosa unha frase explicativa co motivo exacto que empuxa o día no calendario: a que tarefa agarda, que traballo previo ten asignado esa persoa ou que días non laborables coinciden no camiño.

Erros habituais ao configurar dependencias e como evitalos

Cando os equipos comezan a ligar tarefas nos seus proxectos, adóitase caer en vicios organizativos que complican o seguimento:

1. Vincular todo con todo

Crear ducias de fíos invisibles entre tarefas que só teñen unha relación circunstancial fai que calquera cambio de data nunha actividade menor desmonte o calendario enteiro. As dependencias deben reservarse unicamente para restricións estritas: se a tarefa B pode comezar perfectamente sen que A estea lista, non deben estar unidas por unha dependencia.

2. Confundir dependencia de tarefas con carga de traballo persoal

Un erro moi común consiste en poñer unha dependencia entre dúas actividades só porque as vai facer a mesma persoa. Se María ten que redactar dous artigos distintos e independentes, o artigo B non «agarda» polo artigo A; María simplemente non pode facer dúas cousas á vez. En ferramentas que contan con cálculo automático segundo a capacidade individual, o sistema reparte as tarefas de forma natural sen necesidade de crear dependencias artificiais.

3. Crear bucles ou dependencias circulares

Un bucle prodúcese cando unha tarefa remata dependendo de si mesma a través dunha cadea pechada (A agarda por B, B agarda por C, e C agarda por A). Isto bloquea calquera motor de cálculo temporal. Manter as dependencias orientadas nun único sentido cronolóxico garante que o fluxo de traballo sexa comprensible.

4. Non actualizar os tempos de espera

Cando se usan períodos de descanso (como agardar por unha resposta externa ou o secado dun material), moitos equipos esquecen reflectir eses días no plan. O resultado é que as persoas reciben avisos de inicio cando a realidade física aínda non permite avanzar.

Cando usar dependencias e cando abonda cunha lista de tarefas?

Non todas as iniciativas precisan dun mapa de dependencias exhaustivo. Unha táboa sinxela ou unha listaxe de control chega e sobra nos seguintes casos:

• Proxectos individuais onde a persoa decide a súa propia orde minuto a minuto.
• Listas de tarefas recorrentes ou mantementos onde a secuencia non altera o resultado.
• Tarefas que poden executarse en calquera momento dentro dunha mesma semana sen bloquear a terceiros.

Pola contra, as dependencias entre tarefas resultan imprescindibles cando:

• Traballan varias persoas coordinadas e o traballo dunha é o punto de partida doutra.
• Existen fitos ou datas límite estritas con clientes ou provedores externos.
• Cómpre coñecer con exactitude a data real de remate do proxecto en función do esforzo estimado.
• O equipo quere evitar o ruído mental de ver ducias de tarefas pendentes que aínda non se poden executar.

Comprender e aplicar a lóxica de «fin a comezo» permite que o traballo en equipo fluya de forma previsible e ordenada, eliminando as friccións de coordinación antes de que aparezan.