Ma olen tänaseks 10 aastat aktiivsemalt olnud seotud tarkvara arendusprotsessidega nii teenuse tellija kui ka pakkuja poolel, seega mõtlesin vahelduseks sellest kirjutada. Täpsemalt oli mõte peegeldada minu tähelepanekuid selle kohta, miks klient tihti ikkagi ei saa tarkavaraarenduse projektidest seda, mida ta vajab. Oma tähelepanekuid plaanin teile tutvustada läbi Ishikawa või põhjus-tagajärg diagrammi.

Mis on Ishikawa diagramm?

“Kalasaba diagrammi (inglise k fishbone diagramm) tuntakse ka põhjus-tagajärg diagrammi nime all või siis selle looja Kaoru Ishikawa järgi Ishikawa diagrammi nime all. Antud diagrammi kasutatakse probleemi algpõhjuse väljaselgitamiseks. Algpõhjuseni jõudmiseks peab diagrammi joonistamise käigus läbi mõtlema kõik tegurid, mis selle probleemi esile võisid kutsuda.” https://tsenter.ee/kalasaba-diagrammide-kasutamine-probleemide-lahendamisel/

Minu poolt koostatud Ishikawa diagrammi (Joonis 1) probleemiks on küsimus “Miks klient ei saa seda, mis tal vaja on?” ning selle probleemi algpõhjuseid analüüsides olen tuginenud enda tähelepanekutele tarkavaraarenduse projektidest. Minu joonise algpõhjuste grupid on kohandatud vastavalt minu tähelepanekutele. Tavapäraselt võite internetist leida Ishikawa diagramme, milles on algpõhjused grupeeritud 6 suuremasse gruppi.

Joonis 1. Ishikawa diagrammil visualiseeritud algpõhjused

Joonisel viidatud algpõhjuste gruppe kirjutan lahti mitmes järjestikusest blogipostituses. Plaanisin küll seda teha ühe postitusega aga te poleks viitsinud seda siis lõpuni lugeda 🙂 Antud postituses tuleb siis juttu tehnoloogiast ja andmetest.

Tehnoloogia

Tehnoloogia on väga võimas vahend, misiganes tööprotsesside efektiivistamiseks või automatiseerimiseks. Aga seda peab oskama rakendada õigel kujul õigetes kohtades! Mida ma selle all mõtlen? Tehnoloogiat ei ole vaja rakendada lihtsalt sellepärast, et see on uus kuum trend või et keegi teine kusagil seda teeb. See toob kliendile kasu ikkagi siis ja ainult siis kui see haakub antud kliendi tööprotsessidega. Tehnoloogia rakendamise/juurutamisega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

  • Tarkvaraarenduse projektides pööratakse tihti liiga vähe tähelepanu arhitektuuri läbimõtlemisele ja paika panemisele. Ja siin on oluline arhitektuur mitte abstraksel tasandil, vaid juba seoses äriarhitektuuriga ja tööprotsessidega.
  • Tihti on arhitektuur planeeritud nii, et see ei haaku kliendi tööprotsessidega. See viitab sellele, et tehnoloogiline vaade ei ole kooskõlas äriliste vajadustega ning seda on planeeritud ärilistest vajadustest isoleerituna.
  • Üks peamine ootus arhitektidele on see, et nad on kursis erinevate tehnoloogiliste võimalustega ning oskavad neid sobitada ärilistest vajadustest lähtuvalt ka arhitektuuri. Selle tegemine eeldab arhitektilt oskust ja tahet mõista ärilisi vajadusi. Tundub elementaarne aga sellist oskust kohtab kahjuks vähe! Ma olen mainitud 10 aastase perioodi jooksul kohanud ainult kahte sellist arhitekti, kes seda on suutnud hästi teha.

Andmed

Väga hea viis tööprotsesside efektiivistamiseks on elimineerida tööprotsessidest kasutaja sellised manuaalsed tegevused, millega saab väga edukalt hakkama masin/tehnoloogia. Andmete liigutamine ühest allikast teise, andmete kokku kombineerimine ja omavaheline rikastamine on näited sellistest tegevustest, mida saab misiganes tööprotsessides teha väga edukalt tehnoloogia kaasabil. Andmetega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

  • Tarkvaraarenduse projektides pööratakse üldiselt väga vähe tähelepanu andmetele ja justnimelt sellele poolele, kuidas kusagil kogutavad andmed saavad säästa mõnes teises tööprotsessis osalevate inimeste tööaega ning millist kasu/väärtust andmed konkreetsele tööprotsessile annavad.
  • Kuna ei tajuta andmete väärtus tööprotsesside efektiivistamisel, siis tihti ei planeerita ka tarkvaraarenduse projektidesse andmete analüüsimisega seotud tegevusi. Uute IT süsteemide arendamisel jääb vajaka andmete analüüsi vaade – ei analüüsita, mis andmeid mingi tööprotsess vajab, mis kujul ta neid andmeid vajab, millistest allikatest need andmed saadakse jne.
  • Väga tavapärane on see, et arendustele eelnevates äri- või eelanalüüsides reastatakse terve hulk erinevaid liidetusi teiste süsteemidega, mida on vaja projektis realiseerida, ilma endale selgeks tegemata, kas antud allikad sisaldavad ikkagi neid andmeid, mida tööprotsessides on vaja.

Minu joonistatud Ishikawa diagrammilt saate juba märksõnade näol vihjeid, millistele algpõhjustele oma järgmistes blogipostitustes keskendun. Senikaua aga proovige ise ka mõne probleemi kohta koostada Ishikawa diagrammi 🙂

NB! Ishikawa diagramm on väga hea töövahend misiganes muudes tööprotsessides esinevate probleemide algpõhjuste väljaselgitamiseks!

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!