Mis on veebirakendus?

Veebirakendus lühidalt

Mis on veebirakendus? See on tarkvara, mis töötab brauseris ja teeb päris tööd. Kasutaja logib sisse, näeb oma andmeid, teeb toiminguid ja saab tulemuseks dokumendi, arve või staatuse. Erinevus kodulehest on lihtne: kodulehte loetakse, veebirakendust kasutatakse.

Tehniliselt on veebirakendus kolm kihti. Brauseris jooksev osa kuvab vaateid ja saadab päringuid. Serveris jooksev osa kontrollib õigusi ja arvutab. Andmebaas hoiab seda, mis peab alles jääma. HTML-standard kirjeldab dokumendi ehitust ja käitumist, ja see raam on mõistlik tunda enne, kui disain hakkab lubama asju, mida platvorm ei toeta.

Mida see Eesti ettevõttes päriselt teeb

Tüüpilised näited, mis korduvad:

• Kliendiportaal. Klient näeb oma tellimusi, faile ja arveid. Asendab küsimuse „kus mu tellimus on“ e-kirja.
• Broneerimine. Aeg, ressurss ja kinnitus ühes kohas. Väärtus tuleb sellest, et topeltbroneeringud kaovad.
• Sisemine töövahend. Töötajad sisestavad andmeid ühte kohta ja juhid näevad seisu ilma eraldi aruandeta.
• Pakkumiste haldus. Hinnad, mallid ja kliendiandmed ühes voos, et iga pakkumine ei algaks tühjalt lehelt.

Ühine joon: rakendus asendab tabelit või e-kirjavahetust, milles on juba praegu andmed olemas, aga neid ei saa usaldusväärselt lugeda. Kui andmed on olemas ja töö on korduv, on veebirakendus mõistlik.

Näide: broneerimine kolme nädalaga

Hooldusettevõttel on kolm meest ja 40 seadet. Broneeringuid peetakse telefonitsi ja kalendris, topeltbroneeringuid tuleb kuus paar.

Esimene versioon on kitsas: seadme nimekiri, kalendrivaade, broneeringu vorm ja kinnitus e-postiga. Kõik ülejäänud ideed, nagu arveldus ja automaatne teavitussõnum, jäävad teiseks ringiks. Selle loogika kohta on eraldi artikkel MVP arendus: kolme nädalaga saab töökindla esimese versiooni, kui ulatus on aus.

Kui rakendus peab hiljem suhtlema raamatupidamise ja äriregistriga, tuleb API kihid kavandada enne, mitte pärast, sest hiljem tehtud andmemudel maksab rohkem kui alguses tehtud.

Millal veebirakendust ei ole vaja

• Valmis tarkvara katab vajaduse. Raamatupidamine, personali- ja projektihaldus on olemas. Ise ehitada tasub siis, kui see on ettevõtte eripära, mitte üldine funktsioon.
• Kasutajaid on kaks. Kahe inimese töövoog mahub tabelisse, kui reeglid on kirjas.
• Protsess ei ole veel paigas. Kui iga nädal muutub, kuidas tööd tehakse, kodeerib rakendus vana versiooni.
• Keegi ei hoolda. Rakendus vajab uuendusi, varundust ja turvaparandusi. Kui seda pole, laguneb ta vaikselt.

Millest hind koosneb

Enne arendust tasub kirja panna, milliseid andmeid rakendus ise loob ja milliseid küsib mujalt. See üks leht säästab hiljem nädala, sest just seal selgub, kas vaja on liidestust või mitte.

Hind ei tule lehekülgede arvust, vaid sellest, kui palju on erinevaid rolle, olekuid ja erandeid. Kolm küsimust, mis hindavad töömahtu paremini kui mis tahes hinnakiri:

1. Mitu eri kasutajarolli ja mida igaüks tohib?
2. Mitu süsteemi peab rakendusega rääkima ja kellel on liides olemas?
3. Mis juhtub siis, kui midagi katkeb: kas andmed jäävad alles ja kes saab teada?

Töö- ja hinnaraam on teenuse lehel tarkvaraarendus. Kui tahad enne otsust teada, kas ja kuidas teenus tasub, on mõistlik lugeda B2B SaaS otsuseid, sest samad vead korduvad nii sisemises tööriistas kui tootes.