A változások implementálása általában elég merev folyamat. Szeretné az implementációt agilisabban megközelíteni? Ez különböző módokon történhet. Ebben a blogban elmagyarázom, hogyan lehet egyes változásokat agilisabbá tenni, és hogyan tudjuk a részlegünkön belüli változásokat agilisabban kezelni.
Hogyan lehet egy változást agilisabban implementálni?
Ahogyan az előző blogomban is megírtam, egy change, vagyis magyarul egy változás implementációja eléggé kötött folyamat. Ezért először is 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öltenünk, elég csak a nélkülözhetetlen dolgokat meghatároznunk. A két elengedhetetlen dolog, amelyeket rögzítenünk kell, a cél és a keretfeltételek.
Képzelje el például, hogy duplán érkezik be a meghibásodott kávéfőzővel vagy a lassú mailszerverrel kapcsolatos bejelentés. Azért, hogy a duplán bejelentett hibákat megelőzzük, szeretnénk ügyfeleink 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. Azonban meg szeretnénk bizonyosodni arról is, hogy ezáltal nem válnak láthatóvá ügyfeleink számára 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 ugyanis 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 nincsen helye. Az implementáció ideje alatt ugyanis éppen elég dolog változhat. Lehet, hogy az ügyfélnek újabb igényei merülnek fel, vagy egy olyan új technológia jelenik meg a piacon, amelynek a segítségével jobb eredményt érhetünk el.
A változás tervezése és a megvalósítása során több kérdést fel kell tennünk: hozzájárul még az, amit jelenleg csinálunk az eredetileg kitűzött célunkhoz? Teljesülnek a feltételek is? A kisebb változások esetében 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ünk megállni és közbeavatkozni. Előfordul, hogy ez nagyon nehéz, mivel már sok időt és energiát fektettünk bele. Mégis jobb megállni, mint tovább haladni, és létrehozni egy olyan megoldást, ami végül is senki számára nem lesz majd igazán hasznos.
Vonjunk be több szakértőt
Ha egy change megvalósításával kapcsolatban van egy új ötlete, jó, ha azt több szakértő kritikus szemmel megvizsgálja. Milyen hatása lehet ennek a többi alkalmazásra és a hardverekre? Kockázatot jelenthet 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 az, 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ége, kiesik. Hogyan tudjuk ezt megoldani?
Nincsen szabadság felelősség nélkül. Ne csak a megoldás kitalálásával kapcsolatos szabadságot adjuk meg az IT-csapata számára, hanem a felelősséget is, és ellenőriztessük szakértők segítségével, hogy a megoldás valóban működőképes lesz-e.
Hogyan tudjuk agilisabban kezelni a részlegét érintő összes változást?
Az IT-osztály soha nem csak egy változáson dolgozik egyszerre. Még egy 6-8 főből álló csapatnál is könnyen előfordulhat, hogy a párhuzamosan zajló változások száma 10-20 közé esik, de ennél 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, mivel egy csapásra több legyet is üthetünk vele:
Könnyebben megjósolható egy változás átfutási ideje. Azáltal, hogy kevesebb változáson dolgozunk egyidőben, kevesebb bizonytalanság merül fel a munka során és jobban láthatóvá válik, mikor fejeződik be a változás implementálása.
Egy 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 az, ha száz dolgot csinálnak egyszerre, amelyek közül egy sem eredményes.
Változások vagy incidensek: egyértelműen 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, hogy mi a legfontosabb a csapat számára.
Biztosítani szeretne egy meghatározott átfutási időt egy változás esetében? Ehhez minden csapat esetében meg kell határozni azt az időintervallumot, amikor csak ezzel foglalkoznak és el kell fogadnunk azt, hogy néha az incidensek megoldása tovább tart majd.
A legfontosabb az incidensek mielőbbi megoldása? Ebben az esetben tudomásul kell vennünk, hogy a változás implementálása tart hosszabb ideig és a csapat lassabban fogadja be az újdonságokat.
Ossza meg velünk tapasztalatait!
Az agilis változáskezelés még gyerekcipőben jár. Ön már kísérletezett vele? Kíváncsiak vagyunk a tapasztalataira, ezért ossza meg velünk őket kommentben!
Szeretne többet tudni az agilis szolgáltatásmenedzsmentről? Olvassa el az Agilis szolgáltatásmenedzsment – 6 gyakorlati példán keresztül című blogunkat?
