Tavaly ősszel a balatonfüredi INFOTÉR konferencia egy panelbeszélgetés az informatika és az értékteremtés kapcsolatát boncolgatta. Ezen a beszélgetésen Both András, a Lechner Tudásközpont infokommunikációs igazgatója, egy érdekes, a közigazgatástól látszólag távoli módszertanról mesélt, amivel rugalmasabbá és hatékonyabbá tudták tenni milliárdos nagyságrendű projektek lebonyolítását is. Kifaggattuk a módszertanról.

Bitport: Nem mindenki ismeri a Lechner Tudásközpontot. Mi a központ feladata?

Both András: Viccesen azt szoktam mondani, hogy amolyan "ország–város–ház" játékot játszunk. De komolyra fordítva a szót, a Lechner Tudásközpont foglalkozik területrendezési és -fejlesztési, településrendezési és -fejlesztési feladatokkal, valamint az ezeken található építményekkel is, házakkal, hidakkal, utakkal de még a vízi erőművekkel is. Mindegyik területen végez szakmai munkát, illetve elektronikus hátteret is biztosít hozzá.

Ezekhez fejleszt alkalmazásokat, amiben az én feladatom az, hogy az elektronizálás egyszerű és érthető legyen, és a szereplők ne egy szükséges rosszként éljék meg. Olyan rendszereket kell készítenünk, amiket a legkülönbözőbb szintről érkező felhasználók egyaránt tudnak használni. Például egy kőműves nálunk vezeti az elektronikus építési naplót, amibe a műszaki ellenőr is beleír, utána ellenőrzi egy hatóság, a hatóságot pedig a Miniszterelnökség... És ezeknek a felhasználóknak mind mások az igényei.

Bitport: A fejlesztések lebonyolítására dolgoztak ki egy módszert. Mi ennek a lényege?

B. A.: A közigazgatásban a közbeszerzés szabályai miatt nagyon hosszú a beszerzés folyamata. Megfogalmazódik egy ötlet, például hogy szükség van egy új elektronikus építésügyi alkalmazásra. Első lépésben definiáljuk a magas szintű követelményeket, ám ezek alapvetően feltételezéseken alapulnak, hiszen ebben a szakaszban nem tudunk minden érintettet bevonni. Utána jön a legalább háromnegyed évig tartó közbeszerzési folyamat. És mire minden lezajlott, és beszereztünk valamit, eltelt másfél év. Csak közben már az láthatóvá válik, hogy más irányba kellene menni, mint amit másfél évvel korábban kitaláltunk.

Egy több milliárdos közbeszerzéshez a vállalkozó az első fázis teljesítéseként bead több ezer oldalnyi rendszertervet. Ez olyan mennyiség, ami lényegében kezelhetetlen. Ráadásul ezek a tervek gyakran a végső használók bevonása nélkül készülnek. A rendelkezésre álló erőforrásokkal pedig nehezen megállapítható, hogy jó-e a terv.

Ezt szerettük volna feloldani valahogy, és elérni, hogy a vállalkozó és a leendő használó fejében ugyanaz a kép legyen az igényekről és a követelményekről. Ez az üzleti szférában sem egyszerű. A közigazgatásban ráadásul ahhoz szoktak hozzá, hogy az egyes vezetők a saját szempontjaik szerint vizsgálják a projekteket. A főigazgató túl akar lenni rajta, a gazdasági igazgató a mérföldköveket nézi, az informatikai igazgató csak IT-s szempontból vizsgálja a rendszertervet és így tovább. Az meg sehol sem jelenik meg, hogy mint akar a kőműves például, aki végső használó lesz.

Először azt találtuk ki, hogy felbontjuk az óriásprojektet kisebb darabokra, jelen esetben 16 alprojektre, mindegyik élén egy belső projektvezetővel, és ők vezetik a teljes megvalósítási folyamatot is. Hogy az együttműködés zökkenőmentesebb legyen a szállító szintén 16 projektvezetőjével, a dokumentumok küldözgetése helyett közös workshopokat szerveztünk, hogy megrendelő (Lechner), a szállító, valamint a későbbi felhasználó fejében ugyanaz legyen.

Bitport: Hogyan sikerült ennyi embert rávenni az együttműködésre?

B. A.: Valóban az volt a legnagyobb kockázat, hogy meg tudjuk-e győzni a belső szervezeti vezetőket, hogy engedjék el a kollégáikat a workshopokra. Végül választás elé állítottuk őket: vagy elolvasnak és részletesen véleményeznek több ezer oldalt, vagy részt vesznek a workshopon. Ez hatott. Bár utána sem volt mindenki elégedett, azt a célt sikerült elérni, hogy megközelítőleg mindenki ugyanazt gondolja a rendszerről. A módszert egyébként nem mi találtuk ki. Egy külföldi, lean módszertanra épülő követelményelemzési eljárást adaptáltunk.

Jogos lenne a kérdés, hogy mit keres a követelményelemzés a rendszerterv készítésének fázisában, amit már rég le kellett volna tudni. De hadd utaljak vissza beszélgetésünk elejére: az ötlettől eltelt másfél-két év. Az ölet megszületésekor voltaképpen még senki sem látta előre, hogy két év múlva milyen részletes követelmények kellenek egy nagyjából két-háromszáz főt foglalkoztató informatikai fejlesztéshez.

Tehát összeültettük a vállalkozót, a megrendelőt és a későbbi felhasználókat, modulonként 10-20 embert közös termekbe, és adtunk a kezükbe egy olyan módszertant, a „lean inception”-t, amely egyrészt közös tudást alakít ki a projektkövetelményekről, másrészt radikálisan csökkenti a követelményelemzéshez szükséges idő. Bár az elemzés nem teljes körű, de a kulcselemekben konszenzus születik a business analyst, fejlesztők és a rendszer majdani használói, az ügyfelek között, mert ők is ott ülnek minden modulban.

A workshop egyébként azzal kezdődik, hogy egyetlen mondatban meg kell fogalmazni minden termék vízióját, ami nehéz feladat, hiszen az ott ülő húsz ember mind mást gondol róla. Ez a mondat viszont végig nagyon fontos, mert ez lesz a vezérfonal, amely akkor is segít, ha valaki belefeledkezik a részletekbe, és nem az egész projektről próbál beszélni.

Bitport: Említette az ügyfelet. Ő a sokat emlegetett kőműves?

B. A.: Igen, a végfelhasználó. Persze nem feltétlenül egy kőműves, de mindenképpen olyan szakember, aki az ő igényeit is pontosan ismeri. A lényeg, hogy minden modulban képviselve legyen minden érintett szakma legalább egy képviselője. Az ő véleménye persze csak egy a sok közül, de ugyanolyan fontos és segít a sok helytelen feltételezést kihúzni, vagy pontosítani.

Bitport: Az egy mondatos összefoglaló engem kicsit a startup világban ismert ún. "elevator pitch"-re emlékeztet.

B. A.: Igen, gyakorlatilag ugyanarról van szó. Egy kifejező, összefoglaló mondat, amit a projektvezető el tud mondani a vezetőjének, és amivel az ügyfél is egyetért. Fontos, hogy nem ő találta ki, hanem közös gondolkodás eredménye.

Ez a tervezési módszertan egyébként már vagy tíz éve létezik. Kell hozzá egy egyszerű tábla és post-itek. Több változata is van, például az inception deck, de az sokkal több időt vesz igénybe. Vagy van ún. design sprint, ami a felület megtervezésére jó. De mindegyiknek ugyanaz az alapja: üljünk be egy irodába, és közösen találjunk ki valamit, lehetőség szerint olyat, amivel a későbbi használója elégedett lesz.

Bitport: Ez olyannak tűnik, mint az agilis fejlesztés...

B. A.: Van rokonság a kettő között. Az agilis módszertanban a tervezés és a fejlesztés párhuzamosan történik. Ám azt gondolom, hogy a célokat már az elején ki kell tűzni. Nálunk a második nap két nagy kérdéssel foglalkozik: mi az alkalmazás célja, illetve mi nem az? Utóbbi is egy nagyon fontos kérdés, amit még az agilis fejlesztés elkezdése előtt meg kell válaszolni.

Bitport: Úgy tudom, mást is kölcsönöztek a startup világból.

B. A.: Igen, a tervezéshez az MVP-t, azaz a minimum viable product módszert használjuk. Kitaláljuk azt a minimálisan életképes terméket, ami "piacra dobható". Ehhez első körben meghatározzuk a legfontosabb felhasználókat (perszónákat). Például egy építésügyi vezetői információs rendszer legfontosabb felhasználója valószínűleg a helyettes államtitkár alatt dolgozó főosztályvezető, aki az építészeti stratégiáért felel. Ő fogja használni a rendszert, és ő adja a miniszternek azt az anyagot, amiben megnézheti, hogy például Csongrád településen hány egyszerű bejelentés alapján végzett építkezés volt. Az MVP tehát tulajdonképpen azon funkciók összessége, ami a legfontosabb felhasználók legfontosabb céljait teljesíti.

Mindig az aktuálisan legfontosabbal foglalkozunk. Persze vannak más szempontok is, például vizsgáljuk, hogy melyik a legkevésbé költséges, hogy ne a legdrágábbal kezdjük, megpróbáljuk a legkevésbé komplex feladatot lefejleszteni olyan megoldással, ami a legkevésbé költséges.

Bitport: Hogyan vált be a módszer?

B. A.: Megleptük vele a vállalkozókat, mert többségük nem ismerte. De hamar rájöttek, hogy így ők is jobban megértik, min dolgoznak, még saját tervüket is. Az is jó, hogy elég gyorsan át tudunk fordulni a fejlesztésbe, hiszen az MVP-k meg vannak fogalmazva. A sprintek elején a backlogba egyből átemelhető az első MVP tartalma, amit már csak egy kicsit kell cizellálni.

Bitport: Már említette, hogy a módszertant az építésügyi informatikai terület megújításához dolgozták ki. Hol tart most a projekt?

B. A.: Az első mérföldkő március közepén van. Az első három modul nyáron már demózható lesz. A kéthetenkénti demó egyébként unikum a közigazgatásban. Például bemutattuk annak a térképes alkalmazásnak egy korai változatát, ami az összes építésügyi rendszerben egy megjelenítő felületet biztosít majd, és az nagyon sikeres volt. Személy szerint elégedett vagyok a koncepcióval, de a fejlesztési részletek kidolgozása még zajlik, és ebben nagyon sokat segít a folyamatos visszacsatolás.

Bitport: A márciusi mérföldkő már olyan eredmény lesz, amit rögtön használni is lehet?

Both András
CIO, Lechner Tudásközpont

A Budapesti Corvinus Egyetemen szerzett üzleti informatikai diplomát 2014-ben, de már az egyetem mellett vállalt fejlesztői munkákat. Az egyetem elvégzése után egy webfejlesztő céget irányított ügyvezetőként. 2015-ben igazolt a Lechner Tudásközponthoz, ahol egy évig termékfejlesztési igazgatóként dolgozott. 2016 júliusában nevezték ki a Tudásközpont informatikai igazgatójává.

B. A.: Ez a hardverek beérkezésétől is függ, de ha megérkeznek, használatba tudjuk venni az elkészült szoftvereket. Egyébként minden, amit kéthetente hoznak, használható és élesíthető termék. Stratégiai döntés kérdése, hogy mikor élünk a lehetőséggel.

Minden egyes modul tekintetében olyan éles vagy béta indulást tervezünk, ahol egyből kaphatunk felhasználói visszajelzéseket. Például egy elektronikus tervpályázat modult érdemes egy konkrét tervpályázat megindításával kezdeni béta tesztként.

Szeretnénk mindent transzparensen kezelni. Bárhol szívesen beszélünk a terveinkről. Ha esetleg nem sikerülne valami, akkor el szeretnénk mondani, hogy miért nem sikerült, vagy ha csúszás van, annak mi az oka. A piacon is vannak csúszások, ez viszont egyáltalán nem a közigazgatás sajátossága.

Bitport: Egy terméküket én is ismerem, a településképi arculati kézikönyv mintáját. Úgy látom, hogy a települések jól fel tudják használni a saját kézikönyvük elkészítéséhez.

B. A.: Az érthetőségre törekszünk az egész építésügyben. Ez a kézikönyv például sokkal jobban érthető, mint az ezer oldalas szöveges helyi építési szabályzat, amiből nagyon nehéz bármit is kibogarászni. Az épített környezet egységesebb és esztétikusabb megjelenését támogatja a hétköznapi állampolgárnak adott iránymutatáson keresztül.

Személyes véleményem az, hogy nagyon jó elképzelés a településképi arculati kézikönyv, és szakmapolitikai szempontból jó iránymutatást ad. A vizuális kultúrát, az épített környezetet hosszú leírásokból nehéz megérteni, sematikus ábrákkal sokkal szemléletesebbé tehető ez az egész. A települések pedig kapnak eszközkészletet, elektronikus támogatást ahhoz, hogy összeállíthassák saját kézikönyvüket. Ezek egyébként azért jelennek meg több településen könyv formájában is és nem csak elektronikusan, mert az emberek szeretnek kézzel fogható terméket lapozni.

Bitport: Hogyan őrzik meg mindaz a tudást, kultúrát, ami a projekt során felhalmozódik?

B. A.: Olyan dolgokat igyekszünk bevezetni a Lechnerben a fejlesztők, a többi munkatárs és a vezetők szintjén is, amiket jó használni, mert például gyorsítja a munkájukat. És ha valamit szeretnek használni az emberek, nehezen hagyják ott az út szélén.

A másik törekvésem az, hogy meghonosítsuk a közbeszerzések egy újfajta értelmezését, módszertanát. A közelmúltban beszéltem arról a GIRO Zrt. informatikai igazgatójával, Kada Zsolttal arról, hogy jó lenne meghonosítani olyan megoldásokat, amik az észteknél, a briteknél vagy az amerikaiaknál már bevált a közbeszerzésekben. Az államigazgatás foglalkozik az üzemeltetéssel, a fejlesztési eszközökkel, de jó lenne tisztázni, mi a megrendelő és az informatikai vezető feladata. Ez most nem teljesen világos, pláne ilyen méretű projektnél, ami még nem volt a közigazgatásban.

Például sokan az képviselik, hogy a szállítóra nehezedjen nyomás, az sem baj, ha rosszul érzni magát. Ez szerintem rossz hozzáállás. Ha a szállító rosszul érzi magát, akkor az eredmény is rossz lesz. Az a cél, hogy a sajátunk legyen a rendszer, amit a szállító hoz. Ezt csak közös munkával érhetjük el. Meg kell érteni azt, amit a szállító kínál, amihez viszont partnerség kell. És persze nagyon fontos szempont a transzparencia is.

Bitport: Elterjeszthető ez a kultúra?

B. A.: Úgy látom, aki részese lehet ilyen projektnek, maga is terjesztőjévé válik. Fontos eredménynek tartom például, hogy amióta bevezettük az új módszertant, lényegében alig van a fluktuáció, miközben korábban évente tíz IT-szakember ment el. A vezetők pedig átveszik és viszik magukkal, ha úgy látják, segítségével sikerre lehet vinni a projekteket. Persze kérdés, hogy mit nevezünk sikeres projektnek. A dokumentáltság és a mérföldkövek elérése önmagában kevés, hiszen a legfontosabb, hogy a végeredmény jól működjön. Ezt pedig a felhasználók döntik el.