Kihívások egy háborús övezeti projektben

Ki ne dolgozott volna olyan projekten, ahol minden egyes információért, adatért, feladatért meg kellett küzdenie. Ahol folyamatosan az igazát kellett bizonyítania a többiek előtt. Hogyan lehet az ilyen projektek kihívásait megoldani? A legfontosabb, hogy össze kell fogniuk az egyes csoportoknak és igazi projektcsapatként kell működniük! 

A minőséget nem könnyű elérni. Legyen az egy online bankrendszer vagy egy weboldal ahol repülőjegyet esetleg vonatjegyet foglalsz. Az élet keservessé válik olyan hétköznapi teendőknél, amikor bankfiókba kell menned, hogy egy átutalást elintézz, csak mert a felhasználói szoftver nem válaszol. Funkcionális-, teljesítmény-, biztonsági problémák, és sokszor akár hardveres problémák is folytonosan arcul csapják a cégeket: „Hé, tudod mit? Az alkalmazásod gáz!“ Az olyan lelkes embereknek, akik keményen dolgoznak azért, hogy a legjobb minőségű terméket állítsák elő (vagy legalábbis ők ezt gondolják), ez a reakció sokként hathat. „Mindent megtettem azért, hogy javítsam a minőséget. Mit tegyek, ha mások nem olyan jók mint én?“ Az önsajnálatba való belemerülés csak ront a helyzeten.

Egy háborús övezeti projekt

A háborús övezeti projekt olyan, amiben minden kis apróságért meg kell harcolni. Az üzleti elemző panaszkodik, hogy az elvárásait nem megfelelően valósították meg, a fejlesztő úgy gondolja, hogy a követelmények nem voltak elég világosak, a tesztelő visszavág, hogy a verziók az utolsó pillanatban kerültek ki – a projekt minden egyes apró részlete vádaskodásba torkollik. Ó, tudtad, hogy léteznek az efféle háborúkhoz konferenciatermek, amiket „Háborús termeknek“ hívnak? Bárcsak ledobnák az igazi frontra azokat, akik kitalálták ezt a fogalmat az informatikában!

Tesztelés

Minden csapat megvívja a saját belső háborúját. Minden tesztelőnek harcolnia kell, hogy képes legyen szembenézni az ellene vívott háborúval. Gondolj egy tesztcsapatra! A következő problémák bosszanthatják a tagokat: hozzá nem értő tesztelés, más csapatokkal (programozók, üzleti elemzők, technológiai támogatók, adatkezelői csapatok, stb.) való gyenge együttműködés, a teszteléshez nem megfelelő infrastruktúra, nagy mennyiségű tesztadat hiánya, stb. Ezenfelül a tesztelőknek ezernyi más problémája van, amikor közeleg a határidő.

Fejlesztés

Másfelől, a fejlesztőcsapatok nem biztos, hogy örülnek a rájuk erőltetett követelményeknek, amik nem elég világosak. Sokszor nem ismernek megfelelően minden tulajdonságot, s végül kódolnak egy tetszetős grafikus felhasználófelületet, ahol megáll a felelősségük. Ez gyenge kódolási színvonallal társulva silányul felépített terméket eredményez. Ha már elkezdtek agilis módszertan szerint dolgozni, még azelőtt elárasztanák őket ezernyi követelménnyel, mielőtt az aktuális kitételeknek eleget tettek volna, hogy az adott release piacra dobható legyen. Ez oda vezet, hogy a termék technikai hiányosságpontokat kap, amelyek aztán megvalósíthatatlan feladatlistákhoz vezetnek.

Adatkezelés

Például egy kereskedelmi honlap tipikus tesztkörnyezetében egy laptop 2 forintba kerül, egy mosógép 5 forintba. Az adatelemző, aki a mennyiségről, árról, készletről talál ki tesztadatokat aligha tudja, hogy ezt hogyan fogják használni vagy mivel tesztelik, csupán arra kérik: készítsen 200 darab különféle termékkonfigurációt, s minderre kap 2 órát. Ilyen kényszer alatt egy gépies adatlétrehozó munkát kénytelen végezni anélkül, hogy elgondolkozna a feladat életszerű céljáról. Az adatelemzők tudatosság nélküli munkája színvonal nélküli tesztelést eredményez gyenge adatokkal.

Release-menedzsment

A verziókért felelős release-menedzsment csapatnak lehet, hogy nincs is megfelelő rendszere vagy kialakult konfigurációs folyamata. Engem mindig meglep, amikor egy vállalat remek szolgáltatásokat ajánl más cégeknek mondván, nekik nincs működő verziókövető rendszerük. Ez azt jelentené, hogy egy alkalmazás új verziója felülírná a régi változásokat – napról napra, verzióról verzióra. Micsoda helyzet lenne!
A release-menedzsment-csapatokkal kapcsolatban egy másik kihívás, hogy a legtöbb cégnél az illetékesek az infrastrukturális döntésekhez nem rendelkeznek megfelelő jogosultsággal. Ha nem hozhatnak döntést egy kódellenőrző rendszer beszerzéséről, akkor hogyan számíthatnánk arra, hogy a fejlesztők és a tesztelők tiszta verziókkal dolgozzanak?

A Csillagok háborújának helyrehozása

A cégben senki sincs feljogosítva arra, hogy döntsön a minőségi eredmény támasztotta követelményekről. Mindenki arra kényszerül, hogy saját berkein belül dolgozzon, ahol a programozás a fő funkció, a tesztelés, a technikai támogatás és a release-menedzsment a programozás alárendeltjei. Egy évvel ezelőtt egy neves bangalore-i cég alapítója megjegyezte: „A tesztelés azért van, hogy megkönnyítse a programozók életét. A minőség a tesztelő csapat felelőssége. A tesztelők a minőség portásai és házőrzői.“ És a csapat többi tagja mit fog csinálni? Szabályokat állítanak fel arról, hogy hol, miért és hogyan hibáztak a tesztelők, miközben azok ítélkeznek a minőségről? Valóban? Nőjetek már fel srácok!

Probléma-kontextus kontra projekt-kontextus

Pradeep Soundararajan szerint két kontextus létezik: probléma- és projekt-kontextus. Vannak problémák, amelyek minden projektben felbukkannak. Ilyenek például: későn kirakott tesztverziók, gyenge kódminőség, bizonytalan követelmények, rossz tesztelés, stb. Nem tesz jót a projektnek, ha arra várunk, hogy valami csoda majd megoldja a gondjainkat.
Néhány probléma csak bizonyos projektekben merül fel. Ezekkel már jelentkezésükkor foglalkozni kell. A probléma-kontextus segít hosszútávú megoldást találni, ami a projekt-kontextus számos gondját is megoldja. Idejében göngyölítsd fel őket!

Szembeszegülve a „Minőség Istenével“

Minden cégnél van egy „Minőség Isten“ (Quality Center). Ha elfogadjuk amit ez a Központ mond, s vakon követjük utasításait, akkor csak halmozódik a felesleges dokumentáció, metrika és a hatékonyság követésének folyamatai, miközben folytatódik a tesztelők és a projekt más résztvevőinek a demotiválása, akiket minden kis apróságért elővesznek: „Hány hiba csúszott át?“, „Hány hibát találtak X.Y. fejlesztő moduljában?“, stb. Nem azzal motiváljuk az embereket minőségi munkára, hogy a termelékenységüket méricskéljük. Sajnos a Minőség Istene nem látja ezt az igazságot. Meg kellene szabadulni a vizsgálódástól/ellenőrzéstől, s olyan mércét alkalmazni, ami jobb teljesítményre sarkallja az alkalmazottakat.

Szoros együttműködés

A projektek sikerének kulcsa a csapatok közötti szoros együttműködés – legyen az a programozó, a tesztelő, az üzleti csapat vagy a vezetőség. Ha nincs a csapatok között harmónia, az még több háborúhoz vezet, s a projekt sikerességét kockáztatja. A cégeknél az együttműködésnek a legfelső szintektől a legalsókig kell áramlania – azaz a vezetőségnek elő kell segítenie a csapatok közti szoros együttműködést, ami így a cég alsóbb létrafokán lévő dolgozókat is együttműködésre ösztönzi.

Egy fős hadsereg kontra méhraj

A minőség nem lehet egy-egy fős hadsereg. Egy egész méhrajt kell alkotnia a részvevőknek, akik szorosan együtt dolgoznak az adott probléma megoldásán. Nem elég, ha csak egy csapat teljesít jól. Nagyon fontos, hogy az összes csapat együttesen teljesítsen. Például, semmi értelme egy minőségi tesztelő csapatnak, ha a cég kódolási színvonala gyenge. Valamit tenni kell a silány kódolás ellen. Ez lehet jó fejlesztők bérlése, lépések megtétele egy megadott színvonal elérésére, és a programozók motiválása,  hogy jobban kódoljanak.

Sok kihívással találkozhatunk a háborús övezeti projekteken. Ha a csapatok folyamatosan ugyanazzal a problémával kerülnek szembe minden egyes esetben, akkor nagyobb gond lehet a háttérben, ami megoldást kíván. Ha a projekten belüli kis csapatok elejét veszik a problémának, az megoldhatja a régóta fennálló gondokat, amik akár már hónapok vagy évek óta hátráltatják a céget. Minden projektben számos vezető van aki a saját maga módján irányítja a végrehajtást. Nagyon fontos, hogy őket összehozzuk, és előmozdítsuk a szoros együttműködésüket. A vezetőségi csapatoknak utat kell mutatniuk, hogy a problémákat „egy csapat vagyunk“ szellemében oldják meg.

Sose feledd:
„A minőség mindenkinek a feladata, de a vezetőség felelőssége“ ~ John Guaspari

Szerző: Parimala Hariprasad