Kasutajatugi

Vastus:

Väga sageli ei tea süsteemi tulevased kasutajad ja selle arenduse eest maksjad (ei pruugi olla üks ja sama isikute ring), milline täpselt peaks uus süsteem olema. Tulemuseks võivad olla lepingud, mida on ebareaalne täita. Sõltub tellija poolsete läbirääkijate tarkusest, kas nad suudavad lepingusse suruda piisavad hilinemisest tulenevad sanktsioonid ja sellega motiveerida ka arendajaid andma realistlikke lubadusi. Nagu ütleb Marek Helm, siis tellija peab olema tark. Tarka tellijat ei saa ebareaalsete lubadustega petta.
Lehmani tarkvara evolutsiooni seadused (vt "Andmebaasid I", teema 1) ütlevad, et tarkvara funktsionaalsus ja keerukus ajas suureneb ning mingil hetkel jõutakse punkti, kus lihtsam on olemasoleva süsteemi edasise muutmise asemel see nullist uuesti kirjutada e puhtalt lehelt alustada. Samasse seisu jõuti sotsiaalkaitseameti infosüsteemiga SKAIS, mille puhul selgus 2013. aastaks, et olemasolev tarkvara uut töövõimereformi toetada ei suuda ning tuleb alusada selle tarkvara uue versiooni SKAIS2 loomisega.
Suuri süsteeme tuleks arendada väiksemate alamprojektide või äriliselt loogiliste osade (nt ühe teenuse) kaupa. Seda näeb ette strateegilise analüüsi metoodika (vt "Andmebaasid 1", teema 7). Seda soovitab tarkvaraettevõtte Helmes arendusjuht Raul Ennus (siin) ja tarkvaraettevõtte Thorgate tehnoloogiajuht Virgo Riispapp (siin). Sellest saadi lõpuks aru ka SKAIS2 arendamise juures – kui algselt sõlmiti leping terviksüsteemi arendamiseks, siis 2017. aastal, enne arendajaga lepingu katkestamist, mindi üle osade kaupa arendusele. Samuti kirjutab Aivar Pau, et SKAIS2 arendamise uue hanke puhul jagatakse see tükkideks, kusjuures iga arendusetapp puudutab ühte teenust. Selleks tükeldatakse ka kogu süsteemi arhitektuur osadeks nagu üldkasutatavad komponendid, integratsioonikiht, ärifunktsionaalsused, arveldusmoodul ja kasutajaliidesed. Aivar Pau kohaselt sellist tükeldust varem ei tehtud. Süsteemi tükeldamist alamosadeks ja alamosade arendamise jaoks eraldi projektide algatamist näeb samuti ette strateegiline analüüs (vt Andmebaasid I, teema 7). Sellise väiksemate osade kaupa arendamise korral võivad süsteemi erinevate osadega töötada erinevad arendusfirmad. Süsteem ei valmi mitte korraga (suure pauguga), vaid osade kaupa. Väiksematest osadest nagu Lego klotsidest kokkupandud süsteemi korral on lihtsam ja odavam üksikuid osi parandada ja välja vahetada.
Tarkvara arhitektuur on oluline ja aitab tagada, et see klotsidest moodustis oma raskuse all kokku ei kuku.
Suurte projektide korral on hea mõte lasta arendajatel teha proovitöö ning arvestada hanke võitja valimisel ka muude kriteeriumitega kui kõige madalam hind. Projekti prioriteetide kolmnurk (vt "Andmebaasid I", teema 7) ütleb, et kui eesmärgiks on madal hind ja kiire valmimine (nagu SKAIS2 puhul alguses see oli), siis ei saa tulemus olla kõrge kvaliteediga. Muide, sellist valikut, kus saab saavutada vaid maksimaalselt kaks eesmärki kolmest tuntakse trilemmana.
Riiklikus sotsiaalvaldkonnas, kus kõikvõimalikud reeglid ja maksete suurused sõltuvad poliitikute suvast, on nõudmised äärmiselt muutlikud. See sai SKAIS2 arendamisele lõpuks saatuslikuks. Selliste süsteemide arendamisel tuleks kindlasti kasutada iteratiivset arendust (vt "Andmebaasid II", teema 1). Sama soovitab ka Helmese arendusjuht Raul Ennus (siin).
Arvestades nõudmiste muutlikust tuleks luua tarkvara, mida kasutajad saavad uute reeglite kehtima hakkamisel ise kohandada e konfigureerida, mitte ei pea kogu aeg tellima arendajatelt uusi arendustöid. Sellised süsteemid võivad olla andmetega juhitavad (vt "Andmebaasid II", teema 1). Samas tuleb ette vaadata, et paindlikuse tagaajamisega üle ei pingutata ning ei lisata sellega süsteemi asjatut keerukust. Tarkvara peaks olema hästi evolutsioneeritav. Samas seda soodustav lähenemine, mille kohaselt on süsteemi igal alamosal (teenusel/mikroteenusel) oma andmebaas (rakenduse andmebaas), mille vahel võib ka olla andmete dubleerimine, ei ole hästi kooskõlas riiklike infosüsteemide nõuete ja vajadustega.
Arendusse tuleks võimalikult varakult kaasata süsteemi lõppkasutajaid ja hakata neile tagasiside saamiseks iteratiivselt süsteemi uusi versioone esitlema. Kasutajad saavad anda tagasisidet nii süsteemi kasutatavuse kui ka funktsionaalsuse kohta. Suurte riiklike süsteemide puhul võib kasutada fookusgruppe. SKAIS2 puhul tuleks kaasata nii igapäevaseid makseid tegevaid ametnikke kui ka maksete saajaid. Oluline on võimalikult varakult ja regulaarselt saada lõppkasutajate tagasisidet, tagamaks, et uues süsteemis oleks neile kõik lihtne ja mugav. Seda ütlevad nii TransferWise'i arendusjuht Alvar Lumberg (siin) kui Helmese arendusjuht Raul Ennus (siin).
Selle asemel, et iga allüksus (riigi puhul näiteks ministeerium) põlve otsas oma süsteemi arendaks, võiks luua ühissüsteeme üle erinevate allüksuste haldusalade. Sellisel viisil on ka tellijate ja juhtide summaarne ajupotensiaal suurem ja ehk tuleb paremini välja. Riik viib sarnase põhjendusega läbi haldusreformi – väikesed haldusüksused jäävad igasuguste suurte projektidega üksi hätta, vaja on jõud ühendada.