E-teenuste arendusprotsessid ja töövood

Käesolev peatükk annab põhjaliku ülevaate sellest, kuidas peaks toimuma kasutajasõbralike e-teenuste arendus ning kuidas kulges sama protsess Maanteeametis. Arvestama peab sellega, et Maanteeameti projekti raames piirdus ülesanne funktsionaalsuste ärianalüüsi koostamisega. Veebistrateegia protsess on Maanteeametis läbimata, raami wireframe’id ja disain töötati välja eraldiseisva hanke raames. Käesoleva projekti lõpptulemuseks olid funktsionaalsuste disainid ning ärianalüüsi dokumendid, mis olid edasiseks sisendiks IT analüüsi ja realiseerimise etapile. Antud projekti elluviimise ajal ei olnud veel tegeldud e-teenuste sisu tootmise ega integratsiooni ja juurutuse etapiga.

E-teenuste arendusprotsess koosneb viiest suuremast etapist (vt allolevat joonist), kõik need on pikemalt lahti kirjutatud antud peatükis allpool. Oluline on, et kõik need etapid kindlasti läbitaks vastavalt ettenähtud sammudele. Eirates osa protsessist langeb lõpptulemuse kvaliteet, kuidas täpsemalt, on selgitatud vastavas peatükis.

Kogu arendustöö esimeseks etapiks ja eelduseks ülejäänule on veebistrateegia ja roadmapi koostamine. See osa protsessist jäetakse kõige kergemini kõrvale erinevatel põhjustel, kuid see moodustab tugeva vundamendi kogu ülejäänud arendustööle. Teise etapina on oluline välja töötada e-teenuste keskkonna raami wireframe’id ja disain ehk asutuse digitaalne stiiliraamat. Korrektne stiiliraamatu väljatöötamine vähendab oluliselt funktsionaalsuste ja sisu tootmisel kulutatavat aega ja raha. Funktsionaalsuste äri- ja IT analüüsi ning realiseerimise etapp ning sisu tootmine saavad pärast raamistiku väljatöötamist edasi liikuda küllaltki paralleelselt, nende mõlema valmides saab alustada funktsionaalsuste ja sisu integreerimise ning juurutusetappi. Juurutusetapp ei lõpe e-teenuste avalikuks muutumisel, vaid ca 6 kuud pärast lansseerimist koos nn 1.5 versiooni valmimisega.

Arendusprotsessi etapid ei pea ilmtingimata toimuma üksteise järel, teatud ülekattumine erinevate protsesside vahel on täiesti võimalik, mis omakorda võib anda kogu protsessis olulise ajavõidu. Hoolikalt protsesse tihendades on võimalik arenduste kestust kokku suruda kuni kolmandiku ulatuses. Oluline on see, et suurem osa konkreetse etapi tulemist oleks piisavalt paigas, et võib olla suurel määral kindel, et otsustuspunktides ei toimu enam fundamentaalsete aluste muutumist. Näiteks juhul, kui alustatakse funktsionaalsuste ärianalüüsiga enne raami disaini kinnitamist, on taoline ülekattumine võimalik kuni punktini, mil hakatakse funktsionaalsuste disaini välja töötama. Kui plaani järgi hilisem disainietapp algab enne raami disaini lõpetamist, on oht kogu hilisema töö ümbertegemiseks ning ei pruugita saavutada isegi oodatud ajavõitu.

Veebistrateegia ja roadmapi koostamine

Veebistrateegia koostamise tähtsus ning strateegia sisuosad on toodud peatükis 3.?. Antud protsess koosneb viiest peamisest tegevusest, kahest tulemist (veebistrateegia dokument ning arenduste ajakava ehk roadmap) ning ühest olulisest otsusekohast (strateegia ja roadmapi juhtkonnas kinnitamine).

Nagu eespool öeldud, siis Maanteeamet jättis kogu selle protsessi taolisel kujul läbimata ning piirdus suurel määral peamiste strateegiliste pidepunktide kirjeldamisega. Tulemuseks oli see, et funktsionaalsuste arenduse käigus tuli jooksvalt leia vastus ka kõikidele strateegilistele küsimustele. Kuna strateegilised otsused nõuavad terviklikku lähenemist, küllaltki laia eelinfot ning paljude erinevate üksuste osalust, siis tähendas strateegia koostamata jätmine nii arenduste kui analüüside korduvat ümbertegemist, arenduste aja venimist ning täiendavat ressursikulu nii väliste partnerite kui majasiseste spetsialistide aja osas. Heaks näiteks siinkohal olid hanke aluseks olnud eelanalüüsi dokumendid, mis hilisemas reaalses elus praktiliselt üldse kasutust ei leidnud. Eelanalüüsi dokumendi alusel loodud vaated ning funktsionaalsus ei vastanud ei organisatsiooni ega kliendi vajadustele ning andsid vähe sisulist väärtust edaspidiseks, ühe teenuse puhul olid teenuse omanik ning analüütik kirjeldanud teenust teineteisest mööda täiesti erinevate keskkondade tarbeks. Seni, kuni organisatsioon ei oma ühist tegevusplaani e-teenuste osas või on plaan kommunikeerimata, on taolised möödarääkimised tavapärased.

Vajaduse kirjeldamise faasis peab kanali omanik läbi töötama organisatsiooni strateegia ning sellest välja noppima need punktid, mida tema ning juhtkond peavad realistlikuks saavutada või kaasa aidata. Selle etapi tulemusena moodustub paarileheküljeline kirjeldus, mida organisatsioon e-teenustest ootab ning selle põhjal on võimalik hakata järgmiste etappide abil kasvatama strateegia sisulist poolt.

Intervjuude faasis peab kanali omanik sõltuvalt organisatsiooni suurusest läbi viima 15-30 ca 1-1,5 tunnist intervjuud kõikide organisatsiooni võtmeisikutega, välistades ainult tõesti e-teenuste kauged ametikohad. Antud faasi ülesanne on koguda erinevate valdkondade ootusi e-teenustele, prioriteete, olulisemaid eesmärke, tänaseid murekohti, takistusi, üksuse valmisolekut e-teenuste arendamiseks. Tähtis on leida muutused, mille elluviimine e-teenustes aitaks viia kiirete läbimurreteni (nn kiired võidud), sest see aitab süstida usku organisatsioonis e-teenuste arendamise vajalikkusest. Antud etapi lõpptulemusena peab kanali omanik sünteesima kokku organisatsiooni kui terviku vajaduse e-teenuste osas. Konkreetseid reegleid on siin raske anda, kuid sisendi tähtsamad punktid on kas tihedalt äristrateegiaga seotud teemad, kiiremaid ja suuremaid võite andvad teemad ning paljude osapoolte poolt nimetatud murekohad. Antud faasi tulemusel moodustub tervikuna organisatsiooni ootus e-teenustele.

Kolmandas faasis on kanali omanikul tarvis läbi töötada rida sisendeid ning täiendada selleks hetkeks formeerunud strateegiat. Kliendiuuringud, olemasolevate e-teenuste kasutajate tagasiside, teenuste kasutamise statistika ning veebistatistika, organisatsioonisisene aruandlus on peamised infoallikad ning annavad kanali omanikule parema mõistmise, mida numbriliselt on võimalik e-teenuste abil saavutada ning mida ootab e-teenustelt nende kasutaja – organisatsiooni klient. Antud osa lõpuks on veebistrateegias selgelt paigas ka kasutajate ootused. Samuti on suures osas hakanud formeeruma kasutajate ja organisatsiooni vajaduste põhjal visioon sellest, milline peaks olema e-teenuste oodatav terviklahendus, peamised funktsionaalsused ning nn võtmevõimalused, mis annavad suurima ja kiireima väärtuse.

Neljanda faasina toimubki organisatsiooni veebistrateegia terviklik koostamine. Antud etapis kogutakse veel detailsemat informatsiooni erinevatelt valdkondadelt, et konkretiseerida tekkivat plaani, otsitakse informatsiooni puuduvate osade tarbeks, viiakse vajadusel läbi täiendavaid intervjuusid ning tehakse täiendavaid uuringuid kasutajate seas. Antud etapis on väga soovitatav teha juba esmaseid tervikplaani tutvustusi, et saada plaani koostades juba võimalikult sisulist tagasisidet. Vältida tuleks veebistrateegia tutvustamist esmakordselt alles siis, kui kogu plaan tervikuna valmis on, väga suure tõenäosusega nõuab antud strateegia tihedat parandamist ja arutamist. Ideaaljuhul oleks hea luua ka mõni visuaalne pilt veebistrateegia põhjal loodavast keskkonnast, kuid see ei ole kohustuslik. Antud faasi lõpptulemuseks on juba valmis veebistrateegia – siiski ei ole mõtet seda enne juhtkonda kinnitama minna, kui strateegiasse on integreeritud ka selle elluviimisplaan ehk roadmap.

Antud etapi viimane faas ongi tegevusplaani koostamine. Siin koostatakse finantsvaldkonna abiga kulude ja tulude hinnangud, koostöös teenuseomanike ja arendusüksustega koostatakse võimalik tööde järjekord, ajaplaan ning ressursivajadus. Kui veebistrateegia vaatab kuni 3 aastat tulevikku ja võib sisaldada osi, mis ei ole koheselt realiseeritavad ning nõuavad teatud eelduste täitmist, siis tegevusplaan on väga konkreetne, peab olema realiseeritav ning usutav kogu organisatsioonile.

Strateegia ning plaani lõplikul valmimisel on tarvis antud dokumendid kindlasti kinnitada juhtkonnas. See on väga oluline otsustuspunkt ning seda ei tohi kindlasti ära jätta ega juhtkonnal lasta sellesse pealiskaudselt suhtuda. Veebistrateegia on lahutamatu osa organisatsiooni strateegiast ning plaani põhjal muudetakse suurt osa organisatsioonist, seega peab kanali omanikul ja e-teenuseid arendaval meeskonnal olema organisatsiooni tippjuhtkonna tugi. Juhul, kui veebistrateegia ja tegevusplaan ei leia heakskiitu, tuleb strateegia koostamisega liikuda tagasi vastavalt probleemide suurusele mõnda varasemasse faasi ning teha vajalik eeltöö ning strateegia koostamine uuesti, kuni plaan vastab organisatsiooni ootustele ja vajadustele.

Raami wireframe ja disain

E-teenuste keskkonna disainimise töö saab laias laastus jagada kolmeks suureks kujundusetapiks – raami, sisu ja funktsionaalsuste disain. Kuigi tihtipeale on teenuse omanikel ja kommunikatsiooniüksusel tahtmine saada kiirelt korda just neid huvitav sisu ja funktsionaalsus, on siinkohal väga oluline enne saada korda keskkonna raamistiku disain. Raam koosneb menüüdest, päisest, jalusest, läbivatest elementidest ning sisuala põhimõtetest. Järjekord on väga oluline seepärast, et sisualas olev materjal pärib kujunduse ja põhimõtted raamilt, mitte vastupidi. Vastupidiselt tööd tehes läheb osa kujundusest prügikasti või on lehekülgede kujundused väga erinevad ning ei taga ühtset kasutajakogemust keskkonnas.

Raami disaini loomise eelduseks on kindlasti organisatsiooni stiiliraamatu olemasolu, mis on piisavalt värske, et vähemalt paar-kolm aastat stiiliraamatu peamised põhimõtted ei muutu. Organisatsiooni stiiliraamat ei pea sisaldama internetikeskkonna stiiliraamatut ning on isegi parem, kui antud osa ei ole välja töötatud. Vanad kasutajaliidese põhimõtted ei ole tihtipeale rakendatavad uues keskkonnas ning uue kasutajasõbraliku e-teenuse käigus töötatakse uus interneti stiiliraamat välja.

Puuduva või aegunud organisatsiooni stiiliraamatu põhjal kasutajaliidese loomine on väga keeruline ning vaevaline protsess. Kui veebistrateegia puudumisel käivad strateegilised arutelud iga funktsionaalsuse arenduse juures, mis suurendavad nii arenduste ebaõnnestumise riski, pikendavad protsesse ning suurendavad arenduste kulusid, siis stiiliraamatu puudumisel käivad e-teenuste kasutajaliidese loomise käigus organisatsiooni põhiväärtuste arutelud, organisatsiooni peamiste arengusuundade diskussioon ning organisatsiooni soovitava kuvandi arutelud. Veebi kasutajaliidese loomise protsessist areneb välja täismõõduline organisatsioonisisene diskussioon. Veebidisainerid ei ole pädevad organisatsiooni põhiväärtuste loojad, seega ka see protsess ajaliselt venib märkimisväärselt, kasvab kasutajaliidese ebaõnnestumise risk ning õigeaegsete otsuste puudumisel kulub kogu tulemuse saamiseks märkimisväärselt enam raha.

Maanteeametis loodi kasutajaliides antud funktsionaalsuste arendusest eraldiseisva hanke alusel, mille raames loodi lisaks stiiliraamatule ka kahe funktsionaalsuse kujundus. Mõne funktsionaalsuse või sisuosa lisamine raami disaini hankesse on väga mõistlik, sest sel juhul kontrollitakse reaalsete lehtede baasil stiiliraamatu toimivust. Antud hanke nõrk koht oli organisatsiooni stiiliraamatu puudumine, mis tähendas eelpoolmainitud ohtude realiseerumist. Stiiliraamatu väljatöötamise protsess venis oluliselt organisatsioonisiseste kuvandivaidluste tõttu, samuti toimus stiiliraamatu põhimõtete otsustamine (värvid, fotokasutus) sageli mitmekümnete erinevate variatsioonide põhjal, mis raiskas oluliselt kõigi osapoolte aega ning ei taganud parimat disainitulemust.

Raami disaini protsess koosneb viiest suuremast tegevusest, kahest olulisest tulemist ning ühest tähtsast otsustuskohast (vt joonist).

Raami disaini loomise protsess algab kanali omaniku ajurünnakutest kommunikatsiooniüksusega, mille käigus koostatakse uue e-teenuste keskkonna esmane struktuur. Oluline on töötada esmase struktuuri kallal kitsas ringis, sest vastasel juhul on esmaseid sisendeid liiga palju ning on raskendatud erinevate osapoolte huvidest vaba struktuuri loomine. Tõenäoliselt tuleb antud seltskonnaga pidada mitmeid koosolekuid, sest ühe korraga kindlasti peamisi fookuseid paika ei saada. Esmane struktuur peab aluseks võtma organisatsiooni poolt pakutavad teenuste rühmad kliendi vaatenurgast, organisatsiooni ülesehitust ning sisemist struktuuri selles etapis arvesse võtta ei tohi. Esmase struktuuri koostamisel on mõistlik paika panna 1. ja 2. taseme navigatsioon, sügavamale liikumine ei ole selles etapis otstarbekas. Struktuurifail oleks mõistlik üles ehitada tabelina.

Teine etapp on ajurünnakud toodete ja teenuste omanikega. Nende ajurünnakute eesmärk on võtta aluseks esmane koostatud struktuur, verifitseerida antud omaniku vastutusalasse kuuluvate teenuste asukoht struktuuris ning koostada detailsem struktuur teise ja kolmanda tasemena. Selles etapis tuleb läbida sisuliselt kõik teenuseomanikud väiksemate koosolekutena – sel viisil saab tutvustada teenuste omanikele uue struktuuri põhimõtteid ning samas fikseerida vajalikud detailid. Antud koosolekutel üldjuhul enam ei kuulu arutlusele keskkonna struktuuri üldpõhimõtted, vaid oluliste vigade korral tuleb liikuda saadud tagasiside põhjal uuesti tagasi esimese sammu juurde ning muuta esmast struktuuri. Antud protsess kestab tüüpiliselt nädala kuni paar ning võib vajada veebistrateegia tutvustamist eeltingimusena.

Struktuuri valmimisel, kui enam sisulisi täiendusi ei tule, saab liikuda kolmanda ja neljanda faasi juurde ehk struktuuri põhjal raami wireframe’ide loomise juurde. Antud töö peaks tegema juba professionaalne veebiarenduspartner, sest sobiva navigatsioonilahenduse valimine on juba vastavaid eelteadmisi nõudev tegevus.

Kui keskkonna põhimõtteline küljendus on valitud, saab asuda organisatsiooni stiiliraamatu ja olemasoleva wireframe’i põhjal kujundamise kallale. Kujundustöö puhul tuleb arvestada mitmete iteratsioonidega – sobiva lõpptulemuseni jõutakse samm-sammult lähemale ning kindlasti esimese korraga tulemus ei ole selline nagu soovitud.

Vältida tuleb kujundustööd sel viisil, kus veebidisaini partner esitleb pärast nädalaid omaette töötamist lõppversiooni. Kuigi tellija ei pea nägema kõiki variatsioone, peab antud koostöö baseeruma regulaarsetel iganädalastel kohtumistel, kus tutvustatakse valminud tööd, kogutakse tagasisidet ning töötatakse lahenduse parandamise kallal.

Kõrvuti wireframe’ide koostamise ja disainitööga organisatsiooni sees peaks veebiarenduspartner testima oma lahendusi süstemaatiliselt ka kvalitatiivsete kasutajauuringute raames. Disainipartneri käest on oluline nõuda, et nende väljatöötatud lahendus oleks jooksvalt saanud kvalitatiivset tagasisidet ka kasutajate esindajate käest, see peab tänases veebiarendusmaailmas olema standardne lahendus.

Kahe seltskonna (organisatsiooni seest ja kasutajate käest) saadud tagasiside põhjal valmib sõltuvalt organisatsiooni suurusest 1-3 kuu pikkuse iteratsioonide jada tulemusel lõplik raami kujundus ja stiiliraamat.

Raami kujundus ja stiiliraamat tuleb kooskõlastada kindlasti ettevõtte juhtkonnas või juhtkonna poolt määratud e-teenuste arenduste järelvalveorganis (projekti steering, brandinõukogu vms). Kuna loodud lahendused ning stiiliraamat dokumendina mõjutavad olulisel määral ettevõtte kuvandit ning kõiki edaspidi loodavaid lahendusi, on tarbetute diskussioonide vältimiseks oluline saada sellele juhtkonna kinnitus.

Kuna kujundus on valdkond, kus igal inimesel on oma eelistused ning arusaam lihtsast ja ilusast lahendusest, siis kooskõlastust hankimata on oodata tarbetuid vaidlusi sisuliselt iga funktsionaalsuse ja sisulehekülje juures.

Funktsionaalsuste arendus

Funktsionaalsuste arendus on koosneb laias laastus kahest suurest osast – äriarendusest ning IT arendusest. Antud käsiraamatus on käsitletud eelkõige esimest, sest IT arendusele on pühendatud rida teisi käsiraamatuid, mis on suunatud IT valdkonna juhtidele ja spetsialistidele. Käesoleva käsiraamatu lugeja jaoks on olulisem mõista, kuidas käib eelkõige äriarenduse faas. Äriarenduse faas oli ka see etapp, mida antud hanke raames Maanteeametis piloodina läbiti, muid valdkondi (sh IT arendus) antud piloot ei puudutanud.

Äriarendusfaas koosneb neljast olulisest ning teineteisega väga tihedalt seotud protsessist (vt joonist). Esimene ja väga oluline etapp on iga funktsionaalsuse puhul eelanalüüsi dokumendi koostamine. Algab see organisatsiooni eesmärgi (soovitud lõpptulemuse) ja kasutajate vajaduste defineerimisest, millele lisatakse juurde antud funktsionaalsuse tänane olukord, teadaolevad piirangud, seotud infosüsteemid, seadusandlus jms.

Täpsem nimekiri eelanalüüsi dokumendis kaetavatest teemadest on toodud käsiraamatu lisas, kus on ka eelanalüüsi dokumendi näidis. Eelanalüüsi dokumendi koostab organisatsiooni sisene või välise arenduspartneri ärianalüütik koostöös teenuse omanikuga. Kanali omaniku roll on siin eelkõige jälgida, et valminud eelanalüüsi dokument vastaks veebistrateegiale ning teiste teenuste ülesehitusele.

Maanteeametis oli projekti käigus koostatud väga põhjalikud eelanalüüsi dokumendid. Antud dokumendid olid sisukad ning katsid ära kõik vajalikud teemad, andes funktsionaalsusest suurepärase ülevaate, kuid ebamõistlikuks osutus tuleviku vaate kirjeldus. Mõistlik on koostada eelanalüüsi dokumendi protsessikirjelduste osa „as-is“ põhimõttel ning piirduda visiooni kirjeldamisel üldiste põhimõtetega. Ärianalüüsi ning ajurünnakute raames töötatakse välja uus protsess ning lahendus ning tulevase protsessi ning lahenduse kirjutamine peaks toimuma lõpliku analüüsidokumendi koostamise raames.

Kui eelanalüüsi dokument on valmis, liigub töö kolmesammulisse ahelasse, mida läbitakse iga teenuse puhul täpselt niipalju kordi kui on vajalik lõplikult sobiva funktsionaalsuse lahenduse väljatöötamiseks. Sarnast meetodit kasutati Maanteeameti teenuste lahenduse loomisel ning see tagas suurepärase tulemuse.

Kolmesammuline ahel algab alati ajurünnakuga, kus peaks kindlasti osalema kanali omanik, teenuse omanik(ud), arenduse projektijuht, disainipartneri analüütik, ärianalüütik ning IT analüütikud. IT projektijuhi, arhitekti jt osalemine võib olla kasulik, kuid arvestama peab, et tegemist on siiski veel ärianalüüsi etapiga ning olulist infot kõigi jaoks ei pruugi veel piisavalt olemas olla. Antud ajurünnakut võiks juhtida kas kanali omanik või antud funktsionaalsuse arenduse projektijuht, eelistatavalt isik, kes on kõige motiveeritum ja kogenum lihtsate lahenduste loomise osas. Maanteeametis juhtis koosolekuid disainipartneri projektijuht – antud juhtumil tagas see kõrgema kvaliteediga tulemuse, kuid üldjuhul peaks selliseid koosolekuid vedama siiski tellija esindaja.

Esimese ajurünnaku tulemusel saadakse paika teenuse põhiline protsess internetis, arutatakse läbi tekkivad detailsed küsimused ning tekib suurem osa ärilisest ja ka IT lahendusest. Kuna antud arutelude käigus mõeldakse ühiselt läbi suur hulk sisulisi detaile, siis on äärmiselt oluline, et nii ärianalüütik kui IT analüütik teeksid koosolekul olulisi märkmeid, mida nad oma analüüsidokumentides kajastama peavad. Kuigi koosolekuid protokollitakse küllaltki detailselt, on antud faasi eesmärk eelkõige lahenduse loomine ning ärianalüütikule ja IT analüütikule vajalike detailide ülesnoppimine on nende kohaloleku peamine ülesanne. Maanteeametis oli puuduseks just IT analüütikute puudumine või passiivne osalus koosolekutel, mistõttu ei saanud õigel ajal kirja suurem osa olulistest märkmetest.

Ajurünnaku tulemusel tekkinud sisendi põhjal joonistatakse disainipartneri poolt funktsionaalsuse wireframe’id ning võimalusel ka disain. Kuna Maanteeametis tegi wireframe’e ning kujundust sama partner, siis jäeti vahele wireframe’ide osa ning joonistati lahendus kohe valmis disainina. Antud lahendus tagab küll kõrgema kvaliteedi, sest ülevaatekoosolekutel vaadatakse juba päris disainilahendust, kuid pigem soovitaks siiski kõigepealt joonistada valmis funktsionaalsuse must-valged (vajadusel natukese värviga) wireframe’id ning kui see on detailideni kokku lepitud, siis teha wireframe’ide põhjal värviline disain. Soovitus on kasutada võimalusel wireframe’ide ja disaini loomisel sama partnerit, vastasel juhul peab koosolekutel osalema ka wireframe’e ja kasutajaloogikat ülesehitava partneri analüütik ning on täiendav oht lahenduse nõrgenemiseks (keskpärasemaks muutumiseks). Mida rohkem on koosolekul osapooli, seda nõrgemaks kipub lahendus muutuma.

Kui esmane wireframe (ja disain) on valmis, siis tuleb see järgmisel koosolekul sama meeskonnaga detailselt üle vaadata, arutada parandusettepanekuid, otsida vajadusel täiendavat informatsiooni, töötada välja uus või parandatud lahendus. Taas järgneb wireframe’ide ja disainietapp ning järjekordne ajurünnak. Antud ahel käiakse tüüpiliselt läbi ca 3 korda, raskematel ja keerulisematel juhtudel 6-8 korda. Mõistlik on antud protsess läbida võimalikult tiheda ajakava alusel – kohtumised kaks korda nädalas on paras, et hoida arenduses üleval kiiret tempot ning vältida tähelepanu hajumist. Maanteeametis töötati kolme funktsionaalsusega paralleelselt 2 korda nädalas.

Selleks hetkeks, kui disainietapp on viimast korda läbitud, on valmis järgmised dokumendid – ärianalüüsi dokument ning funktsionaalsuse disainid, lisaks ka wireframe’id ja ärianalüüsi osana protsessikirjeldus. Disainid ei ole joonistatud päris igale vaatele, vaid need joonistatakse kõigile põhivaadetele arvestusega, et kõik võimalikud käitumismustrid on kaetud, aga sarnase loogikaga osad lehel käituvad kõikjal sarnaselt.

Järgmise etapina liigub arendus IT töölauale, kus läbitakse üldplaanis arhitektuuri, IT analüüsi ning arenduse faasid. IT arenduses oleva protsessiosa jooksul võib juhtuda, et IT tehnilisest lahendusest tingitud muudatuste tõttu tuleb veel põgusalt läbida disaini, halvemal juhul wireframe’ide või eriti halval juhul ka ajurünnakute faas.

Sel juhul tuleb arendus tagasi äri töölauale ning koostatakse uued ärianalüüsi dokumendid ning disainid. Kui arendus aga on piisavalt kvaliteetselt ka IT-s valmis, liigub töö edasi juurutusfaasi, kus töö tuleb taas tagasi aktiivselt ka teenuse ja kanali omaniku töölauale.

Sisu arendus

Sisu arenduse etapp on olemuselt sarnane funktsionaalsuse arendusele. Suurima erinevusena on siin tunduvalt väiksem IT tehniline roll, mis tähendab, et lõviosa tööst tuleb ära teha teenuste omanikel ning kommunikatsiooniüksusel – tehniliste nüansside asemel tuleb märgatavalt enam tähelepanu panna kasutaja tajumisele ning sõnumi kvaliteetsele esitamisele.

Hea e-teenus sisulises mõttes on just selline teenus, mis on lugeja jaoks lihtne, arusaadav ning kus kõik olulised nüansid on välja toodud. Hea sisulehekülg ei ole massiivne tekstiplokk, vaid kvaliteetselt küljendatud ning kogu alajaotuses olulisele võimalikult palju tähelepanu tõmbav lehekülg. (Näited)

Selline lähenemine tähendab hoolikat sisu ja struktuuri läbimõtlemist ning kvaliteetset kujundustööd. Vältimatu on toimetajate kaasamine sisu arendusse, ideaalis ka tõlketoimetajate kaasamine. Sisuliselt on kvaliteetse e-teenuse sisu loomine sarnane ajakirjanduses tehtava tööga ning sisulehtede lõplik kuju peabki sarnanema ajakirjanduses kasutatud küljenduse ning sisu ülesehitusega.

Maanteeameti projektis liiguti sisu loomise juurde hilisemas etapis ning seetõttu ei ole võimalik analüüsida antud projekti raames hästi või halvasti tehtud osi. Antud peatüki protsess baseerub seetõttu täielikult autorite varasematel sisuloomise kogemustel erinevatest suurorganisatsioonidest.

Sisu tootmise protsess koosneb kuuest erinevast etapist, millel on kaks olulist vahetulemust ning üks otsustuskoht. Sarnaselt funktsionaalsuste arendusele on kogu protsessi puhul väga oluline, et esimestes etappides panustataks võimalikult suur energia ja tähelepanu – kui ajurünnak või vahepealsed otsustuskohad liiga kergekäeliselt läbitakse, töötab lõpuks sobimatu lahenduse kallal vähemalt kuuest inimesest koosnev meeskond. Mida hiljem jõutakse arusaamiseni tegelikust vajadusest, seda enamad inimesed peavad kogu oma töö ümber tegema.

Sisu tootmise protsess algab ajurünnakute etapiga. Enamiku alajaotuste läbitöötamiseks piisab ühest, suuremate ja keerulisemate alajaotuste puhul kahest ajurünnakust. Ajurünnakul osalevad teenuse omanik, vastava teenuste eest vastutav (ja tekste koostav) kommunikatsioonispetsialist, kasutatavusanalüütik ning võimalusel ka lehekülge kujundav disainer ning toimetav keeletoimetaja. Osalejate ring tuleb nendel koosolekutel hoida võimalikult väike – kõik vajalikud spetsialistid peavad kohal olema, niisama huvilistel ei ole mõtet koosolekule täiendavaid arvamusi tooma tulla.

Ühel ajurünnakul töötatakse läbi üks teenus või teenuste alajaotus. Leheküljed peavad looma loogilise terviku ka internetikeskkonna struktuuris. Koosoleku lõpuks peab olema jõutud arusaamisele, milliseid lehekülgi on tarvis antud alajaotuse sisu edastamiseks, kuidas need leheküljed omavahel suhestuvad, kust neile navigatsioonist ligi pääseb, millistest infoosadest antud leheküljed koosnevad, mis on antud sisuosade tähtsuse järjekord igal lehel ning samuti peab olema koostatud visandid sellest, kuidas antud leheküljed olemuselt välja hakkavad nägema.

Oluline märkus: iga sisuosa ei pea ega tohigi moodustada eraldiseisvat sisulehekülge – leheküljed on tänastes keskkondades piisavalt laiad ning ühte alajaotusesse peab mahtuma vähemalt 3-5 erinevat sisuosa. Koosolekutel sündivate visandite näol on tegemist esialgsete kavanditega, lõplikud visandid/wireframe’id joonistab pärast kohtumist valmis kasutatavusanalüütik.

Kavandid, struktuur ning sisuosad protokollitakse üheks terviklikuks dokumendiks, et kõigil oleks ühine arusaam, milles kokku lepiti ning millist tööd peab iga spetsialist oma vastutuslõigus tegema. Kui osalejad ei ole rahul ajurünnaku tulemusega või jäi esimesel koosolekul liiga palju küsimusi lahtiseks, siis tuleb samal seltskonnal koguneda ka teist korda ning koostada uuesti kogu vajalik dokumentatsioon.

Kui osapooled on tulemusega rahul, on järgmise etapina töös kommunikatsioonispetsialist koos teenuse omanikuga ning kirjutatakse kokku koosolekul kokkulepitud tekstid. Tekstid ei pea olema lõplikud ning kindlasti vajavad nad toimetamist, kuid põhiosas peab kogu sisu loodud olema. Sisu loomisel tuleb pidada kinni koosolekul kokku lepitud ning kavanditesse joonistatud sisu mahtudest, lubamatu on kirjutada kordades enam või vähem. Sel juhul tuleb tagasi liikuda ajurünnakute faasi ning joonistada kõik uuesti ümber.

Sisumaterjalide valmimisel liigub töö kujundaja kätte, kes kokkulepitud wireframe’ide ja tekstide põhjal kujundab ning küljendab ettenähtud leheküljed. Kui leheküljed on standardsed ning on teada, millisesse kujundatud templiiti lehekülg mahub, siis kujundusetappi läbima ei pea. Kui lehekülg on unikaalne, sisulises mõttes võtmelehekülg või kui templiite ei ole veel loodud, tuleb antud lehekülg lasta kujundada.

Kujunduse valmimine on otsustuspunkt. Antud pildi ning kaasasolevate tekstide põhjal peavad loodava alajaotuse heaks kiitma teenuse omanik, kommunikatsiooniüksus ning vajadusel veel mõni otsustaja. Sisu edasise realiseerimisega ei tohi enne edasi minna, kui kõik vajalikud osapooled on oma kinnituse andnud. Juhul, kui jätkatakse ilma kinnituseta või tehakse otsus pealiskaudselt, tähendab edasine töö mahavisatud aega ja raha ning sisulist ümbertegemist. Mõistlik on otsused protokollida, et vältida hilisemaid ümbermõtlemisi ning taganemisi. Ebakvaliteetsed alajaotused tavaliselt sünnivadki selles otsustusetapis.

Kui heakskiit on saavutatud, liigutakse edasi tekstide toimetamise etappi. Toimetamine ei tohi piirduda grammatika kontrollimisega, vaid toimetaja peab tagama selle, et antud tekstid oleksid arusaadavad kõikidele keskkonna kasutajatele. Sisuline korrektsus peab säilima, kuid toimetaja võib ja peab kasutama organisatsiooni sõnavarast erinevat keelt.

Tõlkimiseni saab jõuda alles pärast eestikeelsete toimetatud tekstide valmimist. Tõlkima peab toimetatud teksti, mitte toorteksti. Tõlkimisel tuleb eelistada antud keelt emakeelena kõnelevat toimetajat, ideaaljuhul tuleks lasta tõlkide käe alt tulevat materjali veel korra toimetada ka antud keele toimetajal. Kui teiste keelte kasutajate ring on väike, võib täiendavast toimetamisest loobuda.

Kui kõik vajalikud materjalid on toimetatud, võib asuda lehekülje realiseerimisele. Kuna leheküljed on küljendatud, on oluline, et realiseerijal on HTMLi vähemalt kesktaseme oskus ning võimalusel peaks olema tal kogemusi ka CSSi ning skriptide kasutamisel. Keerulisemate lehekülgede realiseerimisel peab kasutama kõrgtaseme front-end arendajat. Realiseerimist võib aja kokkuhoiu mõttes alustada juba ka kujunduste valmimise järel ning esimese valmis lehekülje saab luua originaalkeeles materjalide valmimisel, seega on kogu tervikprotsessi osas võimalik päris märkimisväärne paralleelsus. Seda paralleelsust tuleb ka võimalikult palju ära kasutada, sest valmivate lehekülgede hulk on suur ning vastasel juhul lükkub kogu lehekülje valmimine olulisel määral edasi. Järjekorra mõttes tuleb kõigepealt luua kõik tagumised ja ajas vähemmuutuvad leheküljed, mida enam avalehe või tihedamalt muutuva sisu poole, seda hilisemaks tuleb antud lehekülg kogu valmimise protsessis jätta.

Juurutamine

Juurutamisetapp koosneb keskkonna tervikuks integreerimise, testimise/lihvimise, go live ning live’i järgse arenduse etappidest. Ahelas on üks oluline otsustuspunkt, kus tuleb otsustada, kas olemasolev lahendus on piisavalt hea või vajab veel arendust. Juhul, kui keskkond on kvaliteedi mõttes piisav, saab minna keskkonnaga live’i, vastasel juhul tuleb tagasi liikuda testimise/lihvimise etappide juurde.

Suur osa juurutusetapist on taas nn äripoole panust ja tööd nõudvad, eelkõige just testimisfaasis ning live-järgses kiire arenduse faasides. Juurutusfaasis tehakse tüüpiliselt kaks viga – peetakse antud osa ainult IT pärusmaaks ning arvestatakse liialt lühikese live’i järgse toe ajaga.

Juurutusetapp lõpeb e-teenuste arendamisel ligikaudu 6 kuud pärast reaalset live’i koos e-teenuste nn 1.5 versiooni valmimisega. 1.5 versioon tähendab keskkonna paranduste paketti, mis ei muuda keskkonna ülesehitust märkimisväärselt, vaid parandab rea tehnilisi ja sisulisi vigu ning kasutatavusprobleeme, millele ei ole arendusetappides kas osatud tähelepanu pöörata või on reaalses elus ilmnenud funktsionaalsuse või kasutatavuse osas täiendavaid vajadusi.

Teatud osade ümbertegemise vajadus ei tähenda ebakvaliteetset tööd, suurepärane keskkond ja suurepärane e-teenus vajavad sisendina ka päris lõppkasutaja poolset tagasisidet. Umbes 6 kuud pärast keskkonna lansseerimist on kasutajad jõudnud uue keskkonna loogika ja uuenenud mudeliga kohaneda ning nad suudavad reaalselt hinnata keskkonna kvaliteeti ning nende tagasiside põhjal saab teha muudatusi. Esimese paari kuu jooksul on tavaliselt rahulolu keskkonnaga madalam, kasutajad emotsionaalsemad ning seepärast on kohest tagasisidet keeruline arvesse võtta.

Maanteeametis jõutakse juurutamisetapini alles aasta viimastel kuudel ning juurutusetapp võib neil kesta kuni järgmised paar aastat. Põhjus on selles, et kõiki funktsionaalsusi ei ole võimalik korraga luua, mistõttu on keskkond aktiivses arenduses ja muutumises veel pikka aega. Osade komponentide puhul lõpeb juurutusetapp lõplikult 2014. aasta keskpaigaks. Antud protsessi kohta Maanteeametis seetõttu hinnangut anda ei saa ning käesolev peatükk koosneb autorite kogemusel teiste suurkeskkondade arendamisel.

Juurutusetapi esimene faas on keskkonna integreerimine üheks tervikuks. Eelmiste etappide tulemusel on valminud raami kujundus ja tehniline realisatsioon, kogu sisumaterjal ning funktsionaalsused. Eraldiseisvatena nad kõik kindlasti toimivad, kuid koos kõike tööle pannes tuleb välja rida integratsioonivigu, kasutatavusprobleeme ning lõplikult mitte valmis olevaid tükke. Selles etapis peab kanali omanik pidama lisaks veel lõpetamata tööde nimistule ka nimekirja ülevalolevatest vigadest.

Kõiki neid töid tuleb vaadelda ühe tervikuna, kus kõik probleemid on prioritiseeritud ning nende lahendamisele on loodud selge järjekord iga rolli kaupa. Antud etapis on laual rohkem vigu kui reaalselt enne keskkonna avalikuks minekut ära lahendada suudetakse, seepärast tuleb probleemidega tegeleda vastavalt sellele, milline on nende mõju nii teenustele kui klientidele. Väikese mõjuga vead ja väiksemad iluvead tuleb jätta nimekirjas selgelt tahapoole, keskkonna live’i otsus tuleb teha hetkel, kui vigade hulk on jõudnud kasutajatoe ja kanali omaniku taluvuspiirist allapoole. Ideaalset keskkonda ootama ja otsima jääda ei tohi, vastasel juhul lükkub keskkonna lansseerimine edasi väga pikalt.

Testimisfaasis on teenuse omaniku, kanali omaniku ning kasutajatoe ülesanne väga põhjalikult veel testida kogu keskkonda. IT on oma testimisfaasi selleks hetkeks juba osalt läbinud, antud etapis viiakse läbi nn user acceptance test (UAT). Mitte keegi peale teenuse ja kanali omaniku ei saa öelda, kas teenus toimib äriliselt nii nagu peab ning seepärast peab eriti just teenuse omanik selles etapis funktsionaalsuse ülesehituse testimisele põhjalikku rõhku panema. Kanali omanik kontrollib lahenduse valmisolekut vastavalt seatud kasutatavusnõuetele.

Antud faasi kuluvat inimressurssi tavaliselt tugevalt alahinnatakse – testimise faas on kogu arenduse tervikpilti vaadates põhjalik ja kauakestev ning nõuab väga palju töötunde. Ei tohi olla ootust, et kõik on valminud ideaalselt ja täpselt vastavalt ettenähtud kavanditele. Väljatulevad vead prioritiseeritakse ning lahendatakse vastavalt kriitilisusklassile.

Juhul kui mõni veaparandus võtab rohkem aega kui lansseerimiseni on aega jäänud, tuleb aktiivselt tegeleda möödapääsuvariantide (workaround) väljatöötamisega. Workaroundide väljatöötamine annab tavaliselt märksa enam aega arendusmeeskondadele töötada välja selline lahendus, mis pikaajaliselt ka toimib. Vältima peab suuremate vigade ülepeakaela lappimist, tavaliselt tekitab selline käitumine pigem rohkem vigu juurde kui lahendab.

Siinkohal on otsustuspunkt juhtkonnale või selle poolt määratud projekti järelvalveorganile. Projekti steeringule tuleb anda regulaarne ülevaade kõikidest olemasolevatest vigadest ning nende mõjuulatusest ning kui vigade hulk on talutav, siis määratakse kindlaks lõplik lansseerimise kuupäev. Juhul, kui vigu on palju ning nendega ei ole võimalik live’i minna, tuleb määrata parandusplaan ning määrata uus otsustuskuupäev ning võimalik lansseerimiskuupäev. Sama protsessi tuleb korrata niikaua kuni live’i kõlbulikkus saavutatakse. Projektimeeskonnale on äärmiselt tähtis pidevalt hoida projekti oma kontrolli all ning saada aru, millised on veel keskkonnas olevad vead. Antud ülevaade peab meeskonnal olemas olema igal ajahetkel.

Live’i faas algab mõned nädalad kuni kuu enne reaalset lansseerimiskuupäeva. Faasi pikkus sõltub süsteemi keerukusest ning sellest, kui palju tuleb eelnevalt teha kliendikommunikatsiooni. Mida pikemalt on selles etapis teenuste kasutamine häiritud ning mida elukriitilisemate teenustega on tegemist, seda pikem peab olema ettevalmistusfaas.

Kasutajate teavitamise hulk peab olema mõistlik, Eestis on inimesed harjunud regulaarsete süsteemihooldustega ning juhul, kui süsteem on suuremalt uuenemas, antakse positiivsete ootuste tõttu andeks palju väiksemaid vigu.

IT õlgadele langeb suurem osa lansserimisfaasi muudatustest, äripoole töö algab taas live’i järgse kasutajatoe pakkumisega. Esimese kahe kuu jooksul tuleb kanali omanikul hoida regulaarset sidet kasutajatoega - sõltuvalt teenuse kriitilisusest korra paari päeva jooksul kuni korra nädalas.

Klienditeenindusest, teenuste omanikelt ning otse laekuva tagasiside põhjal tuleb täiendada juba varasemast olemasolevat vigade ja workaroundide tabelit ning tegeleda vastavalt prioriteetsusele nii varasemast ülevaolevate kui juurde tulnud vigade lahendamisega. Ca kuu kuni kaks pärast lansseerimist tuleb läbi viia kasutajate (kvalitatatiiv)uuring ning uurida ka organisatsioonisisest vajadust muudatuste järgi.

Kogu saadud tagasiside formeerub projekti 1.5 plaaniks ehk siit algab täiendava funktsionaalsuse, kasutajamuudatuste, veaparanduste kui sisu täiendamise projekt. Kogu selle miniprojekti raames läbitakse väiksemal kujul kõik juba eelpoolkirjeldatud ahelad, lihtsalt väiksemal ja lihtsustatumal kujul. Muudatuste tegemine live’is peab olema regulaarne ja rutiinne protsess kogu organisatsiooni jaoks.

E-teenuste arendamise projekt tuleb ühel hetkel lõpetatuks lugeda ning meie soovitus on seda teha koos projekti 1.5 lansseerimisega.