Lubasin eraldi blogipostituses jätktata enda koostatud Ishikawa diagrammi lahti kirjutamist. Seekord käsitlen siis metoodika ja meeskonnaga seotud juurpõhjuseid.
Metoodika
Vikipeedia definitsiooni järgi on metoodika (inglise keeles methodology) korrastatud lähenemine suuremale tegevusele. Metoodika jaotab protsessi väikemateks osadeks, püstitab osadele eesmärgid ning võib näidata ära meetodid nende eesmärkide saavutamiseks https://et.wikipedia.org/wiki/Metoodika.
Minu jaoks tähendab metoodika arusaama, kuidas ma konkreetseid metoodeid/töövõtteid rakendades konkreetse eesmärgini jõuan. Ehk siis ühelt poolt peab olema väga selge arusaam, mis on eesmärk. Teiselt poolt peab olema teadmine, milliseid konkreetseid tegevusi/meetodeid, millises järjekorras selle eesmärgini jõudmiseks rakendatatakse. Tundub ju lihtne ja loogiline? Tegelikkuses on kahjuks misiganes metoodilised märksõnad tarkvara arendusprojektides tihti ainult sõnakõlksud. Puudub tegelik arusaam, mis on nende sõnade taga.
Projektijuhtimise metoodika
Projektijuhtimise meetoodikaid on väga palju erinevaid ning neid ma siin kõiki ükshaaval tutvustama ei hakka. Minu tähelepanek on seotud sellega, et väga palju viidatakse tarkvara arendusprojektides mingile metoodikale ilma lahti mõtestamata, mida see tähendab, kuidas seda rakendada ja kas seda antud kontekstis üldse rakendada on võimalik.
Lõpuks ei ole vahet, millist metoodikat kasutatakse, oluline on projekt etteantud piirangute raames võimalikult edukalt ära teha. Kui projekti realiseerimiseks on väga pingeline ajaperiood, kindel skoop ja eelarve, siis peab olema nagu kellavärk selge, kes mida ja millal teeb. Sellisel juhul ei saa lubada endale agiilsuse sildi all planeerimatust ja metoodika ning vajalike oskuste puudumist.
Millest siis kliendi vaatest vajaka jääb? Suurel osal juhtudest jääb vajaka planeerimise oskusest. Ehk siis mõtteviisist, milliseid tegevusi millises vahemikus on vaja teha selleks, et me mingi etapi lõpuks vajalikud eesmärgid täidetud saaks. Sellise plaani olemasolu on vajalik ka kliendi ootuste juhtimiseks – et oleks arusaam, millal peab olema klient valmis midagi üle vaatama või testima.
Teine oluline tegevus, mis tihti tegemata jäetakse on arendustiimi sees rollide vastutuste ja koostöö korralduse kokku leppimine. Kui seda paika ei panda, siis töö tegijad ei tea, mis nendelt oodatakse ja kuhu “maani” peavad nemad panustama. Rollide paikapanemine ja läbirääkimine peab toimuma koostöös kliendiga! Siis on ka tema ootused rollide tööülesannetele juhitud.
Projektis vajaliku kommunikatsiooni tagamine on samuti üks osa projektijuhtimise metoodikast. Eeldatatakse, et meeskonna sees teineteisega suhtlemine ja info vahetamine on elementaarne ning iga meeskonna liige saab sellega edukalt hakkama. Kuna inimtüübid on erinevad, siis paraku see kõigile nii elementaarne ei ole. Siin on jällegi projektijuhi vastutus aidata sellised juhtusid lahendada! Ja kommunikatsiooni all ei mõtle ma ainult silmast-silma suhtlemist, vaid misiganes infovahetuse viisi.
Analüüsi metoodika
Ma ise olen valdavalt olnud erinevatest analüütiku rollides, seega on analüüsi metoodika mulle väga südamelähedane teema. Nagu nimetuski viitab on analüütiku töö olemus mingi info läbi analüüsimine ning selle läbi kliendi vajaduste parem mõistmine. Tihti on läbitöötamist vajavat infot palju ja seda on vaja veel täiendavalt juurde koguda, et tekiks arusaam, mida kliendil päriselt vajab. Selleks, et mingi infokild ei jääks kahe silma vahele, on vaja väga konkreetset ja süsteemset plaani. Vaja on läbi mõelda, millist infot on vaja koguda, kuidas seda võimalikult optimaalselt teha ning milliste meetoditega seda analüüsida.
Kurvaks teeb see, et väga sageli tarkvaraarendusprojektides analüütikutel selline plaan/metoodika puudub ning rööpräheldakse ühel ja teisel rindel. Pole ime, et midagi jääb kahe silma vahele ja analüütikul on enda kaitseks vaid öelda “Aga ma ei saanud aru, et teil selline vajadus on!”. Analüütiku peamine ülesanne on aru saada, mis on kliendi vajadus! Kui seda arusaama ei teki, siis tuleks peeglisse vaadata ja endalt küsida:
- kas ma mõistan üldse probleemi, mida lahendatakse?
- kas ma sain kliendilt kinnituse, et olen tema probleemist õigesti aru saanud?
- kas mul oli plaan/tegevuskava, kuidas kellelt ja mis infot ma vajan?
- kas minu tegevuskava mahub projekti etteantud raamidesse?
- kas ma analüüsisin lahendatavat probleemi erinevatest aspektidest?
- kas ma saan aru, kuidas pakutav lahendus probleemi lahendab? nö suure pildi mõistmine
- kas ma palusin kliendil keerulisemaid asju mitmeid kordi selgitada?
- kas ma peegeldasin kliendile oma arusaama?
Teine tähelepanek, mida olen märganud on see, et kogutakse küll seotud osapooltelt vajalik info ära, mis vormistatakse memodeks ning sellega justkui analüüs lõppeb. Kallid analüütikud, tahaksin teile meelde tuletada, et analüütiku rolli nimetus on meelega analüütik ja hoopis mitte referent! Info kogumine on alles esimene osa analüüsist. Kõige olulisem osa on kogutud info analüüsimine/sünteesimine ning selle pinnalt koostöös meeskonnaga kliendile vajaliku lahenduse välja pakkumine.
Analüütik peab suutma mõista kliendi probleemi ja tööprotsesse. Kogutud info pealt suurt pilt näha ning koostöös tehnilise meeskonnaga välja pakkuda lahendusi kliendi probleemi lahendamiseks. Kui ta seda ei suuda, siis puudub analüütikul antud projektis/teenuses väärtuspakkumine!
Meeskond
Meeskonna puhul on võtmetähtsusega kolm faktorit – oskused, kogemused ja tahe ehk motivatsioon. Ideaalses tarkvaraarenduse meeskonnas on kõikidel rollidel need kolm faktorit esindatud. Ehk rollil on olemas oskused vajalikke metoodikaid rakendada, ta on seda saanud varasemalt praktiseerida ning tal on tahe klienti aidata.
Nagu me juba teame, siis kahjuks ei ela me ideaalses maailmas ning teenust pakkuva meeskonna puhul jääb tihti vajaka üks kolmest faktorist. Ilmselt oleme kõik omal nahal tunda saanud seda, et riigihangetes võib paberile väga ilusad CV-d kokku kirjutada. Aga kui tegelik töö pihta hakkab, siis jääb justkui midagi vajaka.
Kui vajaka jääb oskustest konkreetseid metoodikaid, töövõtteid rakendada, siis tehakse tööd väga ebaefektiivselt. Suure tõenäosusega tekivad raskused projekti etteantud ressursside raames ära teha.
Kui vajaka jääb eelnevast kogemusest, siis suure tõenäosusega ei osata mõelda lahenduse suure pildi peale, mistõttu ei osata ka teatud riske/ohukohti ette näha. See seab samuti ohtu projekti realiseerimise võimalikkuse etteantud ressursside raames.
Kui vajaka jääb tahtest klienti mõista, siis tekib lahendus, mida kliendile tegelikult vaja ei olnud. Sellisel juhul tehakse lihtsalt midagi ära ning pärast vaidluste käigus tuuakse välja argument “Aga te ei öelnud, et teil selline vajadus on”.
Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!
