1. Nincs egyértelmű scope
A projekt úgy indul, hogy "csináljunk egy rendszert". De senki nem határozza meg pontosan, mit jelent a "kész". Az ügyfél mást képzel, a fejlesztő mást ért, és mindenki azt hiszi, hogy egyetértenek.
Az eredmény: folyamatos scope creep. Minden héten jön egy "ja, és ezt is kellene" kérés, ami nem volt benne az eredetiben — de senki nem mondja ki, hogy ez változás, ami időt és pénzt jelent.
Ha nem tudod leírni egy oldalon, mit csinál a rendszer — nem vagy készen a fejlesztés indítására.
2. Rossz becslés, mert rossz kérdések
A fejlesztő/vendor megkérdezi: "Kell regisztráció?" Az ügyfél mond egy igent. De senki nem kérdezi meg:
- Email alapú vagy SSO?
- Kell jelszó-visszaállítás?
- Kell admin felület a felhasználók kezeléséhez?
- Kell GDPR-konform adattörlés?
- Kell kétfaktoros hitelesítés?
A "regisztráció" lehet 2 nap vagy 3 hét — attól függ, mit jelent. Ha a kérdések nem hangzanak el a projekt elején, a becslés garantáltan rossz lesz.
3. A döntéshozó nem elérhető
A fejlesztés közben hetente jönnek a kérdések: "Melyik verziót válasszuk?", "Elfogadható ez a kompromisszum?", "Kinek a munkafolyamata a mérvadó?"
Ha a döntéshozó nem válaszol 2 napon belül, a csapat vagy megáll (és csúszik), vagy dönt a fejlesztő (és nem azt kapod, amit akartál). Mindkettő a projekt ellen dolgozik.
4. Nincs mérföldkő, nincs kontroll
Ha a projekt egyetlen mérföldköve az "átadás", akkor 3-6 hónapig nem látsz semmit. Aztán jön a demo, és kiderül, hogy az alap koncepció nem stimmel.
A megoldás: 2-3 hetente demo, vagy legalább írásos státuszjelentés. Nem azért, hogy ellenőrizd a csapatot — hanem hogy időben korrigálhass, mielőtt a hiba napokat ér.
5. A vendor nem mond nemet
A jó vendor azt mondja: "Ezt meg tudjuk csinálni, de 2 héttel kitolódik a határidő." A rossz vendor azt mondja: "Persze, megoldjuk."
Ha a vendor mindenre igent mond, az két dolgot jelenthet:
- Nem érti, mekkora a feladat
- Érti, de nem akarja elveszíteni a projektet
Mindkét esetben te fizeted az árát. Egy független tanácsadó (vagy külső CTO) feladata, hogy ezeket a jeleket felismerje, és a vendor helyett is kimondja az igazságot.
6. Nincs tesztelési terv
A projekt "kész" — de senki nem tesztelte az ügyfél valódi adataival, valódi munkafolyamataival. Az élesítés napján derül ki, hogy:
- A régi rendszerből nem jött át minden adat
- A felhasználók nem értik az új felületet
- Bizonyos edge case-ek hibát dobnak
- A teljesítmény terhelés alatt elfogadhatatlan
A tesztelés nem opcionális fázis — a projekt szerves része. Ha nincs rá idő a tervben, a terv eleve rossz.
Mit tehetsz?
A legtöbb csúszás megelőzhető lenne, ha a projekt elején 3 dolgot megtesznek:
- Egyoldalas scope dokumentum — amit minden érintett aláír
- 2-3 hetente demo vagy státusz — ahol eldől, jó irányba megy-e
- Független kontroll — aki nem a vendortól, és nem a fejlesztőtől jön
Nem garantálja, hogy nem csúszik — de drasztikusan csökkenti az esélyét.