Kuidas vältida kriise IT-arenduse käigus? (1)
Ootamatused on tarkvaraarenduse osa, mis tähendab, et kuigi arendajad ja teised IT-spetsialistid üritavad luua võimalikult hästi töötavaid süsteeme, siis varem või hiljem tekib kuskil ootamatus, mis nõuab kiiret tähelepanu. Elisa IT-juht Villu Teearu räägib, kuidas vedada IT-arendusi nii, et kriisidega tegelemine kogu tööaega ära ei sööks.
Iga edukas IT-tiim soovib küll selliste olukordade hulga viia miinimumini, kuid mingi piirini tuleb paratamatusega leppida ning juba projekti esimestest hetkedest panna paika töövood, mis lubavad lahendada kriise nii, et nendega tegelemine ei hakkaks häirima igapäevaülesannete täitmist.
Kuigi võiks tunduda, et äkilised tehnilised probleemid on märk nigelast planeerimisest, siis on selline tunnetus petlik. Ükski tehniline lahendus pole kuulikindel ning ka kõige parema planeerimise, dubleerimise ja kvaliteedikontrolli puhul on iga süsteemi sügavuses miskit, mis võib arendusmeeskonda kõige ootamatul hetkel üllatada.
Projektide edukus ja stabiilsus ei sõltu alati sellest, kas asja kallal on töötanud piisavalt pädevate tehniliste oskustega meeskond, vaid sellest, kas meeskond on suutnud piisavalt ette planeerida ja juba eos arvestada, et mingi osa ajast tuleb eraldada jooksvate paranduste tegemiseks.
Olenevalt sellest, kuidas on IT-meeskonnad üles ehitatud ja millist juhtimist rakendatakse, võivad murekohtade esilekerkimised lõppeda väga erinevate tulemustega. Meeskonnas, kus teekaart uputab niigi üle ääre ja kõik inimesed on viidud võimete piirini, võib iga ootamatus projekti päevadeks või nädalateks seisma panna, samas kui piisava ettevalmistusega meeskond võib suuta probleemidega tegeleda nii, et järgmiste arendusetappide ajaraamistik ei pea tundigi nihkuma.
Seega selleks, et ootamatused ei hakkaks sisse sõitma teistele tegevustele, tuleks igal meeskonnajuhil ning arendajal juba projekti esimestest planeerimiskoosolekutest alates mõelda, mis võib minna valesti, millise skoobiga probleemid esineda võivad ning kuidas neid probleeme lahendada.
Kui pädeva lähenemise juures on oluliseks osaks nii piisava ajavaru reservi jätmine kui ka varukoopiate omamine (ning testimine, et neid saaks päriselt kasutada), siis on pusle teiseks oluliseks tükiks oskus probleemide ilmnemisel korrektselt prioriteete seada.
Kriisi või kriisikese puhkemisel on haruldane, et korraga esineb vaid üks probleem. Kui midagi läheb katki, siis mõjutab see harilikult ka millegi teise korrapärast tööd ning see omakorda millegi kolmanda oma. Kuigi esmapilgul võib kõik tunduda ühtlaselt ereda leegiga põlevat, siis reaalsuses on harilikult märksa komplektsem.
Mida suuremad ja keerulisemad on infosüsteemid, seda olulisem on mõista murekohtade reaalset mõju ning nende prioriteetsust ülejäänud eesmärkide suhtes – viit sisekasutajat mõjutav probleem võib ilmselt sprindi lõpuni oodata, 100 000 lõppkasutajat puudutav mure tuleb ära lahendada kohe.
Kriisitiimidele enam kohta ei ole
Suuremates arendusüksustes, kus käib korraga kümneid projekte ning probleemide tekkimisel võivad kahjud ulatuda sadadesse tuhandetesse eurodesse, võib tunduda ahvatleva mõttena pidada kriisitiimi ehk meeskonda, kelle ülesanne ongi lahendada paratamatult tekkinud probleeme, et ülejäänud tiimid saaks keskenduda uute lahenduste ehitamisele.
Kuigi teoorias võib selline meeskond mõnda aega kasulik olla, siis võib üsnagi kindel olla, et selles tiimis töötavad inimesed on ühed kõige õnnetumad arendajad, kes ettevõtte ridadesse kuuluvad. Pidevalt vaid probleemidega tegelemine, nautimata töövõite, hakkab kiirelt motivatsioonitaset ussitama ning viib olukorrani, kus iga päev tööle tulemine on väikestviisi piin. Selle asemel, et keskenduda millelegi olulisele, tuleb kogu oma aeg investeerida teiste jamade lahendamisele.
Kui väga erilistel juhtudel on kriisitiimi pidamine mõistlik – näiteks paljude erinevate kompetentsidega inimestest koosnev tiim, kelle saab kokku kutsuda suure küberrünnaku ajal –, siis täiskohaga probleemilahendajatel ei tohiks tänapäevases IT-ettevõttes kohta olla.
Lisaks sellele, et probleemitiimi inimeste tööstaaž jääb ettevõttes tavaliselt lühikeseks, tasub ka meeles pidada, et selliste tiimide pidamine muudab kõik probleemid kellegi teise omaks. Kui inimesed teavad, et nemad ei pea oma vigade tagajärgedega tegelema, on paratamatu, et arenduskvaliteet hakkab aja jooksul libisema.
Mida rohkem on IT-spetsialistid saba ja sarvedega oma töö eest vastutavad, seda väiksem on tõenäosus, et arendusse satub sisse rumalaid vigu, mida oleks saanud rohkem tuleviku peale mõeldes vältida.
Miks üks meeskond lonkab?
Jätkusuutlikkusele panustavad IT-ettevõtted ei saa tähelepanuta jätta ka üleüldist kvaliteedikontrolli ning meeskondade tööedu adekvaatselt hindamist. Kuigi mõne meeskonna projektid on keerulisemad ja kasutavad uusi tehnoloogiaid, mille puhul on potentsiaalsete rikete tõenäosus kõrgem, siis näitavad laiemad trendid probleemkohad hõlpsalt kätte.
Sestap on nii tooteomanike, meeskonnajuhtide kui ka IT-juhtide töö hinnata oma meeskondade tööd objektiivselt. Kui kõik teised on edukad, aga üks tiim kulutab poole oma ajast tulekahjude kustutamisele, siis tasuks küsida, mis on siin teistmoodi. Ei saa välistada, et tööspetsiifika tingibki rohkem murdega tegelemist, kuid ei saa jätta küsimata, kas ehk on tiimi juhtimises midagi korrast ära.
Keegi ei tee vigu vigade tegemise pärast ning arendusprojektide juures on ootamatused osa tööst. Küll aga ei saa ootamatused ise tulla ootamatult – arendustiimi edu tagab oskus tulevikku ette näha, võimekus planeerida oma aega veel seni juhtumata asjade jaoks ning pädevus seada esikohale see, mis on kõige olulisem.
Piisavalt proaktiivse lähenemise ja läbimõelduse korral saavad tiimid sõuda õiges rütmis – tegeleda kõige olulisega ilma, et probleemidega jagelemine väärtuslikku tööaega liialt ära sööks.