Toomas Polli: kuidas saad aru, kas arendajad teevad päriselt head tööd?

Töötajate edukuse mõistmine on oluline igas valdkonnas, kuid mida loovam ja kiiremini muutuv konkreetne töökoht on, seda raskemaks võib osutuda päriselt töötavate mõõdikute valimine. Elisa tehnoloogiaüksuse juht Toomas Polli tõdeb, et näiteks arendajate töö hindamisel ei saa enamasti kasutada standardset “tegi ära nii palju asju” arvestust, kuid see ei tähenda, et programmeerijate töö täpseks hindamiseks häid lahendusi poleks.

Arendus on IT-võõramate juhtide jaoks veidi must kast, kus ühest otsast suunatakse ülesanne sisse, seejärel läheb veidi aega ning varsti jõuab lauale päriselt töötav lahendus. Need on ka situatsioonid, kui arendajate tööd üritatakse hakata mõõtma kirjutatud koodiridade hulga, lahendatud ticketite või muude otsest tegevust peegeldavate parameetrite järgi. Õrna pildi võib selline lähenemine küll ette anda, kuid samas jätab see suurema osa tööst ja selle headest ja halbadest külgedest varju.

Ükski arendusprojekt ja ükski töölõik pole teisega identne. Mõni lahendus võib olla 30 rida pikk, kuid selle välja mõtlemine võis võtta kauem, kui tuimalt 1000-realise ligadi-logadi koodisasipuntra kokku kirjutamine. Jälgides vaid tehtud tööd, on lihtne jätta tähelepanuta parimate praktikate järgmine, näiteks kvaliteet ja pädev dokumenteerimine, mis tagavad lõpuks töökindluse. Kuid ka viimaste jälgimise puhul ei saa asja taandada vaid numbritele – mõni teenus ongi keerukam ja selle töökindlus võib olla nõrgem, kui teisel, veidi lihtsamal-loogilisemal lahendusel.

Seega ei tähenda vähem koodi või veidi tihedamini maas käiv tarkvaralahendus otseselt seda, et arendajad teeks halba tööd. See võivad seda tähendada, aga ei pruugi. Kui ühe kindla numbriga töö edukust mõõta ei saa, siis mis üle jääb?

Tiim toob nõrgad kohad ise esile

Tänapäevastes agiilsetes arendustiimides on arendajate töö edu mõistmiseks paar peamist viisi. Esimene neist näeb ette, et tiim hindab oma tööd ise, teine hõlmab erinevate mõõdikute kombinatsiooni, mis lubavad ühteaegu hinnata nii töö kvaliteeti, töötaja arengut, tiimi kui terviku toimimist ning eesmärkide saavutamist.

Suurem osa tänasest IT-arendusest toimub agiilsete põhimõtete alusel, mis näeb ette, et uue funktsionaalsuse loomine on jagatud tiimide vahel ning tiimid ise korraldavad oma töö selliselt, et soovitud tulemused saavutataks. Lisaks töötajate võimestamisele tagab selline lahendus, et murekohad konkreetsete töötajatega kerkivad kiirelt esile. Agiilses arenduskeskkonnas on oluline, et tiim tervikuna suudaks oma eesmärgid saavutada ja see eeldab tugevat panust kõigilt. Kui mõni tiimiliige pidevalt ootustele alla jääb, ei jää see harilikult saladuseks.

Seetõttu tasub arendajate tööedu hindamisel kuulata tiimi. Kui tiim väga suuri muresid esile ei too – ja kõik isenähtu paistab seda kinnitavat – siis muretsemiseks liialt põhjust pole. Kui aga üks-ühele vestlustel või muudel viisidel hakkab kostma, et kellegagi on suuremad mured ja töötempo või töö kvaliteet jääb pidevalt meeskonna ootustele alla – ja see olukord ei muutu ajas paremaks – on selge, et midagi on mäda. See on puhtalt kvalitatiivne mõõdik, mis on aga meeletu kaaluga.

Soovides siiski tööedule külge pookida numbreid ja leida viis, mille toel valideerida tiimi tagasisidet, tasub kaaluda mitme erineva mõõdiku kombinatsiooni kasutamist. Seda mitte aga niivõrd töötaja kui indiviidi hindamiseks, vaid terve meeskonna edu mõistmiseks. Selle jaoks oleks tarvis välja mõelda, mis on ettevõtte seisukohalt kõige olulisem – klientide rahulolu, arenduse kiirus, töökindlus, või hoopis midagi muud – ja jälgidagi neid kõiki. Kui meeskond teab, et nende edu hinnatakse selle järgi, kui töökindel loodud tarkvaralahendus on ja kui kõrgelt kliendid seda hindavad, siis selle nimel nad ka pingutavad. Mida tellid, seda saad.

Viimane tuleb kasuks ka juhtudel, kui ettevõte soovib mingid hüved siduda otsese sooritusega. Näiteks kui soov on pakkuda arendajatele neljapäevast töönädalat, on väga lihtne seada õigete kombomõõdikutega varustatud meeskonnale lähteülesanne: reeded on küll vabad, kuid tulemused langeda ei saa. Kui mõõdik on piisavalt laiapõhjaline ja päriselt ettevõtte vajadustest lähtuv, suudavad arendustiimid omakeskis töö niimoodi korraldada, et nautida hüve, langetamata samas kvaliteeti, kvantiteeti või kliendirahulolu, mida juhid ootavad.

Hüvede, preemiate ja teiste motivatsioonipakettide puhul on kriitiliselt oluline tähele panna, et ükski mõõdik või hindamissüsteem ei tohiks üritada hinnata arendajaid kui indiviidi. IT on tiimisport ja head asjad juhtuvad tänu meeskonnatööle. See on ka see, mida tasub mõõta ja hinnata. Siiski ei tasu karta, et sellise lähenemisega nigelama sooritusega töötajad läbi pragude vajuks – ebaõiglus ei meeldi kellelegi ja hästi organiseeritud arendustiimis jõuavad mured kiirelt vastutavate juhtide kõrvu.