All posts by Kaja Trees

About Kaja Trees

Alustas tööd IT-alal tarkvaraarendajana aastal 1999 – esialgu veebiarenduses ja siis IT-süsteemidega, kattes mitmes projektis ka IT arhitekti ja analüütiku rolle. 2006 aastal mõistis ta, et tema huvi ei ole tehnilised detailid vaid eelkõige selles, kuidas olla kindel, et süsteem lahendab kliendi päris vajadused. Sellest arusaamast lähtuvalt muutis ta rolli IT-analüütik-arhitektiks. Aastate jooksul on ta lisaks hakanud katma ka ärianalüütiku rolli. Aastast 2018 pakub ta oma IT- ja ärianalüütiku teenuseid vabakutselisena enda ettevõttes Liriel OÜ.

Kas agiilses maailmas tehakse analüüsi?

Analüüsi tegemine agiilsetes projektides meeskonnatööna vajab väga tihedat kooskõlastamist, et tulemuseks ei oleks nn küürakas süsteem (Pilt: DALL-E)

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

Mis saab IT-projektides valesti minna ja kuidas seda vältida?

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 juhtuda, et projekt on lõpuni viidud, süsteem valmis ehitatud, kuid see ei too soovitud kasu. Foto: Shutterstock

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 “IT-maastikul liiklemine: äriprofessionaali juhend IT-hangeteks ja edukaks koostööks” 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.

“IT-maastikul navigeerimise” kursusele registreerudes 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/

Lükkame ümber 6 müüti dokumenteerimise kohta IT-projektides

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

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.

See on võimalus, mida ei tohiks maha magada! Piletid 30. oktoobril 2023 toimuvale eestikeelsele koolitusele saad soetada SIIT ja 6. novembril ning 8. novembril 2023 toimuvale inglise keelsele koolitusele SIIT.

Avaldatud esimesena veebiajakirjas DigiPRO Geenius.

Mida peaks analüütik kliendilt küsima?

Kirjutasin mõnda aega tagasi hea analüütiku isikuomadustest. Pean sinna juurde lisama, et keegi meist ei ole täiuslik – kõigi nende omadustega inimest leida on keeruline. Kõigil analüütikutel on need omadused erineval tasemel esindatud. Igal analüütikul on võimalik ennast arendada nendes osades, milles ta veel ei ole nii tugev.

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…

Read Full Post…

Milline on hea (IT-)analüütik?

Hea IT-analüütik kirjutab häid märkmeid
Analüütiku märkmed. Foto: Kaja Trees

Minu endised ja praegused kliendid teevad mulle küllalt tihti seda komplimenti, et küsivad, kas ma saaksin veel mõnda nende projekti ette võtta. Või kas saaksin kedagi soovitada, kes samavõrd hea oleks. Kuidas aga sellist inimest leida?

Ma pean analüütiku tööd lihtsalt õpitavaks. Kui ma oma vanaemale selgitasin, mida ma tööna teen, siis ta imestas, et keegi on valmis selle eest maksma! On, ja keskmisest palgast rohkem. Selle töö tegemiseks on olulised ainult teatud isikuomadused ja omandatavad oskused.

Read Full Post…