Agiilne arendusmudel ja SaaS ärimudel
Arendusmudeli valimisel toimib minu meelest järgmine loogika: „Ütle milline on projekti määramatus ja ma ütlen millised arendusmeetodid sobida võiks“.
Arendusmeetodite valik on päris lai, alates väikese määramatusega kosemudelist ning lõpetades suure määramatusega arvestava agiilse mudeliga. Nende kahe vahel on veel hulgaliselt variante, mille vahel valimiseks võiks lisanduda ka ülevaade aja- ning eelarve võimalustest.
Kõige toredam on muidugi arendada ilma määramatuseta projekte, kus kõik on paigas ja selge. Kahjuks vähegi suurema projekti korral pole määramatuse puudumine reaalne, sest see tuleb tahes-tahtmata kuskil mängu. Üldiselt loetakse suure määramatuse korral agiilsed meetodid kõige sobivamaks, kuid võin kinnitada, et agiilne arendus ei ole imerohi ning väga suurt määramatuse see probleemideta kompenseerida ei suuda. Esimene faas, kus pannakse põhiasjad paberile paika, peab ikkagi olema enne arenduse algust tehtud (1).
Näide lonkavast agiilsest arendusest
Osalesin tellijana ühes arendusprojektis, mille võtan näiteks kui suure määramatusega arenduse, mida arendati agiilsel (2) meetodil. Arendus algas faasis, kus klient ei teadnud, mida ta täpselt soovib,
nõudeid ei olnud kogutud ning arendajad ei kujutanud üldse ette, mis
juhtuma hakkab.
Pandi kokku esialgne kavand ja alustati arendusega, samal ajal selgus kliendi poolt iga nädal üha uusi nõudmisi, millest jooksvalt ka arendajatele teada anti. Arendajapoolne projektijuht kurtis, et sel viisil töötades ei ole võimalik mingit minimaalset toodet testimiseks anda, kuna kogu aeg midagi muutub ja infot tuleb aina juurde ning kõigega tuleb kohe arvestada. Infovahetus oli tegelikult päris hea: lisaks meilisuhtlusele toimusid iganädalased koosolekud, kus ettevõte koos arendajatepoolse projektijuhiga hetkeseisu üle vaatas.
Mõni kuu pärast projekti algust selgus, et kõige optimaalsem lahendus loodava tarkvara jaoks vajaks hoopis teist tehnoloogiat kui algselt plaanitud. Vastastikusel kokkuleppel vahetati välja projekti põhitehnoloogia ning kõik arendajad, kuna selgus, et paremini sobiva tehnoloogiaga on kursis hoopis teine arendaja ning koos sellega vahetus ka projektijuht. Edaspidi oli kogu projekt sõltuv ühe konkreetse arendaja saadavusest, mis põhjustas tihti arenduses pikemaid pause. Tundus, et agiilne arendus ühe mehe variandina väga hästi ei töötanud, kohati oli arendaja olulise info kõrvust mööda lasknud ning mitte iga kord ei ärganud ta hommikusteks kliendikohtumisteks üles. Rutiinsed koosolekud asendusid jooksvatega ning projektist kadus viimanegi korrapärasus.
Teoorias peaks agiilne arendusmeetod tähendama
seda, et alguses tehakse mingi väiksem kärbitud funktsionaalsusega variant,
mida järk-järgult täiendatakse ja korrigeeritakse vastavalt kliendilt saadud
tagasisidele. Tööd peaks olema jagatud väiksemateks testitavateks tükkideks,
mida saaks eraldiseisvalt arendada (3). Antud juhul oli alamosadeks jagamine keeruline,
kuna tegemist oli integratsiooniga ning info puudulikkus takistas funktsionaalsuse loogilist tükeldamist. Palju nõudeid selgus mitme kuu jooksul ning sellise integratsiooni osaline teostus projekti keskel polnud ei mõistlik
ega ka normaalse pingutusega tehtav.
Projekti kogu kestvus venis kaheksa kuuni ning
jättis endast maha üsna kopsaka koguse lahendamata probleeme.
Tagantjärgi tarkusena peab tõdema, et kui tahes agiilne meetod ei suuda kompenseerida puuduvat visiooni ning puuduvaid nõudeid kliendi poolt, kes muuhulgas ootab, et arendaja teeks ära kogu projektijuhtimise poole. Arendusega ei tohiks alustada enne, kui klient on vähemalt mingi koguse infot soovitavast tootest kokku pannud ning ettevõttesiseselt läbi arutatud. Soovitus tulevikuks: "Väida, et tuleb kosemudel, küsi plaani ja nõudeid ning kui need on käes võib alustada agiilse arendusega."
Ärimudel SaaS
Software as a service tähendab enamasti tarkvara
müüki/renti, kus kliendil on mingi määratud perioodi jooksul õigus tarkvara kasutada. Sobib
eriti hästi juhtudel, kui kliendil on lühike tähtajaline projekt,
mis nõuab spetsiifilist tarkvara funktsionaalsust, kuid omandvara ainult ühe lühikese projekti
jaoks osta ei tasu.
Näiteks toon Canva disainimiseks mõeldud
tarkvara (4), mis on saadaval läbi
veebi kasutajapõhise tarkvarana. Canva pakub osa funktsionaalsust tasuta, kuid
keerulisemate kujundustööde jaoks on vaja juba tasulist versiooni. Canva puhul on eriti mõnus, et loodud kasutajakonto
ja kujundused jäävad alles ka siis, kui tasuline versioon vahepeal katkestada. Toimib suurepäraselt klientide jaoks, kellel vahepeal töövoogu pause tekib ning nendel perioodidel on võimalik tasuline
teenus peatada.
Võrreldes omandvara ärimudeliga on SaaS kasutamisel
väiksem kulu tööga alustamisel ning kui midagi üldse ei sobi, saab renditud
tarkvara kasutamise peale esimest perioodi lõpetada.
Enamus SaaS tarkvara rendilepinguid pikeneb
automaatselt ja klient saab eelmise perioodi lõpus arve järgmise perioodi eest,
kui ta ise eelnevalt teenust tühistanud ei ole. See on kaval viis hoida kliente ja
vähendada ühe perioodi müümise peale kuluvat ärilist „pingutust“. Canva puhul aitab kaasa ka tasuta konto säilimine ning osaline tasuta funktsionaalsus.
Kommentaarid
Postita kommentaar