Kui USA arvutiteadlane Winston W. Royce 1970. aastal avaldatud artiklis "Suurte tarkvarasüsteemide arenduse juhtimine" üht võimalikku tarkvaraarenduse mudelit kirjeldas, jõudsid paljud lugejad küll artiklis toodud teise jooniseni, mida tänapäeval tuntakse koskmudelina, kuid mitte koheselt selle all toodud hoiatuseni: "Ma küll usun sellesse ideesse, kuid ülalkirjeldatu juurutus on riskantne ning soodustab ebaõnnestumisi". Viimase ligi 50 aasta kogemus toetab tema hinnangut.

Project Management Institute'i (PMI) 2019. aasta andmetel ebaõnnestus täielikult 15 protsenti kõikidest uuritud projektidest. Kuna ametlikult täielikuks ebaõnnestumiseks kuulutamisega kaasnevad (ka kõrgematel ametikohtadel olevatele) osalistele sageli ettepanekud jõukohasema ameti otsinguteks, ollakse sellise hinnanguga ilmselt pigem ettevaatlikud.

Sama aruande kohaselt läks üle aja 49 protsenti ning üle eelarve 43 protsenti projektidest; tegemist on osaliselt kattuvate kategooriatega. Lõpuks siiski eesmärgipäraseks ning kasu toovateks hinnati 68 protsenti projektidest, mis liigutab sisuliselt ebaõnnestunud projektide osakaalu 32 protsendini.

Kuigi rangelt koskmudeli järgi toimuvat tarkvaraarendust kohtab tänapäeval pigem harva, on arendusmaastik täis erinevaid variatsioone uudissõnade sädeleva kihiga kaetud ning fanfaaride saatel "edukalt" juurutatud ebaefektiivsetest värdmeetoditest.

2001. aastal avaldatud Agile Manifesto järgne tarkvaraarenduse maailm on põrkunud paljude takistuste vastu ning mitmeid neist kohtame ka avalikus sektoris. Üheks peamiseks takistuseks on järjekindel ebasobivate meetodite kasutamine.

Projektijuhtimine vs. tootearendus

Projektipõhine lähenemine on üks enimlevinud töö haldamise viise. Projekti definitsiooni juurde kuulub reegel, et projektid on ajutised ning igal projektil on kindel algus ja kindel lõpp.

Kogemus on näidanud, et veebipõhise osisega tänapäevase tarkvara arendamisel on see reegel täidetud harva, ometigi käsitleme me selliseid algatusi prokrustesliku järjekindlusega siiski just projektidena.

Selline lähenemine on stressirohke nii tellijale kui arendajale ning toob endaga kaasa märkimisväärse ebaefektiivsuse. Tsükkel analüüs-arendus-juurutus-hooldus satub igas etapis konflikti tarkvaraarenduse reaalsuse, inimeste kannatlikkuse ning eelarvega.

Põhjus pole mitte selles, et projektijuhtimine oleks põhimõtteliselt  väär lähenemine töö haldamiseks, vaid selles, et projektijuhtimine ei ole universaalne lähenemine igas võimalikus olukorras.

Agiilsete arendusmeetodite edukas kasutuselevõtt ei tähendanud ettevõtete jaoks mitte pelgalt varasema paradigma kontekstis "kiiremini ja rohkem" tarnimist, vaid olulist paradigmamuutust. Teatud tüüpi algatusi asuti käsitlema toodete, mitte projektidena.

Selle muutuse käigus hääbus ka paljudes olukordades ebaloomulikuna tunduv ning tihti mittetoimiv "IT ja äri" dihhotoomia, mille raames olid juurdunud mitmed laialt levinud, kuid segadusttekitavad väljendid – näiteks "IT-projekt".

Jah, loomulikult on olemas ka IT-projektid, mis tihti keskenduvad olemasolevate tehniliste lahenduste ühekordsele parendamisele, kuid suuremahulised, tervet organisatsiooni läbivad olulise tarkvaralise osisega algatused pole seda teps mitte.

Agiilse lähenemise üheks peamiseks eduteguriks on osapoolte vaheline tihe koostöö. Tootejuht on selles mudelis tihti meeskonna liige, mitte väljastpoolt meeskonda tellimusi esitav roll.

Agiilses tarkvara tootearenduses algab toote elutsükkel ideest ning lõppeb olukorras, kus toodet enam ei kasutata. Kõik vahepealsed tegevused – analüüs, arendus, testimine, tarnimine, õppimine, parendamine – toimuvad järjekestvalt, mitte rangelt etappidesse jagatult. Kaob arendus vs hooldus vaade, mis tihti niikuinii reaalsust ei peegelda. Uue funktsionaalsuse tarne ei vaja veebipõhise tarkvara puhul enam uue versiooni CD-dele (või diskettidele, eks) salvestamist ning karpi pakendamist.

Olid ajad, kui tarkvaraarendus käis järjestikuste projektidena, sest nii oli mõistlik. Enamike tänapäevaste algatuste jaoks on see aeg minevikus.

Eesti avaliku sektori tarkvaraarenduse koordineerimisvõimetusest

Riigikontrolli aruandes on toodud välja mitmeid kokkuvõtteid nii ebaõnnestumiste kui ka õnnestumiste põhjuste kohta ja samuti soovitusi edaspidiseks. Peab tunnistama, et kirjeldatud problemaatiline olukord on 2019. aasta ning Eesti kontekstis pettumust valmistav.

Jättes kõrvale selle, et mitte-projekte jätkuvalt projektidena käsitletakse ning et tulemustele (outcome) mitte väljunditele (output) keskenduv ning edukaks projektijuhtimiseks hädavajalik programmijuhtimine näib sama uuendusliku ideena kui "IT ja äri" koostöö, on ehk kõige nukrakstegevam järgmine lõik:

"Asutustel ei ole selge, kas Euroopa Liidu (EL) toetusraha kasutamise reeglid võimaldavad tarkvaraarendustes rakendada agiilseid meetodeid. […] Seni ei ole Majandus- ja Kommunikatsiooniministeerium välja selgitanud, millised on võimalused rakendada agiilseid arendusmeetodeid ELi toetusraha kasutamise korral, ega vajaduse korral nõustanud toetuste taotlejaid nende meetodite kasutamisel."

Nii riigiasutused kui ka tarkvaraarendusettevõtted on selle probleemiga silmitsi seisnud juba viimased 15 aastat. Ka olukord, kus "[…] ei küsitud sageli IT-üksuselt või -asutuselt õigusaktide muudatuste rakendamiseks infosüsteemides selle aja ega maksumuse kohta hinnangut" on vähemalt sama vana.

Kuigi näib, et mõnel juhul on konkreetsed asutused leidnud enda jaoks kuigivõrd toimiva lahenduse, võib riigikontrolli aruandes väljatoodud märkusi kahjuks siiski näha hävitava hinnanguna majandus- ja kommunikatsiooniministeeriumi võimekusele koordineerida riigi IT arendus- ja parendusalgatusi.

On selge, et ministeerium ei ole eelnevate aastate jooksul enda rolli lahti mõtestanud ega edukalt täitnud. Agiilsed tarkvaraarenduse meetodid olid nii mujal maailmas kui ka Eestis kasutusel juba mõnda aega enne seda, kui me Euroopa Liiduga ühinesime.

Tarkvara arenduste "peamised edutegurid"?

Aruandes toodud projektide edutegureid analüüsides jääb aga mulje, et mõnede projektide edu on saavutatud pigem hoolimata mõnedest neist soovitustest ja lähenemistest, mitte tänu nendele.

Näiteks on soovitus "Enne tarkvara arendustega alustamist tuleb kirjeldada ja optimeerida põhitegevuse protsessid" fantastika valdkonda kuuluv, eriti kui seda kombineerida tähelepanekuga, et "Arendusprojektide tõhusat elluviimist takistavad muudatused, mis tehakse arenduse ajal õigusaktidesse".

Selleks ajaks, kui protsessid kirjeldatud (ja hoidku selle eest, et paberil optimeeritud, nagu tihti kipub juhtuma), on reaalsus juba muutunud. Reaalse kliendiväärtuse loomine lükkus selle protsessiga aga 6-12 kuud edasi, optimistlikult rääkides.

Alustada tuleb taotletavate eesmärkidega kirjeldamisega kõikide sidusgruppide lõikes, misjärel on võimalik kitsendusi (näiteks seadusandlus ja selle muutumissagedus) analüüsides võimalik välja pakkuda lahendusvariante, mis võiksid potentsiaalselt aidata kaasa nende eesmärkide saavutamisele.

Seda kõike ei saa teha "ainult IT" või "ainult äri" üksinda ning kõnealused lahendusvariandid pole "IT lahendused", vaid tervet organisatsiooni puudutavad lahendused, mille käigus muuhulgas ning pikema aja jooksul optimeeritakse ka põhitegevuse protsessid – koostöös arendaja, peakasutaja, lõppkasutajate ning partneritega.

Ka soovitus "Regulaarselt (soovitatavalt kord aastas) tuleb küsida infosüsteemide kasutajatelt tagasisidet infosüsteemide kasutatavuse ja nendega rahulolu kohta ning kasutada seda infot uute arenduste planeerimisel" muudab rakendamise korral sisuliselt võimatuks agiilsete arendusmeetodite kasutamise. Tagasiside peab olema järjekestev ja dünaamiline, mitte kord-aastas-episoodiline.

Projektide planeerimise võimalikkusest

Raportis toodud väide, mille kohaselt "Tarkvaraprojekti edu sõltub enamasti sellest, kui põhjalikult on projekt ette valmistatud ning kui hoolikalt projekti plaani järgitakse", on küll sisuliselt korrektne, kuid praktiliselt problemaatiline.

See väide põhineb eeldusel, et iga projektina vormistatud algatuse puhul on põhimõtteliselt võimalik koostada täpne projektiplaan ning et algatuse arenduse jooksul on põhimõtteliselt võimalik sellest plaanist kinni pidada.

Projektide puhul me teame võrdlemisi täpselt seda, mida ja kuidas teha ning kui palju aega ja raha selleks kuluda võiks – kõike seda kokku lepitud lubatud hälbe piirides.

On aga palju algatusi, mille puhul see info on puudulik. Lahendused, mida ehitame esimest korda. Lahendused, millele seatud nõuded on ebaselged ning ajas kiirelt (ja potentsiaalselt drastiliselt) muutuvad. See, et seadusandlus muutub, ei tohiks ühelegi teenekale koordineerimisülesandeid täitvale riigiametnikule üllatusena tulla. Lahendused, mille puhul pole "what does good look like" (e k "kuidas hästitehtu välja näeb") osas konsensust, selgust või üldse aimu.

Sedasorti algatuste puhul muutub "põhjalikult ette valmistatud" projektiraamistik kitsendavaks ja valulikuks teguriks, mis kombineeritult "ükskõik milliseks meie vajadused lõpuks osutuvad, täpselt sellise lahenduse me saamegi" utopistliku lootusega lükkab meie projekti suure tõenäosusega sinna 32 protsendi ebaõnnestunud projektide kategooriasse.

Kõik, mis arenduseelarvega tuleb, ei ole veel projekt

Riigikontrolli aruanne toob väga tänuväärselt välja tähelepaneku, et "Igal tarkvaraarenduse mudelil on oma eelised ja puudused ning enamasti ei saa öelda, et mõni asutus peaks oma arendusprojektis kasutama tingimata mõnda kindlat mudelit", kuid seob selle samas kohe mõistega "projekt".

On algatusi, mille puhul analüüsivajadus on väike ning täpne planeerimine on lihtne – siinkohal sobib projektipõhine lähenemine. On algatusi, mille puhul tuleb analüüsile oluliselt rohkem tähelepanu pöörata, kuid realistliku projektiplaani koostamine on tänu ekspertide kaasamisele siiski võimalik – ka siinkohal sobib projektipõhine lähenemine.

Nende algatuste puhul aga, kus teadmatuse tase on kõrge või küsimusele "kuidas" on mitmeid koherentseid kuid vastukäivatena näivaid vastuseid, ei ole projektipõhine lähenemine mõistlik valik.

Pelgalt ekspertide teadmistel ja kogemustel põhinevast analüüsist ei piisa – süsteemi paremaks mõistmiseks on tarvis eksperimente ning me räägime siin päevadest ja nädalatest, mitte kuudest ja aastatest.

Õpitu põhjal saab agiilsete arendusmeetodite abil asuda samm-sammult ja kohati risti-rästi ekseldes Suurt Süsteemi arendama, arvestades sellega, et keegi veel ei tea (ja ei saagi teada!) milline täpselt see Suur Süsteem välja nägema hakkab.

Kohati nimetatakse sellist samm-sammult lähenemist Minimum Viable Product, kuid kuna see mõiste on viimaste aastate jooksul kahetsusväärselt ära lörtsitud, soovitan vastavasisulist kirjandust ning konverentsiettekandeid teatava ettevaatlikkusega käsitleda.

Kas saaks paremini?

Aruandes välja toodud peamised kitsaskohad ei ole mitte ühe asutuse spetsiifilised, vaid demonstreerivad ulatuslikumaid ning põhimõttelisi probleeme Eesti avaliku sektori IT süsteemide arendamise koordineerimisel. Vastavasisulise võimekuse suurendamiseks ei piisa sellest, et väga-väga tahta või sagedamini sõnavõttudega esineda.

Ülesanne välja mõelda, kuidas riigi IT-süsteemide arendust oluliselt määral paremuse poole liigutada, lasub majandus- ja kommunikatsiooniministeeriumil. Seninähtu ja –kogetu põhjal võib oletada, et efektiivsete lahenduste leidmiseks vajab praegune tõsiste puudujääkidega lähenemine märkimisväärset ümberkorraldust.

Hetkel tundub, et ministeeriumid ning nende allasutused on jäetud omapäi ning majandus- ja kommunikatsiooniministeerium näeb enda rolli määruste esitaja, reeglite kehtestaja ja sõrmega vibutaja, mitte koordineerija ning abistajana.

Jäädes lootma, et pelgalt parem projektijuhtimise võimekus lahendab kõik olulised probleemid, mis aruandes välja toodud, kulutame järgmised kümme aastat potjomkinlikule standardite ja määruste koostamisele vaid selleks, et lõpuks taaskord "üllatuslikus" olukorras maanduda.

Riigi IT-arenduse koostöövõime parandamine ei ole vaid IT-teema, vaid vajab tihedat sisulist koostööd ning toetub sealjuures paljuski lahendustele, mida tänapäevased tehnoloogiad võimaldavad.

Avaliku sektori projektide juhtimise käigus avalduvad probleemid on tihti suuremate organisatsiooniliste või riiklikke probleemide sümptomid ning "valuvaigistite" pikemaajalise kasutamisega kaasnevad omakorda uued probleemid, jättes samas algpõhjuste keeruka süsteemi tähelepanu ning ravita.

Me peame pöörama rohkem tähelepanu sellele, et mõistaksime paremini algatuste konteksti ja sellest tulenevaid piiranguid, ning aktsepteerima seda, et alati pole võimalik kõike detailselt ette planeerida.

Me peame välja mõtlema, kuidas kõige paremini õppida teiste riikide ning rahvusvaheliste ettevõtete kogemustest selleks, et ka Eesti avalikus sektoris tänapäeval pigem reegliks saanud ebamäärasuse ning ülevalt poolt etteantud projektipõhise finantseerimise tingimustes agiilse tarkvaraarenduse põhimõtteid rakendada.

Me peame lõpetama butafooriaplaanide kasutamise sisuliseks tööks ning hindama kainelt nii olukorda kui oma võimekust ja teadmisi. Me peame (riiklikul tasandil!) soodustama turvaliseks ebaõnnestumiseks disainitud eksperimentide kasutamist ning loobuma tavast ebaõnnestumisi karistada.

Me peame lõpetama Hawthorne'i efektide põhjal strateegiliste otsuste tegemise. Me peame lõpetama hõbekuulidele lootmajäämise – tihti on samm-sammult ja konteksti-spetsiifiliselt lahenduse poole liikumine ainus võimalus selle lahenduse jätkusuutlikuks kasutuselevõtuks. Edu ei saa "juurutada".

Lisaks sellele, et otsida paremaid vastuseid küsimusele "kuidas?", tuleb rohkem tähelepanu pöörata ka küsimustele "miks?" ning "kelle jaoks?". Ükski IT-arendus ei ole väärtus iseeneses.

Teenustes väärtuse loomine käib koostöös kasutajaga. Tänastele vajadustele eilse tehnoloogia abil suuremahulisi ning raskesti muudetavaid lahendusi luues oleme juba homme uuesti hädas.