Mida õppisin kommuunil baseeruva disainisüsteemi loomisest avalikus sektoris

Sorry English speaking guests. This is in Estonian. 🙂

Enne kui alustan, siis mainin ära, et tegu oli minu esimese töökohaga avalikus sektoris ning nii suures firmas, kus reaalselt eksisteerib struktuur. Varasemalt olin projektijuht väikeses IT firmas, millel olid ka 2 gigant infosüsteemi ning kus kõik töötajad olid ühes pisikeses ruumis (töötajaid vähem kui ühel käel näppe) ning juhataja istus reaalselt minu kõrval. Seega uus firma erines totaalselt eelmisest.

Tööd alustades oli alus disainisüsteemi edasi arenguks loodud: kokkulepped kommuuni toetamiseks olemasolevate avaliku sektori disainisüsteemide omanikega olid olemas. Oli rahastus edasiarenduseks olemas.Oli ka üks esimesi kommuuni panustajaid olemas, kes arendas senist disainisüsteemi endale sobivamaks.

Sellel hetkel oli üks keerulisem ning läbimõeldud disainisüsteem ühe veebiraamistikuga ning teine lihtsam disainisüsteem teise veebiraamistikuga. Lihtsamalt öeldes: oli 2 disainisüsteemi ja kummalgi oma koodibaas.

Kuna riiklikul tasemel oli hakatud juba korralikku lobi tööd tegema, et uus disainisüsteem liiguks üleriigiliseks, siis üks tihedamaid küsimusi kommuuni poolt oli: mis veebiraamistikku kasutama peaks ning sh. milline disainisüsteem paremini sobiks. Kuna projektide uurimisega ei olnud mõtet süvitsi minna, siis jäi lõpliku otsuse tegemine iga projekti arhitekti ja/või tootejuhi otsustada. Vähe sellest, et olemasolevad projektid pidid pikalt oma hankeid ette valmistama, lisandus sinna järgmine pudelikael, et millist veebiraamistikku ikkagi valida. Ma küll ei olnud nende vaidluste kõrval, kuid usun, et kui arhitekt vaatab projekti tehnilist poolt, kuid projekti-/tootejuht ei ole tehniliselt piisavalt pädev, siis lõpuks vaieldi ikka selle üle, kumb olemasolev disainisüsteem ilusam oli. Tahame me seda või mitte, siis vaidlused värvide ja nuppude kujude üle on alati lihtsamad, kuna neid mõistavad kõik.

Selleks, et pudelikaela eemaldada tuli idee, et peaks 2 senist disainisüsteemi omavahel ühe projektiga ühendama. Disainerid tegid kiire ja korraliku aluse disaini tööfailiks. Ainus murekoht endiselt jäi: navigatsioon, mille üle tol hetkel toimusid suured vaidlused, sest ühele ei meeldinud üks ning teisele ei meeldinud teine. Polnud ka väga aimu, kust otsast kogu seda pundart harutama hakata. Olemasolev infosüsteem, mis pidi esimene kasutaja olema, on ju üks nendest gigantidest, mis aina edasi kasvab ning valitud navigatsioon võib iga hetkega aknast välja lennata. Jõudsime lõpuks konsensusele ning valisime sobivaima välja eesmärgiga see kasutusele võtta ning edasised arendused selle osas kasutajatestidega ära katta.

Esimene ja lõppkokkuvõttes kõige valusam viga

Esimene viga oligi see, et sidusin disainisüsteemi arendamise olemasoleva projektiga. Alguses mõtlesin, et olemasolev projekt annab hea aluse teenuse praktikas kasutusele võtuks ning sellest saab ühtlasi musternäite, kuidas uut disainisüsteemi rakendada. Pange tähele, et siin tekivadki need ohukohad, kus tootejuht hakkab arendama hoopis teist teenust ning sellega seoses on imelihtne kaotada silmist suur pilt, mille tõttu esialgset projekti arendama üldse hakati.

Teine viga, mille tõttu ei saanud esimesest veast kiirelt toibuda

Teine suur viga oli see, et andsin lihtsalt raha ära, kuna varasem kogemus avaliku sektoriga puudus ning eeldasin, et raha ilmub kusagilt kõrgelt maagiliselt tagasi. Kurb tõsiasi oli see, et esimese vea juures mainitud projekt sõi kõik disainisüsteemi arendamiseks mõeldud raha ära ja ka juhataja ei suutnud lisarahastust leida. Ning kui tekkis lõpuks see hetk (~3 viimast kuud töökohal olles) disainisüsteemiga edasi tegeleda ja jõudsin SF rahastuse taotlusega nii kaugele, et sain reaalselt hanke välja kuulutada, siis tuli teade juhatuselt, et terves majas on raha nii otsas, et varasemalt SF-i omaosaluseks lubatud 15 000 € oli lihtsalt haihtunud.

Selle punkti esimene õpikoht on siis see, et ära anna enda projektile saadud raha ära. Nii võivad seatud eesmärgid saavutamata jääda. Teine õpikoht on see, et kui kusagilt lubatakse sulle raha, siis tegele selle summa reaalselt enda kontole saamisega – suuliselt võivad lubadused lennata siia ja sinna, aga oluline on need realiseerida ja kindlustada oma tagal.

Kuidas oleks saanud paremini?

Lühidalt öeldes: võtta projektiks eraldatud raha ja põgeneda teises suunas kui keegi selle jutuga tuleb, et teeme 2 projekti koos [loe: kasutame antud projekti arendusraha teise projekti rahastamiseks]. Kuna muuhulgas ei tasu kommuuni ära unustada, siis tuleks ikkagi viisakalt vastata, et võtame kasutusse siis kui disainisüsteemiks esmaselt vajaminev olemas on.

Oleks pidanud toote arengu strateegia väiksemateks hoomatavamateks tükkideks lööma. Strateegilise eesmärgi saavutamiseks seatud taktika oli vale. Võtsin liiga suure tüki korraga ette. Oleks pidanud esialgu tõepoolest lihtsalt ja ainult disaini töö failidele ning nende dokumenteerimisele keskenduma. Ja seda siis selle loogikaga, et üks komponent -> selle komponendi dokumentatsioon, mitte kõik komponendid -> lõpus dokumentatsioon. Viimase kahjuks räägib see, et kõik kokkulepitu kipub lihtsalt ära ununema, kui seda üheselt kohe üles ei kirjuta. Seejärel oleks saanud teine projekt stiilid võtta ning neid rakendada (ei räägi komponendi kasutuselevõtust). Oleks lõppkokkuvõttes palju kiiremini ja odavamalt esmasele tulemusele jõudnud. Sealt oleks ehk ka teisele projektile siiski raha jäänud: hundid söönud, lambad rahul.

Aga miks ma võtsin liiga suure tüki korraga?

Kuna teistele asutustele tehti lobi selle suunisega, et antud disainisüsteemiga koos saavad nad ka koodi, mis muudab maagiliselt kõik arendused vähemalt 20% odavamaks. Me tegime esialgu küll disaineritega disaini tööfailid valmis, kuid allusin turu nõudele saada kibekiirelt ka kood. Põhjendus nõudjate poolt: me tahame uut disaini kasutusele võtta ning oleme projekti kirjutades arvestanud, et kood on juba olemas, sest see on varasemalt olnud ja meile on seda lubatud. Selle tõttu nõustusin ka oma esimese suurima veaga: tegelen kahe massiivse projektiga ühe projekti alt.

Komponentide arendamine

Avaliku sektori üks rõõmudest on see, et hankelepingud on kas ajaliselt või rahaliselt piiratud. Kui üks või teine ressurss otsa saab, siis tuleb uus hange korraldada. Kui sul veab, siis saad samade arendajatega jätkata, aga kui mitte, siis saad uue hankepartneri. See projekt sai poole pealt uue arenduspartneri.

Kuna BE poolel olid prioriteedid teised, siis hakkasime vaikselt komponente esimese partneriga järjest FE poolel arendama. Saime aru, et nendega me kahjuks kogu projekti (disainisüsteemi komponendid ning neid rakendav infosüsteem) korraga ei suuda arendatud. Ootus oli, et kui saame komponendid valmis, siis saab uus arenduspartner need lihtsalt kasutusele võtta ning vajalikud vaated kokku klõpsida. Ehk siis läheneda lehtede arendamisel atomic design meetodist. Arendajatega said vastavad kokkulepped ja arenduse põhimõtted läbiräägitud.

Esimeste arenduspartneriga jõudsime enam-vähem sellesse olukorda, kus järgmine arenduspartner sai hakata rakendama loodud komponente. Ma elasin endiselt heas usus, et võtame lihtsalt baasosakesed ja komponendid ning paneme uued lehed klõps ja klõps kokku. Kes vähegi arendajaid teab, siis ei tohiks üllatusena tulla, et enamik neist ei ole heade suhtlemisoskustega. Üks klassikaline koht erimeelsuste tekkimiseks on olemasoleva koodi kasutuselevõtt kui see ei ole korralikult dokumenteeritud ega korralikult läbi katsetatud. Lühidalt öeldes: tulid uued arendajad ning eelmiste arendajate töö kritiseerimise osas nad end tagasi ei hoidnud. Kuna koostööd alustati sellise suhtumisega, siis lõin korraliku kaitseseina üles ning ei uskunud VÄGA pikalt, et loodud komponendid nii halvad olid, et arendajad reaalselt iga arenduse mahu automaatselt dubleerisid kui kuulisid, et uute komponentidega tuleb mingit tööd teha. Süüdistasin oma mõtteis neid päris pikalt ebakompetentsuses.

Üks hetk tekkis mul võimalus olla teise projekti kõrval tuttava arendajaga (ta oli varasemalt meie meeskonnas praktikal). Kuna see projekt pidi ka antud disainisüsteemi kasutama ning see tundus oluliselt lihtsam kui minul käsilolev projekt, siis püüdsin arenduse käigul silma peal hoida ja oma meeled samuti avali hoida. Sain oma viga tunnistada: loodud komponentide koodi kvaliteet oli tõepoolest alla ootusi ning tuli leppida olukorraga, et need vajaksid refaktooringut. Loomulikult vabandasin uue arenduspartneri arendaja ja analüütiku ees.

Mis jäi tegemata?

MFN nõuded on igati vajalikud, aga kui nende täitmise kontrollimiseks ressurssi ei ole, siis taandub kõik usaldusele. Sinna kadus ka see osa, et unit testid komponentidele jäid tegemata. Arendajate ning projektijuhtidega suheldes oleks nendest kindlasti olnud palju abi uutele arendajatele. Dokumentatsioon oli pinnapealne ja ebapiisav uutele arendajatele.

Õpikoht: kui on testimiseks eraldi partner, siis lase tal testida ning arvamust avaldada. Soovituslikult mõni nooremarendaja, kes ehk takerduks suurema tõenäosusega logisevate kohtade otsa. Alternatiivina saab vabavaralist koodi mõnes entusiastide grupis jagada, kes pilgu peale heidaks. Teine alternatiiv oleks teha üleskutse koolidele, kus ehk mõni õpilane, kes huvi ja kogemuste saamiseks, oleks nõus loodut katsetama.

Raamistikud vs web componendid.

Alustaks seda analüüsi sellest, et mis olukord oleks sellest tekkinud kui oleks jätkanud spetsiifiliste raamistike toetamist.

Veebiraamistikud ja sarnase mõttega libraryd

Arendajatel on oluliselt lihtsam ühe kindla raamistiku põhiselt arendada -> arendus võtab vähem aega ning kogenud arendaja käe all on vigadeks väiksem võimalus.
Vähem sõltuvusi erinevatest librarydest -> veakindlam kood.
Puuduvad erinevad kihid, millest arenduse sujuvus sõltub -> kood valmib kiiremini, viga kiiremini leitav.

–

Kui tulevad uuendused (ka suured), siis tuleb iga raamistikuga eraldi tegeleda, mis võib olla suur ressursikulu -> aeg = raha. Tihti seda tegelikult ei juhtu, kuid kui raha selleks planeeritud ei ole, siis võib selle raha saamine järgmised 1-2 aastat võtta. See viib taaskord aegunud koodini. Siin oleks kasu aktiivsest kommuunist, kes oleks nõus kas kulusid jagama või oleksid nõus täiesti enda rahade eest seda uuendust läbi viima.
Tehnoloogia on pidevas muutumises, kui majad hakkavad uutele tehnoloogiatele liikuma, siis on vaja disainisüsteem ka uuele tehnoloogiale viia ja seda pakkuda. St. uus kood, mis vajab tuge. Samas vana koodi toetamist naljalt lõpetada ei saa kui kasutajad olemas. Seega halduskoormus pidevalt tõuseks – aktiivse kommuuni korral poleks ehk hullu, kuid alustaval kommuunil jälle potentsiaalne mure.
Kui disainisüsteemi kood on ehitatud kommuunile, kuid kommuun ei ole veel jalgu alla saanud, siis suure tõenäosusega on ainult üksikud nõus suurenevat halduskoormust jagama ja tagasi panustama.
Ka väiksema disaini muutumisel tuleb muudatus sisse viia kõigis kasutuses olevatesse koodipakkidesse.
Halduskoormuse üks vähendamise võimalusi oleks mõnes määruses lubatud tehnoloogia ära märkida, kuid see takistaks uute tehnoloogiate katsetamist. Ajas püsimise ja innovatsiooni toetamise mõistes oleks tegu väga halva lükkega.

Suurimaks plussiks on siis see, et oskusliku arendaja (valitud veebiraamistikul) olemasolu korral saab töö väga kiirelt ning pigem väheste vigadega tehtud. Ta saab keskenduda dokumentatsioonile ning ühiktestide loomisele. Vead tulevad kiirelt välja. See on raha ja aja mõistes päris oluline punkt. See punkt on positiivne just konkreetse projekti juures. Kui sul on projekt, mis keskendub näiteks ainult ühele või äärmisel juhul kahele veebiraamistikule. Pole kõige hullem haldus: maksimaalselt 2 hanget erinevate tükkide ja oskuste sisseostuks. Kui tõsta toetatavate veebiraamistike hulk kolmele või enamale, siis läheb haldus juba ajamahukamaks.

Mammutprojekti juures, kus on äärmisel juhul ainult 1 alaline töötaja (nagu minu puhul oli), on oluline just väikese halduskoormuse säilitamine. Jah, see võib esimestel aastatel olla toote arengule piirav. Eriti kui toote esimese eesmärk on olla kiirelt kasutatav tööriist ning olukorras, kus turul on pigem vähem web componentidega tuttavaid arendajaid.

Siin tekib mõttekoht, et kas jätkata suure halduskoormusega või liikuda edasi väiksema halduskoormuse suunas ning loota, et tehnoloogia areng ning teenusepakkujad jõuavad mingil hetkel järele. Järele siis selles mõttes, et tehnoloogia ühildub omavahel lihtsamini, tekivad võimalused vigade kiiremaks tuvastamiseks ning teenusepakkujad harivad end web componentide teemal piisavalt kiiresti, et liituda selle konkurentsiga.

Web componendid

Hallata ainult üks koodipakk – on aega keskenduda kvaliteedi ja korraliku dokumentatsiooni tagamisele väikese meeskonnaga
Disaini muutumisel kanda muudatus sisse ainult ühte koodipakki.
Saab kasutada iga valitud raamistiku juures.
Kui tuleb juurde web componentide librare, mida soovitakse juurutada, siis õpiprotsess küll suurem, kuid halduskoormus tõuseks ilmselt (garanteerida ei saa – räägime siiski tulevikust) laugemalt kui veebiraamistikega. Tegemist on eeldusega, et pigem võetakse kasutusele vähem uusi web componente kui et uusi veebiraamistikke.

–

Sõltuvus mitmest erinevast libraryst – viga keerulisem leida. Vahelülisid, millest koodi töötamine sõltub, on mitmeid.
Igas majas ei pruugi vastava kvalifikatsiooniga inimest olla, et kohapeal vajalikke väiksemaid muudatusi sisse viia.
Iga raamistiku juures kasutusele võtmine nõuab vahelüli, mis muudaks koodipaki raamistikule arusaadavaks – väike teema, aga lisakeerukus.

Varasemalt mainisin, et mammutprojekti juures, kus on miinimumide miinimum alalisi töötajaid, oli tol hetkel oluline liikuda väiksema halduskoormuse suunas. Oluliseks plussiks saigi just vähemate erinevate raamistike olemasolu. Tuleviku visioonis tähendas see seda, et kui pakume kommuunile vahelüli erinevatele veebiraamistikele (vajalik koodijupp oli pigem väike), siis peaks sellest olema piisavalt, et kood arvutis käima tõmmata. Oli lootus, et saame seejärel keskenduda eelkõige kommuuni loomisele ja selle toetamisele.

Web componentide kasutamisel suurim miinus oli ehk see, et arendajatel kulus arvestatav aeg vigade leidmiseks, mis tegi ka olukorra parendamise keerukamaks. Kõik erinevad seotud libraryd, erinevad kihid, tegid selle keerukaks. Mul on raske öelda, kas see seisnes nii halvas koodi kvaliteedis (s.h. dokumentatsiooni nõrkus ja puudulikud ühiktestid) või arendajate pädevuses. Ilmselt mängis suuremat rolli halb koodi kvaliteet, kuid ma ei välistaks ka arendaja pädevust, kuna räägime tehnoloogiast, mida tol hetkel arendajad küll progeda oskasid, kuid mul on endiselt tunne, et mitte spetsialisti tasemel (seal on põhjus, miks otsitakse konkreetselt Angulari, Reacti, Vue jne raamistike spetsiifilisi arendajaid – miks mitte otsida ka web componentidele spetsialiseerunud arendajaid).

Kuna arendajatega suheldes tekkis arusaam, et nad siiski eelistaks puhast veebiraamistikku ilma web componentideta, siis selle küsimusele ma hetkel vastust ei teagi: kuidas teha web komponentide kasutamine arendajale kasutajasõbralikuks protsessiks. Mis takistas kõige enam koodi normaalselt kasutada?

Kasutamise ajal tekkis pika peale lihtsalt küsimus, et kui oleksime alguses korralikult etapiti need komponendid arendanud, kas arendajad oleks endiselt arvanud, et web compoendid on ebamugavad kasutada. Oleks alustanud näiteks globaalsete väärtuste defineerimisest. Teinud korraliku dokumentatsiooni ja ühiktestid juurde. Seejärel lasknud kolmandal osapoolel loodut testida ning arvamust avaldada. Juhul kui olnuks suuremaid vigu, siis kohe ära parandanud nii koodis kui disainis, dokumentatsioonis ja muudes setud kohtades. Ning alles seejärel liikunud edasi järgmisesse etappi. Ning seda siis iga komponendiga. Sest tol hetkel, kuna leping hakkas lõppema, oli ikka korralik rööprähklemine ja aega asju korralikult teha lihtsalt ei olnud.

Intervjuudest tuli välja, et komponentide arendajal tuleb ka siiski silmas pidada erinevat stiili komponente. Üks mahukas näide oleks tabel. Meil saavad olla kasutuses:

lihtsad tabelid – päis ja sisu nimekirjas,
collapsitavad tabelid – ühe tabeli sees saad veel teise tabeli avada,
tulba ja päise freeziga tabelid (võib olla ka muude tulpade/ridade freeze-iga),
muudetavad tabelid – saad infot sisestada ja/või muuta olemasolevat infot
Jne.

Mõistlik oleks need tabelid eraldi komponentidena hoida, kuid me ei saa välistada, et ühe või teise tabeli featuur ka kusagil kokku võib saada.

Nii suure komponendi loomise juures soovitan alustada kergemaist lahendusest ning seejärel liikuda keerukama lahenduse suunas. Enda vitsad peksid tabeli osas eriti tugevalt.

Avaliku sektori teenused

Tol hetkel kui veel tööl olin, siis vahet pole, kellelt küsisin, puudus riigil ülevaade, kui palju erinevaid infosüsteeme riigil üldse on. Suheldes 2.5 aasta jooksul erinevate asutuste ja projektidega, siis sain aru, et riigis on nii avalikke kui ka vähem avalikke (loe: teadmus ja/või ligipääs infosüsteemile ainult teatud oskuste/kvalifikatsioonidega inimestel) kui ka asutuse siseseid teenuseid tohutult palju. Infosüsteemi all pean silmas e-teenust, kus inimesel on võimalik sisse logida ning teostada mingi infovahetus teenuse pakkujaga (antud juhul riigiga). On meeletult massiivseid infosüsteeme, mis on mõeldud kõigile kodanikele kui väiksemaid teenuseid, mille jaoks pole enamat kui kaheksat lehte vaja, et inimene saaks vajaliku info kätte ja oma info riigiasutusele edastatud. Kui ma seda mõistsin, siis see tunne, mis mind tol hetkel valdas oli piiritu. Võin tuua paralleeli sellega kui üritan universumile piiri panna (teadupärast on see lõputu). Ehk et neid võimalusi mingit infot näidata ja vahetada inimeste ja riigi vahel on hoomamatus koguses.

Ning siis oleme olukorras, kus kuulsin igal aastal vähemalt ühest (kui mitte rohkemast) uuest planeeritavast disainisüsteemist, mida mingi maja endale luua soovis. Ühte asutust isegi konsulteerisin sel teemal enne töölt lahkumist. Miks ma enda hallatavat disainisüsteemi neile ei müünud? Sest väidete kohaselt püüdsid nad oma protsessile niimoodi läheneda, et kasutavad võimalikult palju olemasolevaid infosüsteemide disainisüsteeme (s.h. minu hallatavat). Seega oli lootus, et nad täiesti teises suunas plagama ei pane.

Tegin mõni aeg enne lahkumist ka ülevaate endale, kui palju mõni disainisüsteem või disaini uuendamine maksab. Päris palju otsinguid sai riigihangete registris tehtud. Väiksemad jäid sinna +30 000€ skaalasse. Mõni asjalikum jäi sinna +50 000€. Mammutprojektid nagu eMTA ja eesti.ee jäid sinna +120 000€. Meeletud summad ikka mida disaini uuendamisele panustatakse. Ja kõik projektid vajavad ju ka haldust ning suuremad projektid mitte ainult väikest haldust, vaid arvestatava summa ulatuses haldust.

Kuna riigi rahakott on kõvasti koomale tõmmatud ning iga arenduse soovi on vaja analüüsida tulemustega tõestada. Halvemal juhul alustatakse projekti nullist ning tuleb eraldi nii analüüsi kui POC-i hange ning seejärel saab alles päris asja arendama hakata.

POC-ide juures kuulsin alguses tihti lootust, et arendame kohe valmis ja siis saame juba kasutajaskonna ehk taha. Lähtudes kas või Google disaini sprindi meetodist, siis tekkis mul küll küsimus, et miks teha oma elu nii keeruliseks – sarnane minu esimesele veale: teeme kõik korraga. Figma võimalused praegu on juba sellised, et kui tegemist on staatilise lehega, siis inimesed ilmselt ei saa aru, et nad on prototüüpi lappamas. Seega hakkasin varakult promoma, et unustaks õige selle koodi kirjutamise nii algusfaasis ära ning keskenduks eelkõige sisu loomele. Tõestame ära, et see teenus on vajalik vähemalt 20% madalama hinnaga (võtsin numbri taevast). Sest see info, kas inimene kasutaks seda või mitte, saame me kasutajakogemuse testidest kätte ning selleks ei ole vaja arendajaid kaasata. Üllataval kombel ei pidanud ma inimesi pikalt veenam, sest tundus, et kõik projektijuhid said aru, et mida rohkem inimesi, projektis on, seda keerulisem neid hallata on, lisaks tuleb sisu dokumentatsioonile lisada ka koodi dokumentatsiooni. Koodi loomise ja sellega seotud dokumentatsiooni sai ära jätta kui võtta eesmärgiks õige sisu loomine ja väljaselgitamine, mida kasutaja tegelikult tahab. Kuna selle käigus luuakse üldjuhul ka high-fidelity prototüübid, siis on arenduse faasiks kõik vajalik disainis olemas ning saabki keskenduda kvaliteetse koodi loomisele. Loomulikult võiks disaini partnerid nii kaua siiski edasi su kõrval olla, kuni arendus kestab, sest nägin korduvalt, kuidas arendaja loogika võib kohati laiema haarde võtta kui disaineri oma. On täiesti võimalik, et mõned use-case-id ununevad disaineril ja sinul lihtsalt ära ning hiljem neid use-case-e üksinda läbi mängida on paras peavalu ning kulutad sealhulgas arendaja vajalikku aega, sest tema on põhimõtteliselt ainus inimene, kes su kõrval tol hetkel on.

Miks riiklikult ühine disainisüsteem?

Kui nüüd võrrelda era ja avalikku sektorit, siis teenuse juhtimise osas võime vaielda kui palju tahame, aga selle kvaliteedi ja innovatsiooni osas peaks neile kahele sama moodi otsa vaatama. Riigi poolt pakutavad teenused peaks vaatama oma klienti sama pilguga nagu edukamad erasektori esindajad seda teevad. Keskendudes eelkõige kasutajale, seadustele ja pikale plaanile (ilmselt on keegi seda mõtet juba varasemalt mõtelnud ja suure plaani kusagile visioonidokumenti aastateks 2025-2050 kusagile kirja pannud – hea koht, millele hangetes viidata).

Disainisüsteeme omavad kõik suuremad ettevõtted just nimelt ühtse kasutajakogemuse tagamiseks, disainerite ja arendajate töö lihtsustamiseks ning ka loomulikult oma identiteedi müügiks. Miks ei peaks riik samu põhimõtteid omama?!

Kui lõpetasin oma teekonna, siis oli riigil endiselt 3 disainisüsteemi: ekspordiks, valitsusasutustele ning e-teenustele. Ise olin e-teenuste oma eest vastutamas. Aastake peale tööle asumist leidsime, et kõik 3 peaks pigem tihedamini kohtuma ning omavahel infot jagama, sest asutused ja teenused suhtusid disainisüsteemide seatud piiridesse väga vabalt. Just nimelt selle pärast, et need on ju soovitused, mitte riiklikult ette seatud nõudmised.

Kohtumiste esmane mõte oli jagada omavahel infot, et millised projektid riigis on aset leidmas ning milliseid disainisüsteeme keegi neist kasutab. Tihti omavahel nendest rääkides saime aru, et erinevad projektid lihtsalt otsivad põhjuseid, miks mitte üht või teist disainisüsteemi kasutada ning kuidas saaks neid disainisüsteeme omavahel ühildada.

Mõni hetk enne seda kui asutusest lahkusin, alustat disainisüsteemide poolti plaani seadmisega, et luua üks ühtne disainisüsteem, mida saab kasutada kõigi kolme disainisüsteemi nõudmiste rahuldamiseks. Peamised nõuded siis: kutsuv, silmapaistev, kasutajasõbralik, ligipääsetav, paindlik ning kataks ära nii esitlused, e-teenused kui ka printmaterjalid.

Kõige suurem murekoht on paindlikkus, sest on asutusi, kellel on omad soovid. Kui palju peaks võimaldama isikupärastamist? Millisest hetkest alates peaks hakkama kehtima need nõuded? Kas peaks selle soovituse siiski mingi määrusega siduma, et võimaldada disainisüsteemi omanikul need otsused enne ära teha ja öelda, et nii lihtsalt on?

Lisaks on eraldiseisev punkt ka kohalikud omavalitsused. Teadupärast soovitakse nii KOV-id kui riik omavahel täiesti eristada ning nüüdseks on igal KOV-il ka oma nägu. Probleem tõstatub sellest kui vaadata riigi toimivust ühtselt. Kui kodanik sisestab KOV-i või riiki mingid andmed, siis väiksemates KOV-ides võib selle info kontrollimine tähendada käsitööd. Teises jälle on kõik infovahetus juba automatiseeritud. Igal KOV-il on oma eelarve. Väiksemates KOV-ides ei pruugi olla piisavalt vahendeid, et luua ja hallata eraldiseisvat disainisüsteemi. Sel juhul saaks täiesti vabalt olla abiks just see sama üleriiklik üks ja ainus disainisüsteem. Aga kas sel juhul kaotaks KOV oma isikupära? Kas inimene arvaks, et ta on riigiasutuses oma tegemistega kui ta tegelikult on KOV-i lehel? Ning minu jaoks üks kõige paeluvamaid küsimusi: kas kasutajal päriselt ka on vahet, et millisel lehel ta infot sisestab. Kui kõik infovahetus nii KOV kui riigisiseselt on omavahel kenasti integreeritud ning rakendataks once-only põhimõtet (vahet pole, kuhu info sisestad, kõik vajalikud osapooled saavad selle kätte), siis kas päriselt on vaja neid süsteeme kuidagi omavahel eristada?

Kuna tegemist on lõpuks väga suure disainisüsteemiga, siis suure plussina näen seda, et kuna praegu on 3 disainisüsteemi riigil olemas, siis kogu seda tööjõudud on endiselt vaja. See tähendab, et keegi ei pea oma tööst ilma jääma ning kõik osad saab loodetavasti suuremate erimeelsusteta majade vahel siiski ära jagada. Tuleb lihtsalt jätkata senise koostöö edendamisega.

Tunnistada, et on pooleli või mitte?

Tihti toimus juhatajaga 1:1 vestlus ning jõuti ikka ja jälle arusaamale, et parem panna senine versioon välja ja lihtsalt seda edasi uuendada nii nagu projekt edeneb. Inimestele meeldib näha progressi. Viga oli siin see, et kuna tootejuht tegeles täiskohaga pigem teise projektiga siis seda progressi nii tihti näha ei olnud. Kommuun, mis algselt oli antud, tõmbus pigem tagasi ning inimeste soov panustada nõrgenes märgatavalt.

Kuna e-teenuste disianisüsteemi areng oli suuresti ehitatud eeldusele, et kommuun tegeleb selle arendamisega, siis kommuuni taganemisega tekkis probleem, kus uued teenused ei usaldanud antud teenust. Loovaid lähenemisi, millega püüti teenust välistada, oli mitmeid ning eelkõige rõhutigi sellele, et kuna dokumentatsioonis oli kirjas, et disainisüsteem on pre-alpha versioonis, siis ainuüksi sellest piisas, et antud disainisüsteemiga mitte edasi minna. Leiti, et parem ja soodsam on luua ise uus süsteem või võtta mõni teine disainisüsteem kasutusele, mis tegelikkuses poleks siiski nende nõuetega ühildunud (aga põhjust olemasoleva välistamiseks oli ju vaja).

Kui start-up-idega tegeleda, siis on loomulik, et alustatakse MVP-st. Kuid avalikus sektoris on tihti tunne, et kui MVP ei ole kohe 100% kasutatav ning julged vähegi öelda, et tegemist on Beta või madalama versiooniga, siis ilmselt ei võeta seda projekti väga tõsiselt. Eriti kui tegemist peaks olema kommuunil (mille aktiivsus ei sära silma) baseeruva tootega. Kui inimesed saavad aru, et nad peavad oma vahenditest projekti täiendama, siis suurema tõenäosusega nad seda ei tee ning otsivad lihtsamat lahendust, mis neid projektiga väga ei seoks. Beta ja madalama versiooniga projekt lihtsalt kaotab kredibiilsust. Kuna dokumentatsioon ei sisaldanud endas tulevikuplaane, siis ei olnud väga mõtet loota, et kasutajad tootejuhi pähe näevad. Heal juhul kuuldi küla pealt, mida kõike veel plaanis teha on või küsiti otse.

Mida oleks saanud paremini teha?

Siin on 2 põhilist viga: disain ja kood oli ühte patta pandud ning tol hetkel tundus tootejuhile, et kommuuni saab luua vaid toimivale lahendusele.

Alustan esimesest ning ilmselgest probleemist, et disain ja kood ei olnud eraldatud. Kui disaini tööfailid olid kasutatavad, siis kuna need pandi ühte patta koodiga, liikus ka disain vaikimisi staatusesse: pre-alpha. Disain oleks pooliku dokumentatsiooni tõttu vabalt vähemalt Beta staatuses olla, kuid tööfailid disaineritele olid olemas. Suheldes disaineritega, siis oli neile just toimiv tööfail oluline. Kui tekkis küsimusi, siis sai alati kontaktisiku poole pöörduda. Kood oleks vabalt võinud pre-alpha edasi olla senikaua kuni sellega lõpuks korralikult tegelema oleks hakatud.

Dokumentatsiooni oleks saanud poetada oluliselt enam vihjeid, et see või too lahendus on arendamisel. Veelgi parem lahendus oleks olnud, kui oleks kindlad kuupäevad välja toodud. Kuupäevade väljatoomine oleks lisanud kredibiilsust ning survestanud nii tootejuhti kui teise projekti meeskonda. Loodetavasti oleks ka potentsiaalsed kasutajad enam lärmi löönud kui kuupäevad oleks mööda lastud ning nemad oma tahtmist poleks saanud.

Teine päris suur ahhaa moment mulle on kommuuni tegelikud võimalused (rääkides start-up mindsetist 🙂 ). Selleks, et kommuun tagasi hakkaks andma, ei pea toode ega teenus veel isegi mitte valmis olema. Piisab täiesti ideest, et inimesed kaasa mõtleks ning loodetavasti mõne aja möödudes leiab mõni neist inimestest ka ressurssi oma projektidest panustada ühisesse arengusse. Kommuuni kohtumistel oleks tulnud rõhutada pakutava väärtust, kuna tegemist on siiski kahepoolse porjektiga: sina aitad mind, mina aitan sind. Üks tugevaid väärtuseid on kas või kommuun ise, kus inimesed saavad oma kogemusi jagada.

Päris palju abi oleks olnud juba sellest kui kommuuni arendamisele oleks oluliselt enam rõhku pannud ning nö meediaplaani paika pannud. See oleks võimaldanud rajada võrgustiku inimestest, kes seda edasi oleks promonud ning ehk leidnud pika peale projekte, mis kas või natukene oleks saanud ka oma töödega projekti panustada.Neid mõtteid siia kirjutades tekib väheke tunne, et selleks, et saada ka riigisiseselt oma teenused toimima, tuleb iga teenust ehitada kui start-upi (vähemalt teenusega väga alguses olles).

Kokkuvõte

Punktidena, mida õppisin kommuunil baseeruva disainisüsteemi loomisest avalikus sektoris:

Sidusin disainisüsteemi arendamise olemasoleva projektiga – hakkasin hoopis teise projektiga tegelema.
Ei anna enda projektile saadud raha ära.
Kui kusagilt lubatakse mulle raha, siis tegelen selle summa reaalselt enda kontole saamisega – suuliselt võivad lubadused lennata siia ja sinna, aga oluline on see realiseerida ja kindlustada oma tagal.
Disainisüsteemi arendada üks komponent -> selle komponendi dokumentatsioon, mitte kõik komponendid -> lõpus dokumentatsioon. Viimase kahjuks räägib see, et kõik kokkulepitu kipub lihtsalt ära ununema, kui seda üheselt kohe üles ei kirjuta.
Kui on testimiseks eraldi partner, siis lasen tal testida ning arvamust avaldada. Alternatiivina saab vabavaralist koodi mõnes entusiastide grupis jagada, kes pilgu peale heidaks. Teine alternatiiv oleks teha üleskutse koolidele, kus ehk mõni õpilane, kes huvi ja kogemuste saamiseks, oleks nõus loodut katsetama.
Suheldes erinevate asutuste ja projektidega, siis sain aru, et riigis on nii avalikke kui ka vähem avalikke (loe: teadmus ja/või ligipääs infosüsteemile ainult teatud oskuste/kvalifikatsioonidega inimestel) kui ka asutuse siseseid teenuseid tohutult palju.
Võimalusi mingit infot näidata ja vahetada inimeste ja riigi vahel on hoomamatus koguses.
Disaini partnerid võiks nii kaua edasi mu kõrval olla, kuni arendus kestab, sest nägin korduvalt, kuidas arendaja loogika võib kohati laiema haarde võtta kui disaineri oma.
Riigi poolt pakutavad teenused peaks vaatama oma klienti sama pilguga nagu edukamad erasektori esindajad seda teevad. Keskendudes eelkõige kasutajale, seadustele ja pikale plaanile.
Disainisüsteeme omavad kõik suuremad ettevõtted just nimelt ühtse kasutajakogemuse tagamiseks, disainerite ja arendajate töö lihtsustamiseks ning ka loomulikult oma identiteedi müügiks. Miks ei peaks riik samu põhimõtteid omama?!
Avalikus sektoris on tihti tunne, et kui MVP ei ole kohe 100% kasutatav ning julged vähegi öelda, et tegemist on Beta või madalama versiooniga, siis ilmselt ei võeta seda projekti väga tõsiselt.
Selleks, et kommuun tagasi hakkaks andma, ei pea toode ega teenus veel isegi mitte valmis olema. Üks tugevaid väärtuseid on kas või kommuuni eksistents ise, kus inimesed saavad oma kogemusi jagada.
Et saada riigisiseselt oma teenused toimima, tuleb iga teenust ehitada kui start-upi (vähemalt teenusega väga alguses olles).