IT Business Online

A közigazgatási szoftverfejlesztések nem éppen hatékonyságukról híresek. Tapasztalta ezt Both András is, amikor két és fél évvel ezelőtt projektvezetőként csatlakozott a Lechner Tudásközpont informatikai szervezetéhez. „Nem volt igazi módszeresség a munkában. Elkülönültek ugyan a szerepkörök, kiadták és elvégezték a feladatokat, de az egész ad hoc jelleggel működött. A projektek állását nem lehetett jól felbecsülni, mert azt senki nem tudta megmondani, mit jelent, hogy 62 százalékos a készültség. A megrendelői visszajelzések hiányában pedig túl sokszor fordult elő, hogy senki sem olyannak képzelte el a terméket, amilyen formában végül megszületett. Természetesen készültek jó szoftverek, de a kérdés igazából úgy merült fel, hogy ugyanennyi idő alatt és ráfordítás mellett nem lehetne-e olyan termékeket előállítani, amellyel elégedettebbek a felhasználók” – vázolja a kiindulási helyzetet az azóta infokommunikációs igazgatóvá kinevezett Both András.

Veszteség nélkül

Amikor az e-közmű rendszer fejlesztéséhez az előrelépés útját keresték, nem volt kérdés, hogy az agilis módszertanok között érdemes keresgélni. A módszernek komoly szakirodalma van és külföldön szép számmal lehet találni példákat is, úgymint az amerikai U.S. Digital Service Agency, amely többek között közigazgatási agilitással foglalkozik. A módszer már annyira elterjedt, hogy több nemzetközi konferenciát is rendeznek a közigazgatási agilitástémában. Magyarországon ugyanakkor csak maroknyi szervezet alkalmazza az agilis módszertanokat (noha jóval többen vannak, amelyek ezt állítják magukról), a hazai közigazgatásban viszont még nyoma sincs a módszer alkalmazásának.

Both András a lean szemléletet szerette volna meghonosítani a Lechner szoftverfejlesztéseiben is. „A lean a veszteség elkerülésének művészete, legyen szó gyártásról vagy szoftverfejlesztésről. A gyártásnál a selejt jelenti a veszteséget, nálunk pedig például az, hogy minden munkafázisról hosszú, részletes dokumentáció készült (ezer oldalas rendszerterv, feljegyzés halmok stb.), amit aztán senki nem olvasott el. De ami még rosszabb, ezek egyáltalán nem segítették a kívánt végeredményt, vagyis a jó szoftver megvalósítását. Ugyanígy feleslegesek voltak a sokszereplős, napirend nélküli, döntések és akciópontok nélkül befejezett értekezletek is” – részletezi a szakember.

Both András, Lechner Tudásközpont  

Szoros együttműködésben

A különféle agilis módszertanok közül ők a scrumot választották, nem utolsósorban azért, mert ez illeszkedett a legjobban az építésügyi informatikai fejlesztésekhez. A scrum csapatban gondolkodik, és a szabályok mindegyike valahol arra irányul, hogy a csapat tagjai között minél jobb legyen a kommunikáció, az együttműködés képessége. Ennek egyik látványos eleme az úgynevezett „daily stand-up” – egy nagyjából negyedórás, napindító értekezlet. Mindenki áll (így lesz rövidebb a megbeszélés), a csapat tagjai pedig egymás után elmondják, hogy előző nap mit tettek a közös cél elérése érdekében, aznap mit fognak tenni, és milyen problémákkal szembesültek.

Ugyancsak az együttműködést szolgálja, hogy a csapat tagjai fizikailag is egymás mellett dolgoznak. A térbeli közelség miatt könnyen léphetnek egymással személyes kapcsolatba, mindenki tudja, hol tart éppen a folyamat, hol van esetleg hiba – összességében sokkal kisebb a lehetőség az információk torzulására és a késlekedésre.

Szintén csapatban történik az előzetes tervezés. A megrendelők és a teljes fejlesztőcsapat leül, és pár nap alatt átbeszélik, mi a célja és mi nem a célja a fejlesztésnek, milyen funkciók kellenek a rendszerbe, kik lesznek a tipikus felhasználók, milyen felületet képzeltek el és így tovább. Emellett viszont a scrum fontos eleme, hogy a tervezés az egész megvalósítás alatt folyamatos. A fejlesztés a Lechner esetében kéthetes ciklusokban (úgynevezett sprintekben) történik. Minden sprint végére értékelhető, működő, a megrendelő számára bemutatható eredménynek kell születnie, amelyről a csapat azonnal visszajelzést kap – tehát szükség esetén módosítani is gyorsan lehet.

Végül fontos jellemzője a scrum módszertannak a szerepkörök határozott elkülönítése. A csapat vezetője a product owner, aki nem feltétlenül informatikus, hanem a megrendelői, felhasználói oldal képviselője. A product owner feladata a cél szem előtt tartása, jelszava a „do the right thing”. A csapat tagjai – akik között egyaránt ott vannak a rendszertervezők, a fejlesztők, a tesztelők és a dizájnerek – felelnek azért, hogy a munkát jól csinálják. Végül a harmadik szerepkör az úgynevezett scrum master, akinek a „do it faster” a felelőssége. Az ő feladata, hogy a csapat tagjai minden segítséget megkapjanak a munkájukhoz, szükség esetén közvetít a csapat tagjai között, konfliktushelyzeteket old fel – éppen ezért nem árt, ha van jó adag pszichológusi vénája is.

Rögös úton

A Lechner Tudásközpontban nem akartak nagyot markolni, ezért csak egyetlen, jelenleg az e-közművet fejlesztő csapatra vezették be a scrum szerinti működést. Külső tanácsadó segítségét is igénybe vették a tranzícióhoz, ezt mindenképpen hatékonyabbnak érezték, mintha a leendő csapattagokat elküldték volna egy gyorstalpaló tanfolyamra.

Kezdetben meglehetősen komoly belső ellenállást kellett legyőzni, ismeri el Both András. Kezdődött azzal, hogy a tipikusan magányos farkasként dolgozó fejlesztőket kirángatták a saját kis zugaikból és összeültették másokkal, akik talán más szervezeti egységhez is tartoztak a cégen belül. Nehezen indult be a kommunikáció is. Nem értették a csapattagok, miért kell annyit találkozni, miért kell mindig elmondani, mit és hogyan csináltak, milyen gondjaik vannak. Zavarónak hatott a transzparencia is, vagyis hogy minden nap be kell számolni az előrehaladásról – nincs olyan, hogy valaki a két hétre kiadott feladatot az utolsó két napon csinálja meg (nyilvánvalóan nem működik, mert mi van a csapat többi tagjával, akik szintén ugyanazon a terméken dolgoznak). Nem volt világos számukra a scrum master feladata sem, aki szemmel láthatóan nem dolgozott (hiszen nem írt kódot) – de akkor mit keres a csapatban?

Más jellegű problémákkal szembesültek a vezetőség, a belső megrendelői oldal részéről. Nekik is el kellett sajátítaniuk a módszertan alapjait, mert tőlük is másféle hozzáállást igényelt a scrum. Az elkészített funkciólistából már nem a megrendelő, hanem a csapat becsüli meg, mennyit bír el, persze először azt fejleszti, ami a legkevesebb „fájdalommal” jár és a legnagyobb üzleti értékkel kecsegtet.

„Meg kellett értetni a menedzsmenttel, hogy mostantól nem a sürgős feladatok kapnak prioritást, hanem a fontosak. Abban is más lett a működés, hogy nem adhatnak a csapatnak másik feladatot, amíg meg nem csinálták az előzőt. Nem engedjük, hogy szétforgácsolják az erőket a különféle projektek között, mert szétesik a rendszer” – mutat rá egy fontos aspektusra a szakember.

Minden jó, ha jó a vége

Both András a kezdeti nehézségek és a termelékenység átmeneti visszaesése ellenére teljes sikernek értékeli a scrum módszertan bevezetését. Nem is azt tartja a legnagyobb eredménynek, hogy fél év alatt sikerült megvalósítani egy komoly, országosan több száz szolgáltató által használt, számos belső közigazgatási kapcsolódással rendelkező rendszert. (Bár mint mondja, önmagában már az is eredmény, ha egy szoftver határidőre elkészül.)

Sokkal fontosabbnak érzi, hogy a csapat tagjai elégedetten végzik a munkájukat és szívesen dolgoznak a scrum módszertan szerint. „Amennyire berzenkedtek az elején, most már mindenki azt mondja, a világ legjobb dolga, hogy összeültettük őket, és együtt dolgoznak. A munkakapcsolatból emberi kapcsolatok lettek, az emberek már ebédelni is együtt járnak. Az egyik fő cél amúgy is az volt, hogy a kollégák jobban érezzék magukat a munkájukban, mert az elégedett dolgozó minőségi munkát végez” – emel ki egy fontos szempontot az infokommunikációs igazgató.

A közös munka a hatékonyságot is növelte. Nincsen olyan pont, ahol megcsúszhat a projekt, mert mindenki tud mindenről, és segíteni is képes, ha szükséges. Minden pillanatban van működőképes szoftververzió, a megrendelői visszajelzés pedig folyamatos, így a végeredmény is az lesz, amit a leendő felhasználók elképzeltek.

A bevezetés legnagyobb dicséretének mégis azt tartja Both András, hogy a scrumot a szervezet más részeiben is alkalmazni akarják. Az informatikán belül egy másik csapat – látva az eredményeket – magától kezdte el használni a módszertan elemeit. „Még nem végeztek a tranzícióval, de már az is sokat számít, hogy csapatban dolgoznak és nem kell párhuzamosan tíz különféle feladattal foglalkozniuk.”

A tervek szerint a Lechner Tudásközpont informatikai szervezetében hamarosan minden munkatárs csapatban fog dolgozni, és minden projektnek meglesznek a maguk agilis módszertan szerint előírt szereplői, ahol ez indokolt.