54. PM Műhely –Jenei Zoltán : Projekt minőségbiztosítás a gyakorlatban

Jenei Zoltán : Projekt minőségbiztosítás a gyakorlatban

1.Projekt QA típusai

Az informatikai projektek minőségbiztosításának két fő irányát lehet megkülönböztetni.

Az egyik a projekt leszállítandók, azaz a projekt végtermékek (leginkább az elkészült rendszer funkcionalitása, rendelkezésre állása, válaszidők), valamint a köztes termékek (mint pl. követelmény specifikáció, interfész részletes tervek) minőségbiztosítását célozza meg. Vagyis azt, amit a projekt szállít.

A másik irány a projekt működését elemzi és tesz ajánlásokat a javításra, vagyis a folyamatot, dokumentációs rendszert, kontroll pontokat ill. a soft tényezőket (mint pl. a szponzori elkötelezettség) vizsgálja. Vagyis, azt, ahogyan a projekt szállít.

Ha kizárólag az első irányt végez egy projekt, azt leginkább a teszt menedzsment keretében végzi. A teszt menedzsment tipikusan a projekt operatív munkájának a része, azaz a teszt munkacsoport vezetője a projekt menedzsernek (PM) jelent.

Tapasztalataim szerint projekt minőségbiztosítás (projekt QA) cím alatt futó tevékenység alapvetően a másik irányt fedi le: hogyan működik a projekt. Ebből következően a projekt működési módjának értékelésével a projekt vezetés a PM munkáját is értékeli. Ugyanakkor sok esetben konkrét leszállítandókat is elemez a QA csapat: egyrészt mintavétellel annak meghatározására, hogy milyen lehet általában a leszállítandók minősége, és milyen javításokra van szükség, másrészt esetileg szükség lehet arra, hogy a QA néhány kiemelt fontosságú projekt terméket (mint pl. megoldás architektúra) önmagában is teljes körűen megvizsgáljon, feltárja a kockázatokat és problémákat, ill. javaslatokat fogalmazzon meg.

Jelen áttekintésben projekt QA alatt ez utóbbit értem, azaz a „hogyan” elemzését.

2.Projekt QA szervezeti helye

Ahogy az előző fejezetben is említettem, személyes tapasztalataim szerint a legtöbb projekt QA tevékenység a projekt működési módjára fókuszál, azaz arra, hogy milyenek a folyamatok, dokumentáció, kontrollok, együttműködés stb.

Ez egyben azt is jelenti, hogy a projekt QA jelentés a projekt vezetést, és annak részekén a PM-et is minősíti. Az érdekütközés (conflict of interest) elkerülése és a valódik függetlenség biztosítása érdekében lényeges, hogy szervezetileg a projekt QA ne a PM-nek, hanem a projekt szponzornak/szponzoroknak valamint az SC-nek jelentsen.

Ennek megfelelően egy tipikus projekt szervezet a QA-val együtt a következő:

• projekt SC, szponzorok ebben tagok
• PM az SC-nek jelent
• QA az SC-nek jelent
• alprojektek és munkacsoportok a PM-nek jelentenek
• ezen felül lehetnek további szervezi alábontások és jelentési irányok az alprojektekben és munkacsoportokban

Az alábbi ábra egy tipikus banki projekt szervezetet mutat be, benne a QA helyével:

3.QA riport előállítása és bemutatása

A projekt QA jelentés fő célja, hogy a szponzor/szponzorok számára bemutassa a kockázatokat és problémákat (risks and issues), és javaslatot tegyen a megoldásra ill. a kockázat csökkentésre.

Rendszerint az 1-2 havonta tartott projekt SC (Steering Committee) egyik témája a minőségbiztosítási jelentés, így azt ilyen gyakorisággal készíti el a QA csapat, amennyiben nem egyszeri vagy ad hoc minőségbiztosítói felmérést kérnek a szponzorok. A rendszeres jelentés esetén jó gyakorlat egy kezdeti QA felmérés elvégzése abban az esetben, ha a minőségbiztosítási funkció nincs jelen a projekt indulásától fogva.

A rendszeres QA riport előállításának tipikus lépései az alábbiak:

• Projekt dokumentumok, közbenső leszállítandók áttekintése (pl. követelmény dokumentációk teljességi kontrollja)
• Mintavétel alapján részletesebb dokumentum elemzés (pl. néhány interfész specifikáció részletes vizsgálata, összevetés kapcsolódó dokumentumokkal)
• Rendszeres (napi, heti, havi stb.) munkacsoport státusz jelentések és összefoglalók elemzése
• Interjúk kulcs résztvevőkkel, pl. alprojekt és munkacsoport vezetőkkel, kiemelt szakértőkkel, informatikai és felhasználói oldalon az átvevő területekkel
• Benchmark más, hasonló projektekkel, pl. kockázati szintek összehasonlítása, előrehaladási előrejelzések validálása / kritikája hasonló projektek alapján
• A projekt munkáját támogató rendszerek (JIRA, SNOW stb.) tételes adatai alapján trendek és mintázatok meghatározása (pl. hibajavítás minősége és sebessége rendszerenként és szállítónként, nagy átfutási idejű folyamat lépések listája)
• QA riport tervezet összeállítása, benne főbb területenként a kockázat és problémák mértékének összesített jelölése (tipikusan Low/Medium/High, vagy Zöld/Sárga/Piros), a kiemelt kockázatok és problémák listája, mindegyikhez javasolt intézkedésekkel, valamint egy vezetői összefoglaló
• A tervezet áttekintése a QA csapatot biztosító szervezetben partner/senior szinten (szervezeti tapasztalatok beépítése, ill. több szem többet lát)
• Ezt követően a tervezet megküldése véleményezésre az alprojektek, munkacsoportok vezetői és más kiemelt résztvevők számára
• A beérkezett vélemények alapján a riport véglegesítése. Amennyiben valamely észrevétel nem épült be a végleges dokumentumba, formálisabb szervezetek/szponzorok esetében szokásos háttéranyagként csatolni a véleménykülönbségeket
• QA riport bemutatása az SC-n
• A jóváhagyott akciók feladat regiszterben rögzítése, végrehajtóhoz rendelése (feladat, felelős, határidő)

A fentiek közül nem feltétlenül mindet kell alkalmazni, az elemzési lépéseket mindig az aktuális helyzethez kell igazítani.

4.QA jelentés tipikus elemei

A QA jelentés tartalmilag és formailag is eltérhez szervezetenként és projektenként, de tipikusnak tekinthető az alábbi:

• Vezetői összefoglaló – néhány mondatban a legfontosabb megállapítások és olyan lényeges javaslatok, melyek a szponzorok számára is relevánsak
• Dashboard, mely mutatja a projekt működés főbb elemeinek állapotát; tipikus elemek
  1. Szkóp
  2. Ütemezés
  3. Költségvetés
  4. Előnyök
  5. Minőség
  6. Kockázatkezelés
  7. Erőforrás kezelés
  8. HR
  9. Szponzori és üzleti bevonás
  10. Kommunikáció
  11. Rendszerintegráció
  12. Irányítás/Governance
  13. Tervezés
  14. Alprojektek és fázisok
      • Igényfelmérés
      • Tervezés
      • Fejlesztés
      • IT infrastruktúra
      • Tesztelés
      • Adatmigráció és üzembe helyezés/átállás (cutover)
• Kiemelt kockázatok és problémák, mindegyikhez javaslat intézkedésre a kockázat csökkentés és a probléma elhárítás érdekében
• Esetleg egy-egy kritikus témakörre részletesebb elemzés (deep dive), melynek eredménye szintén kockázat/probléma lista a hozzájuk tartozó javító akciókkal

Az alábbi ábra egy QA Dashboard példát mutat be:

5.Jó együttműködés kiépítése

Lényeges, hogy a QA csapat korrekt, nyílt együttműködést építsen ki a projekttel.

Ennek hiányában fontos információ nem jut el a minőségbiztosítókhoz: az interjúkon a projekt tagok elhallgatják, hogy szerintük mik a jelentős kockázatok és problémák, a kért információkat késve vagy hiányosan juttatják el, valamint, ha a QA is részt vesz megbeszéléseken, akkor kerülik az érzékeny témákat. Ezen felül szintén nagy veszteség lehet, ha a kockázatcsökkentő és probléma elhárító intézkedéseket nem tekintik magukénak és nem hajtják végre, így az egész QA tevékenység hasznossága jelentősen lecsökken.

A megfelelő együttműködés hiánya a szponzori szinten pedig jelentősen korlátozza a hasznosulás esélyét és mértékét. Ha egy felsővezető elfogad és fontosnak tart egy intézkedést, annak sikerére sokkal nagyobb az esély, mint a személyes támogatás nélkül.

A jó együttműködést hátráltatja az is, ha a projekt résztvevők, főleg az operatív szinteken, ellenséges ellenőrként, auditorként tekintenek a QA kollégákra. A minőségbiztosítás több ponton hasonlít is az auditori munkára, bár a formalitás szintjében lehetnek és általában vannak eltérések. Ugyanakkor a kooperációt ronthatják az auditori munkához kapcsolódó előítéletek, amelyek esetleges korábbi rossz tapasztalatokból származhatnak.

A jó együttműködés kialakításának módszerei:

• Nyílt és transzparens munkavégzés: mindenki számára ismert, hogy milyen inputok alapják hogyan áll elő a QA riport, a végleges jelentés is publikus a projekten belül
• Konzisztens üzenetek: a minőségbiztosító kolléga nem képvisel mást négyszemközti megbeszéléseken és a formális prezentációban, pl. nem áll össze egy interjún a beszélgető partnerrel egy másik alprojektet szidalmazni többlet információ reményében, majd azután az említett alprojektet pozitívan értékeli
• Szakmai hitelesség: a QA résztvevőknek nagy erős szakmai tapasztalattal kell rendelkezni egyéni szinten hasonló projektekkel, valamint szervezeti szinten is, amit a rendszeres partner/senior review keretében épül be a QA riportba
• Problémák képviselete: a legtöbb projektben van valaki a szervezetben, aki pontosan tisztában van a kockázatokkal és a problémákkal, de valamit miatt ez nem jut el a projekt vezetés és a szponzorok felé: lehet, hogy szervezeti politikailag érzékeny a téma, a közvetlen vezető nem nyitott problémákra, hanem inkább elhallgatná stb. Ha kialakul, hogy a QA elviheti a felsővezetés felé (amennyiben egyetért vele), akkor sokkal több hasznos inputot kap.
• Hasznosság: a minőségbiztosítás keretében – különösen, ha megvan a bizalmi kapcsolat a szponzori szinttel – több olyan intézkedést is le lehet indítani, vagy elakadt terveket tovább lendíteni, amik hasznosak a projekt szempontjából. Ha a résztvevők ezt tapasztalják, akkor inkább együttműködő partnernek tekintik a QA kollégákat.

6.Részvétel a projekt operatív működésében

A minőségbiztosító akkor tud teljes képet adni a projektről, ha benne él annak működésében napi szinten. Lehet ugyan elemzést készíteni kizárólag rendszerben (JIRA, SNOW) lévő adatok, projekt dokumentumok, emlékeztetők és egyéb írásos adatok alapján, de ez nem adja a teljes képet. Hiányzik a megbeszélések szakmai részletessége, az együttműködési stílus, munkamorál érzékelése, az egyes szakértők véleményének ismere (melyik sok esetben egymásnak teljesen ellentmondanak).

Az operatív működésben számos esetben nem csak azért vesz részt a minőségbiztosító, hogy minél teljesebb képet kaphasson a működésről, hanem azért is, hogy közbenső, a rendszeres QA riportokon felüli elemzésekkel egy egyéb leszállítandókkal segítse a projekt munkáját. Ezek lehetnek célzott elemzések adott területre, projekt számítások ellenőrzése, vagy vitás helyzetekben mediátori feladatok ellátása az érintett felek között.

Fontos, hogy konzisztens legyen a részvétel, és ne sérüljön a független minőségbiztosítás elve. Bizonyos esetekben előfordulhat, hogy a QA csapat felkérést kap egy-egy konkrét feladat elvégzésére, azonban ezt annak tudatában kell megtenni, hogy ezeken a területeken – és esetleg az ahhoz kapcsolódó területeken - a független minőségbiztosítás ugyanezzel a csapattal már nem lehetséges.

Ezért törekedni kell arra, hogy a többlet feladatok is inkább elemzési, kockázat és probléma feltárási és javaslat tételi tevékenységek legyen. Ilyen mélyebb elemzési – „deep dive” – munkákat azokra a témákra érdemes elvégezni, ahol problémák vannak, nagy a hatása a projektre, döntéshez minél több szempontot és véleményt szeretne megismerni a SC, régóra húzódó szakmai vitákat kell eldönteni, és egy jó akcióterv várhatóan nagyban növeli a projekt siker esélyét. Példák erre Business Case részletes elemzése, adott tervezési dokumentumok helyességének és teljességének ellenőrzése, JIRA jegyek minőségének áttekintése.

A legtöbb esetben a minőségbiztosító megfigyelő szerepkörben vesz részt a megbeszéléseken, ezzel együtt javaslatokat is megfogalmaz, amikor pl. a megbeszélésen egy adott témában opciókat kell mérlegelni és döntést kell hozni.

Néhány példa azokra a megbeszélésekre, ahol a QA is részt vesz:

• heti projekt menedzsment státusz meeting
• heti alprojekt státusz meetingek – napi és heti, a projekt üzemmódjának és státuszának függvényében
• projekt all-staff összejövetelek
• kritikus területeken napi operatív egyeztetések, mint pl. testing daily stand-up

Ezen felül az alábbi célzott egyeztetések is szükségesek

• áttekintés a projekt vezetővel – általában hetente
• áttekintés a szponzorral – kétheti, havi vagy ritkább, de mindig célszerű a következő SC előtt
• áttekintés az alprojekt vezetőkkel – alkalmilag, ill. ill. interjúk az aktuális QA jelentés összeállítása részeként

Ezeken felül nagyon hasznosak a kávégép melletti és egyéb informális rövid beszélgetések, ahol szintén sok hasznos információ szokott előjönni.

7.Hatalmi viszonyok kezelése

A minőségbiztosítás akkor tud pozitív hatást gyakorolni a projektre, ha a megfelelő hatalommal rendelkező szereplők elfogadják és végigviszik a javasolt intézkedéseket. Ezért lényeges, hogy a QA csapat értse a hatalmi viszonyokat, és a javítások érdekében annak megfelelően tevékenykedjenek.

Számos folyamat, RACI mátrix, szervezeti ábra határozza meg a formális hatalmi viszonyokat, ezen felül vannak kevésbé befolyásolási vonalak is. Az alábbiakban néhány tipikus esetet mutatok be, és azt, hogyan érdemes ezeket kezelni.

• A projektben belül a legtöbb esetben a projekt charterben definiált hierarchia mentén zajlik a munka, az operatív irányítás élén a projekt vezető áll. A résztvevők munkacsoport / alprojekt vezetők irányítják, őket pedig a projekt vezető. A projekt vezető pedig a SC-nek jelent, operatív szinten pedig a szponzor(ok)nak. Itt lényeges a projekt vezetőjével való rendszeres kommunikáció, javaslatok folyamatos megosztása, valamint a prioritásainak figyelembevétele a minőségbiztosítási munka folyamán, nem sértve a QA függetlenségét.
• A projekt szponzorok szerepe a minőségbiztosításban nagyon eltérő. Vannak a projekt működést jó értő és terepen szerzett tapasztalattal rendelkező szponzorok, másoknak nincs elég gyakorlatuk a projektek irányításában és felügyeletében. Néhányan csak az SC előtt kérnek egy rövid tájékoztatást a QA csapattól (leginkább azért, hogy elkerüljék a meglepetéseket), mások heti vagy kétheti rendszerességgel kérnek egyeztetést, akár célzott témákról is, és van olyan is, aki a projekt miatt érzett frusztráltsága miatt mikromenedzselni kezdeni a minőségbiztosítókat. Rendkívül fontos, hogy a QA csapatnak legyen a szponzorral rendszeres egyeztetése, ne csak az SC előtti rövid felkészítés. Hasznos, gyakorlatias, egyben felsővezetői szintű elemzéseket és javaslatokat kell tenni. Ez a bizalmi viszony alapja. Ha a bizalom megvan, és a szponzor számára többlet érték a QA tevékenység, akkor lényegesen nagyobb az esélye annak is, hogy a javaslatokat a szervezet megvalósítja.
• Szervezeten belül a projekt egy átmeneti struktúra, mely számos ponton erősen kapcsolódik a befogadó szervezethez, mint pl. követelmények definiálása, erőforrások biztosítása, a végtermék átvétele használatra és üzemeltetésre. Ezen felül a SC tagjai is a befogadó szervezet vezetői közül kerülnek ki. A minőségbiztosítóknak meg kell érteni a ezen a területen is a hatalmi viszonyokat, és fel kell tárni a kockázatokat és problémákat. Ha pl. egy terület ellenséges a projekttel szemben, szükségtelennek és így az erőforrás felhasználás miatt károsnak tartja, akkor fel kell mérni, hogy mik a problémák az adott terület szempontjából, és lehetnek-e olyan intézkedések, amelyek által ez az ellenséges hozzáállás csökken, pl. valamilyen hasznos többlet funkció, ami a projekt sikerét nem gátolja. Így a QA tudja segíteni a szervezeti ellenállás csökkentését, és így a projekt kudarc kockázatát. Tapasztalataim alapján a befogadó üzleti területek kimondottan jól veszik és együttműködők, amikor a minőségbiztosítók megkeresik őket.
• Kevés projekt működik szállítók bevonása nélkül, akár kisebb elszórt feladatok elvégzésére, akár rendszerintegrációra. Ugyan a legtöbb esetben ténylegesen közös és jól együttműködő csapatokat alakítanak ki, problémák esetén kiéleződhetnek az ellentétek és a hatalmi harcok („addig nincs baj, ameddig nincs baj”). A legtöbb esetben ezt csúszások, valamint nagyobb változtatási igények okozzák, mivel ezeknek komoly pénzügy, erőforrás következményei lehetnek. A minőségbiztosító esetében itt is lényeges, hogy objektív és pártatlan módon végezze az elemzéseket és tegyen javaslatokat. Ugyan a QA megbízója az egyik fél (általában az ügyfél és nem a szállítók), szükséges a pártatlanság, mivel ellenkező esetben releváns hibák nem javíthatók és összességében a kockázatok nem csökkenthetők. Ha pl. az egyik szállító termékeit nagy arányban utasítják el a tesztelők, ennek lehet oka rossz minőségű specifikáció is a megrendelői oldalon, amit be kell mutatni, és javaslatot tenni a javításokra.
• Számos vállalat és szervezet része vállalatcsoportnak vagy nagyobb szervezetnek. Az adott országban működő projektet így – általában akkor, ha az adott projekt a legnagyobban között van – gyakran felügyeli az anyavállalat is, akár úgy, hogy a SC munkájában is részt vesznek. Ugyan operatív szinten a lányvállalatok elvileg és formálisan általában önállóak, az anyavállalati befolyás nagyon erős, hiszen ők képviselik a tulajdonost, fogadják és a stratégiát és az éves terveket, valamint a költségvetést. Ezen felül sok olyan projekt fut a lányvállalatoknál, amit az anyavállalat kezdeményezett, pl. egységes informatikai rendszer bevezetése érdekében. Az anyavállalat gyakran delegál képviselőt a projektbe, akinek feladata az anyavállalati szempontok képviselete, ill. ezzel együtt az anyavállalati segítség megszervezése szükség esetén, pl. csoport szintű beszállító menedzsmenttel. A minőségbiztosítónak célszerű kiépíteni rendszeres kapcsolatot az anyavállalati képviselővel. Ez lehet heti, kétheti kockázat áttekintés, valamint a QA riportok előzetes egyeztetése.

A fenti hatalmi viszony rendszerben (projektben belül, szponzor, befogadó szervezet, beszállító, anyavállalat) sokszor vannak konfliktusok, eltérő meggyőződések és érdekek. A minőségbiztosító feladata, hogy minden információt feldolgozva adjon egy objektív és részrehajlás-mentes kockázat és probléma elemzést, valamint javításai javaslatokat. Ezt első körben a szponzornak és a PM-nek kell bemutatni, és a visszajelzéseiket indokolt esetben beépíteni az elemzésbe, a függetlenség elvének megtartásával. A hatalmi viszonyrendszer okozta kockázatokat és problémákat is nyíltan javasolt átbeszélni, benne azt, hogy ezeket hogyan lehet csökkenteni.

8.Ki biztosítja a minőségbiztosítás minőségét?

Mint minden tevékenységben, a minőségbiztosításban is lehetnek hiányosságok, hibák. Ezért fontos azoknak a kontrolloknak a beépítése, amit hozzájárulnak, hogy a QA megfelelő minőségű elemzéseket szállítson le. A leginkább használatosak az alábbiak

• Több résztvevő a minőségbiztosítói csapatban. Több szem többet lát, és több agy többet gondol. Az eltérő nézetek kiegészítik egymást, a gondolkodási hibákat könnyebben felfedezzük. Ezért érdemes legalább két főt bevonni a QA működésbe, pl. egy teljes munkaidős kolléga helyett egy heti 2 és egy heti 3 napos lekötöttséggel.
• Partner / senior review. A QA tevékenységben napi szinten részt vevők figyelmét nagymértékben lekötik az operatív információk, rendszeres megbeszélések, részletes adatelemzések. Szükség van arra, hogy távolabbról, a részletekből kiszakadva is időnként átnézze, és intenzív visszajelzésekkel javítsa az elemzéseket, nagy tapasztalatú résztvevők, aki általában a minőségbiztosítást végző vállalkozás partnere vagy kiemelt szakértője. Érdemes elvégezni minden QA riport véglegesítése részeként.
• Vállalati kockázatkezelés bevonása. Több gazdasági szektorban, pl. a banki világban jogilag is kötelező jelleggel létezik kockázatkezelési szervezet. Vannak olyan esetek, amikor a vállalati kockázatkezelés is adat egy elemzést az SC-re. A velük való rendszeres egyeztetés szintén segíti a minőség javítását.
• Széles körű véleményezés. A QA jelentéses tervezetét érdemes szélesebb körben elküldeni véleményezésre, pl. a minden munkacsoport / alprojekt vezetőnek. A visszajelzések hasznos információkat tartalmazhatnak – és tapasztalatom szerint általában tartalmaznak is -, amik segítik a dokumentum véglegesítését. Itt is igaz, amit korábban már említettem, hogy a függetlenséget meg kell őrizni. Pl. ha egy kockázatot magasnak értékel a minőségbiztosító, akkor ezen csak akkor változtasson, ha új információt kap – pl. általa nem ismert kontrollról, és nem csökkentse a kockázat értékelési szintet, ha nincs új adat, csak eltérő megítélés a véleményező részéről.
• Belső ellenőrzés. A vállalati belső ellenőrzés – néha az anyavállalat szintjéről delegálva – időnként szintén végez vizsgálatokat. Egy átfogó projekt audit részét képezi minden lényeges tevékenység, így a QA auditálása is. Ugyan nem folyamatosan, hanem utólag vagy bizonyos időközönként, de ez is egy többlet lehetőség a minőségbiztosítás minőségének értékelésére, és javító intézkedésekre.

9.Kockázat, problémák, javaslatok nyomon követése

Munkája során a QA csapat sok kockázatot és problémát feltár. Ezekhez ad javaslatokat is, melyeket a szponzornak és az SC-nek bemutat. Egy hosszabb projekt esetében ezek száma több száz is lehet.

A hasznosuláshoz több lépés szükséges:

• a szponzor és az SC döntse el, hogy melyik javasolt intézkedéseket kívánja végrehajtani
• a PM rendeljen felelőst és határidőt a javasolt intézkedésekhez
• a felelősök kapják meg a feladatok egyértelműen és félreértések nélkül (ezt általában az előző ponttal együtt, egyeztetéssel érdemes elvégezni)
• a PMO vagy QA terület végezze a feladatok nyomon követését
• a szponzor és az SC rendszeresen tekintse át az előrehaladást, és döntse el, hogy mi történjen csúszások vagy nem teljesítések esetén

A nyomon-követés eszköze célszerűen az, amit egyébként is széles körben használ a szervezet, mint pl. amilyen a ma sok helyen jelen lévő JIRA rendszer. Ha viszont ilyen eszköz nincs, vagy a használata nem elterjedt, akkor a célnak kiválóan megfelel a PMO vagy QA csapat által vezetett Excel tábla is.

Az eszköznél lényegesebb, hogy legyen a folyamatnak egy operatív gazdája, valamint az, hogy a PM és fontosnak tartsa és vezetőként irányítsa a feladatok kiosztását és felügyelje, valamint támogassa a végrehajtást.

10.Buktatók és azok elkerülése

Ugyan a projekt minőségbiztosításra vannak bevált gyakorlatok, a napi életben számos olyan buktató van, melyek kikerülésére folyamatosan figyelni kell. Néhány buktató és a lehetséges kezelési javaslat:

• Kockázatok alul- vagy túlértékelése. Ha magas kockázati értékeket és komoly problémákat mutat be a QA jelentés, akkor előfordulhat, hogy az érintettek – akár projekt vezető vagy szponzor is – érzékenyen, akár megbántva reagálnak. Emiatt az minőségbiztosító visszavehet a kockázati értékből vagy már a tervezetben is alacsony értéket határoz meg, a kockázatokat alulértékeli. Más esetekben, pl. várható csúszás érzékelésekor vagy támadások hatására a QA mindent túlságosan magas szintre értékelhet, hogy utólag ne lehessen felróni neki, miért nem szólt időben. Mindkét szélsőség ártalmas. Ezen buktatókat segít elkerülni a kockázati értékelés objektív és mérhető definíciója, a partner / senior review, a benchmark és természetesen a minőségbiztosító tapasztalata.
• Túlságosan adat vagy túlságosan vélemény alapú inputok. A projektben rengeteg adat keletkezik, ezek elemzésével olyan trendeket és korrelációkat lehet feltárni, melyek segítenek az objektív előrejelzésekben és javító intézkedések kidolgozásában. Tipikus példa, hogy a tesztelés volumene és időbeli előrehaladása, a hibajegyek száma és a létrehozásuk időbeli elosztása, a hibajavítások átfutási idejének eloszlása, valamint a javítások sikerességének aránya alapján elég jó előrejelzést lehet adni arra vonatkozóan, hogy mikor éri el a rendszer az elvárt minőséget. Ugyanakkor ebből hiányzik az a többlet információ és értékelés, amit a projekt tagok tudnak adni a saját értékelésük alapján, pl. hogy más hasonló projektekben mit tapasztaltak az adott szervezetben, a nehéz vagy könnyű teszt eseteken vannak-e túl, és hogy mi az ő becslésük, szakértő véleményük arra vonatkozóan, hogy milyen előrehaladás várható. Másrészt nem elég, ha a minőségbiztosító csak a résztvevők véleményét ismeri meg interjúk és a résztvevők által készített dokumentumok alapján, mert azt befolyásolja az adott személy kockázati felmérő képessége és szándéka, nyíltsága (mennyire akarja felvállalni a rossz közlését), és vágyai a gyors előrehaladásra (wishful thinking).
  A két megközelítést kombinálni kell. Szükség van az QA csapat által végzett adatalapú elemzésekre, és az interjúkra ill. informális egyeztetésekre is. Az adat alapú eredményekkel érdemes szembesíteni a részvevőket és kikérni a véleményüket, másik oldalról az interjúkon előjöhetnek olyan problémás területek és szempontok, amik alapján fókuszált adatelemzéseket lehet végezni.
• Objektivitás torzulása. Számos olyan helyzet adódhat, amikor a minőségbiztosítás függetlensége vagy objektivitása torzulhat. Lehet, hogy a szponzor ill. a PM nehezen fogadja el a rossz híreket és a negatív értékelés, különösen akkor, ha a szervezeti kultúra általában is arra hajlamos, hogy a problémákat elhallgassa. Más példa: a beszállítói együttműködés megromlása estében a QA csapat megbízója kérheti, hogy álljon az ő oldalukra, hiszen ők adják a megbízást, tehát az ő érdekeiket kell szolgálni. Általános szabály, hogy a minőségbiztosító ne adja fel az objektivitást, és mindig a szakmai meggyőződésének megfelelő jelentést és értékelést adjon át a megbízójának. Azt pedig már a megbízónak kell mérlegelni, hogy a jelentést milyen körben és milyen módon kommunikálja és használja fel.
• Túl általános vagy nem reális javaslatok. A minőségbiztosítás akkor ad értéket, ha a javasolt intézkedések megtétele esetében csökkennek a kockázatok és a problémák. Ehhez az kell, hogy a javaslatok kellőképpen specifikusak és egyben reálisak legyenek. Néhány rossz példa: „Nagy figyelmet kell fordítani a minőségre” (általános), „Meg kell kétszerezni a saját fejlesztői kapacitást egy hónap alatt” (nem reális). Többek között így lehetne konkrét „Az x, y, és z minőségi mutatókat át kell tekinteni a heti projekt meetingen, és döntéseket kell hozni a javításokra, utókövetéssel.” és reális: „Külső partner bevonásával is havonta 20% fejlesztői kapacitás növelést kell végrehajtani.”

11.Személyes tapasztalataim, élményeim

Amikor CISA képzésre jártam, az oktató ezzel a viccel indította az első foglalkozást.

„A belső ellenőr találkozott az informatikai igazgatóval, hogy átbeszéljék a következő auditot.

• Azért jöttem, hogy segítsek – mondta a belső ellenőr.
• Örülök, hogy jöttél – mondta az informatikai igazgató

Ebben a pillanatban két hazug ember volt a szobában.”

Utána a képzésen az volt az egyik fókusz, hogy ne ez történjen, hanem hogyan legyen hasznos az auditori munka, az auditor valóban segítséget akarjon adni, az auditált terület pedig szívesen vegye és használja a segítséget.

Ugyan a minőségbiztosító nem belső ellenőr és auditor, mégis sok a közös jellegzetesség, pl. a kockázatok és problémák feltárása, intézkedési javaslatok, függetlenség.

Eddigi szakmai pályafutásom alatt főleg a megrendelői oldalon dolgoztam, sok évet CIO szinten, távközlésben és bankokban. Személyesen több mint 1.000 projektet felügyeltem IT szponzorként. Ezt követően több szervezetben végeztem és végzek független projekt minőségbiztosítást.

A legfontosabb tapasztalatom mind a vevői, mind a szállítói (minőségbiztosító) oldalon, hogy a nagy projektben szükséges és hasznos a független minőségbiztosítás. Egy nagy projekt rengeteg költséget felemészt havonta, ezért, ha a QA tudja csökkenti a csúszási vagy minőségi kockázatokat, akkor a tevékenysége bőségesen megtérül. A megtérüléshez még hozzájárul az, hogy elkerülhető az esetleges projekt bukás miatt veszteség leírás vagy megelőzhető egy járulékos kár, mint pl. a projekttől függő termékbevezetés időbeli megcsúszása.

Természetesen a minőségbiztosítói jelentést meghallgatni nem mindig kellemes élmény, mint ahogy néha nem kellemes élmény egy átfogó orvosi vizsgálat eredményét végigolvasni sem. De ahogy az egészségi problémák esetében, úgy a projekt problémáknál is lényeges a megfelelő időben való kezelés és beavatkozás, hogy a nagyobb problémákat elkerüljük.

Szükséges, hogy a szponzor mindenkiben tudatosítsa, hogy a minőségbiztosítás valóban hasznos lehet, és legyenek együttműködők a QA csapattal, hogy hasznos is legyen.

Minőségbiztosítói oldalról pedig úgy kell dolgozni, hogy a munka eredménye hasznos legyen, ezt folyamatosan szem előtt kell tartani. A kockázat és probléma értékelések legyenek objektívak. A javasolt intézkedések legyen specifikusak és reálisak. A szervezetet pedig abban kell támogatni, hogy a javasolt akciókat hajtsa végre, ezt mérni is szükséges.

Az 54. PM Műhely megbeszélendő kérdései:

1. Hogyan definiáljátok, méritek és biztosítjátok a QA tevékenység hozzáadott értékét?
2. Hogyan kezelitek azt a helyzetet, amikor több rivalizáló szereplő a QA-t akarja felhasználni arra, hogy az ellenoldal fölé kerekedjen?
3. Mennyire tartjátok szükségesnek ill. elfogadhatónak a napi munkában való részvételt, mint pl. tesztelési tevékenységek felügyelete, PMO feladatok részletes átvétele
4. Mi a stratégiátok arra a helyzetre, amikor a megbízó az adott ország lányvállalata, de a anyavállalat mikro-menedzseli a lányvállalatot?
5. Hogyan határozzátok meg a kockázati szinteket?