Kuidas me digitaliseerime töövaidlusi Eestis – paindliku süsteemi loomise väljakutsed

Oma mõtteid jagavad Madleen Mäe Tööinspektsioonist, Maret Kuub Tervise ja Heaolu Infosüsteemide Keskusest (TEHIK) ja Helen Alasoo Trinidad Wisemanist.

Teeme alustuseks tutvust. Milline on teie roll Tööelu Infosüsteemi (TEIS) ja konkreetsemalt töövaidluskomisjonide (TVK) mooduli arendamises?

Madleen: Olen Tööinspektsioonis TEISi tooteomanik. Minu peamine roll on ärivajadused selgeks teha ja lauale tuua.

Maret: Mina töötan TEHIKus Tööinspektsiooni teenuste tiimijuhina ja täidan ka projektijuhi ülesandeid.  

Helen: Mina olen Trinidad Wisemanis projekti vanemsüsteemianalüütik ning tegelen tehnilise poolega.

Rääkige lähemalt TVK projektist. Miks ja kellel sellist süsteemi vaja on?

Madleen: Töövaidlus on olukord, mis võib tekkida töötaja ja tööandja vahel erineval põhjusel, näiteks saamata jäänud töötasu või töötingimused. Töötajad saavad töövaidluse lahendamiseks pöörduda töövaidluskomisjoni, mis on kohtuväline organ tööinspektsiooni juures.

Töövaidluse protsess on seadusega reguleeritud ja selles on väga palju detaile. Näiteks, kas tegu on individuaalse või kollektiivse töövaidlusega, tavamenetlusega, kus toimub ka istung, kirjaliku menetluse või lepitusmenetlusega. Inimesele, kes igapäevaselt sellega kokku ei puutu, võib protsess olla keeruline, eriti stressiolukorras.

Täna puudub digitaalne keskkond töövaidluste avalduste esitamiseks. Avaldusi esitatakse e-kirja või posti teel, mis toob kaasa selle, et avaldustes on palju vigu. Praegu esitatakse Eestis umbes 3000 töövaidluse avaldust aastas ja see number kasvab iga aasta. Tervelt kolmandik neist on puudustega ja saadetakse parandamiseks tagasi.

Töövaidluste mooduliga püüamegi töövaidluse protsessi lihtsamaks ja selgemaks teha. Lühidalt on meil kolm suuremat eesmärki. Esiteks, et suur osa avaldusi hakkaks tulema iseteeninduse kaudu. Teiseks, et puudustega avalduste arv väheneks ehk digitaalne keskkond juhendaks inimest avalduse koostamisel.

Kolmandaks eesmärgiks on menetlusdokumentide kättetoimetamise ja haldamise lihtsustamine kõigi osapoolte jaoks – seni on dokumentide esitamise ajakulu inimeste ja tööandjate jaoks olnud väga suur.  

Helen: Analüüsi ja disaini poolel paneme palju rõhku just sellele, et kogu protsess oleks võimalikult intuitiivne, et avaldust saaks esitama tulla ükskõik milliste tehniliste oskustega inimene, ka üldse mitte arvutikasutaja. Puuduliku avalduse esitamine jääb ka tulevikus võimalikuks, aga me anname inimesele puudusest märku – näiteks, et tal on avalduses tõendamata nõue.  

Samuti on Tööinspektsioonis praegu väga palju manuaalset tööd. Dokumentide kättetoimetamine, aga ka meilitsi ja füüsiliselt laekuvate avalduste registreerimine on väga aeganõudev protsess. Ka tulevikus saab avaldust meili ja posti teel saata, aga automatiseerime süsteemi kaudu tegevusi, nii et dokumendihaldusspetsialistid ei pea iga liigutust käsitsi tegema.

Lisaks muudab iseteenindus töövaidluste protsessi läbipaistvamaks, kuna igal hetkel saab süsteemi sisse logida ja kõiki dokumente näha.  

Mille poolest erineb TVK mooduli arendamine varasematest TEISi arendustest?

Madleen: Üks erinevus varasemate moodulitega võrreldes on see, et töövaidluse protsessis osaleb väga palju erinevaid osapooli – töövaidluskomisjoni juhataja ja dokumendihaldusspetsialist, vaidlustaja ja vastaspool, võibolla nende esindajad advokaadi näol, tavamenetluse puhul veel kaasistujad. Kõik osapooled peavad süsteemi ligi pääsema ja neile mõeldud dokumente nägema.

Helen: Tavaliselt on meil üks kindel protsess ja võibolla mõned äärejuhtumid, mida süsteem peab võimaldama. Töövaidluste puhul on iga vaidlus täiesti erinev, kattuvat osa on väga vähe.

Süsteem peab olema piisavalt paindlik, et seda kõike lubada, samas seda niivõrd piiritletud, et dokumente näeksid ainult õiged inimesed. TVK moodul on tehniliselt teistest moodulitest täiesti erinev, kuna see on väga paindlik. Ja mida paindlikum on süsteem, seda keerulisem see on.

Madleen: Samas kui süsteem lubab liiga paindlikult kõike, kaob ära abistav efekt, mis aitaks inimesel protsessi läbi teha. Nii et siin tuleb tasakaal leida.

Helen: Kuna avaldusi saab ka tulevikus meili teel ja füüsiliselt esitada, tekib olukord, kus iseteeninduses saame süsteemselt inimesi juhendada. Aga ametnikurakenduses peab jätkuvalt saama sisestada avaldusi, mis võivad olla tunduvalt rohkem puudulikud.

Seega ei saa me panna mingeid andmeid täiesti kohustuslikuks. Kesktee leidmine ongi hästi keerukas – kuidas me kindlustame, et menetluseks reaalselt vajalikud andmed on meil alati olemas, nii et puudustega avalduste arv ka päriselt langeks?

Tõite välja mitmeid väljakutseid, nagu osapoolte rohkus ja paindlikkuse vajadus. Kuidas te neid lahendate?

Helen: Ühelt poolt on vaja paindlikkust, teisalt soovime ikkagi luua sellist protsessi, mis menetluse erinevate töövaidluskomisjonide vahel võimalikult ühtlustaks. Proovime leida sellised lahendused, mis TVK juhatajate ja dokumendihaldusspetsialistide vajadused kataks.

Meil on väga tugev omavaheline koostöö ning läbipaistev analüüsi ja disainiprotsess. Teeme regulaarseid analüüsikoosolekuid, kus näitame disaine ning TVKde juhatajad ja DHSid (dokumendihaldusspetsialistid) saavad anda tagasisidet, meie vastavalt suunda muuta ning jooksvalt analüüsiküsimused esitada.  

Samuti teeme kasutajateste, kus erinevad osapooled saavad oma tööprotsessi prototüübi läbi katsetada. Tänu sellele saame kindlustunnet, et oleme õigel teel, või näeme, mida tuleb muuta. Analüüs ja disaini testimine enne, kui päriselt midagi valmis teeme, on väga-väga suur osa arendusprotsessist.

Madleen: Meil on nii TEISi arendustes kui üldisemalt kesksel kohal eri kasutajate kaasamine juba analüüsi protsessis. Ja kui esimesed prototüübid on valminud, siis neile tagasiside küsimine ja kasutajatestide tegemine enne live'i minekut. See aitab hoida kokku aega ja raha ning vältida suuri fopaasid, kus arendame valmis asja, mida tegelikult vaja ei ole.

Maret: Samuti püüame võimalikult palju taaskasutada andmeid teistest registritest ja meie enda süsteemist, et kasutajad ei peaks samu andmeid topelt sisestama.

Näiteks saavad TVK juhatajad nüüd ühe klikiga teha päringu Äriregistrist või Töötamise registrist – varem pidid nad selleks andmed registrist välja võtma, PDF-iks tegema ja süsteemi üles laadima. Liigutame võimalikult palju andmeid, mitte dokumente, ja liigume andmepõhise majandamise suunas.

Madleen: Kui mingite vajalike andmete saamine on piiratud, tegeleme paralleelselt arendusele ka õiguslike läbirääkimistega. Püüame jõuda asutustega kokkuleppele, et saaksime teha automaatsed liidestused, nii et igapäevatöös kasutatavate andmete kättesaamine oleks kasutajale võimalikult mugav.

Projektis on neli osapoolt: Tööinspektsioon, TEHIK, Trinidad Wiseman ja Triple Dev. Kuidas rollid omavahel jagunevad ja mida see meeskonna jaoks tähendab?

Madleen: Trinidad Wiseman teeb analüüsi, disaini ja front-end arendust, Triple Dev back-end arendust ja testimist. TEHIK toetab meid tehnilise poole ja projektijuhtimisega. Mina Tööinspektsioonist olen äripoole esindaja ja tooteomaniku rollis.  

Maret: Projektitiim on päris suur – umbes kakskümmend viis inimest. Sellise suure arendustiimi puhul on rolliselgus ülioluline, et kõik teaksid, mille eest keegi vastutab. Toetame üksteise rolle, aga ei sega end liiga palju kellegi teise töösse. Usaldame seda, et igaüks teab oma tööd kõige paremini. Rollid ja ülesanded on aastate jooksul hästi paika loksunud, aga vajadusel teeme ka muudatusi.  

Helen: Lisaks sellele, et tööprotsessid on hästi paika loksunud, paneme tiimis päris palju rõhku pehmetele väärtustele. Meil on kahenädalased sprindid, kus iga sprint lõpeb demo ja retrokoosolekuga. Me ei jäta retrokoosolekut ära sellepärast, et kõik on hästi – kui kõik on hästi, siis räägimegi sellest, et kõik on hästi.  

Omavaheline suhtlus on väga sujuv ja avatud – ei ole infomulle, vaid vajalik info jõuab alati kõigini. Kogu tiim on hingega asja juures ja kuna meil on ühine eesmärk, siis kui kellelgi on abi vaja, on see abi alati kuskilt võtta. Ei ole üldse sellist tunnet, et oleksime neljast erinevast ettevõttest.

Madleen: See on hästi huvitav tunne, et me justkui oleme eri ettevõtetest, aga mina üldse ei taju “sina” või “mina”. Alati on “meie”, “meie tiim”, “meie teeme”.  

Kuna meil on protsessiline osa juba nii paika loksunud, siis erinevate osapoolte rohkus on teenuse arendamisel pigem lisaväärtus. Kui näiteks Tööinspektsiooni äriprotsesside juhid lähtuvad võib-olla rohkem seadusest või ametniku vaatest, siis arendajad, analüütikud ja TEHIKu inimesed esindavad rohkem tavainimese vaadet. Tänu sellele saab teenus lõpuks lihtsam ja selgem.

Mainisite kõik rolliselguse ja protsesside olulisust. Kirjeldage paari lausega oma tiimi tööprotsesse.

Helen: Meil on kahenädalased sprindid. Tavaliselt toimub igal hommikul kogu tiimiga 15-minutiline daily standup, kus räägime, mida keegi teeb ja kas on tekkinud mingeid takistusi.  

Üle nädala toimuvad grooming-koosolekud, mille jaoks analüütik teeb arenduspiletid ja arendajad hindavad, kaua nendega võiks aega minna. See on vajalik sprindi planeerimiseks, et kõik planeeritud piletid saaksid kahe nädalaga ilusti valmis.

Iga sprindi lõpus on demo, kus näidatakse, mis kahe nädala jooksul valmis sai. Ja retrokoosolek, kus räägime, mis oli viimase kahe nädala jooksul hästi, mis võib-olla mitte nii hästi, ja arutame erinevaid küsimusi.

Madleen: Iga kahe nädala järel on sprinditarned. Meie Tööinspektsioonis teame siis, et peame siis vastuvõtutestimist tegema. Kõik teavad, millal midagi juhtub. Lisaks on meil väga hea dokumentatsioon. Kõik on üles leitav ka siis, kui inimesed vahelduvad või pikemalt puhkavad.

Mis lahendust te dokumentatsiooni jaoks kasutate?

Maret: Meil on Confluence Wiki, kuhu on talletatud kõik analüüsid, tehniline info ja aja jooksul tehtud kokkulepped, näiteks UI ja UX kokkulepped või kuidas bugisid arendajale raporteerida.

Koosolekutel osaleb kogu tiim. Kuna kõik osapooled istuvad daily standup’idel, demodel ja retrodel ühe laua taga, siis tunneme üksteist väga hästi. Nii et kui tekib mõne arenduspileti osas küsimus, tean, millise arendaja või testija poole pöörduda. Meie projektis ei teki sellist situatsiooni, kus laua taga on ainult projektijuhid ja kuskile jääb infosulg.  

Võiks arvata, et meil kulub neile rutiinidele väga palju aega, aga samas me hoiame aega kokku tänu sellele, et me oleme kogu aeg samas infoväljas.

Madleen: Tegelikult ka raha. Teatavasti arendaja iga töötund ju maksab. Aga me oleme sel nõul, et pigem istume koos laua taga ja tänu sellele parandame vähem vigu. Ei räägi üksteisest mööda, vaid oleme ühiselt aru saanud, mida ja kuidas me teeme.  

Maret: Aastate jooksul on just nimelt retrokoosolekutelt tulnud väga palju häid ettepanekuid ja ideid tänu sellele, et kogu tiim on ühe laua taga. Pluss, ma arvan, et see mõjutaks kindlasti tiimiliikmete motivatsiooni, kui nad peaksid ainult koodi kirjutama ega kohtuks kunagi tellijaga, kelle jaoks nad tööd teevad. On oluline, et igaüks tiimist näeks, mille jaoks ta väärtust loob.

Olete TEISi üheskoos arendanud kuus aastat. Mida selline pikaajaline koostöö arenduspartneriga tellijal vaatest annab? Kas siin võib olla ka mingeid miinuseid?

Madleen: Mulle tundub, et see on sarnane teiste partnerluste või isiklike suhetega. Kui oled kellegagi pikemaajaliselt suhtes, tunned inimest paremini, tekib suurem usaldus.  

Koostöö on sujuvam, sest nagu me juba rääkisime, protsessid loksuvad paika. Lisaks annab see teatud meelerahu, et isegi kui on mingi arusaamatus või möödarääkimine, ei vii see lahkuminekuni. Tekib julgus ka keerulisemad küsimused lauale tuua ja ebamugavamaid teemasid vajadusel arutada.  

Maret: Rõhutaksin samuti usaldust ja avatud suhtlust. Kui meil on kusagil probleem, siis keegi ei lükka seda vaiba alla, sest teatakse, et meil on turvaline rääkida ka sellest, kui midagi läheb valesti või midagi saab paremini teha.  

Pikaajalise suhte puhul võiks miinuseks olla see, kui langeme rutiini ja teeme asju koguaeg turvaliselt ühtemoodi. Aga mulle tundub, et meil on ka selles osas hästi, kuna inimesed tiimis aeg-ajalt ikka vahetuvad. Tuleb uusi arendajaid ja analüütikuid, ja kui inimesed julgevad oma ideed lauale tuua, siis ka jätkuvalt värskeid ideid, kuidas asju teistmoodi katsetada.  

Milline on teie soovitus, kuidas sarnastes keerukates arendusprojektides riske maandada? Millisteks ootamatusteks tasub valmis olla?

Helen: Arenduse ja analüüsi poolel tasuks alati valmis olla selleks, et isegi kui on tehtud eelanalüüs, võib alati vaiba alt välja tulla mõni “koll”, mis teeb asja arvatust tunduvalt keerulisemaks. Pileteid hinnates tasub alati puhvrit otsa panna. Ja kui tulebki mõni “koll” välja, siis olla kohe vokaalne ja anda teada, et on probleem, mis vajab lahendust.  

Kui vähegi võimalik, soovitaksin analüütikul valideerida oma analüüsi kellegi teise, näiteks arhitekti või vanemarendajaga. Üksinda tekib kergesti tunnelivaade, midagi võib ununeda või kahe silma vahele jääda. Kasuta ära tiimi, kes on sinu ümber ja küsi neilt abi!

Maret: Meie projektides me ei tee kunagi kogu süsteemi analüüsi lõpuni valmis enne arenduse alustamist. Tänu sellele, et liigume analüüsi ja arendusega paralleelselt, on meil paindlikkus midagi muuta, kui see vajadus peaks tekkima.

Kliendi poolel on oluline leida inimesed, kes oma teenusest räägivad ja aitavad analüüsi teha. See on nende jaoks lisatöö, mida nad teevad oma põhitöö kõrvalt. Kui analüüsikoosolekutel osalevad spetsialistid vahetuvad, võivad muutuda ka vajadused või tekkida teine pilk protsessile. Siis tuleb teha vajalikud muudatused ja võibolla teistmoodi edasi minna. Ka sel juhul on hea, kui kogu analüüs ei ole lõpetatud.

Madleen: Maret ja Helen tõid juba minu mõtted välja. Täiendavad arendusvajadused, olgu tehnilist laadi või äriprotsessist tulenevad, on kindlasti üks ootamatus. Ja inimeste vahetumine, eriti pikemas projektis, toob ikkagi alati kaasa natuke segadust, selsamal põhjusel, et inimesed näevad protsessi erinevalt. Siin võib aidata hea dokumentatsioon, et saaks minna ajas tagasi ja vaadata, mis kellegi mõte või vajadus oli.

Ja kindlasti ajakulu. Olen endale hüüumärgiga kirja pannud, et alati varuda lisapuhvrit.  Praktika on näidanud, et isegi pisikesed liidestused võivad võtta palju rohkem testimist ja aega, kui alguses planeeritud. Kui vähegi võimalik, mitte raiuda kuupäevi kivisse, kui ei ole just seadusest tulenevat tähtaega, vaid olla tellijana kuupäevade osas paindlik.

Pigem teeme kaks kuud kauem, aga saame hästi toimiva lahenduse, kui et kiirustame lihtsalt kiirustamise pärast ja võtame kohe kasutusele süsteemi, mis on ebamugav või ei täida oma eesmärki.

Allikas: TWN