nke logo white

Nemzeti Közszolgálati Egyetem

Az Apertus Nonprofit Kft. célja, hogy közszolgálati alapon, nyereségérdekeltség nélkül, magas szakmai színvonalon támogassa a közszolgálati továbbképzési rendszer – elsősorban informatikai – fejlesztését és működtetését, valamint a Nemzeti Közszolgálati Egyetem közszolgálati továbbképzéseinek megszervezését és fejlesztését.

Ugrás

Egy új informatikai termék fejlesztése mindig tele van kihívásokkal. Hiába tudhat valaki maga mögött ezer korábbi projektet, az ezeregyedik is biztosan tud valami újat mutatni, hiszen a világ, a technológia, az igények és úgy általában minden nagyon turbulensen tud változni. A sikeres fejlesztést az különbözteti meg a sikertelentől, hogy miként tud reagálni az újonnan jövő megoldandó problémákra, illetve a fejlesztőcsapat mennyire tud agilisan viselkedni. Ennek a kihíváshalmaznak a leküzdéséről szól ez a cikk, bemutatva egy olyan sikeres projektet, ami korántsem volt sétagalopp.

A projekt

A projekt – röviden összefoglalva – arról szólt, hogy készítsünk egy terméket, amin keresztül az állami tisztviselők szakirányú továbbképzésen vehetnek részt. Meg tudják nézni az e-tananyagokat és részt vehessenek az e-szemináriumokon, ezzel párhuzamosan pedig az oktatók fel tudjanak készülni az egyes eseményekre, a képzés szervezői pedig el tudják végezni a szükséges adminisztrációt. A termék maga tehát a tanulástámogató szoftverek (Learning Management System – LMS) témakörébe tartozik, és kezdetben két szakirányú továbbképzés támogatására lett optimalizálva. Mindezt nagyjából hat hónap alatt kellett megvalósítani úgy, hogy a projekt végén már az első évfolyam meg is kezdhesse a használatát. Egyszerűen hangzik, igaz?

dashboard

Én is lángolok

Az egyik népszerű internetes fotón látható egy póló, amelynek a felirata nyersfordításban ilyesmi:

Projektvezetőnek lenni könnyű. Olyan, mintha bicikliznél, annyi különbséggel, hogy a bicikli lángol, te is lángolsz, minden lángol és a pokolban vagy.

Hát valahogy én is így éreztem magam, amikor csatlakoztam az Apertus Kft.-hez és hamarosan friss projektvezetőként átvettem egy éppen elindított projekt vezetését. 2016 januárjában tettem le az MSc-záróvizsgámat, majd májusban – a korábbi munkahelyemről átváltva – úgy gondoltam, hogy kilépek az eddigi üzleti elemzői szerepemből és projektvezetőként is kipróbálom magamat. Először csak kis fejlesztést koordináltam, amin keresztül megismertem a munkatársaimat, a környezetet, az erősségeinket és a fejlesztendő pontjainkat. Aztán, amikor 2016 nyarán átvettem a szakirányú továbbképzés projektjét, még azt gondoltam, hogy milyen könnyű dolgom van, hisz sok minden már elő van készítve, ezért a feladat, ha jóval nagyobb is, mint amikkel addig találkoztam, sok gondot nem fog okozni. Tévedtem.

shutterstock 349413722

A bicikli is lángol

Bár a hasonlatnak ez az eleme nem a legtalálóbb, hiszen én leginkább a csapat részeként működtem, és a fejlesztők és az üzleti elemzők nagyon távol állnak az egyszerű eszközzé minősítéstől, de az biztos, hogy ők is lángokban álltak. Hogy miért? Mert éppen mindenkinek most borult fel az eddig megszokott életvitele:

  • A Java-fejlesztők eddig monolitikus alkalmazásokat fejlesztettek, azonban ennél a projektnél már inkább REST-es alkalmazást akartunk csinálni a hosszú távú fenntarthatóság érdekében.;
  • A PHP és a .NET fejlesztőinkre az a feladat várt, hogy rövid idő alatt megtanulják az Angular keretrendszer használatát és ezáltal tiszta frontend-fejlesztésre álljanak át. Az Angularnak ekkor jött ki a béta verziója, amit buildelni nem nagyon lehetett, egy udemy-s kurzus volt a zsoltároskönyv, amit folyton nyitva tartottak és az irányt mutatott nekik.
  • Eddig inkább a vízesés modell szerint fejlesztettek funkcionális specifikáció alapján, ezt a mankójukat azonban elvesztették, amikor a user story-k alapján kellett nekik kitalálni a konkrét működést.
  • A projekt üzleti elemzői is éppen tanulták, hogy miként tudnak a szerepükből a product owner-i szerepbe áthelyezkedni és ezzel milyen feladatok is járnak.
  • És úgy általánosságban sem volt kidolgozva a módszertan arra nézve, hogy egy agilis fejlesztésre lassan áttérő szervezetnek hogyan is kéne működnie, így akár hétről hétre új dolgoknak kellett megfelelniük.
  • Az eddigi öt-hat fő helyett tizenöt embernek kellett együttműködnie napi szinten.

Hogy mit tett mindenki? Kihívásként kezelte a dolgot, megtalálta azt a részét, ami az ő személyes céljaival egybevág, mint például egy új keretrendszer megismerése vagy a szoftvertervezésbe való betanulás. Kritikus szemmel, de a megoldás keresését szem előtt tartva tekintett minden egyes új dologra, legyen az technológiai vagy módszertani újítás. És legfőképp, a képességeinek a legjavát belerakva dolgozott.

Minden lángol

Mindeközben a szervezet informatikai ágazata arra készült, hogy szép lassan magáévá tegye az agilis elveket és az ebből levezetett módszertanokat. A napi stand-up meeting már mindenki számára alapértelmezett volt, azonban még mindig nem volt rendes konvenciónk például arra, hogy mit is írjunk egy user story-ba. És hogy mégis kinek a felelőssége az, hogy a story alapján megmondja a konkrét fejlesztési feladatot, az architekt-é vagy a fejlesztőé? Mi is kell ahhoz, hogy egy feladat jól legyen definiálva? Ezeket és ezekhez hasonló kérdéseket kellett megválaszolni, ritkaság volt, hogy az első ötletünk működött volna. A módszereinket ugyanolyan iterációs ciklusokon keresztül fejlesztettük, mint a szoftvereinket, így szép lassan be tudtak állni egyfajta stabil működésre.

eszem

Eközben a projektnek inputot szolgáltatók is nehézségekkel találták szemben magukat. A képzés indulása fél évvel előrébb került, így a vadonatúj foglalkoztatási formának, az e-szemináriumnak is hamarabb ki kellett találniuk a végleges változatát. Még folyt volna a kutatás, amikor nekünk már el kellett kezdeni az informatikai megvalósítását.

Így nagyon kockázatos volt ugyan a fejlesztés, de ezt azzal igyekeztünk minimalizálni, hogy bevezettünk egy újabb módszertani elemet a scrum-ból, mégpedig elkezdtük rendszeresen demózni a szoftver aktuális állapotát a megrendelő képviselőinek, ezzel minél hamarabb visszajelzéseket gyűjthettünk arról, hogy mi az, ami nem jó.

A pokol

A képzést eközben már elkezdték hirdetni a Járási Hivatalok munkavállalói számára, előzetes számítások alapján hatszáz köztisztviselő várt arra, hogy novemberben megkezdhesse a tanulmányait.

Látszott, hogy minden téren egyre nagyobb a kockázat, ezért a vezetők vésztervek kidolgozásánakláttak neki. Aztán hopp, szervezési okok miatt megérkezett az igény, hogy a félév indulását hozzuk két héttel korábbra. Egyértelművé vált, hogy nem leszünk meg addig minden szükséges funkcióval, úgyhogy átütemeztük fejlesztésünket és úgy dolgoztunk, hogy egy-egy funkció közvetlenül az igénybevétele előtt készüljön el. Az egész valahogy úgy nézett ki, mint ahogy Gromit pakolja maga elé a síneket, miközben száguld a vonaton (Gromit a kutya, a Wallace és Gromit című brit televíziós gyurmasorozatból – a szerk.).

spare track

Bár azt lehet gondolni, hogy ez is nagy problémát okozott, ekkorra azonban már annyi tapasztalattal gazdagodtunk és olyan mértékben sikerült kialakítanunk azt, hogy miként fejlesszünk, hogy ezt az „utolsó” akadályt már könnyedén vettük.

…és mégis sikeres

Szóval ott álltunk november végén egy szoftverrel, ami épphogy csak elkészült, és teljesen ki voltunk merülve. Az emberekben nagyon sok feszültség gyűlt össze, mindenki megfogadta, hogy ilyet soha az életben nem fog bevállalni. Stílszerűen fogalmazva, ha tovább lángolunk, rövid idő alatt ki is égtünk volna.

Ennek ellenére maga a projekt kifejezetten sikeresnek mondható. Azt a célt, hogy a 2016/17/I-es évfolyam közel hatszáz hallgatója meg tudja kezdeni a tanulmányait a két szakirányú továbbképzésen, a félév végén pedig az elsajátított ismeretek birtokában érdemjegyeket tudjanak szerezni, teljes mértékben sikerült elérnünk.

Mit ért még el a projekt ezenkívül?

  • Bebizonyította a megrendelői körnek is, hogy szoftvert ilyen szűk határidővel csak nagyon magas kockázat mellett lehet fejleszteni.
  • Megmutatta az Apertus vezetőinek, hogy az itt alkalmazott emberek, bár képesek ilyen nehéz körülmények között is teljesíteni, ennél sokkal kisebb terhelés alatt kell ahhoz dolgozniuk, hogy komfortosan érezhessék magukat a munkahelyükön, és ők is úgy lássák, hogy minőségi munkát tudnak végezni. Többet ilyen kockázatot azóta sem vállaltak és nem is fognak.
  • Rámutatott és megoldást is nyújtott az új technológiák problémáira. Általánossá tette, hogy az alkalmazásainkat backend–frontend szétválasztásban fejlesszük. Letisztázta, hogy miként lehet összeszervezni tizenöt vagy akár még több szoftver élesítését. Standarddá tette az Angular keretrendszer használatát, ami az éles használatkor szerencsére már átváltott a stabil verzióra.
  • Lefektette az alapjait az általunk alkalmazott módszertani elemeknek, és lefordította a modellek tankönyvszagú példáit arra, hogy konkrétan mit is kell csinálni.
  • Összekovácsolta a különböző helyről érkező embereket.

Összességében tehát elmondható, hogy bár a szerződésünk keretében elvégzendő fejlesztéseink sorát indulásképp olyan projekttel sikerült nyitnunk, amelyre szinte semmilyen szempontból nem voltunk felkészülve, menetközben mégis sikerült egyénileg is és szervezeti szinten is felnőni a feladathoz, valamint kikövezni az utána következő projektek útját.

Az összeállt terméket pedig nem kellett az első használat után kukába dobni, mint ami az ilyen nagy feszültség alatt készülő projektekkel történni szokott, hanem azóta is biztosan üzemel és az új igényként megjelent modulokat is nyugodtan tudjuk építeni hozzá. A tavaszi félévben az új évfolyam is megkezdte a tanulást, idén szeptemberben pedig az eddiginél is több új hallgatót várunk.


Szabó Tamás

Az Apertus Nonprofit Kft Informatikai fejlesztési osztályának projektvezetője, product owner-e. A projektjei mellett szívesen foglalkozik a folyamataink javításával, új elgondolások bevezetésével.