Tehnoloogiajuht: SKAIS2 allakäik oli kui sihita teekond

Virgo Riispapp Foto: Erakogu

Sotsiaalkindlustusameti infosüsteemi kaasajastamise projekti SKAIS2 hädad said alguse planeerimatusest, leiab tarkvaraettevõtte Thorgate tehnoloogiajuht Virgo Riispapp, kes on varem olnud ka politseis IT-süsteemide tellija.

«SKAIS2 stsenaarium on riiklike süsteemide arendamisel pigem reegel kui erand: kokku lepitakse tähtaeg, kuid tegelikult pole selget nägemust eesmärgist ehk sellest, mida selle aja jooksul valmis tehakse või kuhu tahetakse jõuda. Näitlikustades võib öelda, et soovitakse teele asuda, teadmata, kuhu kavatsetakse jõuda, mida on vaja ning kui raske või keerukas saab kandam olema,» leiab Virgo Riispapp.

Täiendavaid piiranguid lisab tema hinnangul ka  valitud riigihankemenetlus, mis välistab sageli vajaliku paindliku ja efektiivsema lähenemise.

«Ainuke õige viis, kuidas ideaalis nii tähtsaid ja mahukaid projekte nagu SKAIS2 teostatakse, on jagada projekt etappideks ehk väiksemateks osadeks,» arvab Riispapp.

Klient võiks tema hinnangul pöörduda teostaja poole idee ja ärianalüüsiga ning pakkujarolliks jääks teha digitootearendust – analüüsi, disaini ja arendust. Täpsed mahuhinnangud järgmisele etapile on võimalik sellise asjade käigu juures anda pärast iga etapi lõppu. Samas käivad tööd tsüklitega – näiteks disainietapist on võimalik minna tagasi analüüsi ja arendusest disainietappi.

«Veel täpsemaks minnes aitab tulemuslikkuse saavutada võimalikult väikeste funktsionaalsuste ja võimalikult väikeste sammude kaupa eesmärgi poole liikumine, kogudes teel olles pidevalt tagasisidet, et loodava lahenduse käigus vajadusel suunda muuta, riske maandada ja kahjusid kontrolli all hoida,» lisas ta.

Toote disainimisel on võimalik kogu loodava lahenduse arhitektuur ja äriprotsessi osised lahti võtta ja üles leida võimalused süsteemi efektiivsemaks muuta, seda  automatiseerimise ja erinevate integratsioonide kaudu. «Lihtsustatult on nutikas kasutada vähem tööjõu ja rohkem e-riigi poolt pakutavaid võimalusi panna arvutid rutiinseid ülesandeid täitma. Nii jääb inimestele vaba aeg, mida on võimalik kasutada sisuliste teemadega tegelemiseks.»

Lahenduse arhitektuuri loomisel saab Riispapi arvates tehnilise disaini ehitada väikeste teenuste kogumitele, mida üksikuna on lihtne muuta ja mis suhtleb teiste osistega standardsete masinliideste (API) kaudu. Selline lahendus teeb omakorda edasise haldamise kulu väiksemaks ja lihtsamaks. Kui mõni komponent ei rahulda enam kasvanud süsteemi vajadusi, siis on võimalik lasta sobival partneril see täiendada või asendada.

«Aga meeles tuleb pidada, et IT ja tehnoloogia on eelkõige vahend sisuliste (äriliste) eesmärkide saavutamiseks ning ei ole eesmärk omaette. Kuniks see nii pole, on tehnoloogia alati süüdi, kahjuks,» lisas ta.

Kokkuvõtteks, suurte projektide edukuse aluseks on Riispappi hinnangul:

•     Selge projekti eesmärk ja selleni jõudmise teekond ning projekti edukuse hindamise kriteeriumid, mis on kogu arendusmeeskonna eesmärgiks.
•     Tasakaalus arendus juhtmeeskond – olemas on nii tootejuht (äriline vastutaja), valdkonna tippjuht (sponsor), äripoole projektijuht, IT projektijuht.
•     MVP (Minimum Viable Product) lähenemine ehk alustada minimaalsest elujõulisest tootest  ja ehitada toodet funktsionaalsuste kaupa edasi. Näiteks maanteeamet lansseeris e-teeninduse esialgu vaid kahe teenusega.
•     Tootedisain kasutajamugavuse disainist, sisu ja äriprotsessideni. Esialgu hinnatakse ning teostatakse analüüsi ja UXi etapp, mille jooksul valmistatakse skemaatiliselt ette kõik süsteemi loogilised vaated, lepitakse kokku funktsionaalsused ja pannakse paika üldine projekti skoop.
•     Lahenduse arhitektuur peab olema paindlik ja võimalikult lihtsasti muudetav. Et oleks võimalik ebasobiv komponent vajadusel välja vahetada nii, et see ei mõjuta terviksüsteemi toimimist. Võti on siin mikroteenuste kasutamine ja teenusepõhine arhitektuur. Teenuste (API) loomisel ja uuendamisel on mõistlik kasutada versioneerimist.
•     Kasutatavuse analüüs ehk lõppkasutajate tagasiside süsteemile ja vajadusel järgmisesse arendustsüklisse muudatusvajaduste kirjeldamine.