Järgnevalt analüüsime Scrum arendusmudelit ning SaaS ärimudelit ettevõtte näitel, kus artikli autor hetkel töötab. Ettevõte on konkreetselt tarkvaraarenduses tegutsenud 1,5 aastat, kuigi on olnud valdkonnas tegev juba varasemalt, ning arendab ühistranspordisektorile suunatud tarkvara.
Veel poolteist aastat tagasi ostis ettevõtte arendustöid sisse tarkvaraarendusega tegelevast firmast ning arendusmudelitest kõige enam vastas tollasele tegelikkusele Waterfall. Tänaseks on liigutud üle Scrum mudelile ning peamine põhjus selliseks valikuks on antud mudeli paindlikus. Arendustsükkel kestab kaheksa nädalat ning sisaldab endast kahte arendussprinti, mis mõlemad kestvad omakorda kaks nädalat. Nende vahele jääb ühenädalane paus, mida kasutatakse backlog’i korrashoidmiseks ning sprindi planeerimiseks. Ülejäänud nädalad kuluvad vastavalt majasiseseks testimiseks, kliendipoolseks testimiseks ning kasutajate koolitamiseks. Kuivõrd reaalselt on Scrum’i ettevõttes juurutatud umbes aasta, on vara öelda, kuivõrd hästi see ettevõtte ja tema klientide vajadused katab. Samas võib kindlalt väita, et kliendi ligipääs dokumentatsioonile Confluencis ning kliendipoolne testimiskohustus aitab arendada kliendi vajadusele paremini vastavat tarkvara ning tagab, et olulised lisafunktsionaalsused ei jää süsteemis riiulile seisma. Samuti on tänuväärt retrod, mis ei aita mitte ainult vigadest õppida, vaid ka tulevikutegevusi paremini planeerida. Olulise lisatähelepanekuna tuleb aga välja tuua, millise kaalu asetab Scrum mudel kliendi poolele. Nimelt ei ole mõeldav Scrum põhine arendus olukorras, kus kliendi poolel puudub kompetents ja ressurss enda rolli täitmiseks.
Ärimudelitest kaldutakse antud toote puhul SaaS mudeli suunas, kuid nagu ka artiklis mainitud, on siingi tarkvara rendi põhise mudeliga piir hägune. Erilist raskust lisab fakt, et tegemist on ühistranspordisektoriga, kus müügitsükkel on sageli võrdlemisi pikk ja keerukas. Täpsemalt võiks väita, et tegemist on kasutuskorra põhise lahendusega, sest tasu arvestatakse müüdud piletite põhiselt. Olukorda lisab keerukust fakt, et üks ettevõte tegevussuundi hõlmab endas tarkvara pakkumist, mis on arendatud pidades silmas konkreetset riistvara. Tegemist pole küll tervikplatvormiga, kuid jätab ettevõttele kohustuse vähemalt teatud osas täita ka riistvara hooldamise rolli. Üldjoontes võib väita, et valitud ärimudel toimib, ning suuremad raskused peituvad pigem turu õiges segmenteerimises ning täiendavate tegutsemisvaldkondade leidmises. Hetkeseisuga jääb puudu äri ning arenduspoole koostööst ning mis jäi eelnevalt mainimata, tegelikult puudub ettevõttes Scrumi mudeli üks osapooli - tooteomanik. Probleemiks on, et täidetakse küll klientide vajadusi, kuid puudub suurem pilt ning täpsem siht vajaduste osas, mida tasuks järgmisena arendada. Samuti on kriitiliseks kohaks küsimus sellest, mida tuleks teenusena pakendada ning millise hinna eest. Arendustundide kõrval on samavõrra oluline projektijuhtimise ning kasutajatoe teenuse pakkumine ning hinnastamine.
No comments:
Post a Comment