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.

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!