Vähem tarkvara on parem

Igaüks, kes on kokku puutunud IT-arendusega, on näinud, kuidas isegi väikesi asju tehes kuluvad miljonid eurod, pidevalt ületatakse eelarveid ja tähtaegu – ja isegi pärast seda võidakse tulemus korstnasse kirjutada. Ma ei tea ikka, kust tekib tolm, aga küsimusele, kuhu  kaob raha, saab vastuse protsessi lähemalt, tarkvara-arendaja mätta otsast vaadates.

Teatavasti koosneb IT-süsteem kolmest põhikomponendist: riist-, tark- ja inimvarast. Riistvara tuleb odavalt Hiinast, tarkvara paljundamine ei maksa midagi. Pudelikaelaks jääb alati inimvara, kes tarkvara arendab: disainib, kohandab, loob ja juurutab. Tarkvara arendamine on keeruline spetsiifiline oskus, mis erineb paljudest teistest töödest selle poolest, et iga päev tuleb lahendada uusi, mittestandardseid probleeme.

 

Erinevalt ehitajatest, õpetajatest või arstidest ei ole tarkvaraarenduses korduvaid ülesandeid, mille sisu ja lahendamise kestus oleks ette teada. Kui tarkvaras on mis tahes korduv probleem, siis saab ja tuleb see lahendada tarkvarakoodi jupiga, mis selle automatiseerib ja ühekorraga ära lahendab. Arendajatele jäävad põhimõtteliselt üle vaid uudsed ülesanded.

Kuidas sa saad planeerida täpset aega (ehk raha), mis kulub tööle, mida sa kunagi varem teinud pole? Heal juhul on probleem ise on selge; enamasti on kliendi keskkonnad keerukad ja dokumenteerimata, vajadused ebaselged ja muutuvad ning silmas peetavate detailide hulk paisub töö käigus plahvatuslikult. Samal ajal peab arendaja jääma matemaatiliselt täpseks loogikuks ja inseneriks, kes selles kaoses suudab biti täpsusega korra luua. Ime, et seal üldse midagi lõpuks toimib.

Tarkvaraarendus on kallis. Okei, aga siis saame ikkagi tarkvara, mis on lihtsalt kopeeritav? Müüme selle maha teistele omasugustele, saame vähemalt kulud jagada, võib-olla isegi suurt raha teenida? Teisisõnu: miks ei võiks Eesti riigi loodud X-tee, ID-kaardi või näiteks e-tervise lahendused teenida teiste riikide ja asutuste huve, kui meil juba on see lahendus olemas?

Kahjuks on see palju keerulisem. Juba meie oma süsteemis oli vaja lahendada miljon keerukat probleemi, tulenevalt ajaloost, keskkonnast, seadustest ja lõpuks tellijate subjektiivsetest maitse-eelistustest disaini asjus. Tõenäoliselt on kõik need alustingimused mis tahes teises riigis pisut teistsugused. Seega, kui Eestis pidime lahendama tuhat unikaalset probleemi, siis kümnele välisturule sama pakkudes tekib neid probleeme suurusjärgu võrra rohkem, vähemalt kümme tuhat. Pealegi, enamasti mõtlevad kliendid ka nii, et see tarkvara on tehtud teie jaoks, meil oleks lihtsam teha enda oma. Ja enamasti nii ongi.

Tarkvara saab luua teistmoodi – selle asemel et lähtuda ühe (esimese) kliendi nõuetest, ja püüda need täielikult lahendada, võib lauale panna kõikide sarnaste klientide sarnased probleemid, leida nende ühisosa ja püüda lahendada need nii, et tehnoloogiliselt toimiks see kõikide jaoks. See on konkreetse kliendi jaoks võib-olla 80% lahendus, aga tuleb kordades odavam.

Näiteks „kõikide infosüsteemide ema“ Excel on kaugel ideaalsest lahendusest spetsiifiliste ülesannete jaoks, aga samas on ta küllalt universaalne, et 99% infotöötlejaid kasutab seda mingis tööetapis, ilma et oleks vaja kirjutada spetsiifilist tarkvara. Selline tarkvara loomine on universaalse toote loomine, ja sellist on põhimõtteliselt võimalik müüa teistele.

Probleemiks on jällegi kulud, mis võrreldes ühele kliendile tehtava lahendusega on kordades suuremad. Me ei saa oodata, et esimene klient on valmis kordades rohkem maksma, et sina saaksid oma toodet rohkem müüa, see investeering tuleb ise teha. Eriti riigisektori suurprojektide puhul ei aita kaasa nüanss, et selle esimese kliendi saad sa, kui teed riigihankel odavaima pakkumise.

Odavaima pakkumisega on võimalik tarnida vaid odavaim toode, kust mis tahes lisaliigutused on välja optimeeritud, ja tehakse täpselt nii palju, kui klient on taibanud pakkumiskutses kirja panna, ei ridagi enam. See pole enamasti isegi see, mida ta tegelikult lõpuks vajab, aga eks 50% eelarve lõhkimineku planeeritakse igaks juhuks niikuinii sisse. Sellest, et valmiks toode, mida saaks mujale müüa, ollakse lõpuks ikka väga kaugel. Sest see miljoneid maksev tarkvara oli paradoksaalselt lihtsalt liiga odav.

Tarkvara loojate jaoks on selge lahendus – unustage (riigi)hanked rätsepatarkvarale, võtke suuremaid riske ja looge enda kuludega universaalseid tarkvaralahendusi, mis on kasutatavad või vähemalt kohandatavad paljudele klientidele. Õnneks edumeelsem Eesti tarkvara (ja eriti kasvuettevõtete) sektor selles suunas liigubki. Aga see on keeruline: investeeringud on mahukad ja riskantsed, ehk saaksid riik ja tellijad  midagi teha?

Saab – tellige vähem tarkvaraarendust. Kuidas nii, on ju vaja maksta toetusi, väljastada ravimeid ja hallata miljonit muud asja? Rusikareegel: ärge otsige ega jumala pärast looge uut tarkvara vastavalt oma protsessidele ja vajadustele, vaid planeerige oma protsessid vastavalt tarkvarale.

Me ei ole mitte kunagi nii rikkad, et iga uue seaduse või protsessi jaoks unikaalset tarkvara kirjutada. Kasutage maksimaalselt võimsaid äriprotsesside valmisplatvorme, vaadake, mis on teistes riikides sobivat loodud, millised on seotud standardlahendused, mida saaks kohandada ja –  mis veel olulisem: kaasake IT-tehnoloogid piisavalt varakult protsessi, et saaks suunata protsesse nii, et need oleksid jõukohaselt lahendatavad.

Olge paindlikumad oma nõuetega, mõni spetsiifiline lisanupp võib vähendada kümme minutit nädalas kellegi tööaega, aga selle arendus võib kulutada mitmeid tunde ülikalli tarkvaraarendaja aega, mis ei tasu end kunagi ära. Juba seaduse väljatöötamise ajal mõelge IT peale – kui see tähendab uusi rätsepatöö infosüsteeme, siis mõelge uuesti, kuidas seda saaks teha paremini, „tehases“ loodud tarkvara abil.

Ostke ja kasutage tarkvara teenusena (Software as a Service), see maksab sageli sisuliselt kopikaid. Võib-olla tuleb selleks muuta isegi riigihanke protsesse, mis tunduvad eelistavat ühekordseid suuri tellimusprojekte suure hulga töötundidega. Osal tarkvarafirmadel on muidugi hea meel töötunde müüa, aga sektorile, ja majandusele tervikuna see ei ole pikaajalises perspektiivis hea. Tarkvaras on lihtne reegel: mida vähem koodi, seda parem.