E-riik vaagub hinge

Eesti kui e-riigi kuvand on üle maailma teada, selle loomisel ja levitamisel on tehtud head tööd. Kindlasti mõnda aega vastas see kuvand ka tegelikkusele, kuid enam pigem mitte. Viimati suure fiaskoga lõppenud SKAIS2 projekt võiks olla piisav hoiatus, et nii me enam jätkata ei saa: eesrindliku e-riigi kuvand on haihtumas.

Probleem algab sellest, kuidas tarkvaraarenduses riigihankeid tehakse. Praegu tehakse kõik hanked e-riigihangete keskkonnas, mille pakutav kasutajakogemus oleks vastuvõetav olnud ehk üheksakümnendatel. Keskkond, mis peaks riigihangete korraldamise tegema lihtsaks ja läbipaistvaks, ei tunnista isegi brauseri tagasi-nuppu (teade keskkonnast: “Kasutaja töö on peatatud andmestiku ebakõla tuvastamise tõttu. Palume mitte kasutada brauseri BACK nuppu.”). See on küll ainult asja nukker tehniline pool, mida annab parandada, aga hoopis keerulisem on lugu tarkvarahangete sisulise poolega. On viimane aeg midagi ette võtta, et tagada meie riigile jätkuv konkurentsivõime järjest kiiremini muutuvas tehnoloogilises maailmas.

 

Vahele jääb sageli ka üks väga oluline etapp -  konsulteerimine tarkvaraarendajatega. Enamasti puudub hankijal endal piisav pädevus tarkvaraarenduse valdkonnas. Miks ei võiks näiteks enne konkursi väljakuulutamist toimuda hankekeskkonnas avalik foorum, kus hankija saaks hanke koostamisel nõu ja soovitusi tarkvaraarendusvaldkonna spetsialistidelt? See parandaks oluliselt hanke sisulise poole kvaliteeti, aitaks koostada pädevad nõuded ning välistaks paljude veidrate ja kahjulike nõuete (k.a lausrumaluse) jõudmise hankesse.

Ühtlasi tagaks see parema läbipaistvuse hangete korraldamisel. Praegu aga näeme liiga tihti hankeid, mis seavad põhjendamatuid ja isegi kahjulikke tingimusi, näiteks arendusmeeskonna komplekteerimise kohta, mis ei kuulu üldse hankija pädevusse; lisaks sisaldavad hanked tihti vigaseid või puudulikke ülesandepüstitusi. Kui teostust pakkuvad pooled näevad hanketingimusi alles siis, kui need on juba kinnitatud, ei ole võimalik saada parimat võimalikku lahendust.

Riigi kodanikele suunatud infosüsteemide lähtekood ja arendus peaksid olema avatud. Riigi tarkvara on põhimõtteliselt meie kõigi oma, see ei sisalda ka ärisaladusi, mida peaks varjama või kaitsma. Lähtekoodi avaldamine suurendaks üleüldist läbipaistvust ja usaldatavust, võimaldaks teostada paremat järelevalvet ning aitaks välistada ka n-ö arendaja lõksu sattumise (s.o tellija jääb arendajast tahtmatult sõltuvaks).Avatud lähtekood annab kõigile huvitatutele ülevaate koodibaasist. Võimalik on hinnata selle tehnilist taset ja korrektsust ning anda vajadusel tagasisidet (näiteks saab juhtida tähelepanu, kui ei järgita häid praktikaid või leitakse mõni tõsine turvaviga jms). Mis peamine, soovi korral on võimalik igal asjast huvitatul ka ise panustada.

Maailma praktika näitab, et seda tehakse tihti isegi täiesti tasuta. Praegu on enamik e-riigi süsteemid kinnised (lähtekood pole avatud), mistõttu keegi teine peale arendaja enda ei tea, kui korrektselt ja kvaliteetselt on tarkvara arendatud, kas see on tehtud jätkusuutlikult, kui turvaline see on jne. Kindlasti ei suurenda selline kinnine süsteem kodanike usaldust e-riigi lahenduste vastu. Õnneks on ka positiivseid näiteid, nagu X-tee, mida arendatakse avatud lähtekoodiga ja ka koostöös Soomega. Loodan, et tulevikus saab see pigem reegliks, mitte ei jää erandiks.

Siit jõuame järgmise puuduseni avaliku sektori tarkvaraarenduses: järelevalve. Ehituses on meile iseenesestmõistetav, et selle juurde kuulub ka järelvalve, aga millegipärast ei peeta seda vajalikuks riigi infosüsteemide arendamisel. Mingil määral oleks abi varem käsitletud lähtekoodi avaldamisest – see distsiplineeriks arendajaid, sest nende kood oleks siis  avalikkusele hindamiseks väljas. Konkureerivad arendajad ei jätaks kasutamata võimalust puudujääkidele vihjata. Et tagada suuremat kindlust, oleks mõistlik tarkvaarenduste järele süsteemselt valvata.  

Praegune hankesüsteem soosib tarkvara arendamist pigem ebatõhusa ja riskantse koskmudeli järgi. See eeldab kogu aastate jooksul arendatava süsteemi täielikku etteplaneerimist ja seega tohutut ressurssi esialgsele planeerimisprotsessile, välistab paindlikkuse, vahepealsed muudatused ning üleüldse on arendusprotsessina kinnine ja tellija jaoks nähtamatu kuni süsteemi kättesaamiseni aastaid hiljem, mida aga pahatihti ei juhtugi. Suur tükk ajab suu lõhki. Selline lähenemine võis sobida ehk üheksakümnendatel, kui ootused  infosüsteemidele olid oluliselt väiksemad ja arendatavad süsteemid olid lihtsamad, internetki oli veel lapsekingades.

Riigihangetes oleks vaja rohkem paindlikkust. Modernses järjest kiiremini muutuvas maailmas tuleks tarkvara arendamisel eelistada metoodikat, mille edu ei eelda kindla plaani järgimist. Selleks sobib väga hästi selle sajandi alguse tekkinud agiilne lähenemine. Agiilsel arendamisel keskendutakse alati kohe sellele, mis on antud hetkel kõige olulisem. Olulisuse defineerib tellija sõltuvalt talle olulistest kriteeriumitest. Näiteks võivad nendeks olla ressursi kokkuhoid, kasumi teenimine, seadusest tulenevad nõuded jms.

Agiilne tarkvaraarendus mõistab muutuvaid olusid – nii nagu areneb pidevalt maailm, peab seda suutma teha ka tarkvara. Arendusi teostatakse väiksemate funktsionaalsete osadena, mis kõik on iseseisvalt kasutatavad. Funktsionaalsusi tarnitakse pidevalt ja võimalikult lühikeste perioodide tagant, tarnitav kood peab olema kvaliteetne, testitud ja kasutamiseks valmis. Arendusprotsess ise on tellijale pidevalt jälgitav, klient on protsessi aktiivselt kaasatud ja omab ülevaadet projekti olukorrast. Nagu on kirjas agiilse tarkvaraarenduse manifesti põhimõtetes: “Agiilse tarkvaraarenduse protsessid soodustavad jätkusuutlikku arendust. See tähendab, et projektiga saab samas tempos jätkata määramata aja jooksul. Lihtsus – ebavajaliku töö tegemata jätmise kunst – on väga oluline. Edu peamiseks mõõdupuuks on töötav tarkvara.”

Kui arendaja ei peaks mingil põhjusel toime tulema esitatud väljakutsetega (asjad venivad põhjendamatult, tarnitud funktsionaalsus on ebakvaliteetne vms) või ilmnevad mingid muud takistavad tegurid, selgub see agiilse arenduse puhul juba lühikese aja jooksul, mis annab võimaluse kliendil reageerida enne, kui on juba liiga hilja. Selle tulemusena on tellija riskid võrreldes koskmudeliga tunduvalt väiksemad.

Agiilne lähenemine eeldab aga ka tellija valmisolekut. Eelkõige tähendab see, et nii tellija kui teostaja tegutsevad ühtse tugeva meeskonnaga, kus tellija annab vajalikku sisendit vajalikul hetkel ning arendaja kasutab oma arenduskompetentsi antud eesmärgile jõudmiseks parimal võimalikul viisil.

Agiilne arendus nõuab keskmisest rohkem ka tarkvaraarendajatelt. Lisaks tugevale arenduskompetentsile peavad agiilsed arendajad olema tugevad meeskonnatöös. Valdkonna spetsialistid ja tarkvaraarendajad peavad töötama tihedalt koos kogu projekti vältel.

Riigi tarkvara tuleb hakata arendama jätkusuutlikult. Tarkvara peab suutma areneda koos oludega. Selleks on vaja riigi tarkvaraarenduses rohkem avatust ja tuleb muuta lähenemist. Alustada võiks riigi infosüsteemide lähtekoodi avaldamisega. Traditsiooniline koskmudel on oma aja ära elanud, maailm on muutuv ja muutuda peab suutma ka tarkvara. Riigil on viimane aeg liikuda uude sajandisse ja hakata tarkvara arendama agiilselt.

Autor: Karel Golberg