Kvaliteedikonsultant: väldi tarkvara tellijana neid levinud ämbreid

Suur hulk tarkvaraprojekte lõppeb hilinemiste ja eelarve ületamistega, mis on juba iseenesest probleemne, kuid eriti painav mure algab alles siis, kui süsteem ei tööta nii nagu peaks – ja seda märgatakse reeglina alles siis, kui see põhjustab juba otsest kahju.

Tarkvara rätseplahendused ei ole enam ammu ainult avaliku sektori ja suurte ettevõtete mängumaa – oma arenduspartner on täna paljudel, kes digitaliseerimisest maksimumi võtta soovivad. Investeeringud tarkvarasse, olgu need nullist arendatud või karbitoote projektid, moodustavad märkimisväärse osa ettevõtete eelarvest. Investeering tarkvarasse ei ole paraku seda tüüpi, mis kord tehakse ning siis unustatakse – see nõuab järjepidevat kaasas olemist.

Nii võivad apsakad tarkvaraarenduses minna kalliks maksma – veniv arendusprotsess ning ebaefektiivsuse tõttu saamata jäänud tulu, vigade tõttu laekunud kliendikaebused, negatiivne meediakajastus kuhjuvad otseseks materiaalseks kahjuks.

Kui testimine pole arendaja tugevus või jääb näiteks ajanappuse tõttu pealiskaudseks, ilmnevad tõsised probleemid. Seda reeglina ikka siis, kui tarkvara on juba justkui täie hooga kasutusele võetud – ja siis on juba tulekahju. „Kui testimine jääb vaid formaalsuseks, ilmnevad probleemid hiljem, kuid sel ajal on juba eriti keeruline midagi muuta,” hoiatab Suvi. Eriti väiksemate ettevõtete puhul, kus sageli puudub eraldi IT-osakond, jäävad sellised vead sageli avastamata ja lähevad hiljem väga kalliks maksma.

“Meil oli üks avaliku sektori projekt, kus meid kaasati päris hilises faasis. Tööd oli juba aasta otsa tehtud, arendada sõnul hakkas asi peagi valmis saama. Nende arust oli seis “päris hea”, reaalsuses raporteerisime aga 500 viga, millest vähemalt kolmandik olid sellise kriitilisusega, et parandus oli hädavajalik enne avaldamist ,” jutustab Suvi.

Õiged mängureeglid tuleb kehtestada enne tööde alustamist, toob Suvi esile. Kokkulepe tellija ja arendaja vahel on vajalik, kuna probleemide tõstatamine pärast, kui tarkvara on valmis, võib viia tulistesse aruteludesse, milles on kummagi poole huvid erinevad.

“Ärinõudeid ei saa kunagi kirja panna viimse detailini – see on arusaadav. Küll aga ei ole arenduspartner ja tellija selles olukorras tihti võrdsed sparringupartnerid argumenteerimaks ja oma positsiooni kaitsmaks, et mis on ilmselge analüüsi, arhitektuuri või arendusviga või mis peaks kuuluma garantiitööde alla, mis olema lisatöö,” annab Suvi nõu.

Ükski töö ei tohiks alata ilma selgete nõueteja kokkulepeteta arendaja ja tellija vahel, muidu võib kerkida ebameeldiv ja kohati ka ebavõrdne vastasseis.

Tihti esineb olukord, kus lepingueelses faasis lubatakse, et kõik on võimalik: karbitoode on lihtsasti konfigureeritav ja kui pole, saab hõlpsasti arendada. Kui projekt on poole peal, selgub aga, et ettevõtte spetsiifika ei mahu karbitootesse ja “väike lisaarendus” muutub eelarvet tundmatuseni paisutavaks lisakuluks.

„Selle vältimiseks peab nõuete analüüs ja äriprotsesside kaardistus olema karbitoodet hõlmavas projektis palju põhjalikum juba enne lepingu sõlmimist,” selgitab Suvi. Kui arendajad ei ole kursis, milline on ettevõtte spetsiifika, on suur oht, et lõpuks ei ole süsteem paindlik ega tule tööle vastavalt tellija vajadustele.

„ Vendor lock on olukord, kus oled sõltuv ühest arenduspartnerist ning sul ei ole mõistliku teed sellest välja. See on riskantne koht, kus olla. Kui analüüs ja dokumentatsioon on puudulikud või kasutatud on vähelevinud tehnoloogiad, siis jäädki oma partneri pantvangiks, kuna teised arenduspartnerid ei taha või ei saa töid üle võtta ning ainus alternatiiv on sama funktsionaalsuse uuesti arendamine” hoiatab Suvi.

Selle vältimiseks on oluline tehnoloogiate ja platvormide valikul olla otsustega kaasas, teha neid teadlikult ning ehitada projekt üles selliselt, et partneri vahetus on realistlik. Muidu on tulemuseks on olukord, kus oled sunnitud seotuks jääma olemasoleva partneriga – ka siis, kui koostöö enam ei toimi. Halvemal juhul võib arenduspartner ootamatult ka tegevuse lõpetada jättes oma kohustused lõpuni täitmata ja sind tellijana pooliku lahendusega.

“Vead on tarkvara loomulik osa, kuid kui arendusmeeskond on väike, siis on suurem osa testimisest tellija mure,” selgitab Suvi. Kui arendusmeeskonnas pole piisavalt analüütikuid ja testijaid, siis tähendab see, et arendaja peab tegema kõike: suhtlema äripoolega, tegema detailset analüüsi, arendama ja seejärel ise oma tööst leitud vigu leidma ja parandama.

„Tulemuseks on, et vead jäävad avastamata ja hiljem maksab tellija nende parandamise eest lisaks. Rääkimata ebamugavustest, mida need vead võivad töökeskkonnas põhjustada,” lisab Suvi.

Parim viis nende probleemide vältimiseks on omada tugevat ja kompetentset meeskonda, kes tuleb toime nende probleemide ennetamise ja lahendamisega.

Neid ülesandeid võib jagada erinevate rollide vahel: IT-juht, arendusjuht, analüütik, projektijuht, testijuht, testija ja tootejuht. Suurtes ettevõtetes on selliste rollide olemasolu tavapärane, kuid väiksemates või ebaühtlase arendusmahuga firmades ei pruugi see olla kuluefektiivne.

Väiksematel ja keskmise suurusega ettevõtetel on mõistlik kaasata sõltumatud eksperdid, nagu ASA Quality Services, kes seisavad arendusprojekti vältel tellija huvide eest. “Me seisame selle eest, et tarkvarainvesteering ei muutuks rahaliselt, ajaliselt ega kvaliteedilt kontrollimatuks kaoseks,” lubab Suvi.

“Õigeid otsuseid tuleb teha algusest peale – mitte napilt enne värske tarkvara kasutuselevõtu kuupäeva. Ära lase tarkvarainvesteeringuid raisku – küsi nõu varakult, nii saad keskenduda hoopis äri kasvatamisele,” möönab ta hingele pannes.

Põhitõde: Äriprotsesside ja tarkvara arendamise planeerimine algusest peale on investeeringu kaitsmiseks hädavajalik. Tarkvara on nagu töötaja kontoris – professionaalne, efektiivne, töökeskkonda sobituv. Selle n-ö töötaja väljaõpetamisel ning kasvatamisel tasub vaeva näha.