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…

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!