Gestión de proyectos

Dependencias entre tareas, sin jerga de Gantt

En una línea: hay dependencia entre tareas cuando una no puede empezar (o terminar) hasta que otra empieza (o termina). “El texto se publica después de que legal lo apruebe” es una dependencia; ignorarla es la diferencia entre un cronograma que se cumple y uno que se rehace cada semana. Aquí están los 4 tipos, en lenguaje llano, y cómo gestionarlos sin instalar un Gantt.
8 min de lectura

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:

TipoEn llanoEjemplo
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:

  1. ¿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.
  2. ¿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?
Son relaciones de orden entre tareas: una no puede empezar o terminar hasta que otra empiece o termine. Ejemplo típico: el envío de una campaña (B) depende de la aprobación de los creativos (A). Detectarlas antes de planear evita cronogramas que se reescriben cada semana.
¿Qué tipos de dependencias existen?
Cuatro: fin-inicio (B empieza cuando A termina, la más común), inicio-inicio (B empieza cuando A empieza y avanzan en paralelo), fin-fin (B termina cuando A termina) e inicio-fin (B termina cuando A empieza, típica de traspasos). En equipos pequeños, casi todo es fin-inicio.
¿Qué es una dependencia FS?
FS (finish-to-start, fin-inicio) es la dependencia donde la tarea sucesora no puede empezar hasta que la predecesora termine. Es el caso por defecto: el texto se publica después de la aprobación, el deploy después de las pruebas. Si solo vas a modelar un tipo, modela este.
¿Cómo marcar dependencias en un tablero kanban?
Tres convenciones: columnas que reflejen el orden real del proceso, una etiqueta visible de espera (‘bloqueada’, ‘espera cliente’) en la tarjeta que no avanza, y la regla de no poner en curso una tarjeta cuya predecesora no está por terminar. El tablero muestra el bloqueo; no recalcula fechas: para eso sirve un cronograma.
¿Cuándo necesito un Gantt para las dependencias?
Cuando la fecha de entrega comprometida depende de una cadena larga (10+ tareas encadenadas), hay aprobaciones o proveedores externos con holguras a calcular, o cada cambio obliga a recontar el plan a mano. Para el flujo diario de un equipo pequeño, el tablero basta; el cronograma con barras es la segunda capa, no la primera.

Equipo Hito

Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.

Empieza

¿Listo para tener el control de tus datos y proyectos?