Egy olyan csapat vezetésével bíztak meg, ami jó szakértőkből állt és sokat dolgoztak, az ügyfél mégis elégedetlen volt, és ez sok konfliktust eredményezett. Utólagos visszatekintés.

Egy olyan csapat vezetésével bíztak meg, ami jó szakértőkből állt és sokat dolgoztak, az ügyfél mégis elégedetlen volt, és ez sok konfliktust eredményezett. Utólagos visszatekintés.

Úgy esett, hogy egy IT csapat vezetésével bíztak. A csapat egy multinacionális nagyvállalaton belül végzett szoftverfejlesztési, alkalmazástámogatási és projekt feladatokat a szintén cégen belüli ügyfél részére. A fejlesztő csapat 10 főből állt, fejlesztők, koordinátorok és PM-ek vegyesen, két országban két külön irodában. Az ügyfél valójában ügyfelek hálózatát jelentette szerte Európában, egy központi koordinációs/döntéshozó csapattal. A fejlesztőknek a döntéshozó csapattal kellett együtt dolgozni.

A kiindulási problémát az jelentette, hogy ez a döntéshozó csapat, a menedzserek – vagyis az ügyfél - elégedetlenek voltak a fejlesztőkkel. Amikor valamilyen változtatásra volt szükség, a fejlesztés rendszerint késett – az IT volt mindenben a „kerékkötő”. A késések miatt sok volt az eszkaláció, és ebből adódóan sok volt a konfliktus. Az általános benyomás az volt, hogy „az IT nem csinál semmit”. Az ügyfelek egy „agilis” IT-t szerettek volna, ami nem megkerülendő akadály hanem partner az üzletmenet fejlesztésében.

Az IT csapatot jobban megismerve a következőkre derült fény: Elkötelezett, hozzáértő emberekből állt, akik régóta végezték munkájukat, nagyon értettek a technológiához, sokat dolgoztak, és igyekeztek a minőségi elvárásoknak megfelelni. A szoftver jól működött, évek óta nem volt adatvesztés vagy kritikus leállás.

Ugyanakkor a rendszertelenül beérkező fejlesztési igények, a sok eszkaláció, a prioritások változása, a direkt felhasználó-fejlesztő kommunikáció sok fennakadást okozott. A csapat alapvetően jól működött, nem volt szükség radikális változtatásokra. Ugyanakkor világossá vált, hogy bizonyos dolgokat lehet – és kell – javítani.

Az első változtatás arra irányult, hogy az IT csapat munkáját transzparenssé tegyem az üzleti vezetők felé. Őket mindig csak az aktuális fejlesztések érdekelték, miközben az IT csapat nagyon sok máson is dolgozott: hibákat javított, karbantartott, projekteket vezetett, projekteket készített elő. Ezek közül az aktuális priós ügyek csak a munka kis részét jelentette – a többit láthatóvá kellett tenni. Ezért bevezetettem egy havonta elkészülő vezetői tájékoztatót, ami a csapat által lefedett terület ÖSSZES informatikai feladatát tartalmazta, eredmények, státusz, projektek, metrikák és előrejelzés témákkal.

Mivel minden adat egy prezentációban jelent meg, közérthető módon, ezért mindenki megértette, mit csinál a csapat, és mit ért el. Korábban nem látott összefüggések jelentek meg, például hogy ha egy adott hónapban sok komoly hiba esett be, akkor a projektek nem haladtak annyira.

A következő dolog az IT és az üzleti terület közötti kommunikáció javítása volt. Korábban a fejlesztési igények kontrollálatlan, teljesen véletlenszerűen estek be. Tipikus eset: az egyik felhasználó az ebédlőben „csípi el” a fejlesztőt, kér tőle valamit, aztán amikor az nem lesz kész másnapra, akkor eszkalál.

Alapszabályként azt fogalmaztuk meg, hogy új igényekkel ne a fejlesztőket keressék meg közvetlenül, hanem engem. Amiről nem tudok és amiről nem tud az üzleti vezető, az nincs, azért nem vállalok felelősséget. A fejlesztők pedig elhessegették a kiskaput kereső felhasználókat.

Ugyanakkor létrehoztunk egy „hivatalos csatornát” a fejlesztési igények leadására, ami ellenőrizhető és számonkérhető. Az igényeket 3 részre osztottuk:

1) Programhibák: Ezeket emailben a helpdesk-re kell bejelenteni, és követni kell a cégnél hatályos helpdesk folyamatot. Súlyos programhibákkal azonnal foglalkozunk, tehát garantáljuk üzletmenet folytonosságát.

2) Change Request-ek: Kisebb fejlesztési igények (1 hónap vagy rövidebb) egy CR listára kerülnek fel, amit az üzleti vezető priorizál, és minden héten közösen átnézzük. Az IT csapat garantálja, hogy ezeket a fejlesztéseket a legjobb tudása szerint végrehajtja, a prioritás szerinti sorrendben (vagyis az 1. helyen álló igényt először, utána a 2. helyen állót, stb)

3) Projektek: Nagyobb fejlesztési igények (1 hónapnál nagyobbak) külön erőforrást igényelnek, ezért ott be kell tartani a cégnél hatályos, a projektekre vonatkozó folyamatokat. Például szükség van szponzorra, projekt indító dokumentumra, jóváhagyásokra. A jóváhagyott projektek saját dedikált erőforrással rendelkeztek, ezért azok végrehajtása garantált (határidő, scope, budget).

Ezzel a 3 folyamattal az összes igényt sikerült lefedni, és mind a 3 fajta igényre (hibajavítás, kis fejlesztés, nagy fejlesztés) sikerült egyértelmű és kontrollált utat adni. Mindegyik esetben a végrehajtás mérhető és visszaellenőrizhető, elkerülendő a félreértéseket.

Az új folyamatok bevezetésénél a felhasználókat segíteni kell a folyamatok megismerésében és betartásában. Fontos volt, hogy ezt ne felesleges bürokráciának lássák, hanem megértsék azt, miért van erre szükség. Fontos volt, hogy a folyamatok egyszerűek legyenek, tehát például az átlagos felhasználónak csak annyi dolga volt, hogy írja le a kérését emailben X-nek és kérjen rá Y-tól jóváhagyást.

Ugyanakkor azt is világossá kellett tenni, hogy ha valami nem követi a folyamatokat, akkor azzal nem biztos, hogy a csapat tud foglalkozni – hiszen a csapat éppen az üzleti vezető által jóváhagyott feladatokon dolgozik.

Az új folyamatok során kulcsfontosságú volt a beérkező igények szűrése. Azzal, hogy a folyamat egységes lett, megelőztük azt, hogy ugyanakkor essen be sok különböző igény különböző emberektől. Az üzleti vezetés látta, hogy mik az aktuális igények, és pontosan meg tudta mondani, ezek közül mi fontos és mi nem. Nem az IT szűrte az igényeket, hanem az üzlet – megszűnt az ellenségeskedés.

A beérkező igényeket nem csak szűrni, hanem limitálni is kellett. A csapat ugyanis csak 10 főből állt, és csak adott mennyiségű fejlesztést tud elvégezni egy hónapban. Megegyeztünk, hogy a Change Request-ek listája maximum 10 elemű, ennél több ügyön nem tudunk egyszerre dolgozni. Viszont nem szólunk bele, hogy mi az a 10, és hogy milyen sorrendben van. Akinek pedig nagyobb munka kell határidőre, az indítson projektet.

Eddig nagyrészt az ügyfél kommunikációról írtam, de az is világossá vált, hogy az új folyamatok mellé megbízható teljesítést is kell tenni – tehát növelni kell a hatékonyságot. Az eszkalációk és a felesleges ügyfél-kommunikációk elkerülésével a hatékonyság már emelkedett, de ennél többre volt szükség. Meg kellett keresni azt a módot, hogy ha az üzleti vezető kér valamit, akkor az tényleg elkészüljön – mert ha nem készül el, akkor az IT kerékkötő lesz.

Ehhez az első lépés az volt, hogy a csapat belső működését meg kellett változtatni: „mindenki mindent csinál” helyett dedikált emberek végezzenek dedikált feladatot. Amíg mindenki mindent csinált, addig ha beérkezett egy hiba, akkor mindenki eldobta az aktuális munkáját és nekiállt a javításnak. Márpedig hibák mindig érkeztek. Ezért a munkavégzés esetleges volt.

Ez átalakult abban az értelemben, hogy a csapat néhány tagja dedikáltan csak hibajavítással, a beérkező hibajegyekkel foglalkozott, míg másik csakis fejlesztéssel és CR-ekkel foglalkoztak. És természetesen voltak akik mindkettővel, az adott helyzettől függően. Ez az átszervezés azt jelentette, hogy ha beérkezett egy új hiba, akkor senki sem dobta el az aktuális munkáját, hiszen tudták, hogy valaki biztosan foglalkozik a hibával és megjavítja azt. Az új fejlesztéseken fix emberek dolgoztak, ezért garantálható volt, hogy a fejlesztések elkészüljenek.

Amikor pedig nagyobb fejlesztés esett be, akkor arra lett külön ember a projekt költségvetéséből, nem kellett a többi munkavégzést felfüggeszteni.

A szoftver jó minőségű volt, de mégis érkeztek be hibák – köztük sok volt az ismétlődő vagy ugyanarra az okra visszavezethető hiba. Bevezettem, hogy a helpdesk hibajegyeket heti rendszerességgel átnézzük, keressük a hasonló okokat és trendeket keresünk. Egy-egy hiba helyett azokra a jelenségekre koncentrálunk, amik sok hibát – ezzel együtt sok munkát – okoznak. Elindultunk egy olyan úton, hogy hónapról hónapra egyre kevesebb hibánk lett – egyre több idő maradt új fejlesztéseket csinálni.

A trend analízis során kiderült, hogy sok hiba nem a csapat „bűne”: interfész hibák, kézi adatbevitel, kézi riporting. Ezeket lépésről lépésre automatizáltuk, hogy kiiktassuk az emberi hiba lehetőségét. Az interfész hibák okát megkerestük és korrigáltuk (ami azért volt nehéz, mert sokszor hálózati problémára vezettük vissza, azaz nem alkalmazás hiba). Sok interfész hiba adódott, egy hibás adatküldés kijavítása jelentős mennyiségű emberi beavatkozást igényelt: nem csak az interfészt kellett újraküldeni, de ellenőrizni az adat integritást és a tranzakció sikerességét mindkét oldalon.

A kézi adatbevitel és kézi riporting helyett inkább a szoftver lett megokosítva, hogy ezeket a felhasználók maguktól is megtehessék. Előfordult, hogy valakinek 1 napi munkájába került adatokat kinyerni az adatbázisból kézzel az egyik üzleti szakértő számára, akinek erre a riportra minden hónapban szüksége volt.

Végül pedig a fenti lépések eredményeit össze kellett gyűjteni és visszajelezni a csapat, illetve az üzlet felé. Őszintén elmondani: miben volt javulás, mi az amin még dolgozni kell. A visszajelzés fontos, különösen ha pozitív.

Az első pozitív élmények után ugyanis mindenki megtáltosodott, és futószalagon hozta az ötleteket, mit hogyan lehetne jobban csinálni.

Fél év alatt sikerült eljutni oda, hogy a kezdeti ellenséges légkör megszűnt, egy év múlva pedig már konstruktív együttműködés jellemezte az IT és az üzlet kapcsolatát.

Az „agilis IT” vonalról e cikk 2. részében foglalkozok.