Veebirakenduse hind sõltub sellest, millist tööd lahendus tegema peab. Sama idee kohta võib saada väga erinevaid pakkumisi, kui partnerid arvestavad erineva funktsioonide, integratsioonide või testimise mahuga. Võrreldava hinnapakkumise saamiseks tuleb kõigepealt kokku leppida, mis peab esimeses versioonis valmis olema.
Eelarvesse kuuluvad analüüs, prototüüp ja kasutajaliides, arendus, testimine ning kasutuselevõtt. Lisaks tuleb planeerida rakenduse kasutamise ja hooldamise kulud. Allpool vaatame need osad läbi ja selgitame, kuidas esimese etapi mahtu mõistlikult piirata.
Miks veebirakendusel ei ole ühte hinda?
Ettevõtte tutvustav koduleht ja töötajate igapäevatööd korraldav veebirakendus lahendavad erinevaid ülesandeid. Rakenduse hind kujuneb muu hulgas kasutajate tegevustest, õigustest, andmemudelist, välistest ühendustest ning töökindluse nõuetest.
Seetõttu ei saa pakkumisi võrrelda ainult lõppsumma järgi. Tuleb kontrollida, kas neis sisaldub sama töömaht ning kas hooldus, litsentsid ja kasutuskulud on eraldi välja toodud. Lahenduste erinevusi selgitab ka meie artikkel kodulehe hinnast ja valikutest.
Analüüs ja nõuete kaardistamine
Analüüsis kirjeldatakse, kes rakendust kasutab, milliseid ülesandeid seal täidetakse ja milline tulemus peab iga tegevuse järel tekkima. Sama oluline on selgitada, mis juhtub vigade või erandite korral.
Hea lähteülesanne eristab hädavajalikud funktsioonid soovidest, mida saab hiljem arendada. Samuti tuuakse välja olemasolevad süsteemid, andmeallikad ja tehnilised piirangud. Nii saab partner hinnata tööd selgete eelduste alusel ning tellija näeb, millest hind koosneb.
Prototüüp ja kasutajaliides
Prototüüp aitab enne arendust läbi proovida, kuidas kasutaja rakenduses liigub. Milliselt vaatelt ta alustab? Mida peab sisestama? Kuidas saab aru, et toiming õnnestus?
Arendusmahtu mõjutavad ekraanivaadete arv, nende erinevad olekud, vormid ja keerukamad toimingud. Valmis kujunduskomponendid võivad tööd lihtsustada, kuid sobivus sõltub kasutajate vajadustest. Prototüüpi tasub testida tulevaste kasutajatega, sest selles etapis on töövoogu tavaliselt lihtsam muuta kui pärast arendust.
Kasutajarollid ja ligipääsuõigused
Klient, töötaja ja administraator vajavad sageli erinevaid vaateid ning õigusi. Iga rolli puhul tuleb määrata, milliseid andmeid ta näeb, mida saab muuta ja millised tegevused vajavad kinnitamist.
Õiguste kontroll peab toimima ka serveris, mitte ainult peidetud nuppude kaudu. Eelarves tuleb arvestada õiguste testimise, vajaduse korral tegevuslogide ning kasutajate haldamisega.
Integratsioonid ja andmevahetus
Raamatupidamistarkvara, laosüsteemi või makseteenuse ühendamine on omaette töö. Hinda mõjutavad liidese võimalused ja dokumentatsioon, andmete kvaliteet, autentimine ning see, kui kiiresti peavad andmed liikuma.
Planeerida tuleb ka katkestused: kuidas tuvastatakse viga, kellele saadetakse teavitus ja kuidas välditakse sama tellimuse korduvat töötlemist. Neid küsimusi käsitleb meie API-liidestamise juhend.
Testimine ja turvalisus
Testimise maht sõltub rakenduse keerukusest ja võimaliku vea mõjust. Olulised töövood, näiteks tellimuse esitamine, maksmine või andmete salvestamine, peavad toimima nii tavapärastes olukordades kui ka tõrgete korral.
Arvesse tuleb võtta kasutajaõigusi, sisendite kontrolli, tundlike andmete kaitset ja saladuste turvalist hoidmist. Kõiki riske ei saa ühe testiga välistada, kuid kontrollide ulatus ja vastuvõtukriteeriumid saab enne töö algust kokku leppida.
Hooldus ja kasutuskulud
Rakenduse üleandmise järel jätkuvad majutuse, litsentside, väliste teenuste, seire ja uuendustega seotud kulud. Kasutuspõhiste teenuste puhul tuleb hinnata ka seda, kuidas muutub arve kasutajate või päringute arvu kasvades.
Leppige kokku, kes reageerib tõrgetele, millised tööd kuuluvad hooldusse ja kuidas hinnatakse uusi arendussoove. Varukoopiate olemasolu kõrval on vaja kontrollida ka taastamise võimalust.
Kuidas esimese etapi mahtu piirata?
Esimene versioon peaks lahendama ühe selge probleemi. Vali põhivoog, mille toimimist saab päris kasutajatega hinnata, ning määra mõõdik: näiteks toimingule kuluv aeg või vigade arv.
- Esimesse etappi kuuluvad põhivoo jaoks vajalikud vaated, õigused, andmed ja ühendused.
- Järgmisse etappi võivad jääda täiendavad aruanded, mugavusfunktsioonid ja uued integratsioonid.
- Turvalisus, vajalik testimine ja andmete säilimine ei tohiks jääda lihtsalt hilisemaks sooviks.
Väiksem maht ei tähenda läbimõtlemata alust. Eesmärk on õppida varakult, milline lahendus toob kasutajale ja ettevõttele väärtust.
Mida arenduspartnerilt küsida?
- Millised tööd ja eeldused hinnapakkumine sisaldab?
- Milline on esimese etapi kokkulepitud tulemus?
- Kuidas hinnatakse mahu muutumist?
- Kes kinnitab testitulemused ja töö valmimise?
- Millised on korduvad kasutus- ja hoolduskulud?
- Kuidas antakse üle kood, dokumentatsioon ja ligipääsud?
Kokkuvõte
Veebirakenduse eelarve koosneb tehniliste ja äriliste valikute summast. Selge lähteülesanne ning etappideks jagatud arendus aitavad pakkumisi võrrelda ja riske varem märgata. BigEye veebirakenduste ja integratsioonide arendus lähtub ettevõtte töövoogudest ja tegelikest vajadustest.
Soovid arutada oma veebirakenduse mahtu ja eelarvet? Kirjuta lauri@bigeye.ee ja lepime kokku tasuta konsultatsiooni.
