Az előző rész folytatásaként most azzal foglalkoznék, hogy az ügyfél agilis IT-t képzelt el, és ebből mi lett. Agilis vagy nem agilis a jó?

Az előző rész folytatásaként most azzal foglalkoznék, hogy az ügyfél agilis IT-t képzelt el, és ebből mi lett. Agilis vagy nem agilis a jó?

Egy 10 fős IT csapat vezetésével bíztak meg, amely belső szolgáltatóként a belső ügyfél számára végzett fejlesztési, karbantartási és projektvezetési feladatokat. A helyszín egy nagyvállalat, ahol az ügyfél valójában egész Európára kiterjedő hálózatot jelent.

A kiindulási helyzet az volt, hogy az üzleti oldal elégedetlen volt az IT csapattal (nevezzük most a csapatot Alfának). 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.

Ezt az érzést erősítette, hogy a felhasználók egy másik IT csapattal is – nevezzük őket Bétának – dolgoztak. Béta külső csapat volt, fizetésüket közvetlenül az üzlettől kapták. Ezért ha az üzlet valamit akart és holnapra készen kellett lenni, akkor készen volt – még azon az áron is, hogy éjszakázni és túlórázni kellett.

Tehát két csapat állt szemben: a hagyományosan dolgoz Alfa és a sokkal dinamikusabb, agilisabb Béta. Az ügyfelek azt szerették volna, hogy az Alfa csapat is legyen olyan, mint Béta.

Az első dolgom volt felmérni a helyzetet.

Nos, nekünk IT-soknak minden felhasználó és minden döntéshozó ugyanolyan, de a valóságban ez nem igaz. Itt ebben az esetben az üzlet alaposabb megismerése után kiderült, hogy az üzleti sajátosságok miatt sok a változás folyamat szinten. Mivel a szoftverek a folyamatok alapján működnek, ezért a szoftvereket folyamatosan változtatni kellene. Ez a legtöbb esetben nem így van: általában elég a szoftvert egyszer jól megírni, és utána csak kevés változtatást kell tenni. Például egy jól megírt számlázó programon csak akkor kell változtatni, ha törvényi változás van.

Szóval itt ebben az esetben az üzletet a sok változás jellemezte. Ezek a változások szoftver változtatást, folyamat változtatást, oktatást, ellenőrzést és persze koordinációt jelentettek.

Kiderült, hogy a szoftver hibákra kevéssé érzékenyek a felhasználók. Fontosabb volt, hogy a kért változtatás elkészüljön és gyorsan készüljön el, mint hogy tökéletes legyen.

Ezen felül kulcsfontosságú volt, hogy a változtatások elindítása jól koordinált legyen – azaz legyen erős az üzlet-IT közötti kommunikáció és együttműködés.

A fejlesztőkkel beszélgetve az alábbi dolgok derültek ki:

A munka nem csak fejlesztésből áll, hanem karbantartásból és hibajavításból is. A fejlesztők számára a minőség a legfontosabb. A szoftverrel nem volt semmilyen komoly probléma 1 év alatt, nem veszett el adat – ez sok munka, de ugyanakkor a felhasználók számára láthatatlan.

Itt az is világossá vált, hogy a fejlesztőknek egy bizonyos szinten igaza van: adatot nem veszíthetünk, kritikus rendszerleállás nem elfogadható. Érdekesség, hogy miközben ez egy fontos üzleti igény, de a döntéshozók és felhasználók nem említették az elvárásaik között. Akkor pedig miből gondolom, hogy fontos igény? Mert ki lehet számolni, mennyi kár érné a céget, ha ezek az adatok sérülnének. És ha valóban történik valamilyen baj, akkor mindenki ujjal mutogatna az IT-ra.

Az is kiderült, hogy már hosszú ideje konfliktus van Alfa és Béta csapat között. Alfa fejleszti a backend rendszert, miközben Béta a frontend-et. Az Alfa fejlesztői szerint Béta rossz minőségben teljesít, rengeteg a programhiba (szemben a backend rendszer stabilitásával). Béta szerint viszont az Alfa fejlesztői lusták és nem értenek a szakmához, hiszen a legapróbb módosítás is hónapokig tart (ami nekik 1 napig).

Vagyis úgy tűnik, két módszertan áll egymással szemben: a bürokratikus, folyamat-alapú fejlesztés a rugalmas, agilis fejlesztéssel.

A terv:

A helyzet alaposabb megismerése után világossá vált, hogy az Alfa csapatnak sokkal rugalmasabbnak kell lennie, azaz valamilyen szinten agilizálódni kell. Ugyanakkor a minőségből nem szabad engedni, és emiatt továbbra is folyamatok mentén kell dolgozni. Tehát a két véglet között meg kell találni azt a pontot, ahol az eddigieknél gyorsabb fejlesztésre van lehetőség és sokkal jobban az ügyfél áll a középpontban, ugyanakkor a minőség is megmarad.

Ez konkrétan három lépést jelentett:

1) Agilis gondolkodásmód bevezetése

2) A meglévő folyamatok ésszerűsítése és lerövidítése

3) A folyamat-alapú fejlesztés megtartása mellett agilis eszközök bevezetése

Bónusz lépésként pedig: Béta csapat „normalizálása”

1) Agilis gondolkodásmód

A fejlesztők eddig minőség- és folyamatcentrikusak voltak. Akkor volt jó a fejlesztés, ha éles indítás után nem lépett fel hiba, és ha nem volt adatvesztés. És nem ez volt az, amit a felhasználók kértek.

El kellett magyarázni a csapatnak, hogy a felhasználók az IT értékét akkor látják, ha dinamikusan együtt tudunk működni változó célok mellett, és gyorsan tudunk szállítani. Egy részmegoldás vagy egy fázisolt megoldás sokkal jobb, mint egy lassú de tökéletes.

Azt is elmondtam, hogy a felhasználók nem rosszindulatból ilyenek, hanem mert az üzleti környezet változik, a piac változik. És ha ezeket a változásokat nem követjük le, akkor a cég minden nap pénzt veszít.

Amikor egy felhasználó azonnali megoldást kér, akkor azért teszi, mert bajban van. Próbáljunk meg segíteni neki, keressünk kreatív megoldásokat – természetesen a minőség fenntartása mellett (az továbbra is cél, hogy adatvesztés ne legyen).

Ezeket az elveket aztán a gyakorlatban is követni kellett. Amikor legközelebb jött egy menedzser egy „most azonnal megoldás kell” kéréssel és a fejlesztő elzavarta, akkor leültünk, átbeszéltük a dolgokat, és megpróbáltunk agilisabban hozzáállni.

Ja igen, és az is fontos volt, hogy ezeket az elveket ne csak a kulcsemberekkel, hanem a teljes csapatban el kellett fogadtatni.

2) A meglévő folyamatok ésszerűsítése és lerövidítése

A meglévő folyamatokat újra kellett gondolni és leegyszerűsíteni. Leegyszerűsítettük annak a módját, hogy egy felhasználó új igényt tegyen fel a listára. A listát is egyszerűsítettük, ésszerű kompromisszumot kötve: egyszerre csak kevés feladaton dolgozunk, de azon gyorsan.

A csapat átszervezése is ezt a célt szolgálta ki.

A legtöbb esetben elég volt a józan észre hagyatkozni. Mind a fejlesztőknek, mind a felhasználóknak voltak ötleteik, hogyan lehetne a dolgokat jobban és gyorsabban csinálni. Ezeket az ötleteket kellett csak felkarolni és végigvinni.

Amint a fejlesztők számára világos volt, mi az üzleti cél, onnantól kezdve nem volt ellenállás – mindannyian ugyanazon az oldalon álltunk.

3) A folyamat-alapú fejlesztés megtartása mellett agilis eszközök bevezetése

A minőségi sztenderdekből nem engedtünk, ezért a folyamat-alapú fejlesztéstől nem lehetett elszakadni (igény-jóváhagyás-felmérés-tervezés-fejlesztés-tesztelés-release). Ugyanakkor senki nem tiltotta meg, hogy ne használjunk agilis eszközöket.

Az egyik ilyen volt a daily standup, ahol az ügyfél oldal képviselője is részt vett. Ez nagyon gyors visszacsatolást eredményezett, gyorsan lehetett dönteni vagy reagálni az eseményekre.

A másik dolog egyfajta Kanban-szerű rendszer bevezetése. Mivel sokan sokfelé voltunk, ezért ez egy hálózati hely volt az intraneten, ahol az aktuális fejlesztések, azok státusza és az aktuális igények voltak megtekinthetőek. Ezt rendszeresen frissítették mind a fejlesztők, mind a felhasználók. Ez a hely mindenki számára elérhető és megtekinthető volt, tehát bármikor bárki láthatta, hogyan áll az adott fejlesztés, vagy hogy milyen feladatok között lehet válogatni.

A harmadik dolog a sprintek bevezetése a projekt munka során. A sok változtatás miatt szinte lehetetlen volt projektet vezetni úgy, ahogy az a nagykönyvben meg volt írva – hiszen az üzleti igények időben változtak. Részletes tervezés helyett inkább azt favorizáltuk, hogy a projekt terv csak elnagyolt volt és elsősorban az üzleti célokra koncentrált. A munka 1 hónapos ciklusokban haladt, a részletes terv havonta lett újra írva, és ott is elsősorban a következő 1 hónap volt fontos.

Az üzleti tervezés során is bevezetésre került a „sprint”. Létezett ugyan stratégia és üzleti terv, de éves tervezés helyett inkább áthelyeztük a hangsúlyt a havi tervezésre. 1 hónapra előre már elég jól lehet látni a feladatokat, ezért ez sokkal stabilabb tervezést tett lehetővé, ugyanakkor tudtunk reagálni a „hirtelen beeső” fejlesztési feladatokra is. Ezzel megszűnt az a jelenség, hogy egy új projekttel csak 1-2 év múlva tudunk foglalkozni a költségtervezés éves volta miatt – és ezért az üzlet akadálynak tekinti az IT-t.

A munkaszervezés úgy változott, hogy „mindenki mindennel foglalkozik” helyett az emberek egy-egy feladatra vagy szerepkörre specializálódtak. Ez azt jelentette, hogy 1 ügyfél igénynek 1 és pontosan 1 gazdája volt, és ez nem is változott. Ezért a fejlesztő közvetlenül párban tudott dolgozni a felhasználóval, akitől az igény érkezett. A párok együtt dolgoztak és sokat kommunikáltak.

Amit nem sikerült megváltoztatni: az agilisabb munka azt követelte volna meg, hogy a pénzügyi keretet story point-okban fogyasszuk el. Azonban egy multinál ilyenre nincs lehetőség. A pénzügyi keretet 1 évre előre kell tervezni, és ennek megváltoztatását senki, semmilyen szinten nem támogatta.

+1) Béta csapat „normalizálása”

Mint említettem, Alfa és Béta között volt némi konfliktus. Ugyanakkor jól látszott, hogy a két csapatnak szüksége van egymásra. Alfa a backend-et fejlesztette, ezért szükségszerű volt a minőség és stabilitás-centrikusság. Béta a frontend fejlesztéssel viszont egy csomó apró igényt gyorsan egy egyszerűen meg tudott oldani. Tehát az volt a normális, hogy a két csapat kiegészíti egymást: Béta agilitása gyors fejlesztés eredményezett, miközben Alfa biztosította azt, hogy legrosszabb esetben is az adatok és az adat-integráció megmarad.

Az volt a lényeg, hogy Béta megmaradjon agilisnak és kielégítse a sok apró igényt, Alfa pedig csakis a nagyobb és komolyabb fejlesztésekkel foglalkozzon.

Ugyanakkor azt is látni kellett, hogy Béta nem lehet a végletességig agilis – mint ahogy Alfa sem lehet a végletességig folyamat-alapú. Annak ellenére, hogy a felhasználók szemében Béta csapat volt a „sztár”, ugyanakkor rengeteg frontend hiba létezett. Számos frontend leállás volt. Amikor ez bekövetkezett, akkor Béta vezetőjéről bizony leszedték a keresztvizet.

Tehát nekik kissé lassítani kellett, és az „azt csináljuk amit mondanak” helyett a minőségre helyezni a hangsúlyt. Segítettem nekik kidolgozni néhány alapvető de hasznos folyamatot, amivel elkerülhetik a tipikus hibákat. És segítettem ezeket a változtatásokat elmagyarázni a döntéshozóknak. (A nagyobb rendszerleállásokat követő időszakban voltak fogékonyak az ilyesmire)

Összességében az látszik, hogy nem minden fekete és fehér, hanem el kell találni a kettő között a megfelelő árnyalatot.