Dependències entre tasques: què són, els 4 tipus i com gestionar-les

Una dependència entre tasques és el vincle lògic o temporal que indica que l'inici o la finalització d'una activitat depèn de l'estat d'una altra. Sense aquests enllaços, una llista d'activitats és només un conjunt desordenat de feines sense seqüència; amb dependències, es converteix en un cronograma estructurat on cada membre de l'equip sap exactament quin pas ha d'esperar abans de posar-se a treballar.

Quan es planifica qualsevol projecte, des del llançament d'un lloc web fins a la publicació d'un informe imprès, les dependències defineixen l'ordre natural del treball. Entendre com funcionen i com aplicar-les amb sentit comú evita retards imprevistos, elimina colls d'ampolla i permet calcular dates de lliurament que realment es puguin complir.

Què és una dependència i per què és indispensable en un projecte?

En la gestió de projectes, una dependència connecta dues tasques: la predecessora (la que condiciona) i la successora (la que rep la condició). Segons la guia de bones pràctiques per a cronogrames de la U.S. Government Accountability Office (GAO), una seqüència lògica completa de tasques predecessores i successores és la base necessària per preveure de manera fiable la data final d'un projecte.

Si les tasques no estan vinculades entre si, l'equip s'enfronta a tres problemes immediats:

1. Feina començada abans d'hora: algú comença a programar una pantalla abans que el disseny estigui validat, fet que sol obligar a refer la feina quan arriben els canvis.
2. Persones aturades sense avís: un col·laborador es queda bloquejat esperant un document que ningú sabia que calia lliurar abans.
3. Dates de lliurament fictícies: si s'allarga una tasca inicial però la resta del calendari no es mou, la data final esdevé una il·lusió.

Enllaçar tasques no serveix per crear gràfics complicats, sinó per reflectir la realitat física i operativa del treball diari.

Quins són els 4 tipus de dependències entre tasques?

La teoria clàssica de la gestió de projectes reconeix quatre maneres de relacionar dues tasques. Tal com documenta Microsoft Support, aquestes relacions es defineixen combinant el començament i el final de cada activitat:

1. Fi a començament (Finish-to-Start o FS)

És la relació estàndard i la més intuïtiva: la tasca B no pot començar fins que la tasca A no hagi acabat. Representa la immensa majoria dels vincles en qualsevol projecte pràctic.

• Exemple quotidià: no pots pintar una paret (tasca B) abans d'haver posat la capa d'imprimació (tasca A).
• Exemple d'oficina: no pots enviar una proposta econòmica al client (tasca B) abans que l'equip tècnic n'hagi calculat els costos (tasca A).

2. Començament a començament (Start-to-Start o SS)

En aquest cas, la tasca B no pot començar fins que la tasca A no hagi començat. No exigeix que acabin alhora, sinó que l'arrencada de la segona depèn de l'arrencada de la primera. Sovint s'utilitza per a activitats que es poden fer en paral·lel un cop iniciades.

• Exemple pràctic: la redacció de la documentació tècnica (tasca B) comença en el mateix moment en què comença el desenvolupament del programari (tasca A). La documentació no pot començar abans perquè necessita veure què es construeix, però no cal esperar al final del codi per començar a escriure.

3. Fi a fi (Finish-to-Finish o FF)

La tasca B no pot finalitzar fins que la tasca A no hagi acabat. Poden començar en moments diferents, però el tancament de la segona està supeditat al tancament de la primera.

• Exemple pràctic: el període de proves d'un sistema (tasca B) no es pot donar per acabat fins que no s'ha acabat d'instal·lar l'últim mòdul del servidor (tasca A). Les proves poden haver començat abans amb mòduls parcials, però no es completen del tot fins que el lliurament principal ha finalitzat.

4. Començament a fi (Start-to-Finish o SF)

És la relació menys habitual i la més confusa: la tasca B no pot acabar fins que la tasca A no hagi començat. La data de finalització de la successora està lligada a la data d'inici de la predecessora.

• Exemple pràctic: un sistema informàtic antic (tasca B) no es pot apagar definitivament fins que el nou sistema de substitució no hagi començat a operar (tasca A). Si l'arrencada del nou sistema es retarda, el vell ha de continuar funcionant.

La U.S. Government Accountability Office (GAO) recomana limitar l'ús de relacions que no siguin de fi a començament, ja que les relacions complexes sovint enfosqueixen la comprensió del calendari i compliquen la detecció del camí que realment marca el final del projecte.

Què són els avançaments i els retards (lead i lag)?

Quan dues tasques estan connectades, pot caldre ajustar el temps que transcorre entre elles. En terminologia de gestió de projectes, aquests ajustos s'anomenen avançaments (lead) i retards (lag):

• Retard (lag): és una espera obligatòria després d'acabar la predecessora abans que pugui arrencar la successora. Per exemple, després de pintar (tasca A), cal esperar vint-i-quatre hores perquè la pintura s'assequi abans de penjar els quadres (tasca B). No s'està treballant durant aquest temps, però el calendari necessita comptar amb aquest lapse.
• Avançament (lead): és un solapament que permet començar la tasca successora una mica abans que la predecessora acabi del tot. Per exemple, començar a revisar el text quan la redacció va pel vuitanta per cent.

Tot i que semblen eines útils, afegir avançaments i retards arbitraris sovint amaga una mala definició de les tasques. Si una tasca pot començar abans que l'altra acabi, sovint vol dir que la primera tasca en realitat eren dues parts diferenciades que s'haurien d'haver separat.

A més, en algunes eines corporatives aquesta funcionalitat requereix nivells de llicència superiors. Per exemple, en la revisió feta el 29 de setembre de 2026 sobre la documentació oficial de Microsoft, editar l'avançament i el retard d'una dependència a Planner requereix Plan 3.

Per què la majoria d'equips només necessiten «fi a començament»?

La gran majoria dels projectes de disseny, màrqueting, enginyeria o desenvolupament no necessiten dependències de començament a fi ni càlculs recargolats. La relació de fi a començament cobreix pràcticament qualsevol necessitat de coordinació si les tasques estan ben acotades.

Quan un model de planificació s'omple de dependències solapades i vincles exòtics, el cronograma es torna fràgil. Un canvi de mig dia en una tasca secundària pot moure dates de manera imprevisible i generar una sensació de descontrol.

En tokidu, el gestor de projectes de Sinergia Barcelona, aquest principi es porta a la pràctica de manera estricta: només existeix la relació de fi a començament mitjançant la regla «Comença quan acabi…». Una tasca queda en espera fins que acaben les activitats de les quals depèn, es desbloqueja sola amb un avís quan l'anterior finalitza, i si l'anterior es reobre per correccions, la tasca torna a quedar bloquejada automàticament. D'aquesta manera s'evita la creació de dependències en cercle que bloquegen els projectes.

Exemple pràctic: com es calcula un calendari amb dependències

Per veure com interactuen les dependències, les durades de les tasques i la disponibilitat de cada persona, vegem un exemple de producció editorial. En aquest cas, cada persona treballa en una sola tasca a la vegada en una jornada laboral de dilluns a divendres (sis hores de feina al dia).

Un fullet per a una impremta

Aquest exemple mostra com es traslladen les dependències a dates d'execució reals:

1. «Dissenyar la portada» arrenca el dilluns 12 d'octubre i requereix dos dies complets de l'Ana, de manera que finalitza el dimarts 13 d'octubre a la tarda.
2. «Maquetar el fullet» espera que acabi la portada. Com que l'Ana no pot fer dues feines alhora, la maquetació comença l'endemà al matí, dimecres 14 d'octubre. Amb una durada d'un dia i mig, s'acaba el dijous 15 d'octubre a migdia.
3. «Revisar els textos» té com a responsable el Luis i espera que la maquetació estigui a punt. Com que la maquetació acaba el dijous al migdia i el Luis té disponibilitat, pot començar i enllestir la seva revisió de mig dia aquell mateix dijous 15 d'octubre.
4. «Enviar a impremta» només necessita una hora, però està pendent de la revisió del Luis. Comença el divendres 16 d'octubre al matí i es completa aquell mateix matí.

Sense dependències, el Luis hauria pogut començar a revisar textos en brut sense la maquetació, o s'hauria pogut fixar una data d'enviament a impremta impossible de complir.

Com distingir una dependència d'una simple prioritat?

Un error freqüent en configurar cronogrames és confondre què ha d'anar abans amb què és més important:

• Dependència: és una restricció estructural. Físicament o lògicament no pots fer la tasca B sense haver fet la tasca A. Si la tasca B es comença sense la A, el resultat serà defectuós o directament inviable.
• Prioritat: és una decisió de negoci o d'organització. Totes dues tasques es podrien fer demà mateix si hi hagués mans disponibles, però es decideix fer-ne una abans perquè aporta més valor o urgeix més.

Si vincules tasques que no depenen l'una de l'altra només per forçar un ordre de treball en una llista, estàs creant rigidesa artificial. Quan aparegui una urgència o canviïn les prioritats, hauràs de desfer desenes d'enllaços ficticis. Les dependències han de reservar-se per a les necessitats reals de seqüència.

Què passa amb el camí crític quan canvien les dependències?

Quan les tasques estan encadenades, la seqüència més llarga d'activitats que determina la data de lliurament del projecte s'anomena tècnicament camí crític. Si qualsevol tasca d'aquesta cadena s'endarrereix, tot el projecte s'endarrereix el mateix temps.

Eines de gestió com Microsoft Planner ofereixen visualitzacions de dependències i camí crític en la seva vista de cronograma per ajudar a identificar quines feines tenen marge i quines no en tenen gens.

Quan s'actualitza el progrés diari d'un projecte, les dependències fan que el calendari recalculi automàticament les dates futures. Si una tasca que no és al camí principal s'allarga una mica, potser no afecta la data final; però si la demora és gran, pot convertir-se en el nou coll d'ampolla del projecte.

Com saber quina tasca toca fer a cada moment?

El perill de tenir moltes dependències definides és la paràlisi per sobrecàrrega d'informació: els membres de l'equip veuen desenes de tasques obertes i no saben quina està llesta per començar i quina està retinguda.

Per evitar aquest desgast, un flux de treball àgil ha de filtrar la feina bloquejada. La vista «El següent» de tokidu, per exemple, mostra a cada persona exclusivament les tasques que ja tenen totes les predecessores completades i estan a punt per executar. D'aquesta manera, ningú perd temps consultant tasques que encara no es poden tocar.