Hát erről is jó sokat lehet olvasni a könyvekben (pl. itt: http://en.wikipedia.org/wiki/Risk_management), lehet őket elkerülni, hatásukat csökkenteni, megszüntetni, felelősöket megnevezni, egyet biztosan nem lehet, nem tudomásul venni őket.
Mi a tapasztalat? Amikor a projekt indul, általában születik egy projekt indító dokumentum (PID) vagy projekt alapító okirat (PAO) vagy bármi más néven futó anyag, ami nagy vonalakban írja le, amit a projektről az elején tudunk. Miről szól, kik és hogyan fogják megcsinálni, erőforrás és költségbecslés, ütemezés és majd minden esetben egy risk management rész. Ez utóbbiban írja le a projektvezető a félelmeit, a potenciális kockázatokat, amik az adott projektre jellemzők vagy azok, amiket zsigerből tud, hogy úgyis baj lesz velük. Utóbbira pár példa: túl kevés üzleti tesztelő/elhúzódó tesztelés az elfogadói teszt során, a tesztkörnyezet instabilitása/különbözősége az éles környezettől, a kapcsolódó háttérrendszerek interfészeinek csúszó fejlesztése, a specifikáció jóváhagyásának – ha egyáltalán ez megtörténik – rétestésztaszerű húzódása. Nagy összegben mernék rá fogadni, hogy a példában szereplő négy esetből három előfordul egy komolyabb szoftverfejlesztési projektben. Ha nagyon komolyan vesszük magunkat, külön dokumentumot szentelünk a témának, amit élőnek nevezünk, mert újra és újra aktualizáljuk és kommunikáljuk. Kockázat megnevezése, a projektre gyakorolt hatása, előfordulási valószínűsége, kezelésének terve. Szép nagy táblázat tud lenni, tudományos szűrőfeltételekkel. Mi a hatása a projektben? Semmi. Lesz több tesztelő, gyorsabban születik meg egy jóváhagyás? Ritka, mikor igen. Általában a hatás korlátozott, hogy politikailag korrekt legyek. Nagyjából ugyanazok a kockázatok kísérik végig a teljes projektet, természetesen más fázisokban, más és más fontossággal, de maga a lista lényegesen nem változik.
Miért van ez? Mert belefáradnak. Mert nyűg, mert intézkedni kell, népszerűtlen döntéseket hozni. És mert a projektvezető alapos, a lista szinte végtelen. Hiszen biztosítani szeretné a hátát, hogy ő időben jelezte a problémát, nem történt semmi, mit tehetne azon túl, hogy újra és újra nyomatékosan elmondja?! Ez vezet ahhoz, hogy mikor akár projekt irányító bizottságon (Project Steering Committee), akár státuszon mutatja be a projekt kockázatokat, gyakorlatilag ugyanazokat a slide-okat használja újra és újra. Nem veszi észre, hogy a hatás ellentétes. Nem veszi észre, hogy ezzel maga is hozzájárul ahhoz, hogy a kockázatkezelés egy kötelezően végighallgatandó/végiglapozandó rész legyen, erősítve ezzel a hallgatólagos belenyugvást, hogy érdemben úgysem tudjuk befolyásolni a dolgokat, majd megoldódik valahogy. Egyszerűbben fogalmazva, ki sokszor farkast kiált, már nem hiszik el neki, még akkor sem, ha már egy komplett falka garázdálkodik a tyúkólban.
Ezzel nagyjából a választ is elárultam, én hogyan csinálnám. “Egy kézzel legfeljebb öt gombot lehet nyomni.” - mondta egyszer egy nagy ember - ha olvassa a blogot magára ismer. A kockázatok közül mindig csak a legfontosabbakkal foglalkoznék, egy Steering Committee-n maximum hárommal, az épp legfontosabb hárommal. Ennél többel döntéshozói szinten nem fognak foglalkozni. De még projektvezetői szinten se. Mikor a kockázatot ismertetjük, nagyon fontos, hogy a projektre gyakorolt hatását tényszerű adatokkal alátámasztva, közérthetően kifejtsük. Mitől félnek döntéshozói szinten? A projekt csúszni fog vagy lényegesen többe kerül a tervezettnél. Meggyőződésem, hogy csak akkor lehet akcióra sarkalni őket, ha legalább az egyik tényező fennáll. Időnként érdemes egy-egy egyszerűbb esetet is bevinni, ami viszonylag könnyen meghozható döntéssel megoldható. Már csak pedagógiai okokból, a sikerélmény miatt.
Vannak olyan esetek is, melyek viszonylag könnyen orvosolhatók. Akár úgy is tűnhet, hogy evidencia. Ne felejtsük el, hogy ami nekünk az, az nem biztos, hogy másnak is. Nem jön meg a szerver? Nem baj, fejleszzünk lokálisan, csak számoljunk rá 3 napot, hogy a kódot majd össze kell tolnunk és elsőre ez ritkán sikerül jól. És persze ezt ne felejtsük el mindenkivel közölni, lehetőleg státuszon, mélyen a fejlesztők szemébe nézve: “Vettétek, lokálisan fejleszt mindenki?”, mail-t korlátozottan olvasnak egyesek. Egyszer kísérletképpen tetettem logolást a wikipédia arra a részére, ami a kódolási szabványról szólt, majd írtam a fejlesztőknek, hol találják a részletes leírást, aminek ismerete ugye elengedhetetlen a munkájukhoz. Lehet tippelni, hányan nyitották meg a következő napokban...
Ami nagyon nem akar megoldódni vegyük le és kezeljük adottságként. Építsük be a tervbe, hogy az üzleti tesztelés el fog húzódni, számoljunk azzal, hogy a megkezdett fejlesztés egyes részeit újra kell majd gondolni, mert az elhúzódó jóváhagyási folyamat alatt változott az igény. Mikor jelezzük ezt, persze mindenki megesküszik majd, hogy “áááá dehogy...”, azért csak készüljünk, ne akkor kelljen kapkodnunk, ha már bekövetkezett. Magunknak meg persze legyen egy részletes táblázat, amiből válogathatunk. Mert a főszabály az, hogy sajnos van miből.
