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.

Paljudes IT-meeskondades on juhuslik, killustatud ja aegunud dokumentatsioon. Süstemaatiline ja ajakohane dokumentatsioon aitaks aga IT-arendustes hoida ühtset joont, efektiivselt probleeme lahendada ja uutel inimestel kiiremini sisse elada. Ma olen tihti kuulnud, et agiilsetes projektides ei olegi võimalik dokumentatsiooni ajakohasena hoida, ja seega ei ole seda mõtet luuagi (kirjutasin sellest varem ka artiklis Lükkame ümber 6 müüti dokumenteerimisest).

Mina ütlen, et on küll võimalik!

Pea igas meeskonnas on dokumentatsioon minu liitumise hetkel olnud killustatud, aegunud või täiesti puudu. Olen näinud süsteeme, kus sama funktsionaalsust oli mitmel korral ja erinevalt arendatud. Olen pidanud meeskonna rahvapärimuse järgi soovitud olukorra kirjeldust taastama. Ja muidugi olen pidanud puudulike dokumentatsiooni põhjal arendusi planeerima. See on üks korduv frustratsioon!

Selle muutmiseks olen katsetanud mitmeid lähenemisi. Mina olen enda jaoks leidnud põhimõtted, mis aitavad dokumentatsiooni luua, hallata ja ajakohastada loomuliku protsessi osana ka agiilsetes meeskondades.

Miks IT-dokumentatsioon on nii tihti aegunud?

Tihti kujutatakse dokumenteerimist traditsioonilise kose mudelina: kõigepealt tehakse analüüs, seejärel süsteemidisain, arendus ja testimine. Kui süsteem paigaldatakse, siis on ka dokumentatsioon valmis. Reaalsuses ei käi IT-arendus aga tänapäeval lineaarselt. See on paindlik, paralleelne ja väikestest tükkidest koosnev. Pidevalt muudetakse ka kasutusel olevaid süsteeme. Dokumenteerimist tuleb agiilse protsessi jaoks kohendada.

Agiilsetes meeskondades on dokumentatsiooni olemas tavaliselt ülesandepüstituseks või ainult siis, kui seda küsitakse. Selles ei tehta muudatusi, mis arenduse käigus vajalikuks osutusid, ja seda ei seota süstemaatiliseks dokumentatsiooniks. Erinevate Confluence’i lehtede rägastikus kaob lugejal kergesti arusaam, milline on päriselt valminud lahendus, mis on alles plaanitud või mis on tegelikult juba kõrvale heidetud uitmõte.

Selliselt jõutaksegi olukorda, kus süstemaatilist ja usaldusväärset dokumentatsiooni ei ole. Inimeste vahetumisel kaob ka kogu teadmine selle kohta, kuidas lahendus on üles ehitatud ja miks just selliselt. Pole siis ime, kui dokumentatsiooni suhtes selline vastumeelsus on!

Kuidas ajakohast dokumentatsiooni saavutada?

Igale meeskonnale saad sobiva lahenduse välja töötada, kui mõtled läbi järgmised küsimused:

1. Kuidas eristad kehtivat (AS-IS) ja visiooni (TO-BE)?

Igaüks, kes dokumentatsiooni loeb, peaks aru saama, millise lahenduse kohta see käib – kas see on valmis või alles loomisel; ja selleks tuleb leida oma tava. Olen selle lahendusena näinud erinevaid lähenemisi:

• kehtiv ja visioon on eraldi dokumendid, kus on selgelt näha, mis olukorda see kirjeldab;
• visiooni kirjeldav osa on kehtivas dokumentatsioonis värviga märgistatud;
• iga muudatusega luuakse uus versioon dokumendist. Vastupidiselt teistele peetakse järge hoopis selle üle, millisele dokumendile vastav lahendus on töökeskkonda jõudnud.

Kõik need võivad selguse luua, aga ükski neist ei sobi igasse olukorda. Kõige halvem variant on see, kui sama meeskonna raames on kasutusel erinevad praktikad – siis on segadus kerge tekkima!

2. Mis seisundile kehtiv dokumentatsioon vastama peab?

Palju räägitakse aegunud dokumentatsioonist, aga mis hetkel see „aegub“ võib olla igas meeskonnas erinev. Dokumentatsiooni luues kirjeldatakse tavaliselt eelkõige visiooni, aga mis hetkel saab lugeda visiooni reaalsuseks? Kas siis kui ta on arendaja poolt valmis programmeeritud, testkeskkonnas üle kontrollitud või alles siis, kui ta on töökeskkonda viidud?

Erinevates meeskondades ei pruugi see vastus olla sama. Ainult siis, kui teed selle kohta selge kokkuleppe, saad kindel olla, et kogu meeskond saab dokumentatsiooni tähendusest samamoodi aru.

3. Kuidas ajakohastamine toimub?

Eelmisest punktist said vastuse, mis hetkel see toimuma peaks. Kindel saad olla dokumentatsiooni ajakohastamises ainult siis, kui see on osa regulaarsest tööprotsessist.

• Tegevusel peab olema kindel vastutaja. Erinevates meeskondades võib selleks olla roll tooteomanikust ja arendajani.
• Vastutaja peab saama ajakohastamise teostamiseks meeldetuletuse. Minu soovitus on luua kindel märguanne – olgu see eraldi ülesanne või kalendri meeldetuletus -, et uuendamine õigel ajal tehtud saaks ja töö ei kuhjuks.

Kui eelnev on lahendatud, siis on dokumentatsiooni uuendamine kiire ja lihtne tegevus. Minu jaoks annab see ka teatud lõpetatuse ja rahulolutunde, et mingile ülesandele on joon alla tõmmatud.

Teadlikult tegutsedes on alati ajakohane dokumentatsioon võimalik

Kuigi põhimõtted on üldised, ei ole ühte kindlat vastust, mis sobiks alati ja igale meeskonnale – kõigel on omad plussid ja miinused. Räägin neist pikemalt oma raamatus “Optimaalne dokumentatsioon: kasulik, ajakohane ja mugav” ja minu mitu korda aastas toimuva „Äri- ja süsteemianalüüsi kursuse“ esimesel päeval. Seal annan ka täpsemaid soovitusi, kuidas enda meeskonnale kõige paremini sobiv lahendus leida.

Julgen kinnitada, et kui need põhimõtted on meeskonnas teadlikult läbi mõeldud ja rakendatud, saab dokumentatsioonist väärtuslik tööriist, mida saad alati usaldada. Minu projektides see nii on!

“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.

Kaasaegsel ärimaastikul on IT-projektid saanud oluliseks osaks innovatsioonist, ent need projektid ei pruugi alati anda oodatud tulemusi ja võivad isegi väga valesti minna.

Äri- ja süsteemianalüütik Kaja Trees, kellel on mitmekümneaastane kogemus mitmekesistest projektidest, on kokku pannud kursuse äri- ja süsteemianalüüsist ning paljastab artiklis IT-projektide ees seisvad levinud takistused ja pakub praktilisi strateegiaid nende ületamiseks.

Eelarve ja tähtaja ületamine

Probleem: IT-projektid kipuvad sageli eelarvest väljuma ja tähtaegu ületama. Arvestades, et IT-projektid ei ole odavad ning tähtaegadest sõltub äritulemus, siis on see suureks probleemiks eelkõige ärile.

Lahendus: selge suhtlemine on eelarve ja tähtaja haldamise edukuse võti. Pöörake erilist tähelepanu, et järgmistes osades oleks kõigil ühesugune arusaam.

• Määratlege selged projekti eesmärgid ja tagage, et kõik mõistaksid neid ühtemoodi. Sealhulgas on oluline ka välja tuua prioriteedid – milline eesmärk on olulisem kui mõni teine.
• Veenduge, et projekti ulatus (skoop) oleks selge ja selle muudatused põhineksid ainult projekti eesmärkidel. Vajadusel loobuge vähemtähtsatest projekti tulemitest olulisemate saavutamiseks.
• Valides tehnoloogiaid, veenduge, et kõik valikud koos piisavate selgituste ja plusside-miinustega oleksid esitatud. Tellija peab aru saama, kuidas teha parim valik lähtudes projekti eesmärkidest.
• Kasuta projekti jaoks sobivat projektijuhtimise tehnikat ja jälgi, et otsuseid teeks tellija.
• Hindamiseks vaadake regulaarselt üle, mis toimib hästi või mitte, ja kohandage vastavalt.

Eelarve ja tähtaja ületamine võib olla projekti eesmärkidega kooskõlas, kui tulemuseks on toode, mis on seda väärt. Sellisel juhul tuleb need otsused aga teha teadlikult. Kui ülaltoodut aga mitte arvestada, võib ka juhtuda, et tulemust ei olegi – kogu töö ja raha on läinud tühja.

Tulem on kasutuskõlbmatu

Probleem: isegi laitmatult tehtud projektid võivad ebaõnnestuda, kui lõppkasutajad leiavad, et süsteem ei sobi neile, sundides neid tagasi pöörduma traditsiooniliste, vähem tõhusate meetodite juurde.

Lahendus: süsteem võib lõppkasutajate nõudmistega mitmel viisil vastuollu minna. Lahendused on siin.

• Funktsionaalsus peab vastama kasutajate vajadustele ja kvalifikatsioonile – kaasake äri- ja süsteemianalüütikud, et süsteem oleks kooskõlas kasutajate vajadustega.
• Süsteemi kasutamine peab olema lihtne; info ja nupud seal, kus seda vajatakse – kaasake kasutuskogemuse (UX) spetsialiste intuitiivse kasutajaliidese tagamiseks.
• Süsteem peab olema piisavalt kiire – kaasake süsteemiarhitekte, et tagada tehnoloogilised valikud, mis vastavad oodatavale kasutuse intensiivsusele.
• Süsteem peab tegema seda, mida oodatakse – kaasake oma meeskonda ka kvaliteedi tagamise insenere (testijaid).
• Minge otse allikani – kaasates tegelikke kasutajaid töörühma kasutajaintervjuude või kasutajate testimise kaudu, saate parimad teadmised sellest, mida tegelikud kasutajad vajavad.

Iga IT-projekt on meeskonnatöö, kus igaühel on oma roll. Tihti tuleb mõnel inimesel täita ka mitut rolli, kuid kui midagi nendest jääb katmata, võib taas juhtuda, et projekt on lõpuni viidud, süsteem valmis ehitatud, kuid see ei too soovitud kasu.

IT-maailm on arenenud väga erinevaks traditsioonilisest ärimaailmast. Seal on oma projektijuhtimise mõisted, spetsiifilised rollid, innovaatilised praktikad, rääkimata tehnilistest terminitest. IT-projektide edukaks läbiviimiseks tasub olla teadlik IT-maailma omapäradest ja nendega teadlikult arvestada.

Kursusel omandate mitte ainult olulisi oskusi, vaid ka enesekindluse keerukate IT-projektide edukaks haldamiseks. Kursusel jagab Kaja reaalse maailma kogemusi ja selgitab üksikasjalikumalt kõike, mida mitte-IT-inimene peab teadma IT-koostöö edukaks toimimiseks ja nende probleemide vältimiseks, mis vaevavad nii paljusid IT-projekte.

Esimene avaldamine Geenius DigiPro’s siin: https://digipro.geenius.ee/sisuturundus/mis-saab-it-projektides-valesti-minna-ja-kuidas-seda-valtida/

Olge valmis, sest kohe lõhume dokumenteerimise müüdid IT-projektides! Maja ehitamisel on dokumentatsioon A ja O, kuid tehnoloogiamaailmas on see tihti jäänud unarusse.

Müüdid kummutab järgnevas artiklis Kaja Trees, kes on kogenud äri- ja süsteemianalüütik ning teeb koolitusi muuhulgas ka teemal “Optimaalne dokumentatsioon: piisav, seotud ja ajakohane” (loe koolituse kohta lähemalt SIIT). Kaja selgitab, miks dokumentatsioon ei ole koorem, vaid väärtuslik abimees meie teekonnal IT-maailmas.

1. Keegi nagunii dokumentatsiooni ei loe

Kaja soovitab unustada detailse dokumentatsiooni, kus iga nüanss on täpselt kirjas ja mõelda selle asemel, kellele see info tegelikult oluline on ja lisa ainult vajalik.

Kliendikokkulepped, tööülesanded ja vastutajad – need on põhitõed, mis peaksid kindlasti dokumentatsioonis kajastuma. Need aitavad projektijuhil hoida projekti liikumas ja arendajal teada, mis on tema vastutusala.

Kui uus meeskonnaliige ühineb, on jällegi hea, kui ta saab vajaliku info dokumentatsioonist, mitte suulise pärimuse kaudu. Kui liitub näiteks tehniline meeskonnaliige, siis tema jaoks on raamistike, tööriistade ja projekti töökorralduse mõistmine kriitilise tähtsusega.

2. Kood on dokumentatsioon

Kaja ütleb, et kood on dokumentatsioon samavõrd kui maailm on maakaart!

Jah, koodis on palju infot, kuid suurte süsteemide puhul võib sellest ülevaate saamine olla nagu Tallinna kesklinnas seistes tee leidmine Rooma. Kood on väga detailne ja sellest ülevaadet saada on keeruline.

Lisaks, kood ei ole kliendile arusaadav ja ei kirjelda kokkuleppeid – kui kood on dokumentatsioon, siis ei saa olla ühtegi “bugi”! Absoluutselt kõik muudatused tuleb kliendil kinni maksta, sest selle loogika järgi oleks nagu koodis alati kõik õige, isegi kui arendaja on millestki valesti aru saanud.

Hea dokumentatsioon aitab kõigil aru saada, mida tarkvara teeb, ja koodis orienteeruda.

3. Dokumenteerimine võtab liiga palju aega

Kaja annab nõu, et üksikasjaliku dokumenteerimise peale ei maksa liigselt aega kulutada. Mõtle, millist infot tegelikult vaja on, ja dokumenteeri ainult seda. Sellise dokumentatsiooni loomise ajakulu on nagu investeering, mis hiljem end koos intressidega ära tasub, kui seda saab kasutada uuenduste ja muudatuste planeerimiseks.

4. Dokumentatsioon on alati aegunud

Kaja selgitab, et dokumentatsioon ei pea aeguma! Oma projektides on ta seda õppinud ajakohasena hoidma.

Põhiline nipp selle juures on lisada dokumentatsiooni uuendamine loomulikku protsessi sobivasse kohta ühe tegevusena – nii et tarkvara ei uuendata ilma dokumentatsiooni uuendamata.

5. Kellelegi ei meeldi dokumentatsiooni kirjutada

Kaja toob välja, et temale meeldib tõesõna dokumenteerida ja tegelikult on palju inimesi, kes naudivad dokumentatsiooni kirjutamist.

Vali oma meeskonda mitmekesiseid inimesi ja lase igaühel tegeleda sellega, mis talle meeldib. See on ka üks põhjuseid, miks on vähegi suurema projekti puhul hea lisada projektimeeskonna hulka ka analüütik või isegi mitu. Igaüks saab tegeleda selle osaga tööst, mis talle meeldib.

6. Agiilses lähenemises ei ole dokumentatsiooni

Kaja paneb paika, et 2001. aastal loodud Agiilse tarkvaraarenduse manifest kirjutas “Hindame … töötavat tarkvara rohkem, kui kõikehõlmavat dokumentatsiooni!” ja sellele järgnenud rohkem kui 20 aasta jooksul on seda liigagi tihti tõlgendatud kui “me ei hinda dokumentatsiooni”.

Unustatakse ära, et juba sellessamas manifestis on kirjas: “Ka parempoolsetel teguritel on väärtus, kuid me hindame vasakpoolseid tegureid kõrgemalt.” Muidugi on olulisim, et tarkvara töötaks, aga selle saavutamisel on hea dokumentatsioon väärtuslikuks abivahendiks.

Dokumentatsioon ei ole vaenlane, vaid kaaslane, kes aitab meeskonnal paremini navigeerida IT-maailma keerukustes. Oluline on leida tasakaal, mis sobib sinu projekti ja meeskonnaga.

Kaja Treesi koolitusel “Optimaalne dokumentatsioon: piisav, seostatud ja ajakohane” saad õppida, kuidas loomulikul moel kirjutada ja uuendada dokumentatsiooni nii, et see annab maksimaalselt kasu minimaalse pingutuse juures.

Avaldatud esimesena veebiajakirjas DigiPRO Geenius.

Analüütiku töös tuleb palju ette dokumenteerimist, küll on vaja nõudeid kirjutada, protsesse kirjeldada ja palju muud erinevat sorti infot dokumentidesse talletada. Kõik see ei ole lihtne tegevus. Dokumenteerimisel on palju erinevaid eesmärke ja selleks, et kirja pandut oleks võimalik efektiivselt kasutada, tuleb läbi mõelda, kellele dokument on, mis detailsusega infot on vaja talletada ning mis formaadis on kõige parem seda teha. Väga laialt võib öelda, et tehtud dokumentatsioon peab vastama järgnevatele tingimustele: see peab edasi andma vajalikku infot, see peab olema muudetav ning see peab olema valminud mõistliku ajaga (dokumenteerimine toetab tarkvara arendust, mitte ei ole eesmärk omaette).

Eelnevalt kirjeldatust tulenevalt proovin ma iga natukese aja tagant üle mõelda, et kas ma ikka kirjutan nii head dokumentatsiooni kui võimalik? Kas ma kirjutan liiga palju või liiga vähe? Kuidas ma saaks infot paremini edasi anda? Kuidas oma dokumentatsiooni paremini struktureerida ning mis erinevaid formaate kasutada saab?

Kahjuks on igas projektis dokumenteerimise vajadused erinevad ja seega ma ei saa siin kirjeldada, mis on kõige parem viis dokumenteerimiseks (ma ei ole senini veel ühest vastust leidnud). Küll aga saan ma ära kirjeldada need küsimused, mida saab enne dokumendi koostamist endalt küsida ning mis loodetavasti aitavad paremini aru saada, mida kirjutatavalt dokumendilt vaja on.

Kõigepealt tahan ma üldisema poole pealt üle käia küsimused, kas ja miks on vaja dokumenteerida. 

Kas on vaja dokumenteerida?

Üks agiilse metoodika põhimõtteid on, et “Töötav tarkvara on olulisem kui põhjalik dokumentatsioon” (“Working software over comprehensive documentation”). Sellest tulenevalt on üks ekstreemsemaid vaateid see, et dokumentatsiooni ei ole üldse vaja. Minu enda vaade on, et jah, dokumenteerida on kindlasti vaja, ning täpsemalt selgitan ma seda järgnevalt vastates küsimusele: “Miks?”. Üldiselt ma toetan agiilse põhimõtte järgi dokumenteerimist ehk siis nii palju kui vaja, siis kui vaja, aga kindlasti vaja.

On ka olemas vaade, et kood on dokumentatsioon. Jah, on olemas projekte, kus hästi kommenteeritud koodist piisab dokumenteerimiseks, aga neid on vähe. Ilma kommenteerimata kood on dokumentatsiooni osas täiesti kasutu. Põhjus on selles, et tahes tahtmata tehakse vigu ja kui koodi ei ole kommenteeritud, mis mingi kindla koodijupi eesmärk on, siis võib juhtuda, et hiljem vigast koodijuppi vaadates ei ole võimalik aru saada, mida tegelikult saavutada taheti. Lisaks sellele on kood väga piiratud moodus dokumenteerimiseks mitmel põhjusel. Visualiseerimine tekstina on keeruline ning tellijal ja ka osadel teistel projekti liikmetel reeglina ei ole moodust ega oskuseid selle lugemiseks. 

Miks dokumenteerida?

1. Inimesed unustavad – Ühe tarkvara eluiga võib varieeruda, aga parematel juhtudel on see siiski rohkem kui üks aasta. Potentsiaalselt isegi palju rohkem. Kogu tarkvara eluea jooksul tuleb ette küsimusi, näiteks “Kas see funktsionaalsus sai realiseeritud?”, “Kas see funktsionaalsus toimib nii, nagu sai algselt plaanitud?”, “´Mida see funktsionaalsus teeb?” ja veel palju muud. Mida rohkem aega möödub tarkvara valmimisest, seda väiksemaks läheb tõenäosus, et selle arendanud inimesed oskavad nendele küsimustele peast vastata. Kui seda infot ei ole dokumenteeritud, siis on see kadunud ja need küsimused jäävad vastuseta. Kui hästi läheb, siis selle tagajärjed ei ole suured, aga realistlikumalt on tulemuseks raha ja aja kulutamine kas siis topelt funktsionaalsuse realiseerimiseks või eelnevalt skoobist välja jäänud asjade arendamiseks, kuna pole kokkulepet mis näitaks, et see oli eelnevalt nii planeeritud.

2. Inimesed vahetuvad – Inimesed jäävad haigeks, käivad puhkamas ning vahetavad tööd. See on normaalne ja see ei tohi tähendada seda, et nende peas olev info on kas ajutiselt ligipääsmatu või siis halvemal juhul alatiseks läinud. Selleks, et teised inimesed saaksid üle võtta ja jätkata tööd, on vaja informatsiooni talletada ühel või teisel kujul. Ideaalne juht on muidugi see, kui info antakse edasi juhendamise teel, aga see ei pruugi alati olla võimalik ja juhendamist toetav dokumentatsioon on alati vajalik.

3. Ühtse arusaama kinnitamiseks – Kui tegemist on kliendi poolt tellitud spetsiaaltarkvaraga, siis kasutatakse dokumentatsiooni väga tihti tellitud funktsionaalsuse kinnitamiseks. Analüütik kirjeldab funktsionaalsuse dokumentatsioonis ning kui klient on selle üle lugenud ja läbi arutanud, siis see kinnitatakse. Peale kinnitamist on tegemist ametliku dokumendiga, mida saab tulevikus kasutada arveldamiseks ja pretensioonide lahendamiseks.

Kindlasti on ka rohkem põhjuseid, aga need kolm loetletut on käesoleval hetkel need, millega mina olen kõige rohkem kokku puutunud. 

Lisaks toon siia ka mõned näited, mis ei ole head põhjused dokumenteerimiseks.

1. Sest klient nõuab – Jah, on lepinguid, kus on kliendi poolt esitatud kindlad nõuded, mis dokumendid peavad olemas olema. Küll aga on kliendil olnud mingi põhjus need nõudmised lepingusse kirja panna. Analüütikuna tuleb aru saada, mis on see “Miks” nende dokumentide nõudmise taga ning mida klient tahab nende dokumentidega edasi teha.

2. Programmeerija tööks on vaja sisendit – Jah, programmeerijatele on abiks, kui nende töö sisendiks on dokumentatsioon, aga see sisend ei tohi olla ainult kirjalik. Programmeerijal on vaja tekitada endale arusaam sellest, mida on vaja arendada. Ainult dokumentatsioon ei ole selle arusaama tekitamiseks väga hea. Ennekõike tuleb programmeerijaga koos läbi arutada, mida on vaja teha ning mis peab olema tulemus, ja dokumentatsioon saab seda kõike toetada.

Mida kirjutada?

Kui nüüd on läbi mõeldud, et jah, dokumentatsiooni on vaja kirjutada, siis järgmiseks tuleb see keerulisem osa, ehk siis kuidas seda kirjutada? Nagu ma varem siin kirjutasin, ei ole ühtset head viisi, kuidas dokumenteerida. Igal projektil on omad vajadused, osad projektid vajavad integratsioonidokumentatsiooni, osade puhul piisab ainult kasutajalugudest (user story) ning muud projektid vajavad veel hoopis midagi teistsugust.

Selleks, et natukene paremat aimdust saada, mis dokumente ja kuidas teha, võiks mõelda järgnevatele asjadele:

Miks seda dokumenti vaja on?

Jälle see miks. Kõigepealt me vaatasime, miks üldiselt on dokumentatsiooni vaja, ja nüüd me peame iga dokumendi kohta eraldi aru saama, mis on selle dokumendi eesmärk, miks me seda kirjutame? Kui see dokument on valmis kirjutatud, siis kuidas seda kasutama hakatakse? Kui dokumendi lõppsaaja ütleb, et ega me selle dokumendiga midagi ei tee, paneme sahtlisse, siis selle dokumendi kirjutamisele ei peaks aega raiskama.

Kes hakkavad seda dokumentatsiooni lugema?

Selleks, et osata õiget infot kirja panna, peab aru saama, kes hakkavad seda tulevikus lugema. Näiteks on dokumente, mille eesmärk on edasi anda tehnilist informatsiooni. Sellisel juhul tuleb kirja panna detailid ja keskenduda väga spetsiifilisele info alamhulgale. Sellist informatsiooni loevad enamasti tehnilise taustaga inimesed (arhitekt, arendaja jne) ja kliendi äripoole esindaja ei peagi sellest dokumentatsioonist nii täpselt aru saama. 

Kui dokumentatsioon on aga mõeldud kõigile lugemiseks, siis ei ole hea mõte seda detailidega üle külvata, vaid pigem tuleks keskenduda üldpildile ja detailid jätta teiste dokumentide jaoks. Sellised dokumendid on enamasti mõeldud kas kliendi või tegija firma enda äripoolest teadvate inimeste jaoks ja need peavad sisaldama teistsugust infot ja teistsugusel kujul kui eelnevalt mainitud tehniline dokumentatsioon. 

Siin on kirjeldatud ainult kaks dokumendi lugejate äärmust, tegelikkuses võib olla rolle rohkem ning igaühe puhul tuleb mõelda selle üle, mis on lugejatele oluline.

Kas tegemist on ajutise või pikaajalise dokumentatsiooniga?

Kõik kirjutatud dokumendid ei pea elama pikka elu. Mõne dokumendi eluea pikkus võibki olla ainult nii kaua, kui võtab aega selles sisalduva info läbi töötamine. Näiteks minu kogemuses on prototüübist kasu olnud ainult senikaua, kuni prototüübil kujutatav on valmis tehtud. Edaspidi käib arutamine ja muudatuste tellimine siiski tarkvaras oleva pildi pealt ning prototüüp langeb unarusse (Kaja nentis peale lugemist, et tal on prototüüpidega teistsugused kogemused, aga üldmõttega oli nõus, et osa dokumentatsiooni on ajutine). Prototüüp on ainult üks näide, selliseid dokumente võib veel olla palju. Üldiselt ajutised dokumendid kipuvad olema need, millega antakse programmeerijatele edasi infot, kuidas asjad täpselt töötama peavad. Kui süsteem on realiseeritud, siis on väga keeruline neid dokumente sellise detailsusega ajakohasena hoida ning selleks pole ka vajadust.

Pikaajaline dokumentatsioon on see, mis peab tulevikus küsimuste tekkimisel aitama neile vastuseid leida. Kui detailne see dokumentatsioon on, on igaühe enda otsustada, aga väga oluline on see, et seda dokumentatsiooni hoitakse ajakohasena. Kui seda ajakohasena ei hoita, siis kaob sellel mõte ära. Jah, see tähendab seda, et iga väiksem muudatus tuleb sinna ära kirjeldada (kui see muudab dokumentatsiooni) ning sellest tulenevalt peab see olema võimalikult hästi struktureeritud, lihtsalt otsitav ja muudetav.

Kuidas kirjutada?

Nagu varem öeldud, dokumentatsiooni kirjutamine ei ole lihtne tegevus. Kõigepealt tuleb põhjalikult läbi mõelda, mida on vaja kirjutada, ja alles siis jõuab selle tegeliku küsimuseni, kuidas seda kirja panna. Paljud targad inimesed on oma töö jooksul välja mõelnud palju erinevaid formaate ja standardeid.

Kui vaadata üldiseid põhitõdesid, siis tuleb alati jälgida, et kirjutatud dokumentatsioon oleks struktureeritud. Tulevikus hakatakse sealt infot otsima ning struktuur on üks moodus, kuidas aidata otsitut kiiremini üles leida. Järgmine põhitõde on, et visualiseerida tuleb nii palju kui saab, sest keegi ei jaksa läbi lugeda mitut lehekülge teksti (irooniline asi, mida öelda blogiartiklis, kas pole). Protsessidiagrammid, olekumudelid, lihtsalt kastid ja ringid, mis iganes, mis aitab inimestel visuaalselt pilti paremini haarata. Ma ise näiteks olen enda kasutuslugudes (use case) protsessi kirjelduse teksti asendanud protsessi joonisega. Tekib natuke parem pilt alternatiivide ja üldse protsessi kohta.

Kasutada võib nii kasutuslugusid (use case) või kasutajalugusid (user story) või mingit muud struktureeritud teksti. Küll aga tuleb mõelda selle peale, et detaile tuleb kirja panna just nii palju, kui käesoleval hetkel vaja. Näiteks kasutajalugude mõte on see, et nad on lühikesed. Nende eesmärk ei ole kirjeldada kogu funktsionaalsust, vaid nad ongi mõeldud lühikokkuvõtteks, mida kasutatakse arutelu loomiseks. Kui kasutajalugu on meeskonnaga läbi arutatud, siis tekib sellest põhjalikum dokumentatsioon. Ehk siis arutelu käigus selguvad detailid ning ka see, mis sorti dokumentatsiooni vajavad arendajad enda töö sisendiks – mis info saab kirja panna kiiresti ja paari lausega ning mis läheb pikaajalisse dokumentatsiooni ja vajab rohkem tööd. 

Kui ette kirjutada väga põhjalik dokumentatsioon, siis tuleb ennast valmis panna selleks, et seda tuleb põhjalikult muutma hakata.

Rõhutan veelkord üle, et pikaajalist dokumentatsiooni tuleb hoida ajakohasena või muidu kaob selle mõte. Kui tehakse bugiparandusi või lisatakse uut funktsionaalsust, siis peaks kas projektijuht, tooteomanik või analüütik üle vaatama olemasoleva pikaajalise dokumentatsiooni ja seda täiendama. See peab olema muudatuse protsessi üks osa. Üks põhilisi põhjuseid, miks inimesed dokumentatsiooni vastu on, ongi see, et see on vananenud ja ei sisalda seda infot, mida vaja on. Sellise olukorra vältimiseks tuleb ennekõike teadvustada, et dokumentatsiooni peab ajakohasena hoidma ja selle peab oma tööprotsesside osaks tegema.

Ma väga põhjalikult ei kirjeldanud erinevad joonisetüüpe ega mudeleid, mida dokumenteerimiseks kasutada. Põhjus on selles, et erinevaid formaate on palju ja neil kõigil on oma head ja halvad küljed. Et natuke rohkem infot saada erinevate võimaluste kohta on mul endal kodus raamaturiiulil Business Analysis Techniques: 99 essential tools for success ja BABOK. Need kaks raamatut ei sisalda endas infot ainult dokumenteerimise kohta, vaid seal on ka palju muid töönippe analüütikute jaoks, aga siiski on nad ka väga head materjalid selleks, et tekitada arusaama, mis võimalused on olemas informatsiooni talletamiseks.
Siin kirjutatu on hoolimata oma pikkusest siiski üsna üldine ülevaade dokumenteerimise osas. Kui tekkis küsimusi, siis võib need postitada meie Facebooki lehele või saata meie e-mailidele kaja.trees@itbac.eu ja kristin.meriniit@itbac.eu.

Oleme alati rõõmsad küsimuste ja tagasiside üle!

26.11.2020 toimus Nortali poolt korraldatud Analüütikute hommiku nimeline webiseminar, mille teemaks oli seekord “Analüütik teelahkmel – vanamoodi ei saa ja uutmoodi hästi ei julge”. Üritusel rääkis üldisest vaatest IT turul toimuva kohta kohta ITL-i president ja Nortali partner Andre Krull ning hiljem jagasid oma kogemusi analüütikutööst Kadri Siinmaa (UX ja innovatsioonikonsultant, seikleja), Inge Prangel (Nortal AS, vanemanalüütik), Meelis Lang (Helmes AS, arendusjuht) ja Antti Haljak (ärianalüütik ja disainer, freelancer). 

Huvitavaid mõtteid

Kokkuvõttes oli väga tore kuulata teiste inimeste kogemusi ning kuidas nemad oma tööle lähenevad, aga on mõned punktid, mida ma tahaks täiesti eraldi välja tuua. Enamus neist on positiivsed tähelepanekud, aga on ka paar väikest nurisemise kohta. Alustame siis positiivsetest tähelepanekutest.

Kui küsiti, et mis on olnud töös keerulised kohad, siis huvitav oli kuulata, et tehniliste oskuste puudujäämist ei kurtnud keegi. Teemaks oli pigem ikka see, et inimestevaheline suhtlus on see keeruline osa. Küll on probleemiks see, et meeskonnaliikmed on väga erinevad ja tahavad erinevaid asju, või siis tuleb kliendile selgitada et see, mida nad arvavad, et nad tahavad, ei ole see, mida nad tegelikult vajavad. Ka meie kirjutatud artiklis Milliseid oskuseid vajab hea analüütik? on öeldud seda, et suhtlusoskused on väga vajalikud ja nüüd rohkemate analüütikute kogemusi kuulates saab see aina enam kinnitust.

Üsna palju rõhutati ka seda, et väga oluline on ikkagi tegeleda enesearendusega. Tuleb analüüsida seda tööd, mida sa senini teinud oled ning ka iseennast. Mis on läinud hästi, mis halvasti ning kuidas edaspidi teha aina paremini. Kindlaid näiteid väga ei antud aga esinejate lugemissoovitused lubati meetupi lehele üles panna. Jään huviga ootama. Väga huvitav oleks teada saada selle raamatu nimi, mida põgusalt mainiti ja mis räägib sellest kuidas osata tagasisidet vastu võtta. 

Paneelis osalejad enda kohta rääkisid, et nad on pigem ise õppijad, ehk siis kui tundmatu teema otsa sattuvad, siis uurivad. Või siis kuulavad näiteks laiema silmaringi podcaste ning siis sealt liiguvad edasi huvipakkuvate teemade juurde. Üks podcast mida mainiti oli Making Sense with Sam Harris, ma ise ei ole küll seda veel kuulanud, kuid leidsin et see on mul huvipakkuvate podcastide nimekirjas juba olemas. Tuleb siis see prioriteetide järjekorras ettepoole liigutada.

Natuke tuli juttu ka analüütikute sertifikaatidest. Inge Prangel on ära teinud IIBA (International Institute of Business Analysis) poolt välja antava sertifikaadi ja kuulajate poolt esitati küsimus, et kas sellest on ka kasu olnud. Üldine konsensus panelistide poolt oli see, et Eesti siseste projektide puhul ei ole see sertifikaat väga oluline, küll aga võidakse seda küsida kui on huvi tegeleda rahvusvaheliste hangetega. Üldiselt on tegemist IIBA enda poolt välja antud materjalile keskendunud eksamiga ning kui oma töös seda raamistikku väga ei kasuta, siis ei ole ka eksamiks õppimisest suurt kasu.

Viimane tore tähelepanek, mida ma tahaksin mainida, käis selle kohta, et kuidas saaks keegi siseneda analüütiku valdkonda. Vastuseks mainiti ära muidugi kursused ja lugemine, aga öeldi ka et kõige parem moodus on läbi tutvuste leida üks ärianalüütik, kutsuda ta kohvile (boonusena võib talle kohvi välja teha) ning küsida temalt nõu ja kogemusi. Lühidalt siis leida endale mentor, kas firma sisene või firma väline. Panelistid pakkusid ka ennast välja, et võib ka nendega ühendust võtta ja küsida. Ma lisaks siis siia juurde, et sama kehtib ka meie kohta siin blogis, kui teil on huvi analüütiks saamise osas, siis võite võtta ühendust minu (Kristin) või Kajaga, kohvi me küll ei joo, aga tassi tee kõrval võime rääkida küll.

Mida oleks rohkem oodanud

Nüüd siis ka paar väikest nurinat. Kui küsiti, et mis on üks olulisemaid asju analüütiku töö juures, siis räägiti, et näost näkku kohtumine on väga oluline ja ilma selleta ei hakka projektid hästi tööle.

Siin osas ma vaidleks vastu. Ilmselgelt on näost näkku kohtumine väga oluline tööriist suhtlemise juures, aga on olukordi kus see ei ole võimalik. Eriti veel praegusel ajal, kus COVID-19 tõttu ei ole füüsiliselt koos olemine soovitatud. Kui vaadata, et webinari pealkiri oli, et vanamoodi ei saa, siis siin oleks just tahtnud kuulda rohkem selle kohta, et näost näkku kohtumine on senini olnud väga oluline tööriist, aga kuna praegult seda väga tihti ei saa teha, siis nüüd peame me asjadega tegelema teistmoodi. Olenemata olukorrast peab projektid ja suhtluse ikka sama hästi tööle saama, olgu see siis sellega et kaamerad on kohustuslikud, või siis teha koosolekul eraldi üldistest asjadest jutustamise paus.

Need kaks viimast asja on siis need, mida ma ise kasutan praegusel ajal üsna palju. Kuna on ette tulnud projekte, kus osad inimesed istuvadki teisel pool maakera või siis COVID-19 tõttu on rohkem kodus, siis olen pidanud leidma mooduseid kuidas kaugusest hoolimata saada inimesed omavahel suhtlema. Muidugi sõltub kõik sellest, missugused inimesed projektis on ja mul on tunne, et mul on sellega ka väga vedanud, aga siiski soovitan lugeda või kuulata loenguid selle kohta, kuidas teha kaugtööd efektiivselt ja missuguseid erinevad nippe ja trikke on võimalik kasutada.

Ja minu viimane nurin on selle kohta, et väga ei olnud juttu selle kohta, et mismoodi see “uutmoodi” siis on. Webinari nime vaadates ma natuke ootasin, et kas tuleb juttu agiilsetest protsessidest, et kuidas analüütiku töö on tänu sellele muutunud? Või siis ongi rohkem juttu COVID-19 tõttu tekkinud probleemidest, et kuidas saab analüütikutööd sellest hoolimata hästi ja effektiivselt teha? Kahjuks ei räägitud kummastki.

Üldiselt oli ikkagi tegemist väga toreda üritusega ja suur aitähh osalejatele ja korraldajatele! Ma jään huviga järgmist webinari või siis, olenevalt olukorrast ja ajast, juba päris kokkusaamist ootama.

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!