2018. augusztus 1., szerda

Pengeélen

Nemrég egy igen komoly rendszerfejlesztés/átalakítás első fázisát fejeztük be. Komoly volt az alábbi értelemben:

  • Egy, már öt éve működő (és ezen időszak alatt is folyamatosan bővülő, finomodó) rendszer került szinte teljesen új alapokra, de NEM újraírásra
  • Az öt év tapasztalataiból nagyon sok mindent felhasználtunk és a legfontosabb struktúrális és elvi problémákat sikerült is kezelnünk
  • A rendszer teljes mértékben támogatja a korábbi folyamatokat, ugyanakkor teljesen új folyamatokat és irányvonalat is alkalmaz (pl. elektronikus dokumentumkezelés, érintőképernyős aláírások kezelése, teljes tablet- és mobiltámogatás, ami még nem volt a rendszerben a 2012-es indulásakor)
  • A számos új lehetőség és folyamat miatt az adatmodell (táblák és mezők) száma kb. 40%-kal, a kódbázis pedig kb. 50%-kal nőtt (így lett kb. 440e sornyi saját kód a rendszer aktuális állapotában), ugyanakkor a teljesítmény nem csökkent, sőt több helyen nőtt (a struktúrális átalakítások következtében)
Minden naptári időben kb. 15 hónapot vett igénybe, 5-6 kollégával. Az eddigi pályafutásom talán legkomplexebb feladata volt. Szerencsére sikerrel vettük az akadályt, gyakorlatilag határidőre és egészen jó minőségben sikerült leszállítani a rendszert.

Maga a projekt ütemezési/belső technikai része is érdekes volt: pl. milyen metodikával tudtuk elérni, hogy "nem törtük szanaszét" a rendszert a teljes átalakítás során, erről később írok.

Ami a projekt kapcsán leginkább megmaradt bennem, az, hogy mennyire sokféle területen van szükség "egyensúlyozásra" annak érdekében, hogy a projekt sikeres legyen, és sokszor mennyire nehéz ezen egyensúlyozás végrehajtása. Gyakorlatilag több dimenzióban is folyamatosan "pengeélen" táncol az ember, és bármelyik irányba lép nagyot, abból tuti zakózás lesz.

Ebben a fejlesztésben - mai divatos szavakat használva - voltam business analyst, architect, product owner, tesztelő és ügyfélszolgálatos is (utóbbiak leginkább a kollégák tehermentesítése céljából, hogy legyen idejük és lehetőségük az elmélyült és alapos munkára, legalábbis annyira, amennyire az ütemezés és a feladatok komplexitása ezt lehetővé tette).

Mindegyik szerepkörben voltak nagyon érdekes kérdések, amelyek felmerültek, és nagyon nem volt egyértelmű, hogy mit kezdjen vele az ember. Ennek oka elsősorban a "tipikus nagyvállalati szoftverfejlesztés" háttere volt:
  • A megrendelő részéről nem volt egy dedikált projektfelelős, aki kézben tartotta és priorizálta volna a feladatokat, hanem több üzleti területnek voltak delegált tagjai, akiknek - az egyébként is túlzsúfolt és adminisztrációval telített - napi operatív feladataik mellett kellett (volna), hogy a rendszerrel kapcsolatos elvárásaikat meghatározzák, és olyan szinten dokumentálják, ami alapján már értelmezhető a feladat. Látszott, hogy igyekeznek megfelelni a feladatnak, de erős hátrányból indultak már eleve ezen körülmények miatt.
  • Több üzleti területtől voltak olyan delegált tagok, akik gyakorlatilag nem is ismerték a rendszer aktuális változatát, mivel az még az ő tevékenységüket nem támogatta, de az átalakítás és bővítés után már nekik is ebben a rendszerben kell dolgozniuk. Ez egyrészt kihívás volt (teljesen más fogalomrendszer használata, számunkra sokszor ismeretlen üzleti folyamatok), másrészt jó volt abban az értelemben, hogy kiderült, hogy a támogatott üzleti folyamatok sem úgy vannak teljesen a valóságban, ahogy az a rendszerben működik (mertháthogy nem nagy az eltérés, és erre az adaptációra, amikor a folyamatunk megváltozott, nem akartunk pénzt költeni).
  • Láthatóan mindenkinek a célja a saját elvárásainak kielégítése volt, és nem igazán voltak olyan megrendelői egyeztetések, ahol az egyes üzleti területek egymással tisztázták volna a prioritásokat. Így időnként
  • A napi munka melletti tevékenységnek és a korábbi rendszer "nem ismeretének" volt egy olyan mellékhatása is, amitől egyes megbeszéléseknél egyértelműen az 50 első randi című film jutott eszembe. Voltak olyan folyamatok, amelyeket a tervezési fázisban négyszer, a fejlesztési fázisban szintén négyszer alakítottunk ki/át teljesen, majd a tesztelési fázisban is sikerült alaposan felforgatni egyes területeket. És nem azért, mert az üzleti folyamat változott, hanem azért, mert igazából nincs definiált üzleti folyamat, hanem a szereplők nagyjából így és így dolgoznak, de igazából minden nap egy kicsit másképp. Hiába volt bármi leírva, ha a napi munka mellett nincs idő elolvasni, így, ha egy kérdés újra felmerült, már más volt a válasz, mint korábban (akár egy héttel azelőtt).
  • Mindezek mellett ugyanakkor a teljes projekt egy, a projekt elején készített specifikáció alapján fix határidős, fix költségvetésű projektként ment. Ezért egy idő után a közös érdek mellett (ti. hogy legyen egy jól használható, hatékonyan működő rendszer, ami az üzleti elvárásokat megvalósítja és a felhasználók is szeretik használni a célszerűsége miatt) megjelentek a saját érdekek is (beszállítói oldalon értelemszerűen, hogy ne nyújtsuk túl a projektet, megrendelői oldalon pedig a "ezért a projektért sokat fizetünk, így ez még bele kellene, hogy férjen" merült fel teljesen természetes emberi hozzáállásként).

A fenti körülmények által létrehozott univerzumban minden szerepkörömben érdekes "pengeéles" szituációk voltak. Ezek közül amelyek a legjobban megmaradtak bennem, az alábbiak voltak:
  • business analyst-ként:
    • Ha már letárgyaltunk és specifikáltunk valamit, majd attól elkezdünk eltérni, mennyire hívjam fel erre a figyelmet és kérdezzek vissza, hogy mi az oka a változásnak? Vagy inkább figyeljem meg, hogy mik azok a területek, amelyek "folyamatosan változnak" és ott specifikáljuk úgy a folyamatokat, hogy rugalmasan kezelhető/módosítható legyen?
    • Mennyire kérdezzem ki a valós üzleti folyamatot, mennyire erőltessem a nem tiszta / nem egyértelmű megfogalmazások letisztázását? Látszólag erre a kérdésre egyszerű a válasz, mert legyen minden egyértelmű, ugyanakkor teljesen más az a szint, ami egy, az adott üzleti területen gyakorlott embernek "egyértelmű", és más az, amikor egy, az adott üzleti területen relatíve kevés tapasztalattal bíró fejlesztő számára "egyértelmű".
      • Ez egyébként két irányban is problémát jelentett. A megrendelővel való kommunikációban én voltam a "gyenge láncszem", nekem voltak hiányos háttérismereteim az üzleti folyamatról. A fejlesztő kollégákkal való kommunikációban viszont fordított volt a helyzet, hozzájuk képest én rengeteget tudtam az üzleti folyamatról, amit ők (joggal) nem tudtak.
    • A különböző üzleti területek keveset egyeztettek egymással, és mivel nem volt üzleti oldalon priorizálási felelős, a beszállítónak (nekünk) kellett ellátni ezt a meglehetősen hálátlan feladatot (hiszen itt valakinek mindig "rossz lesz", ha egymással ellentétes elvárásokból kell kihozni "valami jót"). Ugyanakkor muszáj volt ezt megtenni, másképp könnyen halastóvá válhatott volna a projekt, és az még rosszabb lett volna. Viszont ezt a szerepet sem szabad túltolni, mert akkor nagyon rossz híre lesz a beszállítónak a megrendelőnél ("azok a kötözködősök már megint...").
  • architekt-ként:
    • Hogyan legyen az alap úgy felépítve, hogy az üzleti igények folyamatos változása és átalakulása a legtöbb esetben ne alapjaiban rengesse meg a felépítményt, hanem még beleférjen a koncepcionális modellbe? De ne legyen túltolva ez sem, mert akkor meg sosem lesz konkrét rendszer belőle...
    • Lépjünk előre mindig mind a rendszerfelépítés, mind a felhasznált eszköztár tekintetében (cél, hogy ne váljunk "dinoszaurusszá" azzal, hogy görcsösen a már megismert környezetekhez és lib-ekhez ragaszkodunk), de ugyanakkor ne túl nagy lépésben, mert akkor a projekt helyett eszköztanulással töltjük az összes időt.
    • Fontos az üzleti folyamat támogatása, de (majdnem) ugyanilyen fontos a rendszerben a "transzparencia" (problémafelderítésre, auditálásra és belső ellenőrzési feladatokra is alkalmas log-ok), a biztonság (mindenki csak ahhoz férjen hozzá, amihez kell) és a minél egyszerűbb üzemeltethetőség/frissíthetőség. Ja, és persze a teljesítmény is jó legyen :) Szóval ezen területek között is érdekesen lehet "lavírozni", és nagyon könnyű elcsábulni valamelyik faktor erősítése felé a többiek rovására.
  • product owner-ként (bár itt kicsit többről/másról van szó, egy kicsit projekt menedzserként, egy kicsit vezető fejlesztőként és egy kicsit Scrum master-ként is tevékenykedtem ebben a projektben):
    • Hogyan legyenek a feladatok úgy szétosztva a kollégák között, hogy mindenkinek legyen feladata; ne legyen túlterhelve de ne is tudjon "takubakuzni"; miközben figyeljünk az egyes személyek kompetenciájára, aktuális tapasztalatára, erősségeire is, építsünk rá, de engedjük továbbfejlődni/kiteljesedni is - de persze nem a feladatvégzés kárára. És persze, nem utolsósorban, a prioritásoknak és a felépítésnek megfelelő sorrendben végezzük a feladatokat.
    • Ha valamit úgy lát az ember, hogy "nem megfelelő", az kivel milyen módon, formában, lehetőleg előremutatóan legyen kommunikálva.
Szóval, érdekes volt. Sokat tanultam magamról is, meg a világról is, és sikerült továbbfejlődni kommunikáció terén is (bár, néha nem vagyok biztos abban, hogy a továbbfejlődés a megfelelő szó... :) ). De az biztos, hogy ez a projekt is megmutatta, hogy a szoftverfejlesztés egy bizonyos szint felett (amikor komplex feladatokat kell több embernek sok hónapon keresztül megfelelően elvégeznie, folyamatosan változó követelmények mellett) meglehetősen embert próbáló feladat. 
Le a kalappal azok előtt, akik a következő komplexitási szinten (több millió soros projektek, több tucat szereplővel, több éves átfutás alatt) képesek irányítói szerepkörben megfelelően teljesíteni.