„A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process.” - Wikipedia

„A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process.” - Wikipedia

Nem olyan régen egy megbeszélésen jártam, ahol különböző területek európai vezetői vettek részt, és arról beszélgettünk, hogyan tudná a cégünk jobban kezelni a változás igényeket.

A legelső benyomásom az volt, hogy a változás igények kezelésére minden terület kialakított egy folyamatot. Ezek a folyamatok nagy vonalakban hasonlítanak egymásra (hasonló lépésekkel és döntési pontokkal), de valójában egyik folyamat sem azonos a másikkal. Vagy a lépések sorrendje tér el, vagy extra lépéseket tartalmaz, vagy másképp hozzák meg a döntéseket az egyes pontokon.

Nagyjából fél napot beszélgettünk ezekről a dolgokról, próbáltunk egységesíteni, amikor kiderült, hogy dacára minden hasonlóságnak és egymásra hasonlító folyamatoknak, a változás alatt mindenki egészen mást ért.

Az infrastruktúra és üzemeltetés területen dolgozó vezetők számára a változás valójában telepítést jelent. Például egy új szerver építése, új szoftver verzió élesbe telepítése, konfiguráció változtatás. Azaz változás a meglévő infrastruktúrán. Az, hogy kinek miért van erre szüksége, hogyan jutottunk el idáig, az nem annyira érdekes. Csak az, hogy este 20:00-kor a ZBERG28 nevű szerverre fel kell telepíteni a 431353-es számú telepítő csomagot az ott megadott lépések szerint.

A szoftverfejlesztés számára a változás nem más, mint egy kitöltött+jóváhagyott változáskérelmi formanyomtatvány, ami elkezdődik a kérelem megkapásával, befejeződik a kérelem sikeres megvalósításával, a telepítés pozitív visszaigazolásával és a kérelem lezárásával. Ennek a hosszú folyamatnak része a telepítés (lásd előző bekezdés), de ez csak egy lépés a sok közül. Ráadásul nem is a legfontosabb, mert az inkább az elemzés és a tesztelés.

Az üzleti döntéshozók számára a változás nem más, mint olyan igény, ami kellő haszonnal jár ahhoz, hogy eljusson a lista élére, és ezért méltó legyen a változáskérelmi nyomtatvány kitöltésére. Számukra a folyamat ott kezdődik, hogy összegyűjtik az ötleteket. A munka derékhada az, amikor az egyes ötleteket kiértékelik, cost-benefit és ROI számításokat végeznek, és utána döntés hoznak. Miután a döntés megvan, csak lepasszolják a fejlesztőknek, és innentől a munka számukra nagyjából véget is ért (leszámítva a számukra kevéssé fontos tesztelést és éles indulást).

A munkatársak (IT szakszóval: felhasználók) számára a változás egy új ötlet vagy egy új kérés, amit bedobnak a megfelelő virtuális ötletládába, aztán imádkoznak, hogy megvalósuljon. Számukra a folyamat az ötlettel kezdődik. A munka javát azt jelenti, hogy lobbizni kell az ötlet megvalósításáért, gondoskodni róla, hogy a listán előre kerüljön. Ezzel a munka java le is van tudva, már csak várni kell, hogy kész legyen. Hogy mivel jár az ötlet megvalósítása, hányszor kell a rendszerszervezőnek összeülnie a szakértőkkel, a fejlesztőkkel és az architect-tel, az nem annyira érdekes.

A konklúziót a Kedves Olvasóra hagyom J