Dependencias entre tareas, sin jerga de Gantt
Qué es una dependencia entre tareas
Una dependencia entre tareas es una relación de orden: el trabajo de una tarea necesita que otra haya avanzado (o terminado) primero. No es una preferencia de organización: es una restricción del mundo real. El pedido no se envía antes de estar embalado; la campaña no arranca sin creativos aprobados; el deploy no ocurre antes de las pruebas.
Se distingue de otros vínculos que se confunden con ella:
- Dependencia ≠ prioridad. La prioridad dice qué va primero aunque podría ir después; la dependencia dice qué no puede ir después, aunque quieras.
- Dependencia ≠ misma persona. Que dos tareas las haga Ana no las vincula; que la segunda use el resultado de la primera, sí.
- Dependencia ≠ bloqueo. El bloqueo es el estado en el que se convierte una tarea cuando su dependencia no avanza. En un tablero, el bloqueo se marca; la dependencia se declara.
Los 4 tipos de dependencias (con ejemplos)
La jerga formal usa iniciales en inglés: FS, SS, FF, SF. La traducción útil es esta:
| Tipo | En llano | Ejemplo |
|---|---|---|
| Fin → Inicio (FS) | B no puede empezar hasta que A termine. | Publicar el post solo después de que legal lo apruebe. |
| Inicio → Inicio (SS) | B no puede empezar hasta que A empiece (pueden avanzar en paralelo). | Traducir el manual apenas empieza a escribirse la versión original. |
| Fin → Fin (FF) | B no puede terminar hasta que A termine. | La puesta a punto del local termina el mismo día que la obra gruesa. |
| Inicio → Fin (SF) | B no puede terminar hasta que A empiece. Rara en la práctica; típica en traspasos. | El proveedor nuevo no cierra la transición hasta que el viejo arranca la operación. |
En la vida real, el 90 % de las dependencias que gestiona un equipo pequeño son del primer tipo (fin → inicio), algunas del segundo y casi ninguna de los otros dos. No necesitas dominar la taxonomía: necesitas detectar cuándo existe una relación de orden y nombrarla.
Cómo detectar las dependencias antes de que te muerdan
Las dependencias no se “configuran”: se descubren con dos preguntas al armar el plan o llenar el tablero:
- ¿Esta tarea necesita un resultado de otra? Si B consume lo que produce A (un diseño, una aprobación, un dato), hay dependencia FS.
- ¿Esta tarea necesita una respuesta de alguien fuera del equipo? Cliente que aprueba, legal que revisa, proveedor que entrega. Esas son las que más atrasan proyectos pequeños, porque el reloj de otra persona define el tuyo.
Cuando encuentres una, anótala en la tarjeta —“espera aprobación de X”, “requiere entrega de Y”— con la fecha límite de la respuesta si la hay. Eso convierte una sorpresa futura en un compromiso presente: si X no responde, el atraso ya es visible el día que empieza, no el día de la entrega.
Si encadenas 15 dependencias y la fecha final depende de una cadena crítica, ya estás en territorio de análisis de ruta crítica: qué tareas no pueden atrasarse ni un día, en Ruta crítica de un proyecto.
Cómo gestionarlas en un tablero (sin Gantt)
Para la mayoría del trabajo diario de un equipo pequeño, el tablero kanban basta con tres convenciones:
- Orden de columnas = orden de proceso. La secuencia real del trabajo (diseño → aprobación → publicación) ya codifica las dependencias frecuentes. Una tarjeta solo avanza a la derecha.
- Etiqueta de espera. Una marca visible (“bloqueada”, “espera cliente”, “espera legal”) en la tarjeta que no puede avanzar. El bloqueo se ve sin preguntar.
- La tarjeta dependiente entra al tablero cuando su predecesora está cerca de terminar. No antes: una tarjeta “en curso” esperando a otra es WIP de mentira (por qué eso mata la entrega, en Cómo reducir el trabajo en curso).
Lo que el tablero no hace es recalcular fechas. Si mueves la aprobación de legal una semana, el tablero no te dice cuántos días come eso del resto del plan. Esa aritmética es el territorio de un cronograma.
Cuándo necesitas un cronograma (y el Gantt deja de ser adorno)
El tablero gana para el flujo diario; el cronograma gana cuando se cumplen dos condiciones: muchas dependencias encadenadas y una fecha de entrega comprometida con alguien de afuera. Señales concretas:
- La fecha final depende de 10+ tareas encadenadas, no de 2–3.
- Hay proveedores o aprobaciones externas con holgura que hay que calcular, no adivinar.
- El cliente pide ver el plan: barras, hitos y fechas, no un tablero.
- Cada cambio (“el proveedor se atrasa una semana”) obliga a recontar el resto a mano.
Ahí conviene armar un cronograma liviano —hitos y dependencias, no 200 barras— y dejar el tablero para la operación diaria. El formato y la plantilla están en Plantilla de cronograma de proyecto y la vista visual de barras, con cuándo ayuda y cuándo estorba, en Diagrama de Gantt: qué es y cómo hacerlo.
En Hito gestionas el flujo en tablero kanban con etiquetas de bloqueo y los hitos y dependencias del proyecto quedan documentados junto al trabajo — todo local, en tu carpeta, sin cuenta.
👉 Prueba Hito gratis — tablero, procesos y automatizaciones local-first para equipos de 1 a 15 personas.
Preguntas frecuentes
¿Qué son las dependencias entre tareas?
¿Qué tipos de dependencias existen?
¿Qué es una dependencia FS?
¿Cómo marcar dependencias en un tablero kanban?
¿Cuándo necesito un Gantt para las dependencias?
Equipo Hito
Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.