A nagy IT projektek kényelmetlenül nagy arányban nem úgy végződnek, ahogy tervezték. Csúsznak, túllépik a büdzsét, vagy elkészülnek ugyan, de nem hozzák a várt üzleti értéket. Ez nem néhány szerencsétlen eset, hanem évtizedek óta ismétlődő minta.
Amikor egy ilyen projekt megbukik, a szervezet ösztönösen egyetlen bűnöst keres: egy rossz technológiai döntést, egy hibás rendszert, egy gyenge csapatot. A valóság szinte mindig kiábrándítóbb és tanulságosabb: a bukás mögött ritkán áll egyetlen technikai probléma. Sokkal inkább szervezeti és folyamatbeli okok láncolata, amelyek külön-külön kezelhetők lettek volna, együtt viszont kifogtak a projekten.
Nézzük meg a négy leggyakoribb okot, és azt, hol van bennük a minőségbiztosítás valódi, se nem túlbecsült, se nem lekicsinyelt szerepe.
1. Kommunikáció és elváráskezelés
A legtöbb projekt nem a kódban törik meg, hanem a mondatok között. Az üzleti és a fejlesztői oldal ugyanazt a követelményt gyakran másképp érti, és a különbség sokáig láthatatlan marad. Mindkét fél meg van győződve róla, hogy egyetértenek, egészen addig, amíg elő nem kerül az elkészült funkció.
Gondoljunk csak egy olyan gyakori kikötésre, mint „a rendszer legyen felhasználóbarát”. Az üzleti oldalnak ez letisztult, gyors felületet jelent, a fejlesztőnek a technikai megvalósíthatóságot, az ügyfélszolgálatnak a kevesebb bejelentést. Három ember, három kép, egyetlen mondat mögött. Amíg ezt senki nem fordítja le konkrét, mérhető elvárássá, addig mindenki mást épít, és a különbség csak a végén, az átadásnál robban.
Ezt a jelenséget nem véletlenül emelik ki a projektkutatások is. A sokat idézett Standish CHAOS jelentés (első kiadás 1994) szerint a projektek sikerének három legfontosabb tényezője a felhasználók bevonása, a vezetői támogatás és a világos követelmények. Feltűnő, hogy egyik sem technológiai kérdés. Mindhárom kommunikációról és elváráskezelésről szól.
Ahol a közös nyelv és a rendszeres visszacsatolás hiányzik, ott a félreértések végigfutnak a projekten, és a legrosszabb pillanatban, a végén válnak láthatóvá.
2. Kontrollálatlan terjedelemnövekedés (scope creep)
Egy nagy projekt ritkán úgy bukik el, hogy egyszer csak leáll. Sokkal gyakrabban úgy, hogy folyamatosan, észrevétlenül nő. Minden hét hoz egy „ezt még gyorsan tegyük bele” igényt, és külön-külön mindegyik ésszerűnek tűnik. Együtt viszont szétfeszítik az eredeti terveket, a határidőt és a költségkeretet.
Vegyünk egy tipikus példát. Egy nagyvállalati ERP bevezetésnél minden osztály hoz még egy „apró” kérést: a pénzügy egy plusz riportot, a logisztika egy extra mezőt, az értékesítés egy új jóváhagyási lépést. Külön-külön mind jogos. Fél év múlva a terjedelem a duplája, a határidő viszont ugyanaz, és a tesztelésre szánt idő az, ami elfogy. Az éles indulásnál derül ki, hogy a számlázási modul egy ritka, de kritikus esetben rossz adót számol. A hibát nem a fejlesztők tehetetlensége okozta, hanem a csendben növekvő terjedelem, amelyet soha senki nem állított meg tudatosan.
A terjedelemnövekedésnek ugyanis van egy ritkán emlegetett minőségi ára is: minden új igény új tesztelendő felületet jelent. Ha a scope nő, de a tesztelésre szánt idő nem, akkor a lefedettség csendben zsugorodik, és a kockázat nő, anélkül hogy bárki kimondaná.
3. Rossz prioritások és irreális határidők
A „mindent, egyszerre, gyorsan” elvárás a legtöbb projektben ott lappang. A baj nem az ambícióval van, hanem azzal, hogy nyomás alatt mindig ugyanazok a lépések esnek ki először: a minőségi ellenőrzés, a felülvizsgálat, a tesztelés.
Amikor egy projekt csúszni kezd, a legcsábítóbb behozni az időt a tesztelés rovására. Ez rövid távon működni látszik, hosszú távon viszont épp a legdrágább hibákat engedi tovább. A csúszás így nem megszűnik, csak áttolódik a kiadás utáni időszakra, ahol a javítás sokszorosába kerül. És minél nagyobb a szervezet, annál több lépcsőn kell átfutnia egy késői javításnak, ami tovább hízlalja a számlát.
4. A minőségbiztosítás hiánya vagy késői bevonása
Itt érkezünk el a minőségbiztosítás valódi szerepéhez, és fontos, hogy ne becsüljük túl. A QA nem csodaszer, és nem old meg egy rosszul kommunikált vagy rosszul priorizált projektet. De van egy szerepe, amelyet semmi más nem tölt be.
Ahol a minőségbiztosítás csak a folyamat legvégén kapcsolódik be, ott a projekt lényegében vakon repül a kiadás felé. Senki nem méri objektíven, hol tart valójában a rendszer minősége, így a döntéshozó a saját reményeire támaszkodik, nem a tényekre.
A független minőségbiztosítás szerepe itt nem a hibaszámlálás, hanem a valós állapot láthatóvá tétele a vezetés számára. Egy külső, elfogulatlan szereplőnek nincs érdeke szépíteni a státuszt, és nem a saját munkáját kell igazolnia. Épp ezért lát meg olyat is, ami a csapatnak vakfolt: azt, amit a rendszer alkotója öntudatlanul is igazolni akar, nem pedig kikezdeni. Erről a jelenségről a Miért nem szabad a fejlesztőnek a saját kódját tesztelnie? cikkünkben írtunk részletesen.
5. Mit tesznek másképp, akik nem buknak el?
A sikeres nagyprojektek nem attól sikeresek, hogy nincs bennük gond, hanem attól, hogy a gondok időben láthatóvá válnak. Három dolog tér vissza bennük újra és újra.
Az első a korai, közös értelmezés. Az üzleti oldal, a fejlesztés és a minőségbiztosítás már a kezdetkor leül, és tisztázza, mit jelent a siker, és mi a legnagyobb kockázat. Ez a néhány órás befektetés zárja be azokat a réseket, amelyeken a félreértések később kicsúsznak. Hogy ez a korai stratégiai tisztázás mennyire meghatározó, arról a A legtöbb tesztstratégia már a projekt elején elbukik cikkünkben írtunk bővebben.
A második a folyamatos visszacsatolás. Nem a projekt végén derül ki, hol tart a minőség, hanem menet közben, kis lépésekben, amikor még olcsó korrigálni.
A harmadik a független kockázati rálátás. Van egy elfogulatlan szereplő, aki a valós állapotot mutatja meg a vezetésnek, nem a kívánt állapotot. Nem dönt a menedzsment helyett, de gondoskodik róla, hogy a döntés tényeken alapuljon, ne reményeken. Hogy egy vezető szemével mit jelent a jól sikerült kiadás, arról a Mit jelent egy sikeres release a CIO szemével? cikkünkben írtunk.
Összegzés
A nagyvállalati IT projektek elbukása jellemzően többtényezős: a kommunikáció, a terjedelem kezelése, a prioritások és a minőségbiztosítás helye a folyamatban együtt döntenek a kimenetről. Aki egyetlen bűnöst keres, az a következő projektben ugyanabba a hibába fog beleszaladni.
A minőségbiztosítás ebben nem a főszereplő, hanem valami ennél hasznosabb: az egyik legjobb korai figyelmeztető rendszer arra, hogy a projekt letér a pályáról, még akkor, amikor van idő korrigálni. A projektsiker végső soron nem elsősorban technológiai, hanem szervezeti és minőségkultúra kérdése.
Források
- Standish Group: CHAOS Report (IT projekt siker- és bukáskutatási sorozat; első kiadás 1994, legutóbbi teljes kiadás 2020). A cikkben említett három fő sikertényező az 1994-es kiadásból származik, amelyet a későbbi kiadások is megerősítettek. A jelentés módszertanát a szakma vitatja, ezért az adatait nagyságrendi trendként érdemes kezelni, nem pontos igazságként. Elérhető: standishgroup.com (a teljes jelentés fizetős)
