Autor: Marek Mühlberg • 26. veebruar 2014
Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Margus Püüa: eelarvetesse mahub rohkem kvaliteetset arendust

Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT) strateegia- ja planeerimisosakonna juhataja Margus Püüa esineb 27. veebruaril Äripäeva seminaril "PARIMAD PRAKTIKAD: Milline on edukate tarkvarahangete valem?" 

Milliseid avaliku sektori arendusprojektides levinud probleeme võimaldaks agiilsete meetodite aktiivsem rakendamine vältida?Esimene kõige suurem probleem on muidugi loodava lahenduse vastavus tegelikele vajadustele. Kui kasutatakse klassikalist „koskmudelit", siis tegelik lahendus saab kasutajale kättesaadavaks alles projekti lõppfaasis ja siis on ju tõenäosus, et lahendus kasutajale ei sobi, väga suur. Aga projekti lõppfaasis pole enam aega ega raha oluliste muudatuste tegemiseks.

Vältimaks suuri üllatusi projekti lõppfaasis, kasutatavad paljud avaliku sektori IKT lahenduste tellijad prototüüpide loomist. Prototüübi loomine võimaldab kasutajaga põhimõttelise lahenduse läbi arutada ja leida juba analüüsifaasis kasutajale sobilik lahendus. Prototüüp annab ettekujutuse küll kasutajaliidesest, aga süsteemi enda loogika jääb ikka projekteerimise ja realiseerimise faasi. Samas on prototüüpidel põhinev arendus omakorda kaasa toonud olukorra, kus üks IT ettevõte teeb analüüsi ja prototüübi (ehk mõtleb välja lahenduse) ja teine ettevõte realiseerib. Kui nüüd oletame, et projekt kestab 1,5 aastat, siis kes vastutab selle eest, et tarnitav tarkvara vastab tegelikele vajadustele. Realiseerija ettevõte kirjutab ju koodi täpselt spetsifikatsiooni järgi.Teine probleem on lahenduse tarnimise aeg. Kasutaja saab talle vajaliku lahenduse kätte koskmudeli kasutamise korral vajaduse tekkimisest alates minimaalselt 2 aasta pärast. Selle ajaga on vajadused muutunud ja katkenud ka kasutaja kannatus.

Kas ja kuidas saame kombineerida hangetes paindlikkuse ja samal ajal fikseerida projekti eelarve ja tähtaja. Kas võluvits ühe konkreetse arendusmeetodi näol on olemas?

Ei, võluvitsa ei ole. Vaja on muuta paindlikumaks nii arenduse planeerimise, arenduste realiseerimise kui ka rahastamise otsustamise protsessi. Seda tuleb teha viisil, et maksumaksja raha kasutamise otsustamine oleks jälgitav ning auditeeritav ja otsused hästi argumenteeritavad. Tuleb vältida olukorda, kus eelarve koostamise protsessis pannakse raha kinni projekti alla, kuid projektiga realiseeritav lahendus on alles väljatöötamata. Tuleb luua mehhanism, kus raha tullakse küsima investeeringuks alles siis, kui lahendus on projekteeritud ja realiseerimise sammud paigas. Seda põhimõtet on kasutatud eelmise EL vahenditest infoühiskonna projektide rahastamisel. Otsus rahastamise osas tehti alles siis, kui oli olemas parimaks kuulutatava pakkumuse kandidaat. Siis vaadati lahendus üle ja tehti otsus.Väledad arendusmeetodid ise eeldavad ju kiireid vahetarneid, mis tähendab, et arenduse ajagraafik on päris hästi kontrolli all. Seatakse ju sprintidele agressiivsed tähtajad, mis tähendab, et varuaeg võetakse üksikutest sprintidest välja. Iga vahetarne testitakse ja vahetarne arendamise käigus väljatulnud üksikasjad, kas projekteeritakse ringi või lisatakse järgmise tarne arenduse skoopi. Julgen väita, et tänaste „harjutud“ eelarve  ja tähtaegade sisse mahub oluliselt rohkem kvaliteetset arendust, kui kasutada väledaid arendusmudeleid.Üks oluline oht on siin küll. Viimasel ajal on levinud praktika, kus projekti käigus tehtavaid skoobi muudatusi tõlgendatakse hanketingimuste muutmisena. Siin on vaja juristide abi, et teha vahet hanke tingimuste muutmise ja loomuliku arendusprotsessi käigus tehtavate muudatuse vahel. Täna asutuste juristid pigem ei luba muudatusi teha.Erasektor armastab rääkida „targast tellijast“ kui tulevikukliendi visioonist (justkui vihjates, et kivi on tellija kapsaaias). Kas riik (kui üks suurimaid tellijaid) vastab täna sellele visioonile või oleks mõistlik eeldada, et struktuursed ebakõlad ja erinevad huvid peavadki püsima jääma?

Mina tahan rääkida pigem „targast pakkujast“. Minu hinnangul liiguvad arendused pigem sinna suunda, et nutikad lahendused tulevad nendelt arendajatelt, kellel on tellija „ärist“ selge teadmine. Tundes tellija „äri“ olemuslikult ja tundes parimaid tehnoloogiaid on võimalik luua lahendusi ka ilma, et tark tellija kirjutaks põhjaliku spetsifikatsiooni programmeerimiseks.

Kui mõelda millised on need maailmas läbilöönud IT lahendused, mis on spetsifitseeritud targa tellija poolt, siis mulle ei tule ühtegi meelde. Küll aga teame lahendusi, mida on loonud tehnoloogiat valdavad ja tellija tegelikke olemuslikke vajadusi tundvad tehnoloogiaettevõtted. Kes spetsifitseeris Facebooki näiteks, või Skype, või Isepankuri? Targad tellijad??

Liitu ITuudiste uudiskirjaga!
Liitumisega nõustud, et Äripäev AS kasutab sinu e-posti aadressi sulle uudiskirja saatmiseks. Saad nõusoleku tagasi võtta uudiskirjas oleva lingi kaudu. Loe oma õiguste kohta lähemalt privaatsustingimustest
Indrek KaldITuudised.ee toimetajaTel: 511 1112
Anne WellsReklaami projektijuhtTel: 5880 7755