Renārs Jansons. Publicitātes foto
Mēs - pašvaldību vēlēšanu vērotāji - varam tikai nojaust, kas tonakt notika. To mēģina atšķetināt žurnālisti, vēlēšanu iecirkņu darbinieki, un brīžiem šķiet, ka arī paši vēlēšanu organizētāji.
Man sava darba specifikas dēļ ir padziļināta interese par visiem procesiem, kuru rezultāts ir kāda digitāla produkta izstrāde. Te gan jāpiebilst, ka ne es, ne uzņēmums, ko pārstāvu, nav bijis iesaistīts vēlēšanu organizēšanā vai to norisē un ar to saistīto IT risinājumu izstrādē. Tāpēc manā rīcībā ir tikpat daudz informācijas, cik lielākajai daļai sabiedrības. Tas, par ko es gribu runāt un arī iemesls, kāpēc uzskatu, ka nevar klusēt, ir -
pašvaldību vēlēšanu nedienas ir loģisks iznākums novecojušai pieejai digitālo produktu izstrādē.
Pirmajam solim jebkura digitāla produkta izstrādē vienmēr ir jābūt visu pušu sanākšanai kopā un vajadzību noskaidrošanai. Visiem kopā ir jāmeklē efektīvākās iespējas, kā ieceres realizēt, un arī jāplāno to īstenošana. Es, protams, ļoti ceru, ka tā tas notika arī šajā gadījumā. No otras puses, redzu, ka digitālu produktu izstrādē, tajā skaitā valsts pasūtījumos, tas tā vienmēr nenotiek. Tāpēc diezgan droši pieļauju, ka tas tā tomēr nav noticis arī šoreiz.
Pārāk daudz izmaiņu pārāk īsā laikā
Analizējot informāciju, kas izskan publiski, drīzāk noticis tā, ka ar konsultantu palīdzību ir tikušas aprakstītas prasības sistēmas izstrādei. Un atbilstoši sistēma ir arī izstrādāta. Ģenerālmēģinājums tās darbības pārbaudei jeb akcepttestēšana, saskaņā ar publiski pieejamo informāciju, varētu būt notikusi mēnesi pirms vēlēšanām. Ideālajā gadījumā to varētu darīt ātrāk, bet arī viens mēnesis pirms pasākuma ir gana ilgs laiks, lai salabotu nianses. Bet tiešām nianses.
Pašvaldību vēlēšanu gadījumā vairāk izskatās - akcepttestēšanā ir konstatēts, ka trūkst funkcionalitātes, kas ir kritiski nepieciešamas, lai sistēmu varētu izmantot. Vienīgais variants šādā gadījumā bija sagatavot tehniskajam izstrādātājam izmaiņu pieprasījumus, kas droši vien arī tika izdarīts.
Īsi pēc vai paralēli akcepttestēšanai, visticamāk, tika veikti arī slodzes testi, kas ir standarta procedūra. Bet, ja nepieciešama papildus funkcionalitāte, tas var nozīmēt arī papildus slodzi - jauna funkcija var sistēmu padarīt lēnāku vai tai var būt nepieciešams papildus resurss ārdarbības optimizēšanai. Visa šī procesa rezultātā - jaunas prasības, izmaiņu pieprasījumi, funkcionālā pārtestēšana, slodzes pārtestēšana, ja vispār bija - noved pie secinājuma dažas dienas pirms vēlēšanām, ka sistēma nav kārtīgi vai pareizi testēta.
Jāiesaista lietotāji
Kā šo situāciju labot un kā nepieļaut līdzīgas kļūdas nākotnē? Mēs savā praksē organizējam kopīgas darbnīcas, kurās piedalās pilnīgi visas iesaistītās puses. Arī cilvēki, kas sistēmas izmantos, nevis tikai viņu vadītāji. Tieši visu iesaistīto cilvēku sasaukšanas kopā vienā fiziskā vai virtuālā telpā un fasilitēta saruna dod iespēju visiem saprast projekta tvērumu (scope - no angļu val.) un plānu, riskus un izaicinājumus, kas šādā sadarbībā tiek laikus definēti.
Šāda veida digitālām platformām, kā tas ir vēlēšanu sistēmu gadījumā, efektīvāk pie rezultāta var palīdzēt nonākt vizuālais prototips, kuru var "klikšķināt" vēl pirms programmēšanas sākšanas. Tas ir ierasts digitālu produktu izstrādes posms. Prototipā var izmēģināt reālās iespējas, kas būs iestrādātas gala produktā. Un ir ļoti svarīgi to iedot izmēģināt lietotājiem. Tiem cilvēkiem, kas ar šo sistēmu pēc tam reāli strādās. Tā ir lieliska iespēja konstatēt trūkumus funkcionalitātē, vēl pirms ir sācies reālais darbs - investēts laiks un nauda programmēšanā. Pēc programmēšanas sākšanas jebkuras izmaiņas izdarīt ir ilgāk, dārgāk un riskantāk.
Pēc tam, kad kopīgās sarunas un prasību definēšana ir notikusi, manuprāt, viss tālākais ir par savstarpējo komunikāciju, paša procesa organizēšanu, atbildības uzņemšanos un arī drosmi laicīgi atzīt un pateikt, ka, iespējams, būs problēmas.
Es arī saprotu visas šajā procesā iesaistītās puses. Daudziem no viņiem nav nekādas izpratnes un pieredzes attiecībā uz tehnoloģiju projektiem. Tāpēc - kā gan viņi var zināt, ko jautāt? Par ko vajag pārliecināties? Analoģijās runājot, tas būtu tieši tāpat, kā man uzticētu uzraudzīt, piemēram, gēnu sekvencēšanas projektu. Vienīgais, ko es varēt darīt, ir pastāvīgi jautāt: "Vai viss ir kārtībā?" Jo neko citu nevaru pajautāt - neko no tā nesaprotu. Cilvēkam bez konkrētās nozares pieredzes projekta laika plāns ir tikai krāsaini klucīši ar datumiem un bultiņām.
Jāmaina IT projektu realizēšanas pieeja un jāakceptē objektīvas cenas
Publiskajos iepirkumos bieži vien tiek izmantots tā sauktais "ūdenskrituma" (Waterfall - no angļu val.) piegādes modelis. Tas sākas ar to, ka klients pats vai biežāk kāds piesaistīts uzņēmums izstrādā ļoti detalizētu tehnisko specifikāciju – precīzu uzdevuma aprakstu. Šis dokuments tiek “iesaldēts”, un uz tā pamata tiek izsludināts konkurss sistēmas izstrādei.
Taču "ūdenskrituma" modelis nav efektīvākais, pēc kura realizēt kompleksas IT sistēmas. Realitātē projektu gaitā neizbēgami parādās jauni apstākļi, nianses un idejas, ko nav iespējams paredzēt iepriekš. Tas ir kā sākt filmēt filmu pēc iepriekš sagatavota scenārija un aizliegt režisoram vai citiem veikt jebkādas izmaiņas filmēšanas laikā. Pat, ja kāda aina dzīvē neizskatās labi vai filmēšanas laikā prātā ienāk labāks risinājums.
Un vēl viena lieta, par ko runā gadiem un ko vajadzētu mainīt, ir zemākās cenas princips valsts iepirkumos.
Esmu pārliecināts, ka vismaz daļa ķibeļu digitālo produktu izstrādes procesā ir tieši tāpēc, ka pie pasūtījuma realizēšanas tiek nevis kompetentākie cilvēki, bet tie, kuri spēj piedāvāt zemāko cenu.
IT projektu plānošana vairs nenotiek tā, kā tas bija pirms 10 gadiem. Mēs dzīvojam dinamiskā pasaulē - ļoti daudzas lietas mainās ļoti ātri. Un agri vai vēlu pie šāda secinājuma būs jānonāk arī valsts pārvaldei. Jāstrādā dinamiski un atbilstoši jaunākajām tendencēm, pieejām un tehnoloģijām.
Autors ir CUBE Systems līdzdibinātājs