Peamine erinevus on analüüsi kogemuse järgi: need, kes alles tahavad analüütikuks saada; need, kellel on juba esimesed kogemused saadud, ja need, kes võiksid teoorias juba ise koolitusi anda. Huvitaval kombel leiab igaüks neist koolituselt midagi uut – kuigi see “midagi” on igal juhul natuke erinev.

Karjäärimuutja – IT valdkonda liikumine ilma koodita

Igas grupis on vähemalt mõni inimene, kes tuleb koolitusele sooviga alustada tööd analüütiku või tooteomaniku positsioonil. Tavaliselt on ta varem olnud kas projektijuht või testija – IT-tiimides on ta juba koos töötanud, aga sees on kõhklus: “kas ma sobin analüütikuks?”.

Teisalt on ka neid, kes tahavad liikuda mõne ärivaldkonna spetsialisti kohalt IT valdkonda, kuid päris programmeerimine tundub liialt hirmuäratav. Analüütikuks või projektijuhiks saamine paistab neile mõistlikum alternatiiv.

Karjäärimuutjatele on tavaliselt väga huvitav, kui koolituse alguses räägime erinevatest rollidest, kes eri tüüpi organisatsioonides analüüsi teevad, ja mis on nende vastutused. Arutelud, kuidas töökuulutustest vajalikku rolli välja lugeda, jätkuvad vahel isegi lõunalauas ja pausidel.

Koolituse käigus leiavad nad enamasti, et analüütiku roll ei ole mingi müstiline salakunst. Kui arutada, mida analüütik päriselt teeb ja mis nende erinevate ametinimetuste taga peitub, siis avastab karjäärimuutja tihtipeale, et ta on paljusid neist tegevustest juba teinud. Lihtsalt nimetatud on seda teisiti.

Kui need pusletükid saavad paika ja mõned augud teadmistes täidetud, on kergem oma asjakohast kogemust ka tulevasele tööandjale arusaadavate mõistetega CV-s esile tuua. Mulle endale on kõige liigutavam olnud see, kui mõni karjäärimuutja saadab hiljem kirja, et ongi analüütikuna tööle võetud!

Algaja analüütik – tean küll, aga ei oska päriselt

Algaja analüütiku väljakutsed on teistsugused. Tal on tavaliselt taskus ülikoolidiplom või paar aastat kogemust, aga peas tiirutavad ikka kümned küsimused: “Kuidas ma teen analüüsi ajakuluhinnanguid? Kuidas ma leian aega, et kõik dokumendid teha, mida ülikoolis õppisime? Ma ju tegin nagu vaja – miks see projekt üle aja läks?” Tal on küll olemas teadmised, kuid kogemust napib – ta ei oska teha õigeid valikuid kõigi nende kümnete võimaluste vahel.

Koolitusel oskavad nad dokumente küll õigesti teha, kuid ahhaa!-moment on see, mis järjekorras ja mis puhul üldse mingit tööriista kasutada. Nad hakkavad mõistma paremini teisi rolle ja protsesse enda ümber; õpivad tegema valikuid ja küsima õigeid küsimusi. Juba koolituse ajal olen tihtipeale saanud tagasisidet, näiteks: “Meil tööl just tuli välja, et projekti skoopi tuleb hakata kärpima. Võtsin meie slaidid ette ja leidsime lahenduse!“

Kokkuvõttes saab algaja analüütik koolituselt selguse: kõik need killud – protsessid, inimesed, dokumendid, tööriistad – moodustavad ühe süsteemi. Ta hakkab kasutama õigeid tööriistu õigel ajal, mis teeb projektid sujuvamaks ja kliendid õnnelikumaks.

Kogenud analüütik – erinevad töövõtted ja kogemused

Ja siis on veel need vanad kalad. Nad on juba aastaid analüütikuna töötanud, oma rutiinid välja arendanud ning protsessidiagrammi või andmemudeli joonistamine on nagu teine emakeel. Nad on minu koolitustel vähemuses ja nad tulevadki eelkõige sellepärast, et kuskil eelarves on koolitusraha ja kogenud IT analüütiku koolitusi on vähe.

Esialgu pika kogemusega analüütikud ehk isegi kahtlevad, kas nad sellelt koolituselt üldse võivad saada, aga peagi saan neilt põnevaid küsimusi stiilis: “Kas keegi päriselt seda meetodit kasutab?” või “Miks seda nii teha, meil on alati teisiti olnud?” Sageli avastavad nad, et on jäänud kinni ühte tüüpi projektide juurde, ning et maailmas on palju rohkem kasulikke töövõtteid – neid luuakse koguaeg juurde! Minu kui koolitaja jaoks on põnevad ka detailsed küsimused spetsiifiliste olukordade kohta, mis ka teistele osalejatele jällegi põnevat konteksti annavad.

Tagasisides ütlevad kogenud analüütikud tavaliselt, et neile meeldis just teada saada, kuidas eri tüüpi projektides töötatakse, ja nad on rahul, et said teistsuguseid töövõtteid katsetada. Mõni isegi tunnistab, et avastas oma teadmistes augu või sai mõne hea nipi, kuidas igapäevast tööd paremini teha. Päris hea tulemus ju, kui tulla “niisama” koolitusrahaga ja leida midagi praktilist!

Mida neist lugudest kaasa võtta?

Kui vaadata neid kolme tüüpilist osalejat, joonistub muster üsna selgelt välja:

• Karjäärimuutja saab enesekindluse, et “analüütik” ei ole niivõrd keeruline töö vaid levinud oskuste rakendamine uuel viisil.
• Algaja analüütik leiab struktuuri – kuidas erinevad tööriistad aitavad ja millal neid kasutada.
• Kogenud analüütik saab värskeid vaatenurki ja mõne uue tööriista oma tööriistakasti.

Kokkuvõttes tähendab see, et sõltumata taustast läheb igaüks koju mingi olulise mõistmisega: “Ahhaa, nüüd ma saan aru, miks see kõik tegelikult tähtis on!”

Ja võib-olla ongi see kõige olulisem õppetund – analüütiku töö ei tähenda ainult dokumentide tootmist või protsesside joonistamist. See tähendab arusaamist, kuidas inimesed, tehnoloogia ja äri kokku käivad. Ja kui see arusaamine tekib, siis läheb ka igapäevane töö palju sujuvamaks.

Tule proovi järele!

Kui sa loed seda ja tunned end ära ühes neist tüpaažidest, siis oled täpselt see, kelle jaoks see kursus loodud on.

Järgmine avalik koolitus toimub 29. septembrist 3. oktoobrini Tartus (koos online võimalusega).
Vaata täpsemat infot ja registreeru siin:

Sellepärast ma kirjutasingi raamatu Optimaalne dokumentatsioon: kasulik, ajakohane ja mugav

Karjääri alguses olin samamoodi frustreerunud. Nägin tihti meeskondasid, kes jätsid dokumentatsiooni tegemata või, mis veel hullem, lõid hunnikute viisi aegunud faile, mida ei saanud usaldada. Äri- ja süsteemianalüütikuna ei saanud ma mööda vaadata sellest, kui palju aega ja raha raisati, kuna õige info polnud õigel ajal kättesaadav. Samas kogesin neid raskusi omal nahal — dokumentatsiooni asjakohase ja ajakohasena hoidmine ei ole intuitiivne tegevus ning keegi ei osanud mulle ka õpetada, kuidas seda teha.

Aastate jooksul õppisin läbi katse-eksituse meetodi dokumenteerimise parimad praktikas, mis aitasid mind järjel püsida. Ma leidsin viisid, kuidas kirjutada kasulikku ja lihtsasti hallatavat dokumentatsiooni, ja mis tõesti toetab meeskonda – ja seda lähenemist ma siin raamatus jagangi.

Siin on mõned mõtted sellest raamatust.

1. Dokumentatsiooni kohta on palju müüte ja halba argumentatsiooni, mis võtab ära motivatsiooni sellega tegeleda

Artikkel “Lükkame ümber 6 müüti dokumenteerimisest” on täielikult raamatusse kaasatud, aga ma räägin seal ka lihtsalt halbadest põhjendustest:

Χ „Peab”, „ülemus käskis”.
Χ Nii on alati tehtud.
Χ See on ju analüütiku väljund.
Χ Lepinguliste kohustuste täitmiseks.
Neid argumente kuulen ma tihti. Kui sina oma töös selliseid põhjendusi kuuled, et lihtsalt
peab või keegi käskis, siis pole imestada, kui ei tunne erilist motivatsiooni dokumentatsiooni
kirjutamiseks. Selliste argumentide puhul tasub alati küsida „miks?” ja see enda
jaoks päriselt lahti mõtestada, muidu on tõesti õigustatud jätta dokumentatsioon tegemata.

1. peatükk: Miks ei taheta dokumenteerida?

Tõeliselt kasuliku dokumentatsiooni kirjutamiseks on oluline aru saada, miks me seda kirjutame, kellele ja milline dokumentatsioon on päriselt abiks.

2. Dokumentatsioon peaks abistama sind ennast

Tihtipeale on nii, et käin kliendiga koosolekul, kus ta mulle oma ideid ja vajadusi selgitab
ja kõik küsimused vastab. Mulle tundub, et kõik on arusaadav… Aga siis hakkan seda
loogilist tervikut kirja panema ja leian, et on veel detaile või lünkasid, mida oleks vaja
täita. Dokumentatsiooni süstemaatiline olemus aitab reaalselt kogu terviku läbi mõelda
ja puudused esile tuua.

2. peatükk: Dokumenteerimine on kasulik sulle endale

Hea dokumentatsioon ei ole ainult auditeerijatele üleandmiseks – see on tööriist mõtlemiseks. See aitab sul varakult üles leida puuduvat infot, vähendab korduvaid seletamisi ja teeb põhjendatud otsuste tegemise kergemaks.

3. Integreeri ajakohastamine oma töövoogu

Üks levinumaid dokumenteerimise vastuargumente on, et “Dokumentatsioon on nagunii aegunud“

Aga see ei pea nii olema ja loomulikult on rohkem kasu ajakohasest dokumentatsioonist.
Ja dokumentatsiooni ajakohasena hoida on ka täiesti võimalik! Selleks tuleb dokumentatsiooni
vastavalt vajadusele uuendada. Loomulikult vajab see kindlat vastutajat, kellel
on järjekindlust ja oskust seda teha.
Seda, kuidas mina olen selle enda jaoks lahendanud, räägin „Ajakohane“ osas. Seal selgitan,
kuidas dokumentatsiooni uuendamise saab integreerida dokumenteerimise loomuliku
osana oma tööprotsessi.

1. peatükk: Miks ei taheta dokumenteerida?

Ma jagan praktilisi viise dokumentatsiooni ajakohasena hoida ka oma artiklis “Alati ajakohane dokumentatsioon on võimalik” – ja raamatus kirjutan selle dokumenteerimise parimate praktikate raamistiku detailselt lahti.

4. Sa ei pea dokumenteerima kõike

Tegusatel meeskondadel ei ole luksust kirjutada romaane. Seepärast keskenduvad minu dokumenteerimise parimad tavad sellele, et dokumentatsioon oleks projekti vajadustele piisava mahuga — nii palju, kui on vaja selguse andmiseks, kuid mitte nii palju, et muutuks raskesti hallatavaks.

Nende mudelite vahel peab targalt valikuid tegema. Näiteks ka maakaardist on võimalik
luua palju erinevaid vaateid – liiklusskeem, elektripaigaldiste info, katastripiirid,
maavarade kaart jpm. Kõiki neid ei ole vaja luua – kui ei ole tegu just keskse geoinfo
teenusega – vaid piisab baaskaardist ja sellele loodud vaatest, mis just meie sihtgrupile
vajaliku info nähtavaks teeb. /…/

Teisalt, jätkates kaardi näitega, saame me valida ka õige detailsustaseme – millisel suurendustasemel
kaarti meil on vajalik mingil juhul vaadata? /…/

IT-süsteemide dokumenteerimisel luuakse tihtipeale dokumentatsiooni erineva detailsusega
vaadetena, kus üldisema tasandi vaatel on komponentideks detailsema taseme
vaated ja nende seosed. Nii tekib hierarhia, kus detailsemal tasemel on palju rohkem
vaateid/dokumente kui üldisematel – ja see tekitab ka mõtte, et ehk ei kirjutaks lahendust
dokumendi tasandil nii detailselt läbi, et halduskoormust vähendada.

6. peatükk: Piisav dokumentatsioon

Vajalike dokumentatsiooni liikide ja üldistuse tasemete läbimõtlemine aitab sul teha dokumentatsiooni osas tarkasid valikuid. See aitab sul hallata oma töökoormust – teha ainult seda, mis on päriselt vajalik. Raamatus ma selgitan, kuidas tuvastada õiged mudelid ja vajalik detailsustase.

Kas oled valmis muutma enda dokumentatsiooni kasulikuks ja kergesti hallatavaks?

Kui oled ärianalüütik, süsteemianalüütik, projektijuht, tootejuht, tooteomanik — või lihtsalt osa hõivatud IT-tiimist —, siis võid lõpetada dokumentatsiooni käsitlemise tüütu kohustusena ja hakata seda kasutama tootlikkuse tööriistana.

Selles raamatus käime samm-sammult läbi kuidas mõista frustratsiooni põhjuseid ja dokumentatsiooni väärtust kuni praktiliste põhimõteteni, kuidas muuta dokumentatsioon tõeliselt kasulikuks, arusaadavaks ja mugavaks. Kuigi mainin vastavalt vajadusele ka standardeid ja raamistikke, keskendub see raamat dokumenteerimise parimatele tavadele, mida saab rakendada igal pool. Teooriale lisaks on enamiku peatükkide juures ka harjutused, mis aitavad sul teemat sügavamalt mõista ja seda just enda dokumentatsiooni ja protsesside puhul rakendada.

Loe täpsemalt raamatust Optimaalne dokumentatsioon: kasulik, ajakohane ja mugav, mis on saadaval nii e-raamatuna kui ka pehmete kaantega väljaandena. Kui soovid teemat kogu oma meeskonnaga samm-sammult läbi käia, on sellel teemal saadaval ka koolitus-töötuba.

“Meil ei olegi analüütikuid!” ja “Ma ei taha enam ühtegi analüütikut oma projektides näha!” on IT-projektides aina levinumad fraasid. Ometi oli enne agiilse arenduse võidukäiku analüütikul IT-arenduse ettevalmistamisel kriitiline roll. Kuidas seda siis nüüd tehakse?

Teemat avab rohkem kui 20-aastase kogemusega süsteemi- ja ärianalüütik Kaja Trees, kes jagab oma kogemusi ka koolituste näol. Ta on pakkunud konsultatsiooniteenuseid erinevates ettevõtetes.

Analüütiku asukoht IT-tiimis

Kaja sõnul jaotub praktikas IT-tiimide ülesehitus ja analüütiku asukoht neis umbes nelja rühma:

1. Meeskond, kus analüütikuid tõesti ei ole.

Iga arendaja teeb aga analüüsi oma arendusülesande kohta. Seetõttu võib lahendus olla ebaühtlaselt läbimõeldud, nn küürakas süsteem. Sellised süsteemid võivad sisaldada duubeldust, tehnoloogilist võlga ja skaleerimise probleeme. Kasutajad on tihti rahulolematud UXiga ja IT-arhitektid tehnilise ülesehitusega.

Probleemiks on üldise pildi koos hoidmine, kui seda teeb nn hivemind ehk taru-mõistus, mitte keskne roll. Loomulikult on olemas tarkvaraarendajaid, kes suudavad ühiselt suurt pilti koos hoida ja vajalikud vestlused kliendiga peetud saada, kuigi väga paljud neist eelistavad keskenduda tehnilisele poolele. Agiilsetes metoodikates on ka palju praktikaid, mis aitavad seda riski maandada. Kaja kogemuses on siiski siin vajalik analüüsi rolli teadvustada, et probleeme vältida.

2. Meeskond, kus analüütik on olemas, kuid teise nimega.

Tooteomanik, IT-arhitekt või isegi Scrum Master võib seda rolli täita, kui tal on vastavad oskused. See on nagu “salaja” analüüsi tegemine, et mööda hiilida rangetest piirangutest.

Ohukohaks on see, et tema muud tegevused võivad saada ebapiisavat tähelepanu, kuigi need on samuti olulised. Kui siin on arendajate ja muude rollide tasakaal paras, siis võib selline meeskond aga väga hästi toimida.

3. Meeskond, kus analüüsi teeb tellija.

See tähendab, et kliendi poolel on tugev ärianalüütik, kes hoiab skoopi ja lahenduse loogilist kooskõla, valmistades ette arendusülesanded (näiteks kasutajalugude kujul) ja jälgides, et lahendus oleks tellija ja kasutaja vaatenurkadest parim võimalik. Ideaalis on tal ka infotehnoloogiline taust, et ta oskaks ära kasutada IT pakutavaid võimalusi ja ei teeks asju liialt keeruliseks. Arendustiimini jõuab juba tööülesanne, mis on arendaja jaoks mõistetav, ta saab keskenduda tehnoloogilisele poolele.

Suurim ohukoht ongi see, kui analüütik ei saa päriselt aru, kuidas IT-süsteemid päriselt toimivad. Siin aitab avatud dialoog IT-arhitekti või arendajatega, kes kaasa mõtlevad ja vajadusel soovitavad väljapakutud lahendusele alternatiive.

Teisalt peab sellises meeskonnas olema kas IT-arhitekt või väga hea arendajate koostöö, et lahenduse kõik osad töötaksid ühtse tervikuna ka tehnilisest vaatepunktist. Kui siin puudub suur visioon, siis võidakse näiteks alustada arendust platvormil, mis on lõpliku lahenduse jaoks ebapiisava skaleeruvusega vmt.

4. Meeskond, kus analüütik on osa arendustiimist.

Analüütiku ülesanne on ette valmistada pileteid samamoodi nagu arendaja ülesanne on neid arendada ja testija ülesanne on neid testida.

Kui tellija poolel puudub tugev tehnoloogiaga kursisolev ärianalüütik, siis peab projektimeeskond selle rolli täitma. Kaja on paljudes projektides sellisel kohal olnud ja näinud, et see võib väga hästi toimida. Siiski näevad stiilipuhta agiilse arenduse toetajad seda kui pühaduseteotust, sest nende arvates peaks arenduspilet olema algusest lõpuni ainult ühe inimese käes.

Analüüs on kriitilise tähtsusega

Oluline on mõista, et analüüs on kriitilise tähtsusega osa igas projektis, olenemata sellest, kes seda teeb. Vaidluste vältimiseks läheneb Kaja analüüsi vastutusele tihtipeale ametinimetustest ja määratletud rollidest mööda vaadates – leides inimese, kes selle vastutuse enda kanda võtab. Analüütik on tema jaoks see inimene, kes teeb analüüsi, sõltumata tema ametinimetusest või meeskonna struktuuris “istumise” kohast. Arusaam, et ainult ametliku “analüütiku” tiitliga inimesed saavad seda tööd teha, on piirav ja vastuolusid tekitav.

Samamoodi on mõeldud Kaja õpetatav “Äri- ja süsteemianalüüsi kursus” kõigile äri- või süsteemianalüüsiga tegelevatele rollidele – lisaks analüütikutele ka arendajatele, tooteomanikele, Scrum Masteritele, testijatele ja projektijuhtidele. See õpetab analüüsi oskusi läbimõeldud teooria ja tagasisidestatud praktika abil ning on investeering isiklikku ja ettevõtte arengusse.

Artikkel ilmus esimesena DigiPRO’s.

Kui eesti keeles öelda sõna ärianalüüs, siis erinevatel inimestel tulevad seda kuuldes pähe erinevad teemad. Kui nüüd inglise keel appi võtta, siis on olemas ärianalüüs ehk siis „Business analysis“, mis tegeleb protsesside kaardistamisega ja ärivajaduste väljaselgitamisega. Lisaks on ka olemas ärianalüüs ehk siis „Business intelligence“, mis tegeleb analüütikaga, numbrite analüüsimisega ja sellest järelduste tegemisega. Siin artiklis ja ka üldiselt sellel lehel räägime me ennekõike sellest esimesest.

Just see segadus analüüsi ja analüütika vahel ongi üks põhjustest, miks mul tekkis tahtmine sellest teemast kirjutada. Teine põhjus on see, et tegelikult olen ma oma karjääri jooksul väga vähe kokku puutunud korraliku ärianalüüsiga. Midagi küll tehakse, aga tavaliselt ilma täpsema arusaamata, mida tegelikult on vaja kaardistada ning ennekõike on eesmärgiks kirjeldada infosüsteemi. Ärianalüüs aga ei tähenda üldse seda, et lõpptulemuseks peab olema infosüsteem. Otse vastupidi, tulemuseks võib olla arusaam, et muuta saab protsesse ja ei ole vaja lisa tarkvara juurde hankida.

Mis on ärianalüüs?

Mis siis aga see ärianalüüs e. „Business analysis“ ikka on? Lühida kirjelduse leiab ka siitsamast ITBAC enda lehelt artiklist Mis on IT- ja ärianalüüs? ja sealt kokkuvõtet tehes on ärianalüüs organisatsiooni muudatuste teostamiseks vajaduste uurimine ja kaardistamine. Seal artiklis on ka ära toodud kaks eri rolli: Ärikonsultant ja Ärianalüütik, kellest esimene kaardistab organisatsiooni üldised vajadused ja muudatuskohad ning teine kaardistab siis juba täpsemalt muudatusega seotud protsesse. Mõlemad need rollid teevad ärianalüüsi, ärikonsultant teeb seda lihtsalt natuke kõrgemal ja üldisemal tasemel kui ärianalüütik.

Ärikonsultandi tehtavat ärianalüüsi me väga põhjalikult ei kirjelda. Kui väga kokkuvõtlikult sellest rääkida, siis nad istuvad koos organisatsiooni juhtidega maha ja aitavad paika panna üldise visiooni ja eesmärgi. Nad kaardistavad erinevaid siseseid ja väliseid mõjutajaid ja leiavad valupunkte ning riskikohti. Selle töö tulemusena pannakse paika edasised eesmärgid ja mõõdikud (inglise keeles KPI – Key Performance Indicators) ning need omakorda võivad olla algatajaks muudatustele.

ITBAC-i põhiline fookus on just ärianalüütiku poolt tehtaval ärianalüüsil. See saab alguse siis kui on teada muudatuse vajadus ja on vaja hakata uurima sellega seotud protsesse ning kuidas seda muudatust realiseerida. Näiteks muudatusvajadused võivad olla järgmised:

• Meie veebipoe müüginumbrid on väga madalad, meil on vaja tõsta veebipoe kaudu tehtavate müükide numbrit.
• Kliendid ei ole rahul, et tagasiside saamise protsess on väga aeglane ja nad pöörduvad konkurentide poole. Tagasiside andmise protsessi peab parendama.
• Seadused muutusid ja firma praegused protsessid ei kata neid muudatusi ära. Protsessid ja tarkvarad tuleb üle vaadata ja kirjeldada ära kohad, mis vajavad muutmist.

Ärianalüütik võtab talle antud probleemi kirjelduse, hakkab seda süstemaatiliselt lahkama ning peale leidude dokumenteerimist saab ka pakkuda välja lahendusvariante.

Ärianalüüsi ei saa alati teha kindlate sammudega, mõne probleemi puhul on vaja teha asju, mida teiste probleemide puhul ei ole vaja teha, aga on mõned üldised tegevused, mis on vajalikud suuremal osal juhtudest:

• Osapoolte kaardistamine (firma sisesed, firma välised jne.)
• Hetke olukorra kirjeldamine (protsessidiagrammid, nõuded jm.)
• Välja pakutud lahendus ja oodatud tulemused (protsessidiagrammid, nõuded jm.)
• Muudatuse väärtuse mõõtmine

Oluline on ära mainida, et välja pakutud lahendus ei saa olla põhjalik IT süsteemi kirjeldus. Ärianalüütiku töö tulemuseks võib olla kirjeldus, et on vaja veebipoodi ja veebipoes peab olema võimalik tooteid ostukorvi panna, aga täpsemalt see IT süsteemi kirjeldada ei tohi. Näiteks järgnev tekst ei ole väga hea ärianalüüsi tulemus:

“Kui kasutaja avab meie veebipoe, siis näidatakse seal toodete nimekirja piltidega. Kui toote pildi peale klikkida, siis avaneb toote leht ja seal saab kasutaja vajutada nuppu toote ostukorvi panemiseks.” 

Miks on selline kirjeldus halb (kui jätta kõrvale sõnastus, pealiskaudus jne.)? Sest see on täpne lahenduse kirjeldus inimese poolt, kes ei oma põhjalikke teadmisi kasutatavatest tehnoloogiatest ja nende võimalustest. Näiteks kui juba eelnevat näidet vaadata, siis ei ole tegelikult mingit vajadust avada toote lehte selleks, et toodet ostukorvi lisada, aga kui keegi on harjunud just nii poodlema, siis see on esimene lahendus, mis talle pähe tuleb.

Kui nüüd eelnev jutt kokku võtta, siis ärianalüütik alustab oma tööd muutmisvajadusest ja kirjeldab ära sellega seotud osapooled, protsessid ning muu vajaliku. Kui hetke olukord on piisava täpsusega ära kirjeldatud, siis on võimalik selle põhjal kirjeldada nõudmised lahendusele, kuidas see lahendus võiks toimida ning mis on selle lahenduse tulemusel ettevõtte jaoks lisanduv väärtus. Nende teadmiste pealt on võimalik IT analüütikul hakata disainima IT lahendust, muidugi kui see osutub vajalikuks.

Miks on ärianalüüsi vaja?

Miks on ärianalüüsi vaja? Lihtne viis sellele küsimusele vastust leida on küsida endalt, kas sa tahaksid kasutada süsteemi, või olla osaline tarkvara arenduse protsessis, kus kõiki osapooli pole kaasatud ja vajadused pole selged? Kui enne pole ärianalüüsi tehtud (mõistlikus koguses siiski, ma ei räägi siin pikast Waterfall metoodika ärianalüüsi protsessist) ja hakatakse ehitama IT lahendust, siis kõige tõenäolisem tulemus on see, et uute osapoolte ja vajaduste selgumisel projekti skoop muutub ning sellega koos ka projekti maksumus ja valmimise aeg. Halvimal juhul jääb projekt üldse pooleli ning suure hulga töö ja rahakulu peale ei ole tulemuseks midagi näidata.

Teine oluline põhjus, miks ärianalüüsi on vaja, on selleks et teada saada mis on soovitud muudatuse väärtus. Kas see mõjutab oluliselt ettevõtte protsesse säästes aega ja raha või kas see tõstab märgatavalt klientide rahulolu? Kui neid asju ei tea, siis võib juhtuda, et tehakse tarkvara, mida ei ole vaja ning peale aja ja raha kulutamist ei võeta valminud lahendust kasutusele. Põhjuseid võib olla küll erinevaid, kuid eelnev ärianalüüs ja muudatuse väärtuse kindlakstegemine aitab selliseid olukordi vältida.

Elu on näidanud, et kõikide projektide puhul selgub tegemise käigus ootamatuid asjaolusid, olenemata sellest kui hästi on eeltööd tehtud. Oluline on see kui palju neid ootamatusi tekib. Ükskõik mis arendusmeetodeid kasutatakse, iga töö käigus leitud ja juurde lisatav funktsionaalsus maksab, kas ajas ja rahas või teiste funktsionaalsuste arvelt. Kui enne süsteemi arendust teha korralik ärianalüüs, on võimalik vähendada juurde lisanduvaid asju ja seega ka projektile kuluvat aega ning raha. Ja muidugi on tulemuseks ka parem IT süsteem.

Varem kirjutasin sellest, millised isikuomadused on vajalikud heal analüütikul. Ainult nendest isikuomadustest aga ei piisa – vaja on ka olulisi analüütiku oskusi. Siin artiklis ei jõua ma nimetada absoluutselt kõiki oskusi, mis heal analüütikul vaja on – toon välja kolm olulisemat oskuste gruppi.

Kontoritöötaja baasoskused

Need on baasoskused, mida on vaja kõigil kontoritöötajatel ning mis kasuks tulevad ka mujal. Kahjuks neid oskusi üldiselt ei õpetata koolides. Nende puudumine maksab aga valusasti kätte – keerulisem on koos töötada või kliendiga suhet hoida.

Kontoritöötaja baasoskuste alla käivad:

• Viisakus – viisakas käitumine, sobivalt riietumine, keskkonnale sobiva formaalsustaseme kasutamine, dokumentide korralik vormindamine.
• Suhete hoidmine – vestlemine, erinevate osapoolte informeerituna hoidmine, ootuste haldamine ning lubadustest kinnipidamine.
• Enesejuhtimine – ajajuhtimine, prioritiseerimine, oma ülesannete süstemaatiline haldamine.
• Kontoritarkvara kasutamine – e-mailide, dokumentide, tabelite halduse, online koosolekute tarkvara kasutamise oskused.
• Koosolekute juhtimine – olgu need intervjuud, workshopid, läbirääkimised või esitlused. Ta peab oskama neid läbi viia näost-näkku, video teel või kasvõi kirjalikult.

Need oskused võivad tunduda iseenesestmõistetavana. Kahjuks olen töö käigus näinud küllalt tihti, et nendest jääb vajaka mul endal või kolleegidel. Reaalses elus võib nii mõnigi neist tegevuse käigus ununeda, kui neile teadlikult tähelepanu ei pööra. Need on oskused, mida tasub alati täiendada.

Suhtlemisoskused

Analüütikut võib vaadata kui vahendajat erinevate projekti rollide vahel:

• erinevad kliendi esindajad, kellega ärinõudeid arutada;
• arendajad ja arhitektid, kes soovivad tehnilist kirjeldust;
• projektijuht, kliendihaldur jm, kellele on oluline projekti käekäik.

Analüütik peab suutma tõlkida infot erinevate rollide vahel. Ta peab suutma valida sobivad mõisted, vaatepunkti, detailsustaseme ja teemade valiku.

Lisaks rollidele peab analüütik arvestama ka osapoolte isiksuse tüüpidega. Analüütikul tuleb toime tulla ka suhtlemise äärmuslike vormidega, näiteks:

• tagasihoidlike inimestega, kes ei seisa enda nõuete eest;
• jutukate inimestega, kes räägiks koosoleku teema asemel pigem eilsest jalgpallimatšist;
• visuaalse, kirjaliku või auditoorse suhtlejaga jne.

Lisaks puutub analüütik oma töös kokku väga erinevate keeruliste olukordadega. Näiteks:

• Lepingute või muudatuste läbirääkimised;
• Skoobi kärpimise läbirääkimised;
• Suhtlemine osalistega, kes on vastu projekti teostamisele või vastupidi, sellest ei huvitu;
• Vastukäivate nõuete lahendamised;
• Suure mahu, stressi ja lähenevate tähtaegade surve all lahendusteni jõudmine;
• jne

Kuigi analüütikul ei ole kõigis nendes olukordades vastutav roll, peab ta olema suuteline projektijuhti toetama ning vajadusel probleeme eskaleerima. Analüütik peab oskama igas olukorras pinged hallata ning hoida jutu plaanitud teemal. Ta peab olema valmis vestlust juhtima, selgitama erinevaid projekti tahke, jne. Selle kõige juures aitavad aktiivne kuulamine, enesekehtestamine, läbirääkimisoskused, esinemisoskused jne.

Paljud analüütikud ei teadvusta, et suhtlemisoskused on õpitavad või et neid oleks vaja õppida. Kahjuks ei ole professionaalne ja efektiivne suhtlemine loomulik – see vajab teadlikku harjutamist.

Analüütiku tehnilised oskused

Analüütiku tehnilised oskused on spetsiifilised analüütikutele ja omandatakse eriala õppides.

Analüütiku tehnilisteks oskusteks loen eelkõige erinevaid dokumenteerimisoskuseid:

• koosoleku märkmete tegemine;
• visualiseerimise võimalused, sh diagrammide märgendikeeled – nt UML, BPMN jne;
• dokumentatsiooni liikide tundmine – nt kasutuslood, vormide või integratsioonide spetsifikatsioonid jne.

Lisaks loen siia alla ka teadmisi:

• IT-süsteemide toimimisest (IT-analüütikul põhjalikumaid kui ärianalüütikul);
• Levinumate analüüsiraamistike tundmist ja sealt tulenevate mustrite kasutamist;
•      standardite lugemise ja kasutamise oskust;
• arendusmetoodikate ja analüüsitehnikate tundmist;
•  jpm.

Kogemusega omandab analüütik ka võime vastavalt olukorrale valida sobiv raamistik, standard või metoodika.

Analüütiku tehnilised oskused on kõige kergemini õpitavad ja neile pannakse ka analüütikuid palgates kõige enam rõhku. Siiski on paljude analüütikute oskused ühekülgsed ja vajavad täiendamist.

Analüütikute koolitusvõimalused

Analüütikutele ei pakuta Eestis süstemaatilist koolituskava peale ülikooli lõpetamist. Ingliskeelsest internetist on küll võimalik leida online kursusi, aga tuleb hästi teada, mida otsida.

Kontoritöötaja baasoskuste ja suhtlemisoskuste osas on palju raamatuid ja koolitusi. Nende tase on küll ebaühtlane, kuid on võimalik leida tõeliselt kasulikke kursusi. Neid koolitusi tasub kindlasti praktiliste koolitustena läbida, et oskusi rollimängus harjutada.

Analüütikute tehnilisi oskusi saab õppida TalTechi Äriinformaatika erialal nii bakalaureuse kui magistriõppes ning Infosüsteemide analüüsi ja kavandamise erialal (eesti ja inglise keeles) magistriõppes. Ülikoolide üldistel informaatika erialadel puudutatakse analüütikule vajalikke oskusi vaid põgusalt. Samas on sellel teemal palju raamatuid, kuid raamatust õpitav ei pruugi olla otse kasutatav kohalikul turul.

Lisaks on vestlustes välja tulnud, et koolituste tellijatel on puudu ka analüütikute koolitusvajaduste süstemaatiline kaardistus. Loodan, et sain siin anda lühida ülevaate, milliseid oskusi on minu hinnangul analüütikul vaja.

Lisa oma arvamus siinsamas, meie Facebook või LinkedIn grupis!

Minu enda suurimaks nõrkuseks on (minu enda hinnangul) küsimuste esitamine. Tihtipeale ei oska ma küsida ka siis, kui selge on ainult see, et ma ei saa millestki aru. Ometi peab kuskilt alustama…

Leidsin autistlike inimeste maailmast raamatu „5 küsimust“. See raamat ütleb, et autistlikel lastel on kergem, kui alati vastata viiele küsimusele: “miks?”, “kes?”, “kus?”, “millal?” ja “kuidas?”. Olen hakanud samu küsimusi kasutama, et IT-projektides kõik vajalik teada saada.

Miks?

Miks seda projekti üldse läbi viiakse? Mis eesmärke tahetakse sellega saavutada? Milliseid mõõdikuid soovitakse sellega parandada? Miks on just need mõõdikud nii olulised?

Kui miks ei ole selge, ei ole mõtet järgmiste küsimuste juurde minnagi. Simon Sinek on kirjutanud raamatu „Esmalt küsi miks“. Ma ei ole seda lugenud, kuid ma olen selle raamatu pealkirjaga nõus selletagi. See küsimus on kõige olulisem, kõige lihtsam küsida – ja samas kõige alakasutatum. “Miks?”’ist lähtudes saab seada prioriteete ja suunata sobivamale funktsionaalsusele. Sellele küsimusele mittevastav IT-süsteem on kõigi osapoolte aja ja raha raiskamine.

“Miks?” seab kogu projektile eesmärgi ning seab selle ümbritseva maailma konteksti. Sellest lähtuvalt on kõigil osapooltel selgem alus otsuste tegemisel. Oluline on ka seotud vastupidine küsimus “Miks mitte?”. Näiteks ei ole vaja realiseerida olemasolevat funktsionaalsust või parasjagu vähem tähtsat nõuet. See seab piirid projekti skoobile ja aitab tagada õigeaegset valmimist.

Vastus „Miks?“ile ei jõua tihti dokumentatsiooni. Mina ei ole veel leidnud ka ühtegi head tehnikat, millega seda sinna alati lisada. “Miks?” peaks olema eelkõige visiooni, lähteülesande või projekti lepingu osa. Kuna see on tellija poolt ette antud, siis ei ole sellel standardset struktuuri. Ärianalüüsi käigus analüüsitakse erinevate tehnikate abil (SWOT, MOST, PESTLE, äriplaan jne) taustsüsteemi, kuid põhjus on ka neis vaid väike osa. “5 miksi” tehnika aitab sügavamaid põhjuseid välja uurida, kuid seda tehnikat kasutatakse minu kogemusel harva, ja ka siis ainult alguses.

Kui “Miks”’i ei ole välja selgitatud, siis:

• Töö on mehhaaniline ja veaohtlik kõigil rollidel – arendajatel, testijatel, juurutajatel;
• Programmi parandajad ja hiljem edasi arendajad võivad minna “Miks”’iga vastuollu;
• Keegi ei tea, kas kirjeldatud funktsionaalsus on tegelikult vajalik või on analüütik selle välja pakkunud oma arvamuse põhjal.

Agiilne tarkvaraarendus lahendab probleemi sellega, et toob kliendi ja arendaja sama laua taha. Samas ka sellisel juhul jääb „Miks?“ ainult mällu. Juba paari iteratsiooni järel ei mäletata vahel, miks lahendus on loodud just selliselt. Sellega võib kaotada kliendile vajalikku, mida on vaja siis taastada.
„Miks?“ tuleks küsida ka kõigi järgnevate küsimuste alamküsimusena:

• „Miks tema projektist huvitatud on?“
• „Miks just nii?“
• „Miks just sellisel ajal, sellise regulaarsusega?“
• „Miks just seal?”

Kes?

Kes on selle projekti tellija? Kes on selle süsteemi kasutajad? Kes on sellest süsteemist mingil muul moel huvitatud?

“Kes?” on tihti IT-projekti alguspunkt, sest nagu öeldakse – kes maksab, see tellib ka muusika. Tellija „miks“ on projekti jaoks kõige tähtsam, just tellija eesmärke peab projekt esimeses järjekorras täitma. Küll aga peab analüütik vaatama kogu lahendust kõigi huvitatute vaatenurgast. Selle väljaselgitamiseks tehakse osapoolte analüüs, milleks saab kasutada erinevaid tehnikaid.

„Kes?“ ütleb analüütikule, kellega tal on vaja projekti raames rääkida või kelle huvide kohta tuleb infot muudest kanalitest otsida.

Sellele küsimusele saab anda ka levinumad vastused. Esiteks tellija ja erinevad rollid, kes loodavat süsteemi hakkavad kasutama. Analüütik veedabki suurema osa ajast nendega koos või nende vaatepunktist lähtuvalt. Kergesti võivad kahe silma vahele jääda aga:

• riiklikud nõudmised (kui tellija seda ise välja ei oska tuua);
• konkurentide huvi (millele ilmselt vastupidiselt tahame toimida);
• raamatupidamise/juhtkonna jaoks vajalike tulemuste kättesaadavus;
• ja süsteemi haldajate vajadused.

Selguvad vajadused on tavaliselt vastuolulised, kuid nende vahel tuleb leida just tellijale sobiv lahendus.

Kus?

Kus tulevane kasutaja praegu vajalikke toiminguid teeb? Milline on kasutajate ja tellija visioon, kus kasutaja saab tulevikus vajalikud toimingud teha? Kus on toodud süsteemi huvitatud isikutele vajalik info?

„Kus?“ räägib esiteks loodava lahenduse arhitektuurist. Näiteks, millised vaated on vajalikud, kuidas andmeid säilitatakse, millised süsteemid on kaasatud – või ei ole.

Teiseks räägib “kus?” tulevaste kasutajate kasutatavatest seadmetest. Võibolla on kasutajaks tehnik, kes objektil viibides kasutab väikese ekraaniga mobiiltelefoni? Võibolla varem seda ei olnud ning projekti raames tuleb ka sobiv seade leida? Võibolla on kõigil tulevastel kasutajatel kohustuslik teatud operatsioonisüsteemi kasutamine? Võibolla on mõistlik, et osaliselt jätkatakse olemasolevate lahenduste kasutamist? Seda võidakse teha näiteks ajapuudusel, üleminekuna või ka osa arenduse asemel.

“Kus?”-küsimuse erinevad tahud kirjeldatakse (mittefunktsionaalsetes) nõuetes, arhitektuuri kirjeldustes ja paigaldusvaadetes. Samuti mainitakse seda protsessidiagrammidel, kasutuslugudes ja kasutusjuhtudes.

Millal?

Millal protsess käivituma peab? Mis on erinevate protsesside järjestus, tihedus? Millal kasutaja peab mingit infot nägema? Millal peavad mingi protsessi tulemused valmis olema?

“Millal?” aitab otsustada, kas mingi protsess automatiseerida või teha käsitsi kättesaadavaks. Tihedamini kasutatavad protsessid ja info võib olla vajalik tuua süsteemis esile. Ajakriitilisi protsesse võib vaja olla optimeerida.

„Millal?“ annab eelkõige infot selle kohta, milline saab loodav lahendus olla. See info kirjeldatakse nõuetes, protsessides ja kasutuslugudes.

Kuidas?

Kuidas süsteemi tulevased kasutajad neid tegevusi praegu teevad? Milline on tellija või kasutajate visioon, kuidas nad saaksid seda tulevikus teha? Kuidas oleks kõige mugavam/efektiivsem/veatum viis jõuda tulemuseni?
Kuidas saaks tellijale pakkuda parima lahenduse etteantud aja- ja raha raamides?

“Kuidas?” küsimusega tegeletakse suurem osa IT-projekti koosolekuid ja analüütiku üksinda veedetud tunde. See aitab aru saada kõikidest detailidest, mis eelmiste küllaltki üldiste küsimuste juures välja ei tule. Selle abil analüütik mõistab, kuidas toimivad protsessid uues süsteemis või selle ümber.

“Kuidas?” juures on oht unustada ära „Miks?“. Näiteks luuakse süsteem täpselt olemasoleva paberil või Excelile toetuva protsessi põhjal. Sellises süsteemis puudub lisandväärtus protsessi optimeerimise näol.

„Kuidas“ kirjeldatakse enamasti kas protsessidiagrammide, kasutusjuhtude või kasutuslugudena. Minu kogemusel on parim variant protsessidiagrammid koos täpsustavate märkustega. Need on ka vähese IT teadmisega inimestele hästi loetavad. Olenevalt projektist võib siiski olla mõistlikum luua kasutajalood või kasutusjuhud.

Kokkuvõtteks

Võibolla imestate, miks ei ole siin nimekirjas „mis“ küsimust? Seda ei olnud etteantud raamistikus – ja kas puhta õnne läbi või mingil muul põhjusel ei olnud ka vaja. Sellele küsimusele vastab nimelt analüütik ise oma tööga. Mõned tellijad annavad üpris täpse nägemuse sellest, mis see tulevane süsteem olema peaks. Siiski peab analüütik selle siis tingimata detailselt läbi analüüsima, kas see on tõesti parim võimalik lahendus. Analüütiku kogemuse najal analüüsiprotsessi läbides jõutakse enamasti mingil määral teistsuguse lahenduseni. Kliendi poolt ette antud lahenduse visioon võib mõnikord kogu analüüsiprotsessi pikemaks ja keerulisemaks muuta; seda eriti siis, kui analüütik jätab seetõttu küsimata “Miks?”.

Need küsimused ei ole ilmselgelt ammendavad. Kõiges saab minna rohkem detailidesse ja projektipõhiselt võib vaja olla küsida väga spetsiifilisi küsimusi. Siiski aitab see raamistik IT-projekti analüüsi käigus katta suuremad välja selgitamist vajavad valdkonnad. Need aitavad mul alustada juttu, kui see mingil põhjusel on raske, ja hoida silme ees seda kõige olulisemat.

Miks teie sellist raamistikku kasutaksite – või ei kasutaks? Kas teil on lihtsaid raamistikke, mis analüüsiprotsessis aitavad? Lisage kommentaaridena siia alla või meie Facebooki või LinkedIn grupis!

Parim viis analüüsi rollide mõistmiseks on käia läbi projekti protsess.

Lihtsustatud projekti protsess

Projekt algab, kui Klient loob visiooni uueks ärimudeliks või organisatsiooni muudatuseks. Ta defineerib muudatuse mudeli Ärikonsultandi abiga. Nende eesmärk on välja selgitada kas muudatuse mudel on väärt selle teostamist. Selle protsessi peamised tulemused on visioon, eelarve ja tähtaeg.

Kui projekt on väärt teostamist, leiab klient Projektijuhi, et selle täitmist jälgida. Ta kaasab projekti vastavalt vajadusele ka teisi rolle – muuhulgas ka Äri- ja IT-analüütikuid.

Järgmiseks defineerib Ärianalüütik rollid ja äriprotsessid vastavalt kliendi visioonile. Tal võib kõikide vajaduste väljaselgitamiseks vaja olla töötubasid teiste projektist huvitatud inimestega. Ärianalüütik võib töö käigus avastada viise visiooni parendada, mis juhul ta annab selle info edasi Kliendile või Ärikonsultandile. Tihti leiavad Ärianalüütikud vajaduse olemasolevaid IT-süsteeme muuta või võtta kasutusele uusi. Sellisel juhul kaasatakse projekti ka IT-analüütik.

IT-analüütik defineerib IT-süsteemide detailid ja nende andmevahetuse. Ta kasutab äriprotsesse ja töötubasid kaasatud inimestega, et üksiasjalikke vajadusi mõista. Ta võib ka avastada viise IT-süsteeme kasutades optimeerida äriprotsesse. Sellisel juhul töötab ta koos Ärianalüütikuga, et neid täiendada.

IT-Analüütik kaasab IT-Arhitekti IT-süsteemide struktuuri määratlemiseks. See sisaldab nii süsteemide-siseseid komponente kui ka süsteemidevahelist andmevahetust. IT-Arhitektid leiavad lahenduse, mis sobib mitte-funktsionaalsete nõuetega nagu jõudluse ja turvanõuded. IT-Analüütik defineerib aga, kuidas erinevad protsessid seda struktuuri kasutavad.

Järgmiseks loodud lahendus:

• teostatakse Arendaja poolt;
• testitakse Kvaliteedikontrolli (Testija) poolt;
• kinnitatakse kõigi eelpool loetletud rollide poolt juurutamiseks;
• juurutatakse organisatsioonis läbi erinevate tegevuste;
• projekti tulemusi tõlgendatakse Kliendi poolt, et vajadusel alustada täienduste jaoks uut projekti.

Täpsustused

Ülalolev kirjeldus näeb välja kui kardetud joa mudel, kuid see ei pruugi nii olla. Kõik need tegevused saavad olla iteratiivsed või paralleelsed, niivõrd kuivõrd see on võimalik. Kõiki neid rolle võib katta üks isik, nagu see on tavapärane väiksemates projektides või agiilsete arendusmetoodikate puhul. Siiski võivad rollid mõnes suuremas projektis olla isegi täpsemalt jaotatud:

• Kasutajaliidese analüütik
• Andmebaasi analüütik
• Integratsioonide analüütik
• jne.

Rolle ja nende kohustusi on kergem mõista, kui need on niimoodi detailselt lahti kirjutatud. Me kasutame sellel lehel rolle selles tähenduses, nagu need on selles lihtsustatud protsessis kirjeldatud. IT- ja Ärianalüüsi klubi keskendub IT-analüütiku ja Ärianalüütiku rollidele.