Agilis változáskezelés a gyakorlatban

A változások implementálása általában elég merev folyamat. Szeretnéd az implementációt agilisabban megközelíteni? Ez többféleképpen is lehetséges. Ebben a blogban elmagyarázom, hogyan tehetjük agilisabbá egyes változások kivitelezését és hogyan kezelhetjük agilisabban a részlegeden belüli változásokat.

Hogyan lehet egy változást agilisabban implementálni?

Ahogy az előző blogomban is írtam, egy change, vagyis egy változás implementációja eléggé kötött folyamat. Nézzük meg, hogyan lehet az egyes változások kivitelezését agilisabb módon kezelni.

Csak a célt és a keretfeltételeket határozzuk meg

A változás igénylésekor jó esetben nem kell egy teljes űrlapot kitölteni, elég csak a nélkülözhetetlen dolgokat meghatározni. A két elengedhetetlen dolog, amit rögzítenünk kell, a cél és a keretfeltételek.
Képzeld el például, hogy duplán érkezik be a meghibásodott kávéfőzővel vagy a lassú mailszerverrel kapcsolatos bejelentés. Ahhoz, hogy a duplán bejelentett hibákat megelőzzük, szeretnénk az ügyfelek számára láthatóvá tenni, hogy az adott hibát korábban bejelentette-e már valaki. Azt a célt kell kitűznünk, hogy a felhasználók lássák, milyen bejelentések érkeztek be korábban. Ugyanakkor meg kell győződnünk arról is, hogy ezáltal nem válnak láthatóvá mások személyes, például HR-rel kapcsolatos adatai. Ez egy keretfeltétel.

A célnál és a keretfeltételeknél nem kell sokkal többet tudnunk ahhoz, hogy neki tudjunk kezdeni a folyamatnak.

Ellenőrizzük rendszeresen, hogy teljesülnek-e a keretfeltételek és a cél

Ha egy változást a hagyományos vízesés modell alapján valósítunk meg, megnő az esélye annak, hogy a folyamat végén a megoldás nem felel meg az ügyfél kérésének. A vízesés modell során az előre elkészített, lépésről lépésre követett tervből indulunk ki.
A folyamatos korrigálásnak időközben nincs helye. Az implementáció ideje alatt éppen elég dolog változhat. Lehet, hogy az ügyfélnek újabb igényei merülnek fel, vagy egy új technológia jelenik meg a piacon, amelynek segítségével jobb eredményt érhetünk el.

A változás tervezése és megvalósítása során többször is fel kell tennünk a kérdést: hozzájárul még az, amit csinálunk, az eredetileg kitűzött célhoz? Teljesülnek a feltételek is? A kisebb változásoknál ez nem mindig releváns, mivel ezeket egyszerűbben tudjuk kivitelezni. Azonban a nagyobb változásoknál a rendszeres ellenőrzés kimondottan hasznos.

A megoldás nem megfelelő? Ebben az esetben lehetséges az időközbeni korrekció. Néha azonban túlságosan előrehaladunk ahhoz, hogy javítsunk rajta. Ilyenkor ne félj megállni és közbeavatkozni. Előfordul, hogy ez nagyon nehéz, mert már sok időt és energiát fektettünk bele, de mégis jobb megállni, mint tovább haladni, és létrehozni egy olyan megoldást, ami végül senki számára nem lesz igazán hasznos.

Vonjunk be több szakértőt

Ha egy change megvalósításával kapcsolatban van egy új ötleted, jó, ha azt több szakértő kritikus szemmel megvizsgálja. Milyen hatása lehet ennek a többi alkalmazásra és a hardverekre? Jelenthet-e kockázatot a biztonság szempontjából?
Hagyományosan a „sanity check-et”, vagyis az alapvető tesztet a CAB-csapat tagjai hajtják végre, amikor egy kérelmet értékelnek ki. Az agile filozófiája szerint jobb, ha a csapatra bízzuk a megoldás kitalálását. Azonban, ha az IT-csapat találja ki a megoldást, a „sanity check”, amelyet ideális esetben a CAB-csapat hajt végre, kiesik. Hogyan tudjuk ezt megoldani?

Nincs szabadság felelősség nélkül. Ne csak a megoldás kitalálásával kapcsolatos szabadságot add meg az IT-csapat számára, hanem a felelősséget is, és ellenőriztesd szakértők segítségével, hogy a megoldás valóban működőképes lesz-e.

Hogyan kezeljük agilisabban a részlegedet érintő összes változást?

Az IT-osztály soha nem csak egy változáson dolgozik egyszerre. Még egy 6-8 fős csapatnál is könnyen előfordulhat, hogy a párhuzamosan zajló változások száma 10-20 közé esik, de akár több is lehet. És ez valóban sok. Néha olyan érzésünk támadhat, hogy kicsúszott a kezünkből az irányítás.

Korlátozzuk az egyidejű változások számát

A megoldás kézenfekvő: korlátozzuk a párhuzamosan kivitelezett változások számát. Igen, könnyebb beszélni róla, mint megvalósítani. Azonban megéri a fáradtságot, mert egy csapásra több legyet is üthetünk vele:
Könnyebben megjósolható egy változás átfutási ideje. Kevesebb változáson dolgozva kevesebb bizonytalanság merül fel a munka során, és jobban látható, mikor fejeződik be a változás implementálása.
Jobb minőségű új szolgáltatást kapunk. Kisebb az esélye annak, hogy hibázunk, ha zavartalanul, teljes figyelemmel a munkára koncentrálunk.
A csapat számára is élvezetesebb lesz a munka. Jobban tudnak fókuszálni, ezáltal pedig gyorsabban érnek el eredményeket. A Harvard Business Review kutatása kimutatta, hogy az előre látható végkimenetel az egyik legfontosabb munkakedvet befolyásoló tényező. Ez sokkal nagyobb motivációt jelent a kollégák számára, mint ha egyszerre száz dolgot csinálnának, amelyek közül egy sem eredményes.

Változások vagy incidensek: különítsük el őket

Hogyan tudunk elegendő időt fordítani a változásokra, ha közben nyakig ülünk az incidensek között? Hozzunk megfontolt döntést azzal kapcsolatban, mi a legfontosabb a csapat számára.
Szeretnél biztosítani egy meghatározott átfutási időt egy változás esetében? Ehhez minden csapat számára meg kell határozni azt az időintervallumot, amikor csak ezzel foglalkoznak, és el kell fogadni azt, hogy néha az incidensek megoldása tovább tart majd.

A legfontosabb az incidensek mielőbbi megoldása? Ebben az esetben el kell fogadnunk, hogy a változás implementálása tart hosszabb ideig, és a csapat lassabban fogadja be az újdonságokat.

Oszd meg velünk tapasztalataidat!

Az agilis változáskezelés még gyerekcipőben jár. Te már kísérleteztél vele? Kíváncsiak vagyunk a tapasztalataidra, ezért oszd meg velünk kommentben!
Szeretnél többet tudni az agilis szolgáltatásmenedzsmentről? Olvasd el az Agilis szolgáltatásmenedzsment - 6 gyakorlati példán keresztül című blogunkat!