Sellest on juba palju räägitud, et tarkvaraarenduse tellimine pole nagu poes käimine, kus laod riiulitest ostukorvi kaupu täis ning kassas juba tead, palju maksma pead. Paraku ei taha keegi ka sellist arendust osta, et kui oled juba kassas kõik ära maksnud, jookseb hiljem keegi sulle järele ja ütleb, et me siin arvutasime ja tegelikult peab poole rohkem maksma.
Tarkvaraarenduse hinna arvutamine on siiski võimalik ka nii, et mõlemad pooled on rahul ja keegi ei tunne end petetuna. Kuidas see käib? Proovimegi selle ostja ja müüja vaheliste kompromissidega protsessi selgelt lahti seletada. Abiks on Singletoni kaasasutaja Jurgen Herzmann, kes on sellistes läbirääkimistes ja planeerimistes pidevalt osalenud.
Kliente on alati nii-öelda seinast seina. Mõnedel on lausa oma IT arendusosakond, mõni pole aga IT-st eriti midagi kuulnud ja tegutseb alal, kus on vaja hoopis muid oskusi ja teadmisi. Kas need viimased peaks nüüd hakkama end ka IT-teemadega kurssi viima või mida võiks üks arendust tellima tulev ettevõte teada arenduse kuludest ja nende arvestamisest? Siit leiadki selle, mida neist teemadest peab teadma ise arenduse tehnilistesse detailidesse sukeldumata.
Ära räägi mööda
Arenduse kuludest on juba päris alguses elementaarsetel teemadel võimalik väga mööda rääkida. Palju on ettevõtteid, kes ühel päeval otsustavad, et nüüd aitab, hakkame ka moodsaks ja teeme ägeda “äpi”. Samas ei mõelda sellele, et äpil peab olema ka nii-öelda back-end. Esimene möödarääkimine võibki tekkida sellest, et arendusfirma eeldab back-endi olemasolu ning annab esialgse maksumuse hinnangu just selle põhjal.
Teiseks levinud näiteks möödarääkimisest on disain. Ilma kogemuseta tellija eeldab, et “äpipakkumine” sisaldabki kogu teenust, kuid arendusfirma ei pruugi disainiga üldse tegeleda. Sellised arendajad on tavaliselt harjunud, et tullakse juba valmis disainiga ning seda üle täpsustama ei hakata.
Ära karda rumalaid küsimusi
Neid näiteid on muidugi veel, aga kõigi puhul saab teha vaid ühe järelduse: kõik sellised elementaarsed teemad, mis arenduses võivad ette tulla, peaks alguses üle käima. Igaks juhuks võiks mõlemalt poolt ka “rumalaid küsimusi” küsida ja neid pole vaja karta. Singletonis tehakse üldjuhul üsna detailsed pakkumised, kuid ka siis on täiesti võimalik, et kliendile jääb lugu segaseks, kui tal varasemalt tarkvaraarendusega kokkupuudet pole olnud.
Seega tulebki esimeses kokkulepete faasis keskenduda väga üldistele ja lihtsatele teemadele: kas räägime näiteks kogu platvormi, ainult mobiilirakenduse või front-endi arendamisest ning kes korraldab disainilahenduse?
“Meie juhime!”
Kui lihtsad teemad on paigas, siis järgmisena on väga olulised ka testimise ja projektijuhtimise rollid ning ootused ja mahud.
Paljud arenduse tellijad ei soovi maksta näiteks projektijuhtimise ja testimise eest, kuna esialgu tundub, et sellega saab ka ise väga hästi hakkama. Mis saaks siin valesti minna?
Tegelikult saab ja isegi väga palju. Kui teenusepakkuja soovib tellimust ja klienti endale saada, siis võib ta isegi vastu tulla ja jätta need teemad kliendi hooleks. Lõpuks aga võivad kaotada sellest mõlemad pooled, sest kui projekt on kliendi poolt kehvalt juhitud ja poolikult testitud, siis hakkavad tähtajad venima, kannatab töö kvaliteet ning mõlemad osapooled saavad kaela “alternatiivkulud”.
Hindu ei saa kivisse raiuda
Palju segadust tekitavad tihti ka fikseeritud hinnaga projektid. Kui paljudes valdkondades on lõpliku hinnapakkumise alusel töötamine standardiks, siis tarkvaraarendus pole nagu maja ehitamine, eriti just tootearendus.
Kogu projekt on tavaliselt täis pidevaid üllatusi ja muudatusi, mida esialgu pole võimalik ette näha. Näiteks võivad ootamatused tekkida turuolukorrast, klientide tagasisidest, muutunud ootustest jne.
Singletonis arveldatakse tehtud tööde eest enamasti tundide alusel, mida saab väga täpselt logida. Ka kliendi jaoks on see mugav, sest ta saab igakuiselt detailse raporti, millistele arendustöödele aeg ja raha kulus.
Samas on levinud ka kuupõhine arvestus. See on mõistlik siis, kui üks arendaja tegeleb sama kliendiga aastaid.
Riigihangetel on aga pea võimatu esialgset fikseeritud eelarvet muuta, kuid eraklientidega annab üldjuhul läbi rääkida.
Singletonil ning ilmselt igal teisel tarkvaraarendusfirmal on olnud siiski ka fikseeritud hinnaga projekte, kus läbi ei õnnestu rääkida ning üsna paljudel juhtudel teevadki arendajad nii-öelda hambad ristis kahjumiga projektid lõpuni. Sellest olukorrast heal juhul aga õpitakse ning kliendisuhe saab jätkuda mõistlikematel alustel. Heaks näiteks fikseeritud pakkumistest on mobiilirakendused, kus pannakse kohe alguses lõplik disain paika. Need on üldiselt väiksemad, kuni pooleaastase mahuga projektid.
Kui palju arendus ligikaudu maksab?
Iga arenduse puhul kujuneb hind muidugi konkreetsete tööde arvestuse põhjal, kuid iga tellija tahab siiski alguses teada vähemalt ligikaudset hinnavahemikku, millega peaks arvestama.
Lihtsamate veebilehtede pakkumised näiteks on jäänud tavaliselt suurusjärku 5-10 tuhat eurot, lihtsam mobiilirakendus (ilma disaini ja back-endita) maksab 15-20 tuhat eurot. Veebipõhiste platvormide projektid algavad aga 50 tuhandest eurost.
Kui raha kulub plaanitust rohkem – mis siis saab?
Kui aga esialgsete kuludega hakkama ei saa, siis tuleb teha lisaeelarve, mis nõuab igas valdkonnas palju selgitamist.
Digitoodete puhul tekib lisaeelarve õnneks üsna läbipaistvalt.
Kui näiteks klient soovib täiendavaid funktsioone või muudab disaini ja äriloogikat, siis ei saa enam sama eelarvega hakkama. Ehk siis tihti on just klient see lisaeelarve põhjustaja erinevalt näiteks ehitusest, kus kuskil taustal materjalide hinnad mingil arusaamatul põhjusel mitu korda tõusevad.
Ootamatuid lisakulusid põhjustavad enamasti äriloogika uuendused ja muudatused ning nendega kaasnevad disainimuudatused. Samuti võib testimise maht kujuneda niimoodi planeeritust suuremaks.
Mõned oskused on turul kulla hinnaga
Eks arenduse kulu sõltub väga palju ka sellest, milliseid spetsialiste on tööks vaja.
Eestis on platvormide lõikes vähe näiteks Ruby on Rails arendajaid, seega tunnihind võib selle võrra kõrgem olla, samas mõnes teises riigis on see väga levinud tehnoloogia.
Oskuste poolelt aga tasub kõrgelt hinnata selliseid tehnilisi spetsialiste, kes oskavad ka äri poolel piisavalt kaasa mõelda, küsida õigeid küsimusi nii tehniliselt kui äri poolelt ning teha antud ajahetkel kõige optimaalsemaid otsuseid, mis aitavad toote arendamisega kiiresti edasi liikuda.
Singletonis on kombeks öelda, et tehnoloogia on vaid tööriist, millega lahendatakse olulisi äriprobleeme.
Kõige keerulisem on tellija soovid varakult teada saada
Kui klient ise ka ei tea, mida ta täpselt tahab, siis ei aita ka tuleviku ennustamine – kõige keerulisem ongi arendajal aru saada, kas kogu vajalik funktsionaalsus on kirjeldatud või tahetakse veel midagi. Päris paljudel juhtudel ei teagi klient ise päris täpselt, mida vaja, kui tegemist on näiteks täiesti uue lahendusega.
Kui liiga palju oletusi teha näiteks seni tehtud projektide põhjal, siis võivad hinnangud paigast minna. Samas on ka selliseid arendusmeetodeid, mis sel puhul aitavad.
Kui klient tahab “väledat” arendust – mida siis teha?
Üks moodsatest arendusviisidest on agiilne ehk “väle” arendus, mis sobib paremini just sellistel juhtudel, kui ei ole teada, kuhu lõpuks välja jõutakse.
Esimese asjana võiks klient agiilse arenduse puhul projektile väga aktiivselt kaasa elada. Seda on vaja ka siis, kui teenusepakkuja poolt on kogu meeskond olemas, sealhulgas projektijuht.
Prioriteedid peaksid väga täpselt paigas olema, sest olukord muutub pidevalt ja peab valima, mida antud ajahetkel arendada.
See tundub pealtnäha väga lihtne, aga tegelikult on see kõik siiski suur väljakutse mõlemale poolele. Kõige paindlikum ja soodsam on agiilne arendus olukorras, kus turule tuuakse täiesti uut toodet või funktsionaalsust, mida on vaja iga nädal muuta vastavalt turu tagasisidele.
Mis saab pärast seda, kui toode on valmis?
Kui arenduse kulud on kokku lepitud, siis lõpeb paljude jaoks töö tavaliselt siis, kui toode välja tuleb ja kasutusele võetakse. Kuid mis saab edasi? Tarkvara on teatavasti selline toode, mida peab aeg-ajalt uuendama ja täiendama, sest tehnoloogiad muutuvad ning turvaolukord samuti pole täna enam see, mis eile.
Selle, kui pikalt arendaja toe tagab, määrab juba eraldi kokkulepe. Singletonil on päris pikaajalisi kliente, kellega tehakse koostööd aastaid ning nende puhul on elementaarne, et kõik uuendamise ja toe teemad on kaetud.
Mobiilirakendustega on lihtsam – need reeglina toimivad üsna kaua ka ilma toeta. Samas ka siin võib tekkida olukordi, kus midagi peab ette võtma. Näiteks võib mõne kuu pärast välja tulla uus React Native´i versioon, millele oleks mõistlik ka äpp üle viia. Mõnikord on taolised uuendused vältimatud. Üldjuhul kliendid selliseid kokkuleppeid ei soovi, et pärast tarkvara üleandmist veel mitu põlvkonda platvormiuuendusi tehtaks ning tegelevad hilisema arenduse või täiendamisega ise.
Kas küsida võib kõike?
Kui fikseeritud hinnaga arendustes jooksvalt juurde tekkinud tööd on umbes samas mahus, kui “ära jäänud” tegevused, siis on mõistlik keskenduda kiirelt toote valmis saamisele, kui iganädalastele töömahu läbirääkimistele. Kui arendaja tuleb “tasaarveldustes” vastu, võib see aga arendusfirmale olla siiski üsna õhukesel jääl kõndimine, sest klient saab aru, et “tasuta” võib küsida kõike.
Seega kokkuvõtteks on tarkvaraarenduse tellimine siiski inimeste vaheline äri ja igal kliendil võiks olla arenduspartneriga ühine missioon, mille käigus tullakse üksteisele vastu ja keskendutakse lõpptulemusele. Siis ongi mõlemad osapooled rahul.
