Dependencias entre tareas: qué son, los 4 tipos y cómo encadenar proyectos sin fricción

Las dependencias entre tareas son las relaciones lógicas que determinan el orden en el que se ejecuta el trabajo dentro de un proyecto. En lugar de asignar fechas fijas a mano en un calendario, una dependencia especifica qué tarea necesita de otra para poder empezar o completarse, evitando solapamientos imposibles y cuellos de botella imprevistos.

Cuando una tarea predecesora sufre un retraso, la dependencia traslada ese desfase a las tareas sucesoras de forma automática. Entender cómo funcionan estos enlaces permite estructurar proyectos con solidez, saber qué pasos bloquean el avance real y calcular con precisión cuándo se entregará el resultado final.

¿Qué es una dependencia y por qué no conviene usar fechas fijas?

Al planificar un proyecto, la tentación habitual consiste en abrir un calendario y colocar días concretos a cada actividad. Este método falla ante el primer contratiempo: si redactar un informe se retrasa dos días, todas las fechas posteriores quedan desactualizadas de golpe y exigen un ajuste manual tarea por tarea.

Una dependencia convierte esa lista rígida en una cadena dinámica. Al conectar las tareas entre sí, el plan refleja la realidad técnica del trabajo: pintar una pared requiere haber revocado el yeso antes; revisar un contrato exige que el borrador esté escrito; programar una pasarela de pago pide haber definido antes la arquitectura de datos. La guía metodológica GAO Schedule Assessment Guide señala que un cronograma bien construido debe basarse en una red lógica completa de predecesoras y sucesoras, reduciendo las restricciones de fecha fija al mínimo imprescindible para que el calendario reaccione a los cambios.

Al vincular tareas mediante dependencias se obtienen tres ventajas inmediatas:

1. Claridad sobre qué hacer primero: el equipo no duda sobre qué tareas están listas para arrancar y cuáles permanecen a la espera de entregas previas.
2. Actualización automática del calendario: si una entrega se adelanta o se retrasa, el resto del cronograma se desplaza en consecuencia sin necesidad de reprogramar cada casilla a mano.
3. Identificación de cuellos de botella: se hace evidente qué tareas, si sufren demoras, comprometen la fecha final de todo el proyecto.

¿Cuáles son los 4 tipos de dependencias entre tareas?

En la gestión de proyectos tradicional se reconocen cuatro tipos de relaciones entre una tarea predecesora (la que condiciona) y una sucesora (la condicionada), tal como documenta la guía técnica Link tasks in a project de Microsoft Support:

1. Fin a comienzo (FC o Finish-to-Start)

Es la relación natural y más común en cualquier trabajo: la tarea B no puede comenzar hasta que la tarea A haya terminado por completo. Representa una secuencia directa y lógica.

• Ejemplo cotidiano: no puedes hornear un pastel (tarea B) hasta haber mezclado los ingredientes (tarea A).
• Ejemplo en oficina: no puedes maquetar un catálogo en PDF hasta que el cliente apruebe los textos definitivos.

La inmensa mayoría de las relaciones en un proyecto profesional responden a este modelo.

2. Comienzo a comienzo (CC o Start-to-Start)

En este enlace, la tarea B no puede comenzar hasta que la tarea A haya comenzado. No exige que la tarea A esté terminada para arrancar la B, sino que ambas pueden desarrollarse en paralelo una vez iniciado el primer paso.

• Ejemplo en obra: una cuadrilla empieza a tender tuberías (tarea A); una vez iniciado el tendido, otra persona puede empezar a inspeccionar la soldadura del tramo tendido (tarea B).
• Ejemplo en software: el equipo inicia las pruebas de usabilidad preliminares (tarea B) tan pronto como el equipo de desarrollo comienza a desplegar las primeras pantallas de la versión de prueba (tarea A).

3. Fin a fin (FF o Finish-to-Finish)

Aquí, la tarea B no puede completarse hasta que la tarea A haya concluido. Ambas tareas pueden comenzar en momentos distintos y avanzar a la par, pero la entrega de B está supeditada al cierre formal de A.

• Ejemplo editorial: la corrección ortotipográfica en vivo (tarea B) no puede darse por terminada hasta que el redactor termine de escribir el último capítulo del manuscrito (tarea A).
• Ejemplo en eventos: el servicio de recepción de invitados (tarea B) no finaliza hasta que concluye la ceremonia de apertura (tarea A).

4. Comienzo a fin (CF o Start-to-Finish)

Es el tipo más infrecuente y suele prestarse a confusión. Indica que la tarea B no puede terminar hasta que la tarea A haya comenzado. Rara vez se utiliza en proyectos creativos o de conocimiento, y suele reservarse para procesos de relevo operativo continuo.

• Ejemplo de guardia: el turno de guardia saliente (tarea B) no puede terminar su servicio hasta que el nuevo vigilante del turno entrante haya comenzado su jornada (tarea A).

¿Qué son el adelanto y el retraso en una dependencia?

Además del tipo de relación, algunas dependencias necesitan incorporar una separación temporal entre las actividades. En la terminología de gestión de cronogramas, estos márgenes se denominan retraso y adelanto:

• Retraso (lag): es una pausa obligada entre dos tareas. Indica que, tras terminar la predecesora, debe transcurrir un tiempo muerto antes de poder iniciar la sucesora. Por ejemplo, tras aplicar una capa de imprimación en una pared (tarea A), hay que esperar 24 horas de secado antes de empezar a pintar con el color final (tarea B). Durante esas 24 horas nadie trabaja activamente en la pared, pero la tarea B no puede arrancar antes.
• Adelanto (lead): es una aceleración en la que la tarea sucesora se adelanta al término de la predecesora. Por ejemplo, comenzar la maquetación visual cuando la redacción del texto va por el 80 %. Técnicamente equivale a un retraso negativo.

Conviene tener precaución con los adelantos. Tal como analiza la documentación de Introducing Lead & Lag in Task Dependencies de Microsoft Tech Community (comprobada el 2026-09-29), el uso de márgenes exige planes avanzados en herramientas complejas (como Plan 3 en Planner) y, si se abusa de ellos, dificulta entender la causa real de las fechas calculadas. Muchas veces, un adelanto artificial oculta que una tarea grande debería dividirse en dos tareas más pequeñas encadenadas de forma natural con un simple fin a comienzo.

¿Cómo encadenar un proyecto real con dependencias sencillas?

Para comprobar cómo interactúan las dependencias directas con los calendarios laborales y la disponibilidad de cada persona, examinemos un ejemplo práctico real. Se trata de coordinar el diseño, revisión y entrega de un folleto.

En este ejemplo, el calendario de trabajo es de lunes a viernes, con 6 horas laborables de tareas al día por persona (donde «1 día» equivale a 6 horas de dedicación). Cada persona trabaja en una sola tarea a la vez. El encargo arranca el lunes 12 de octubre de 2026.

Un folleto para una imprenta

Observa lo que ocurre paso a paso en esta secuencia:

1. Diseñar la portada: Ana necesita 2 días completos (12 horas de trabajo). Comienza el lunes 12 por la mañana y concluye el martes 13 al final de su jornada.
2. Maquetar el folleto: esta tarea espera a que termine el diseño de la portada. Como la realiza la misma persona (Ana), la maquetación empieza el miércoles 14 por la mañana. Con una duración de 1½ días (9 horas de trabajo), Ana dedica las 6 horas del miércoles y 3 horas del jueves 15, terminando a mediodía.
3. Revisar los textos: Luis entra en acción en cuanto Ana termina la maquetación. Como Luis tiene disponible su tarde del jueves 15 y la revisión dura ½ día (3 horas), empieza y concluye ese mismo jueves.
4. Enviar a imprenta: depende de la revisión de textos. Como la jornada del jueves ha concluido tras la revisión, la tarea de 1 hora se programa para la primera hora del viernes 16 de octubre, fecha en la que concluye el proyecto.

Si la maquetación se retrasase un día entero, Luis no podría revisar los textos el jueves, sino el viernes 16, y el envío a imprenta se desplazaría automáticamente al lunes siguiente (respetando el fin de semana sin trabajo).

En tokidu, el gestor de proyectos de Sinergia Barcelona, este modelo de vinculación se gestiona de forma intencionadamente simple mediante la opción «Empieza cuando acabe…», disponible en todos los planes. tokidu solo utiliza dependencias de tipo «fin a comienzo»: una tarea espera a que terminen las tareas previas designadas dentro del mismo proyecto. Gracias a su motor de «Fechas que se calculan solas», el sistema toma la duración de cada tarea y la disponibilidad de cada persona para calcular cuándo empieza y termina cada entrega, bloqueando automáticamente lo que no puede arrancar todavía y ofreciendo la vista «Lo siguiente» para mostrar exclusivamente el trabajo desbloqueado.

¿Por qué las dependencias complejas suelen arruinar los cronogramas?

Las herramientas tradicionales de gestión permiten combinar libremente los cuatro tipos de dependencia, superponer porcentajes de adelanto y añadir demoras arbitrarias. Aunque esto parece flexible sobre el papel, en la práctica suele generar tres problemas graves en equipos cotidianos:

1. Dependencias circulares que bloquean el sistema

Ocurre cuando la tarea A espera a la tarea B, pero la tarea B (directamente o a través de intermediarias) acaba esperando a la tarea A. Si el software no previene activamente los bucles, el cálculo de fechas colapsa en un error infinito. Una gestión limpia exige rechazar las esperas en círculo en el momento en que se intentan configurar.

2. Ocultamiento de la ruta crítica y pérdida de visibilidad

Cuando se conectan actividades con relaciones de «comienzo a fin» o adelantos de días variables, resulta casi imposible para el equipo comprender a simple vista por qué una tarea tiene asignada una fecha determinada. La publicación técnica Advanced project planning with Microsoft Planner: Dependencies and critical path in Timeline view de Microsoft Tech Community destaca la importancia de visualizar con nitidez la cadena crítica de tareas que determinan la fecha final del plan. Cuando la lógica interna es confusa, las personas dejan de confiar en el cronograma y vuelven a coordinarse mediante mensajes sueltos.

3. Falsa sensación de paralelismo

Configurar dependencias de «comienzo a comienzo» suele ser un intento de esquivar una realidad incómoda: si una persona tiene asignadas dos tareas que arrancan a la vez, no podrá ejecutarlas de forma simultánea. Salvo que existan dos personas trabajando en paralelo, una de las dos tareas quedará desatendida. Tratar a las personas como recursos capaces de realizar multitarea perfecta falsea los plazos de entrega.

¿Cómo elegir qué dependencias configurar en tus tareas?

Para mantener un cronograma manejable y fiable a lo largo del tiempo, conviene aplicar tres pautas básicas de modelado:

• Divide el trabajo en entregables independientes: si sientes la necesidad de enlazar dos tareas con «comienzo a comienzo» o con adelantos («empieza dos días antes de terminar la anterior»), comprueba si la tarea predecesora es en realidad un paquete demasiado grande. Divídela en dos hitos claros («Borrador inicial» y «Ajustes finales») y enlázalos con una relación directa de fin a comienzo.
• Vincula únicamente lo estrictamente necesario: no unas tareas solo porque te gustaría hacerlas en un orden determinado si no existe una restricción real entre ellas. Las dependencias deben reflejar impedimentos lógicos genuinos (no se puede probar un software sin compilarlo), no preferencias personales de orden de lectura.
• Consulta la causa de cada fecha calculada: en tokidu, ante cualquier duda sobre el motivo de un plazo, la función «¿Por qué esa fecha?» (disponible en todos los planes) resume en una frase qué elemento empuja la tarea: si está esperando a otra predecesora, si la persona asignada tiene trabajo previo agendado o si coincide con días no laborables.