Van egy mém ami pontosan leírja a scope creep-et: egy aranyos kiskutya rajza a projekt indulásakor, majd hat kép múlva egy szőrös, agyaras, hétfejű szörnyeteg , ugyanazzal a felirattal, hogy "ugyanaz a kutya, csak pár apró módosítással."
Ismerős? Ha valaha vezettél projektet, biztosan.
A scope creep az egyetlen jelenség az IT-ban, ami mindenkit egyszerre érint, mindenki panaszkodik rá, és mégis szinte senki nem kezeli tudatosan. Ez egy kicsit olyan mint az időjárás - mindenki beszél róla, de senki nem csinál semmit ellene. Pedig lehetne.
Mi az a scope creep, pontosan?
A hivatalos definíció: a projekt hatókörének fokozatos, nem tervezett bővülése a projekt indulása után anélkül, hogy ezt megfelelően dokumentálnák, jóváhagynák, vagy kompenzálnák időben és pénzben. (Még idevehetjük a projekt tartalmának módosulását is, mert a gyakorlatban az is bővíti a feladatokat.)
A gyakorlati definíció: az a pillanat, amikor valaki azt mondja "csak egy apró dolgot kellene még hozzátenni" - és három hónappal később rájössz, hogy a projekt fele ezekből az "apró dolgokból" áll.
A scope creep nem egyetlen nagy katasztrófa. Nem egy hatalmas robbanás. Sokkal inkább egy lassú, észrevehetetlen szivárgás ezért is nevezik "creep"-nek, nem "explosion"-nek. :-) Egy-egy kis kérés önmagában ártalmatlannak tűnik. (Minden apró kérés ártalmatlan...sokszor nem is dokumentáljuk pontosan...)jAz összesített hatásuk viszont képes derékba törni bármilyen jól megtervezett projektet. (Főleg, ha nem is dokumentáljuk az apró változásokat...)
Tipikus scope creep helyzetek - amiket Te is biztosan felismersz
"Csak egy gyors megbeszélést szeretnék"
Ez a mondat statisztikailag a scope creep leggyakoribb előszele. :-) A "gyors megbeszélés" végén mindig van egy új ötlet, amit "úgyis be lehetne tenni, hiszen már úgyis ott vagyunk a kódolásban...csak egy paró módosítás..."
A demo utáni lelkesedés
Bemutatod a software-t. A stakeholder lelkes. Aztán elkezdi mondani: "ez tényleg jó, de mi lenne, ha még hozzátennénk..." - és a demo, ami a haladást volt hivatva bemutatni, hirtelen egy új wishlist felolvasásává válik.(Általában a demozás nem alkalmas új igények befogadására..arra normális workshop kell...)
A "ezt biztos nem vettétek észre" jelenség
Valaki felfedez egy edge case-t, amit a specifikáció nem tartalmazott , és azonnal új követelményként kezeli, nem pedig egy olyan kérdésként, amit priorizálni és tervezni kell.
A vezetői "csak egy kérés"
A legveszélyesebb típus. Amikor egy vezető szól be egy "apró" kéréssel, senki nem meri megkérdezni: ez hogyan hat a határidőre? Mert ki merne visszakérdezni a főnöknek?
A fejlesztői jószándék
Igen, ez is scope creep, csak befelé irányuló. A fejlesztő úgy gondolja "amíg itt vagyok, megcsinálom ezt is rendesen" , és egy 2 órás feladatból 2 napos lesz, mert közben "csak még egy kicsit" foglalkozott vele. (Tipikus, amikor a fejlesztő gyorsan végig gondolja, hogy á műszakilag ez nem túl sok munka...csak nem gondol mindenra...ezért máshol is feladatot generál..meg egyébként is alulbecsülte...nem beszélte meg a BA-val, PM-el....)
Miért veszélyesebb a scope creep agilis projekteknél?
Itt jön a rész, ami sokakat meglep , de logikus, ha végiggondoljuk.
Waterfall projekteknél a scope creep látható és fájdalmas: mindenki tudja, hogy egy fix, megkövesedett terv változik, és ez formálisan is engedélyt igényel. Kellemetlen, de átlátható.
Agilis projekteknél viszont a scope creep álruhában érkezik. Mert az agilis módszertan alapja a változás elfogadása - "reagáljunk a változásra a terv követése helyett" áll az Agilis Kiáltványban. Ez fantasztikus elv. De van egy csapdája:
Ha minden változás "agilis rugalmasság", akkor semmi sem scope creep - még akkor sem, ha az.
A csapat megszokja, hogy a backlog folyamatosan változik. A sprint közben érkező "sürgős" kérések természetesnek tűnnek - hiszen "agilisek vagyunk, alkalmazkodunk." A product owner minden új ötletet betesz a backlogba, mert "ott a helye, majd priorizáljuk." Az eredmény: a scope folyamatosan nő, de soha senki nem mondja ki hangosan, hogy "ez most scope creep."
A rugalmasság néha csak szép neve a kontrollálatlan változásnak.
Hogyan ismerd fel, mielőtt túl késő?
Néhány korai jel, ami előre jelzi a bajt:
A sprint státuszjelentések egyre optimistábbak, miközben a tényleges haladás lassul , mert a csapat próbál lépést tartani az új igényekkel anélkül, hogy ezt hivatalosan jelezné.
A csapat egyre gyakrabban mondja: "ezt nem így képzeltük el" - ez azt jelzi, hogy az eredeti közös megértés már nem érvényes.
A "csak egy gyors kérdést" típusú megbeszélések száma nő, miközben mindegyik végén valami új követelmény születik.
A sprint velocity csökken, de senki nem tudja pontosan miért, mert az extra munka nem hivatalos backlog itemként, hanem "gyors javításokként" szivárog be. (Utána azt látjuk, hogy a sprintek csúsznak...rosszul terveztünk...pedig jól terveztünk...csak beengedtünk plusz feladatokat...
Kinek a feladata kezelni?
Ez a kérdés, amit a legtöbb cikk elkerül, de itt nem fogjuk.
A product owner felelőssége a backlog prioritizálása és a kapuőr szerep , minden új igény hozzá fut be, ő dönt hogy bekerül-e a backlogba és mikor. Ha a product owner nem elérhető, nem döntésképes, vagy nem meri visszautasítani a felsővezetői kéréseket- a scope creep garantált. (A PO az, aki legjobban átlátja az igényeket, neki kell nemet mondnai, vagy
A projektmenedzser vagy delivery lead felelőssége a hatás láthatóvá tétele. Nem az a feladata, hogy megakadályozza a változást - hanem hogy minden változásnál egyértelműen kommunikálja: ez mibe kerül időben, pénzben, csapatkapacitásban. (Azaz neki kell kirakni az aztalra a problémát, és nem engdeni elsikkadni...ha bővül a scope akkor azt kezelni kell a projekt tervezésben...mert azért lehet olyan eset, hogy indokolt a bővülés...de akkor is kezelni kell.)
A csapat felelőssége a jelzés , amikor valami new work-öt kap ami nem volt a sprint tervben, ezt fel kell szólalni, nem csendben elvégezni.
Az üzleti elemző felelőssége - és itt jön a rész, amiért mi ezt fontosnak tartjuk , hogy az igényt már a legelején olyan mélységben tárja fel, hogy a "váratlan felfedezések" száma minimális legyen. A scope creep jó része nem is új igény, hanem olyan régi igény, amit senki nem fedezett fel időben. (Persze egy sokváltozós helyzetben ez nem könnyű...ezért fontos az elkészült tervek alapos végigelemzése...és jóváhagyása...)
A gyakorlati eszköztár nem elmélet, hanem working megoldás
Definiáld, mi NEM tartozik a scope-hoz. A legtöbb specifikáció csak azt írja le, mi a cél. A jó specifikáció explicit módon leírja, mi nem tartozik bele. Ez a legkevésbé bevallott, mégis leghatékonyabb védekezés. (Ez szerintünk a legjobb módszer a későbbi viták elkerülésére, és a NEM sokszor rámutat látens igényekre, mert amikor az ülzet látja, hogy mi NEM, akkor jobban eltudja képzelni...)
Vezess változási naplót nyilvánosan. Minden scope módosítás kerüljön be egy közös, mindenki által látható listába: mit kértek, mennyi pluszidőt/erőforrást igényel, ki hagyta jóvá. Ez nem bürokrácia ez transzparencia, ami lehetetlenné teszi a "csendes" scope creep-et. (Mondhatjuk, hogy alap, de még is sokszor elsikkad a backlog...vagy nem elég részletes...nincs jobb módszer...)
A sprint zárva van pont. Ha valami tényleg sürgős, az azt jelenti valami mást kivesznek helyette. Nem azt, hogy a csapat pluszban dolgozik. Az "egyenlő csere" elve az egyetlen ami valóban működik. (Egy pontozásos agilis módszertannal ez vizualizálható is. 3 story pont be 3 story pont ki....:-))
A demo ne "wishlist gyűjtés" legyen. A sprint review célja a visszajelzés a leszállított munkára nem egy új ötletbörze. Az új ötletek természetesen felmerülnek, de ezeket a backlogba kell irányítani, nem azonnal a következő sprintbe. (Ez nagyon fontos. A demo az demo. Ha ez alapján további egyeztetést lát fontosnak az üzlet, akkor az külön workshop, ahol mindneki ott van... a szokásos eszközökkel...backlog..specifikéció...jóváhagyás....)
Mérd és mutasd meg a hatást. Ha valaki azt mondja "csak egy apró dolgot", mutasd meg neki számokban: ez X óra fejlesztést, Y nap csúszást jelent. A absztrakt kérésekből konkrét trade-off-ok lesznek és , hirtelen már nem is tűnik olyan "aprónak". (A story pontozás szerintünk ebben jó segítség lehet...figyelj ez egy 1 napos munka...)
A pénzügyi szektorbeli sajátosság
Pénzügyi szektorbeli projekteknél a scope creep egy extra dimenzióval bővül: a szabályozói változások. (illetve ezkenek a szabályozóknak az értlemezése...sajnos nagyon sokszor menet közben alakulnak a szabályok...lásd most AI...tehnikailag már van...EU szabélyozás már van...de nincs még MNB ajánlás...
Míg egy sima fejlesztési projektnél a scope creep "csak" stakeholder kívánságokból ered, addig biztosítóknál, bankoknál és lízingcégeknél gyakran menet közben érkező kötelező szabályozói követelmények is bővítik a hatókört. Ez nem elutasítható scope creep , ez compliance kényszer. (Ezért kell ma már mindne projektbe kötelezően compliance felelős....)
A megoldás itt nem a visszautasítás, hanem a különválasztás: legyen egy külön "compliance sáv" a projektben, saját kapacitással, ami elválik a diszkrecionális fejlesztési igényektől. Így a kettő nem keveredik , és nem az derül ki, hogy egy MNB előírás miatt csúszik a marketing csapat kért funkciója is.
Mit csinálunk a FrontX-nél?
A FrontX projektjein minden scope módosítás formális változáskezelési folyamaton megy át , függetlenül attól, hogy "kicsi" vagy "nagy" a kérés. Nem azért, mert bürokraták vagyunk, hanem mert tapasztalatból tudjuk: a kis kérések összeadódnak.
Amikor szoftvert fejlesztünk, .minden változás dokumentálva van, hatásvizsgálattal, és az ügyfél explicit jóváhagyásával. Ez nem lassítja a projektet, ez az, ami megakadályozza, hogy a projekt hat hónappal később egy hétfejű szörnyeteggé váljon, miközben mindenki azt hitte, hogy még mindig a kiskutyán dolgoznak. A backlogra különösen figyelünk...az ügyfelektől mindig kérjük a compliance officer jelenlétét a projektekbe...alapvetően minden erőforrásigényt előre rögzyítünk....mert nagyon sokszor a szű keresztmetszet a megrendelő...ezért késés...rohanás...a projektszabályok lazítása....
Ha a projekted kezd egy kicsit "hétfejűvé" válni — szívesen segítünk visszaterelni a kiskutya méretére: frontx.hu/kapcsolat
Gyakran ismételt kérdések
Mi a scope creep egyszerűen megfogalmazva?
A scope creep a projekt hatókörének fokozatos, nem tervezett bővülése a projekt indulása után , anélkül, hogy ezt megfelelően dokumentálnák, jóváhagynák vagy kompenzálnák időben és erőforrásban. Nem egyetlen nagy változás, hanem sok kis, önmagában ártalmatlannak tűnő kérés összeadódó hatása.
Miért veszélyesebb a scope creep agilis projekteknél?
Mert az agilis módszertan alapelve a változás elfogadása - ez viszont álcát ad a kontrollálatlan scope bővülésnek. Ha minden változás "agilis rugalmasságnak" számít, senki nem mondja ki hangosan, hogy valójában scope creep történik. A waterfall projekteknél a scope változás formális és látható; agilis projekteknél könnyen észrevétlen marad.
Kinek a feladata a scope creep kezelése?
Megosztott felelősség: a product owner a kapuőr szerep és prioritizálás felelőse, a projektmenedzser a hatás láthatóvá tételéért felel, a csapat a jelzésért ha nem tervezett munka érkezik, és az üzleti elemző azért, hogy az eredeti igényfeltárás elég mély legyen ahhoz, hogy minimalizálja a "váratlan felfedezéseket."
Hogyan lehet felismerni a scope creep korai jeleit?
Néhány jel: egyre optimistább státuszjelentések lassuló tényleges haladás mellett, gyakori "ezt nem így képzeltük el" megjegyzések, növekvő számú "gyors megbeszélés" ami új követelményekkel végződik, és csökkenő sprint velocity megmagyarázhatatlan okokból.
Hogyan kezelik a scope creep-et pénzügyi szektorbeli projekteknél?
Pénzügyi szektorbeli projekteknél gyakran szabályozói kényszerek is bővítik a hatókört - ez nem elutasítható, mint egy stakeholder kívánság. A legjobb megoldás egy külön "compliance sáv" kialakítása saját kapacitással, elválasztva a diszkrecionális fejlesztési igényektől, hogy a kettő ne keveredjen a priorizálásban.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban.
LinkedIn: linkedin.com/in/laszlobehan | FrontX blog: frontx.hu/blog
