A. Mikulskis. Kodėl valstybinės sistemos tokios „kreivos“
Nejaugi niekam nekyla klausimas, kaip verslas su dešimtis kartų mažesniu biudžetu sugeba susikurti daug patogesnes sistemas, kurių išdėstymas lyg anksto nuspėja, ko ieškai, siūlo populiariausias kategorijas čia ir dabar, viskas parašyta žmogiška kalba ir yra pasiekiama per kelis spragtelėjimus?
Pagalvokite apie populiariausias Lietuvos e.parduotuves, kurios klientų turi beveik tiek pat, kiek Lietuvoje yra registruotų e.sveikatos pacientų. Arba bankus. Kad ir skelbimų portalus.
Tipiniame valstybiniame tinklapyje turi raustis po voratinklius, kol atrandi tą primityviai sukurtą funkciją.
Taip, valstybinėse daugiau integracijų, saugumo reikalavimų, bet tai niekaip nepateisina prasto dizaino.
Dizainas yra tai, kaip lengva naudotis svetaine. Kalbame ne tiek apie grožį, kiek apie patogumą.
Būkime teisingi ir pripažinkime, kad yra ir puikių valstybinių sistemų: VMI, „Sodra“, „Mano vyriausybė“. Visgi kol kas didžioji pyrago dalis priklauso gnomsistemėms.
Su valstybiniais projektais dirbame jau ne vienerius metus, per šį laiką pastebėjau kelis dėsningumus.
Taigi, kodėl dauguma valstybinių sistemų tokios prastos:
1. Biurokratų baimė klysti. Atsakomybės vengia dauguma valdininkų, todėl nieko įspūdingo ir neįgyvendina. Tą matome ir iš aukštosios lygos politikų – veržlūs, atvirai kalbėti ir sprendimų priimti nebijantys ministrai nuverčia užšalusius kalnus, įgyvendina projektus, kurių pirmtakai negebėjo įgyvendinti dešimtmečiais. O atsargiai prieš kameras renkantys žodžius daro privalomąjį minimumą ir primena vadinamuosius bebrus. Gerus valdininkus atpažinsi iš to, ar baigus tarnybą juos pagriebia lyderiaujantys verslai.
2. Sutarčių nelankstumas. Lengviau Seime pakeisti įstatymą, nei su valstybine įstaiga sutarti termino pratęsimą. O jei bedirbant tiek tiekėjui, tiek įstaigai paaiškėjo, kad vienas iš reikalavimų nereikalingas, neprotingas arba net sugadinsiantis sklandžią vartotojo patirtį, tiekėjas greičiausiai vis tiek turės jį atlikti, kad „atitiktų raidę“. Įstaiga taip pat griežtai kontroliuoja, kas tavo komandoje gali dirbti, kas ne. O juk neesminiams sutarties keitimams galėtų būti laisvė.
3. Biurokratiška programuotojų atranka. Joks verslas neatsirenka darbuotojų ar tiekėjų taip, kaip viešasis sektorius. Viešasis koncentruojasi į dalykus, kurie neparodo tikrųjų žinių: sertifikatus, įrodančius ne programavimo įgūdžius, o kad išmokai tos riebiai uždirbančios ir nuo praktinio pasaulio atitrūkusios akreditavimo įstaigos terminologiją. Dievaži, kai kurios kursų mokyklos, „mokančios“ programavimo ar vartojo patirties (UX) pačios turi „@takas.lt“ laikų dizainą.
Bet ei, pasak valstybės, sertifikatas yra geriau nei reali programavimo patirtis banke ar versle. Šituo klausimu peržiūrėjau kelių šimtų HR specialistų apklausas – nė vienas iš jų darbo pokalbiuose neprašo iš programuotojų sertifikatų. Kodėl įstaigos negali tiesiog prašyti realios patirties ir projektų pavyzdžių, niekas neatsako.
4. Dizaino ir programavimo darbai sumalami į vieną. Pirmiausia turi būti dizaino, ir tik tuomet sekti atskiras programavimo konkursas. Beveik visada įstaigos užsakinėja dizainą ir programavimą iš tos pačios įmonės. Vadinasi, jei sutartis numatyta metams, pirmus 6 mėnesius bus derinamas dizainas, kol jis praeis pro visus atsakomybės vengiančius raštų karaliukus, tuomet į nugarą pradės šnopuoti terminas, tad ne visai išdirbtas dizainas bus paskubomis programuojamas.
Jei pasidomėsite lankomiausiomis pasaulio svetainėmis, kaip „Google“ ar AirBnb – visos pirma susikuria dizainą ir prie jo pritaiko funkcionalumą, o ne atvirkščiai. Vadinasi, ir įstaigai derėtų pirma skelbti UX konkursą, ir tik po jo kurti reikalavimus programavimui. Galų gale, taip ir programuotojams bus lengviau suprasti įstaigos lūkesčius.
5. Gerų IT projektų vadovų neturėjimas. Čia aiškiai pamatysim, kad įstaigose, kuriose yra 2 sąlygos: dideli atlyginimai ir laisvė klysti, dirbs veržlūs ir sėkmingi projektų vadovai, įgyvendinantys dideles reformas ir atnaujinimus. Šios dvi sąlygos būtinos.
Gerą sistemą sukurti tikrai nėra lengva. Reikia prasiskinti kelią per prieigų džiungles, neužlipti ant nepataisytų klaidų minų ir perstatyti senų „legacy“ technologijų griuvėsius. Egzistuoja begalės rizikų, kintamųjų ir nežinomųjų. Bet atsižvelgiant į išvardytus 5 punktus tai pasiekiama ir jau įrodyta.
Įžvalgos autorius – Arnas Mikulskis, sudėtingų sistemų programavimo įmonės Slyva.lt įkūrėjas
