A roadmap tele van új fejlesztéssel, a hónap végén mégis azt látod, hogy a csapat idejének jó része tűzoltással ment el. Jött egy éles hiba, egy sürgős megfelelési kérés, egy „ezt csak Sanyi tudja” helyzet, és az új funkciók megint csúsztak. Ez nem egy rossz hónap volt, hanem a legtöbb örökölt rendszernél visszatérő minta, aminek jól leírható oka van.
Honnan jön az állandó tűzoltás?
Minden változtatás előtt először meg kell érteni, mihez nyúlunk. Egy átlátható rendszernél ez gyors; egy tizenkét éves, dokumentálatlan core-nál viszont a fejlesztési idő jelentős része erre megy el. A csapat nem lassú, csak minden lépésnél kézzel deríti ki, mi mit érint. Mi ezt „megértési adónak” hívjuk: rejtett költség, amit minden feladatnál újra kifizetünk, és ami miatt az új funkciókra alig marad keret. (A fejlesztői idő árán számolva ez évi több tízmillió forintos tétel is lehet, csak épp egyetlen riportban sem jelenik meg külön sorként.)
Három lépés, hogy mégis felgyorsulj
A kiút nem egy nagy rendszercsere, hanem egy sorrend, amit körülhatárolt területen is el lehet kezdeni.
- Teljes, felokosított dokumentáció a kódból. Először a kódbázisból építünk élő, kereshető tudásréteget, ahol minden állítás visszavezethető a forrásra. Ezzel megszűnik a kézi nyomozás minden feladat előtt, és a „mi mást érint” kérdésre azonnal, ellenőrizhetően érkezik a válasz.
- A nem használt részek levágása. A rálátás birtokában kiderül, mi a ténylegesen futó kód és mi a holt teher, amit évek óta csak cipelünk. Amit nem használ senki, azt biztonsággal el lehet távolítani, így kevesebb a karbantartandó és a félnivaló felület.
- Részleges vagy teljes újraírás, a dokumentáció fényében, AI-val. Csak ezután, már a megértés birtokában érdemes modernizálni. Az AI itt sokat gyorsít, de minden lépése a forráskódra hivatkozik, így az eredmény ellenőrizhető marad (arról, hogy miért nem bízható a teljes újraírás vakon az LLM-re, külön is írtunk).
A sorrend a lényeg. Aki a harmadik lépéssel kezd, az vakon írja újra a rendszert, és jó eséllyel pont oda jut vissza, ahonnan indult: egy olyan rendszerhez, amit megint csak néhányan értenek.
Mit nyersz vele
Ahogy csökken a megértési adó, a csapat ideje átbillen a tűzoltásról a tényleges fejlesztésre. Az átfutások rövidülnek, a kockázatos változtatások kiszámíthatóbbá válnak, az új kollégák pedig gyorsabban produktívak, hiszen nem egy-két ember fejéből kell kibányászniuk a tudást (így a kulcsemberi függőség is oldódik). A leglátványosabb a hatáselemzésnél: egy közép-európai lakossági banki core-nál a „mi mást érint ez” kérdés hetekről egy-két órára rövidült, ellenőrizhetően. Ezt a board is érzékeli: a roadmap végre tartható, és a negyedéves beszámolóban nem a csúszásokat kell magyarázni.
Hol érdemes kezdeni
Ha a fenti minta ismerős, és nálatok is a tűzoltás viszi az időt, az első lépésnek nem kell projektnek lennie. Összeraktunk egy rövid önértékelőt: hat dimenzió mentén, kizárólag a saját válaszaidból rajzol board elé vihető kockázati képet, akár adatmegadás nélkül. Mérd fel, hol áll most a rendszered (kb. 5 perc). Azt pedig, hogy maga a megközelítés hogyan működik, a Nitro Legacy Explorer oldalán nézheted meg.
Az érdemi első lépés ezután egy kisebb, jól körülhatárolt modul: egy ilyen szeleten megnézhetjük, mennyi nálatok a rejtett megértési adó, és hol nyerhető vissza a legtöbb idő, mielőtt bármilyen nagyobb döntés születne. Ha szeretnéd, egy rövid beszélgetésen közösen kiválasztjuk, melyik modul lenne erre a legalkalmasabb.
