Minu lõppeva aasta tähelepanekud tarkvaraarenduse projektidest

Seekordse postituse fookuses ei ole kitsalt äriprotsessid, vaid see kajastab laiemalt minu lõppeva aasta õppetunde ja tähelepankuid tarkvaraarenduse projektidest.

Käesoleva aasta lõpp tähistab minu jaoks mitme suure ja pikaajalise projekti lõppu ning tunnen, et on aeg tagasi vaadata ja panna kirja oma tähelepanekud. Etteruttavalt pean kurvastusega tõdema, et mõned tähelepanekud on täpselt samad, mis enam kui 10 aastat tagasi oma esimest tarkvaraarenduse projekti läbi viies.

Tähelepanek nr 1- Agiilsus ei tähenda planeerimatust ja lohakat tegutsemist

Agiilsus on tarkvaraarenduse projektides endiselt üks väga oluline mõiste. Iga tellija tahab oma tarkvara lasta arendada agiilselt, enamjaolt võrdsustatakse agiilsust paindlikkusega. Ometi ei mõisteta tihti, mis on selle mõiste taga ja seda kiputakse väärkasutama. Paljude arendusfirmade jaoks on see lihtsalt sõnakõlks, mida lisada oma pakkumusse lihtsalt sellepärast, et tellija tahab seda seal näha. Ja kui projekt pihta hakkab, siis ei ole agiilsest mõtteviisist ega arendusmetoodikast halli haisugi. Agiilsuse sildi taha peidetakse planeerimatust, lohakat ja läbimõtlematut tegutsemist ja kompetentsi puudumist. Väga hästi võtab minu tähelepanekuid kokku Merle Randleppa blogipostitus agiilsest mõtteviisist ja müütidest. Oma viimaste projektide kogemuste põhjal võin kinnitada, et müüdid nr 1, 4, 5 ja 6 on arendusprojektides väga visalt kanda kinnitanud.

Tähelepanek nr 2- Riigihankes kannatab paber kõike

Kui ma ise mõnda aega tagasi erasektoris töötasin ja erinevatele hangetele pakkumusi koostasin, siis ringlesid kuulujutud, et osad firmad “kirjutavad” oma pakutavale meeskonnale kompetentse, mida neil tegelikult ei ole. Tookord ei võtnud ma seda kuigi tõsiselt ja mõtlesin, et see on lihtsalt kuulujutt või liialdus…kuni tänaseni. Olles ise olnud taas tellija poolel, olen kahjuks pidanud korduvalt tõdema, et seda siiski tehakse ja isegi väga nahhaalselt. Olen korduvalt näinud, et arendusfirma meeskonna rollidel ei ole olnud küsitud rollile kohaseid elementaarseid baasoskuseid ja/või kogemusi. Ometi on tellija justnimelt selle ettevõte kasuks otsustanud heas usu, et tal on vajalik kompetents olemas. Pakkumustesse kirjutatakse tõepoolest kokku igasugust mulli – peaasi, et klient uskuma jääb.

Tähelepanek nr 3- Testimine on osa korralikust arendusmetoodikast

Siinkohal on paslik tuua näide viimasest “agiilsest” arendusprojektist. Arendusfirma väitis, et spetsifikatsiooni loomine enne arendust ei ole agiilse arendusmetoodika osa ja nemad seda ei tee. See oli minu jaoks väga kummaline väide, kuna esiteks on nõuete fikseerimine spetsifikatsiooni kujul kokkulepe tellijaga, mille põhjal toimub hiljem ka testimine ning tööde vastuvõtmine. Samuti meenus mulle ülikoolist õpitud V-mudel, mille järgi on spetsifikatsioon üks-ühele seotud erinevate testimise liikidega.

Ma üritasin pihta saada loogikale, kuidas toimub testimine kui spetsifikatsiooni ei looda. Ja ma ei pidanud kaua pead murdma kui selgus, et meeskonda pakutud testijal ei olnud õrna aimugi minu viidatud seosest. Muuhulgas laekusid esimeste etappide tarned meieni täiesti testimata. Hoolimata sellest, et testimine võiks olla iga endast lugupidava arendusfirma kvaliteedi tagamise protsessi osa, pidime seda edaspidi neile pidevalt meelde tuletama.

Tähelepanek nr 4 – Äriprotsessidest arusaamine on suure pildi mõistmisel väga oluline

Selleks, et arendada kliendile head lahendust, peab kõigepealt mõistma, kuidas ta toimetab (AS-IS tööprotsessid) ning millised on tema praegustes töövoogudes valupunktid (selle info pinnalt disainitakse TO-BE tööprotsessid). Sellise infota ei ole võimalik mõista suurt pilti ning luua lahendust, mida klient päriselt vajab. Jällegi oli minu hämmastus suur kui arendusfirma pakkus meeskonda analüütikut, kes ei suuda aru saada äriprotsessidest (rääkimata oskusest neid kaardistada ja optimeerida) ning mõista kasutuslugude olulisusest tellija ärireeglite ja nõuete talletamisel.

Teine suur komistuskivi, millest ma ei väsi rääkimast ja mida korduvalt tehakse, on AS-IS tööprotsesside kohene automatiseerimine. See on kõige suurem karuteene, mida võib ühe infosüsteemi arendamisel teha. Enne tööprotsessi automatiseerimist tuleb AS-IS tööprotsess disainida võimalikult mõistlikuks. Sellest olen pikemalt kirjutanud eraldi blogipostituses.

Tähelepanek nr 5 – Spetsifikatsioon on kommunikatsioonivahend, mitte tüütu kohustus

Minu kui analüütiku jaoks, on olnud tarkvaraarenduse projektides üks tulemuslikumaid tööriistu hästi arusaadav spetsifikatsioon. Sellele küsin alati tellija kinnitust, et ta tõesti soovib sellist lahendust nagu spetsifikatsioonis kirjas. Selline töökorraldus maandab analüütiku jaoks nii mõnegi riski – näiteks selle, et tellija väidab, et ta ei ole olnud teadlik meie kokkuleppest. Või selle, et arendaja hakkab ise leiutama, mida kliendil võiks vaja minna (või veel hullem kuidas võimalikult lihtsalt antud arendusülesanne kaelast ära saada).

Viimaste projektide käigus olen märganud, et tihti analüütikud sellist töövõtet ei kasuta ja selle läbi projekti riske ei enneta. See päädib alati sellega, et arendamisel tehakse teatud eelduseid, millest klient ei tea midagi ning mille üle hakatakse hiljem vaidlema. Sellistes olukordades olen tihti tabanud ennast mõttelt, et palju aja- ja ressursisäästlikum on kohe alguses teha natuke rohkem ja korralikumalt tööd kui hiljem hakata vaidlema ning asju ringi tegema. Analüütiku tegevustest ja tööprotsessides olen samuti kirjutanud eraldi blogipostituse.

Tähelepanek nr 6 – Tuleb mõista ja austada projekti raame ja piiranguid

Olen korduvalt näinud, kuidas riigihangete projektides (kus teatavasti on alati fikseeritud eelarve ja ajaraam ning tihti ka fikseeritud skoop) hakatakse arendama “agiilselt”. See tähendab ilma igasuguse plaanita, kuidas oleks võimalik jõuda projekti oodatava tulemini. Sellise lähenemise lõpplahendus on, et arendusfirma kulutab ära tunnid ja raha ning klient ei saa sellist tulemit, mida ta vajab.

Siinkohal peaks tuhka pähe raputama nii kliendile kui ka arendusfirmale. Klient ei saa küsida arendusfirmalt ebamõistlikku skoopi. Klient peaks suutma ise ära teha ärianalüüsi, et mõista väga täpselt, mida ta hankima läheb ja mis on reaalne ettenähtud eelarve raames ära teha. Teiselt poolt hämmastab mind alati arendusfirmade naiivsus fikseeritud eelarve, ajaraami ja skoobiga projekti arendada agiilselt. See ei ole ju kuidagi võimalik! Seda sellepärast, et kliendil on peaagu alati rahastusallikaga seotud kohustus projekt teatud ajaraamis, teatud eelarve ning lubatud skoobiga ära teha. Ja kuna kõikidest piiravatest faktoritest on kõik fiskeeritud, siis ei ole ju millegi arvelt võimalik agiilselt arendada.

Tähelepanek nr 7 – Rolliselgus on oluline

Rolliselgus ei ole oluline kitsalt tarkvara arenduses vaid igas ettevõttes/asutuses, mille eesmärk on võimalikult efektiivselt toimetada ning tagada oma töötajatele arusaam nende ülesannetest. Kuna tarkvaraarenduse projektid on tavaliselt väga ajakriitilised, siis on ükskõik millise arendusmetoodika eeldus, et täpselt oleks kokku lepitud rollid ning nende vastutused. Mida ma sellega mõtlen? Ikka seda, et arendusmeeskonnas teaks näiteks projektijuht, millised on tema ülesanded selleks, et projektis suhtlus toimiks (nii meeskonna sees kui ka kliendiga), tööd saaks nõuetekohaselt ja õigeaegselt tehtud, projekti riskid oleksid ennetatud ja maandatud ning meeskond oleks juhitud. Kui millegipärast ei ole arendusmeeskonnas ette nähtud projektijuhi rolli, siis peab olema selge, milline muu roll katab neid tavapäraseid projektijuhtimise ülesanded. See oli üks näide projektijuhi vastutusest aga sama loogika kehtib iga misiganes arendusmeeskonna rolli kohta.

Rolliselguseta ei ole võimalik üles ehitada toimivat koostööd nii arendusmeeskonna sees kui ka kliendiga ning tekivad “hallid vastutused”, mis on projekti/töö õnnestumiseks olulised aga mille osas keegi vastutust ei võta.

Minu soov uueks aastaks oleks see, et arendusfirmad päriselt ka läbi mõtestaks, kas ja kuidas nad oma tegevusega kliendile väärtust pakkuvad. Siinkohal on märksõnad – soov klienti mõista ning leida talle kontekstist lähtuvalt parim lahendus, läbitöötatud ja toimivate metoodikate kasutamine, rolliselgus arendusmeeskonnas.

Selleks, et tellijad oskaksid paremini oma vajadusi kirja panna ning osata seista oma õiguste eest, olen välja töötamas uut targale tellijale suunatud koolitust. Täpsemalt aga sellest juba uuel aastal 🙂 !

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