Egy üzletileg kritikus rendszer modernizációjára könnyű csak technológiai projektként gondolni. Új architektúra, új komponensek, migráció, teljesítmény, stabilitás. Mi is így indultunk neki. Aztán menet közben kiderült, hogy a legnehezebb kérdéseink jelentős része mégsem csak technológiáról szól, hanem valami egészen másról. Arról, hogy képes-e egy szervezet és egy csapat éveken át együtt változni és fejlődni azzal a rendszerrel, amelyet maga hozott létre.
Berlinben az Agile meets Architecture-konferencián a Racing with Two Engines: Navigating Trade-offs in a Large-Scale Legacy Transformation című előadásomban erről beszéltem.
Történetünk főszereplője Magyarország legnagyobb energiaszolgáltatójának online ügyfélszolgálati rendszere, amelyet 2020 óta fejlesztünk a Webstarnál a 4Sales Systems-szel együttműködésben.
Sok millió aktív felhasználó és közel négymillió felhasználási hely kapcsolódik hozzá,
olyan platformról beszélünk tehát, amely az ország teljes lakosságát érinti, és amely mögött valódi, mindennapi, akár kritikus élethelyzetek is vannak.
Egy ilyen rendszer modernizációjánál van egy nagyon egyszerű probléma: nem állítható le, amíg átépítjük.
Nekem erről egy idő után egy hasonlat jutott eszembe. Olyan, mintha az autópályán haladó autóban menet közben kellene motort cserélni:
- az autó nem állhat meg,
- az utasokat el kell juttatni oda, ahová tartanak és
- lehetőleg semmit se vegyenek észre abból, hogy közben mi történik a motorháztető alatt.
Miközben az egyik csapat azon dolgozik, hogy az autó biztonságosan haladjon tovább, mások már az új motort építik be.
Technológiailag ez önmagában is izgalmas feladat. Nekem mégsem ez lett a projekt legfontosabb tanulsága.
Technológia és egyéb megoldások
Egy elavult, ún. legacy-rendszer modernizációjakor hosszú listánk van azokról a technológiai kérdésekről, amelyekre választ kell találnunk. Például:
- Melyik modult bontsunk szét és milyen sorrendben?
- Hol húzzuk meg az új komponensek határait?
- Milyen kompromisszum fér bele átmenetileg?
- Hogyan biztosítsuk, hogy a régi és az új világ együtt is stabilan működjön?
Ezek nehéz kérdések, de van egy nagy előnyük: mérnöki módszerekkel vizsgálhatók. Modellezhetünk, mérhetünk, tesztelhetünk, kipróbálhatunk alternatívákat. Ha valami kezdetben nem működik, előbb-utóbb adatunk lesz róla, és megoldjuk.
Az embereknél és a szervezeteknél ennél jóval bonyolultabb a helyzet.
Egy technológiai modernizáció során ugyanis nemcsak azt kell eldöntenünk, milyen legyen az új rendszer, hanem arra is választ kell adnunk, hogyan tud majd a projekten dolgozó több közepes méretű csapat másképpen működni úgy, hogy közben a napi szállítás folyamatossága is megmarad.
Egy ponton aztán kezdett átalakulni bennem az egész projektről alkotott kép. Rájöttem, hogy a modernizáció sebességét nem feltétlenül az határozza meg, milyen gyorsan tudjuk új technológiai alapokra helyezni a rendszert, hanem az, hogy
mekkora változást képes a csapat megbízhatóan és sikeresen kezelni.
Egy új architektúrához új működés is kell
Ahogy nőtt a rendszer és a projekt komplexitása, azt vettük észre, hogy a korábbi működésünk a mindennapokban egyre kevésbé volt hatékony. Nem azért, mert rosszul dolgoztunk, hanem azért, mert a projektcsapatot eredetileg sokkal kisebb probléma megoldására terveztük.
Ez pedig fontos különbség.
A projekt növekedésével olyan kérdések jelentek meg, amelyeket már nem lehetett egy-egy szakmai terület határain belül megoldani. Több lett a függőség, nagyobb lett egyes döntések hatása, egyre fontosabbá vált, hogy világosan lássuk, ki miért felel, és melyik döntést milyen szinten kell meghozni.
Ezért a portfólió-architecttel fokozatosan új működési modellt kezdtünk kiépíteni. Létrehoztuk például a domain expert-szerepkört, tisztáztuk a felelősségi határokat, RACI-alapú működést vezettünk be és rendszeres közös fórumokat alakítottunk ki. Később külön release manager-szerepre is szükség lett, mert az egyre komplexebb szállítás koordinációja már önálló felelősséget kívánt.
Nem a kontroll mértékén akartunk változtatni, hanem azon, hogy hol és milyen formában van rá valóban szükségünk.
Rá kellett jönnöm, hogy nagy komplexitás esetén nem az a jó vezetés, amikor minél több döntés fut össze nálam – éppen ellenkezőleg.
A cél az, hogy az emberek, a csapat tagjai pontosan értsék a saját felelősségüket, legyen elegendő információjuk a döntéshez, és azon a területen valódi mozgásteret kapjanak. A vezetőnek pedig ott kell belépnie, ahol a probléma már túlnő egyetlen csapat vagy projekt látóterén.
A rendszer mellett a bizalmat is folyamatosan üzemeltetni kell
A modernizáció első szakaszában elsősorban technológiai kihívásként tekintettem arra, amit csinálunk, ma azonban már másképp fogalmaznék. Egy többéves transzformáció legalább annyira bizalmi projekt, mint technológiai. Az üzleti oldalnak bíznia kell abban, hogy
- a változás nem veszélyezteti azt, ami ma működik,
- az üzemeltetésnek abban, hogy az új rendszer valóban stabil lesz,
- a fejlesztőknek abban, hogy azok az architekturális döntések, amelyek ma esetleg plusz munkát jelentenek, később valóban jobb rendszert eredményeznek,
- a vezetőknek pedig abban, hogy érdemes erőforrást fektetni valamibe, amelynek teljes üzleti értéke esetleg csak évek múlva válik láthatóvá.
Mindez ráadásul nem egyszeri megállapodás.
Egy hosszú projekt közben emberek jönnek-mennek, változnak az üzleti prioritások, új problémák jelennek meg. Ami fél éve mindenkinek egyértelmű volt, azt ma lehet, hogy újra el kell magyarázni. Portfólióvezetőként ezért egyre inkább azt éreztem, hogy
az egyik legfontosabb feladatom a fordítás.
A technikai kockázatot le kell fordítanom üzleti következményre, az üzleti célt végrehajtható szakmai prioritásra, egy csapat problémáját pedig úgy kell megmutatnom a többieknek, hogy értsék, az hogyan hat az egész rendszerre. Nem ugyanazt az információt kell mindenkinek elmondanom, de ugyanazt az összefüggést kell mindenki számára láthatóvá tennem. Ezt a folyamatot Pálfiné Heizer Ritával, a portfólió architectjével közösen vittük végig. Rita szerepe megkerülhetetlen volt abban, hogy a sok különálló technológiai döntésből egy koherens, hosszú távon is működő rendszer álljon össze, én pedig azon dolgoztam, hogy ennek az üzleti logikája és következményei minden érintett számára világosak legyenek.
Egy örökölt rendszer, amit nem lehet kódból kiolvasni
A projekt egyik legérdekesebb felismerése számomra mégsem a szervezeti struktúrához kapcsolódott, hanem a szervezeti tudáshoz. Amikor elavult, legacy-rendszerekről beszélünk, akkor általában régi technológiára, technikai adósságra vagy nehezen karbantartható kódra gondolunk. (A technical debt managementről itt írtunk részletesebben a IX. Országos Megmérettetés kapcsán.)
Pedig a legacy egy része nem is a kódban van, hanem emberekben.
Egy évek óta működő nagyvállalati rendszer tele van olyan döntésekkel, megállapodásokkal és kivételekkel, amelyeknek történetük van. Valaki tudja, miért pont úgy működik egy folyamat, valaki emlékszik arra, milyen üzleti helyzet miatt született egy furcsának tűnő szabály, valaki pontosan érti azt a függőséget, amelyet a dokumentációból soha nem lehetne teljesen rekonstruálni.
Ezek az emberek tulajdonképpen a rendszer élő dokumentációi.
Ezért volt számunkra fontos a domain expert-szerepkör kialakítása is. Egy nagy modernizációban ugyanis nem egyszerűen technológiát migrálunk, hanem tudást, történetet és szervezeti emlékezetet is. Ha az egyik átkerül az új világba, az új rendszerbe, a másik viszont nem, akkor csak félig végeztük el a munkát.
Amiről nem beszélünk eleget
Van még valami, amiről technológiai konferenciákon szerintem túl keveset beszélünk: az el- és kifáradásra gondolok.
Egy néhány hónapos projektet sokáig visz előre a lendület, egy többéves transzformációt azonban már nem. Az utóbbi esetben nem elég azt mondani a csapatnak, hogy „ez stratégiailag fontos”. A csapattagoknak időről időre látniuk kell, hol tartunk, miért csináljuk, amit csinálunk, és hogyan kapcsolódik az ő munkájuk az egészhez.
Ezért nálunk a technológiai működés mellett fokozatosan kialakult egy másik rendszer is: rendszeres check-inekkel, wellbeing-beszélgetésekkel, vezetői mentorálással, anonim projekthangulat-méréssel és portfóliószintű fórumokkal próbáltuk, próbáltam láthatóvá tenni, mi történik nemcsak a rendszerben, hanem a csapatban is. Nem azért, mert ettől minden nehézség eltűnik, hanem azért, mert amit nem látunk, azon változtatni sem tudunk.
Kontroll?
Ennyi tapasztalat után ezt a kérdést ma már egészen másképp válaszolom meg, mint néhány évvel ezelőtt. Régebben a kontrollt könnyebb volt a tervhez kötnöm: van egy roadmap, vannak mérföldkövek, meghatározzuk az utat, aztán végigmegyünk rajta. Egy nagy, hosszú ideig tartó és folyamatosan változó projektben ez illúzió.
A terv biztosan változni fog.
Változik az üzleti környezet, a technológia, a prioritások. Olyan dolgokat tanulunk meg a rendszerünkről, amelyeket a projekt elején még nem tudhattunk.
Számomra ma a kontroll ezért nem azt jelenti, hogy változatlanul végigviszem az eredeti tervet, hanem azt, hogy gyorsan láthatóvá tudom tenni egy változás következményeit, alternatívákat tudok adni a döntéshez, majd az egész rendszer érdekeit nézve újra tudjuk tervezni a következő lépést.
Talán az volt a berlini beszélgetések legérdekesebb része, hogy egészen más iparágakból érkező emberek mennyire hasonló kérdésekkel küzdöttek. Csak néhány példa:
- Hogyan maradjunk stabilak úgy, hogy közben gyorsan kell változnunk?
- Hogyan építsük a következő rendszert anélkül, hogy veszélyeztetnénk a jelenlegit?
- Hogyan tartsunk egy irányban egy szervezetet éveken keresztül?
Ezekre nincs egyetlen architekturális minta vagy projektmenedzsment-módszertan, amit egyszerűen elő lehet venni a fiókból. Nekem legalábbis más lett a válaszom, mint amikor elkezdtük a rendszer modernizációját.
Jobban vezetünk
Egy nagy technológiai transzformáció végén nemcsak egy új rendszernek kell létrejönnie, hanem a csapatnak, a szervezetnek is képesebbé kell válnia arra, hogy együtt éljen a változással.
Ha ez nem történik meg, akkor csak motort cseréltünk.
Ha viszont igen, akkor már nemcsak az autónk lett jobb, de mi is megtanultunk jobban vezetni.
Van, hogy egy új nézőpont visz közelebb a megoldáshoz
Mire számíthatsz?
Add meg néhány adatodat, és máris küldjük szakértői tartalmunkat!
SIKERES FELIRATKOZÁS ÉS LETÖLTÉS!
Hamarosan érkezik a megadott e-mail-címre szakértői dokumentumunk.
