Autor: Indrek Kald • 18. september 2019

Järgneb Lars-Erik Hioni kommentaar:

Riigikontroll avaldas eelmisel nädalal auditi, mille eesmärk oli välja selgitada, miks avaliku sektori tarkvaararendused ebaõnnestuvad. Muuhulgas selgus, et eesmärgid püstitatakse ja sõnastatakse valesti ja arenduse tellijad ei tea täpselt, mida nad soovivad. Teenusedisaini– ja arendusettevõtete jaoks on selline hinnang ränk, eriti arvestades asjaolu, et olukorra paremaks muutmine eeldab enamasti asjatundlikumat tellimust, mitte suuremat eelarvet.

A - IT-projekti õnnestumiseks ei piisa vaid IT-arendajaist

Veel kümmekond aastat tagasi oli levinud arusaam, et IT-projekte teostavad ainult IT-arendajad. Tänaseks on mõistetud, et lõppkasutaja, tellija ja arendaja vahel peab tegutsema lüli, kes kirjeldab projekti sisulised eesmärgid selliselt, et kogu meeskond mõistab täpselt, mida on vaja teha.

Selliseid n-ö IT-tõlke nimetatakse kord teenusedisaineriteks, kord kasutajakogemuse ekspertideks või analüütikuteks, aga igal juhul on tegemist spetsialistidega, kelle kaasamine suurendab tõenäosust, et kõik osapooled saavad projekti ülesannetest ja eesmärkidest sarnaselt aru ja suureneb sisemiste ja väliste kasutajate rahulolu. Seejuures peaksid sellised spetsialistid proovima mitte mõelda lõppkasutajate eest, vaid koos nendega.

B - Lõppkasutaja on kuningas

Avalik sektor on oma teenuste pakkumisel mõneti monopoli seisundis - kui pakutav teenus ei ole kasutajasõbralik, ei jää kasutajal muud üle, kui hambad ristis ennast arusaamatust teenusest läbi närida. Erasektoris valib klient lihtsalt konkurendi, kelle teenuse kasutamine on mugavam, loogilisem või kiirem.

Infoühiskonnas kasvavad kasutaja ootused kiiremini, kui organisatsioon sageli nendele vastata suudab. Selleks, et kliente mitte kaotada ja leida uusi, on oluline kasutajat tunda ning püsida tema ootuste kõrgusel.

Ka arendusprojektide puhul tuleb uurida kasutaja psühholoogiat, tuvastada tema ootused ja vajadused, unistused ja hirmud ning kogu arendusprotsessis prioritiseerida kasutaja eelistusi, mitte organisatsioonisiseseid takistusi.

C - Üheksa korda joonista, üks kord programmeeri

Kui juba projekti esimeses faasis (kasvõi paberil) koos kasutajatega läbi mõelda pakutava teenuse protsess tervikuna ning analüüsida, millisel kujul ellu viia kulukas IT-arendus, on võimalik eelarvet kontrolli all hoida või märkimisväärselt kokku tõmmata. Piiratud ressursside kontekstis kiputakse eelanalüüsi etappi vähe tähtsustama või seda pealiskaudselt ellu viima ning ei mõisteta, et eelanalüüsile kuluv ressurss on tühine võrreldes sellega, kui IT-projekt tervikuna ebaõnnestub.

Selgitus on lihtne - projekti eelanalüüsi faasis tuvastatud probleemi saab lahendada muudatustega projektiplaanis, arendusfaasis aga juba üpris kuluka tarkvara ümberkirjutamisega. Kui aga teenus on juba kasutajale kättesaadavaks tehtud, lisandub arendustöödele ka kommunikatsioonikulu ning kaalul on ka organisatsiooni maine kvaliteetse teenuse pakkujana.

Agiilset lähenemist saavad endale lubada tarkvaraprojektid, millesse vigade korral on muudatusi teha on lihtne ja kiire – avaliku sektori ülesehitus tervikuna sellist lähenemist ei soosi, sotsiaalkindlustusameti infosüsteemi ei saa kunagi arendada nagu idufirmat.

Teenusedisain koosneb läbimõeldud meetoditest ja praktikatest, mida õnneks üha rohkem rakendatakse nii arendusprojektides kui õpetatakse ka ülikoolides. Loodame, et järgmine riigikontrolli samateemaline audit annab rohkem põhjust rõõmustada ning kasutajakeskne arendamine ja sisemistesse reeglitesse ja pseudotakistusse kriitiliselt suhtumine saab alati ka Eesti avaliku sektori IT-projektide puhul normiks ja Eesti e-riigi lippu ei ole vaja poolde vardasse tõmmata.