Cum construiești un Gantt cu dependențe realiste?
Un Gantt util are dependențe explicite (FS/SS/FF/SF), milestone-uri puține și clare, și recalculează drumul critic automat când un task alunecă. Fără asta, e doar un calendar colorat în Excel.
Gantt-urile false sunt tool-uri vizuale unde toată lumea estimează "vreo 2 săptămâni" și nimeni nu urmărește cum o alunecare la task-ul A mută livrarea totală. Gantt-urile reale au dependențe codificate (Finish-to-Start, Start-to-Start etc), un drum critic vizibil și actualizare automată când realitatea diverge — așa devin instrument de control, nu doar prezentare.
1. Tipurile de dependență contează
Finish-to-Start (FS) e cea mai obișnuită: task B nu începe până nu termină A. Dar nu e singura. Start-to-Start (SS): B începe când A începe (paralel, dar nu mai devreme). Finish-to-Finish (FF): B se termină când A se termină (deadline comun). Start-to-Finish (SF): rar, dar real în programare de mentenanță.
Un Gantt care permite doar FS suprasimplifică. "Setup-ul de infra trebuie să fie terminat înainte să înceapă deploy-ul" e FS. "QA-ul începe când dev-ul începe (paralel)" e SS — fără asta nu modelezi corect echipele care lucrează cap-coadă pe același feature.
2. Drumul critic (Critical Path) trebuie afișat
Drumul critic e lanțul de task-uri unde orice alunecare împinge data finală. Task-urile din afara drumului critic au "float" (margine) — pot aluneca fără să afecteze livrarea.
Fără drumul critic vizibil, PM-ul tratează toate alunecările la fel și se panichează aiurea. Cu el, deciziile devin clare: "Asta e pe drum critic — alocăm încă un dev. Asta nu e — îl lăsăm să alunece 3 zile, nu afectează". Tool-ul trebuie să recalculeze drumul critic automat când muți un task, nu să te oblige să-l recalculezi mental.
3. Milestone-uri puține și concrete
Maxim 5-7 milestone-uri pentru un proiect de 3-6 luni. Fiecare milestone e o livrare verificabilă: "Backend API v1 deployed pe staging", "User flow complet în UI", "Pilot live cu primul client". Nu "Sprint 3 încheiat" — asta nu e milestone, e calendar.
Milestone-urile sunt punctele de comunicare cu stakeholderii. Între milestone-uri faci status update standard; la milestone faci demo concret. Dacă milestone-urile sunt prea dese (10+), pierd semnificația. Prea rare (1-2), nu prinzi devierea la timp.
4. Buffer pe drumul critic, nu peste tot
Adaugă buffer (zile de margine) la sfârșitul drumului critic — nu împrăștiat peste fiecare task. Buffer-ul concentrat absoarbe alunecările cumulate ale tuturor task-urilor din drumul critic.
Critical Chain Project Management (Goldratt) demonstrează că un buffer concentrat de 30-50% din durata drumului critic e mult mai eficient decât 20% adăugat la fiecare task individual — pentru că task-urile care merg mai bine "împrumută" timp celor care merg mai prost.
5. Actualizare zilnică, nu lunară
Un Gantt actualizat o dată pe lună e fictiune. Realitatea diverge zilnic — dependențele se descoperă, vendorul livrează în întârziere, scope-ul se clarifică. Gantt-ul trebuie să reflecte starea curentă în orice moment.
Practic: orice schimbare la un task (status, durată, start date) recalculează automat dependențele, drumul critic și data finală. PM-ul vede instant impactul oricărei modificări — și poate avertiza stakeholderul cu o săptămână în avans, nu cu o zi după ce s-a întâmplat.
Gantt cu dependențe în 4myprojects
FS, SS, FF, SF — toate tipurile de dependențe native, drumul critic recalculat la fiecare modificare, milestone-uri pe board și warnings când buffer-ul se consumă.