Rääkisin ühe tuttavaga teemal, mida on võimalik IT-s karjääri poolest üldse peale hakata. Enda üllatuseks leidsin, et ükski IT-d õpetav Eesti kool ei loetle just kuigi põhjalikult võimalusi ja ameteid, millega pärast nende stuudiumi lõpetamist on võimalik tegeleda, ja samuti ei kujuta ka paljud tudengid ette, mida nad täpsemalt pärast kooli tegema hakkavad. Hakkasin neid seetõttu ise kirja panema ja mõningase mõtlemise järel jõudsin järgmise tabelini (kliki, et suurendada):

Siin on ära toodud üksteisest ülesannete sisu poolest erinevad ametid, mille täiskohaga pidajaid ma ise näinud olen, ja kus tarkvaraalasest (päris tervet IT-d+arvutiteadust ei oleks jõudnud ühte tabelisse kirja panna) haridusest kasu oleks. Grupeering on mõneti meelevaldne ja mõnes situatsioonis liigitataks ameteid ehk teisiti. Siiski läheb praktiliselt igas tarkvaraprojektis peaaegu kõiki ka vaja, kuigi olenevalt projekti suurusest võib mõnele neist kuluda 0,1% ühemehefirma omaniku ajast kuni tervete meeskondadeni. Nt Microsoftis on tiim, kes päevast päeva lihtsalt jooksutab igapäevaste Office’i buildide suitsuteste. Testid käivad automaatselt, kuid sellegipoolest on vaja, et keegi kontrolliks, et kõik sujub, koordineeriks parandusi, saadaks vastavaid teavitusi jne.

Peale nende on muidugi veel musttuhat spetsiifilisemat varianti, üks huvitavamaid ametinimetusi, mida ma olen kohanud, oli Emulation Ninja Microsofti XBoxi divisjonis, aga need on üldjuhul teisendid tabelis toodud ametitest.

Kuna aga need ametid erinevad mitte ainult tehnoloogia, vaid ka sisu poolest, oleks väga hea, kui ülikoolid mõistaksid nende olemasolu ja annaksid ka spetsiifilisemaid teadmisi, kuidas ühes või teises hakkama saada. Igaüks neist vääriks eraldi loengukursust, kardetavasti utoopia, aga unistada ju võib.

Veel: siit ei järeldu, et ma pooldaksin mingit superkitsast spetsialiseerumist. Minu peamine point on, et nende tegevusalade olemasolu tuleb teadvustada ning ennast nende läbiviimiseks korralikult ette valmistada, kuid õige professionaal võiks vallata päris paljusid selle tabeli lahtritest. Inimene on ikkagi generalist, spetsialiseerumine on putukatele

Tiiu Laks oli kena inimene, kes mind intervjueeris.

— Kuidas sulle tundub, kas Eestis on nii kõrge infotehnoloogia tase, kui siin tavatsetakse arvata?

— Oleneb, millisel tasandil me vaatame – kas riiki tervikuna, inimesi eraldi või IT-spetsialiste. Vastus on iga grupi puhul natuke erinev.

— Näiteks e-riik, mille üle eestlased uhked on?

— Rahvusvaheliselt on Eesti võib-olla kõige olulisem omadus see, et Eesti on hästi väike. Kui Eestis elada, siis ei anna sellest endale ehk nii väga aru, aga kui käia maailmas ringi ja sõita ühest linnast teise, siis märkad, et selles või tolles linnas elab sama palju inimesi kui terves Eestis, mõnes teises jälle kolm korda rohkem inimesi kui Eestis. See on tegelikult üsna haruldane, et nii väike riik on olemas.

Nii on meil ka infotehnoloogilises mõttes võimalik väledamalt reageerida ja igasuguseid asju teha. Teinekord me kirume Eesti bürokraatiat, aga kujuta ette suurriiki, kus riigiaparaat on sada korda suurem kui Eestis. Sada korda suurema ametnikkonnaga riiki e-riigiks muuta on üsna lootusetu projekt.

Sest mida rohkem on süsteemi kasutajaid, mida rohkem eri huvisid, mida keerulisem on protsess, seda raskem on seda IT-projekti läbi viia. Ühel hetkel kasvab keerukus nii suureks, et projekti ei ole võimalik mõistliku ajaga täide viia.

Ameerikas on olnud selliseid kolossaalseid ebaõnnestumisi IT-vallas. Tihti tuuakse näiteks FBI. FBI tahtis endale infosüsteemi, kus oleksid kõik nende menetlused ja kriminaalasjad ning igal agendil sellele ligipääs. Projekti peale kulutati müstilisel hulgal raha, sadades miljonites dollarites, mis on rohkem kui terve Eesti avaliku ja erasektori IT-kulutused ma ei tea mitme aasta peale kokku. Ja sellegipoolest asi lihtsalt ei läinud käima.

Eestis on neid asju lihtsam läbi viia, on lihtsam e-riigi taolist süsteemi käivitada. Selle pärast vaatavadki välismaalased, et ohoo. See võtab neil suu lahti, et kodanikul on võimalik riigiga kõik asjad kodunt lahkumata korda ajada. E-valimised on paljudele muidugi täielik ulmeteema, aga kas või sellised lihtsad toimingud, nagu ID-kaardiga allkirja andmine. See on väga lahe.

— See tähendab siis ju, et Eestil pole mõtetki üritada kas või e-pileti süsteemi näiteks Poola eksportida, sest süsteem ei hakka suuremas kohas tööle?

— Oleneb. See on natuke erinev, kas luua süsteem nullist või käivitada väljatöötatud lahendus uues kohas.

Paljud IT-lahendused jäävad tihti selle taha, et hakatakse nullist tegema ja tahetakse, et süsteem rahuldaks kõigi huve, et kõik inimesed saaksid kohe kõike teha. Just siin mängib rolli, kas meil on 50 või 500 või 5000 ametnikku ehk erinevat soovi. Väga tihti jääb kõik selle taha, et hammustatakse liiga suur tükk, alahinnatakse ülesande keerukust ja ülehinnatakse enda võimeid. Ühel hetkel saab jõud lihtsalt otsa.

Aga kui süsteem on juba olemas ja on selge, mis töötab ja mis mitte, siis sealt samm-sammult edasi minna on oluliselt lihtsam. Kuigi ka sel puhul võib mingil hetkel keerukuse piir vastu tulla.

— Eesti on siis IT-lahenduste inkubaator?

— Eestis on suhteliselt vähe programmeerijaid. Hästi raske on öelda, kes neist on millisel tasemel. Hulk tudengeid lõpetab igal aastal informaatika eriala Tartu ülikoolis ja tehnikaülikoolis. Kuid mitte kõik lõpetajad ei jää tingimata selle eriala peale. Aga lisaks on hulk rahvast, kes ei ole programmeerimist koolis õppinud, kuid töötavad sel alal.

Kokkuvõttes – suurusjärk jääb umbes samaks.

Aga maailma mõõtkavas on neid ikka vähe. 10–15 aasta peale kokku on seda kaadrit tekkinud ikka suhteliselt vähe. Mõnes rahvusvahelises suurfirmas (Microsoftiga ma ei hakka võrdlemagi) töötab mitukümmend korda rohkem programmeerijaid kui terves Eestis.

See tähendab, et meil ei ole võib-olla võimalik teha nii suuri, vägevaid ja seinast seina IT-lahendusi. On oluliselt vähem spetsialiseerumist ja oluliselt rohkem seda, et üks inimene peab ära tegema seitse eri ülesannet, milleks suurkorporatsioonis oleks seitse inimest. Loomulikult ei ole tal siis võimalik tööd nii põhjalikult teha. Eestlastel on tekkinud harjumus väiksemate jõududega teha valmis töötav lahendus, mis ajab asja ära.

Võib-olla Saksamaal kirtsutatakse nina, et teete seal kümne inimesega projekti, mis projekt see sihuke ka on. Aga enamiku e-riigi lahendusi on loonud maailma mõistes väga väikesed meeskonnad. Struktuurne probleem on lihtsalt Eesti üks eripära – Eesti on väike, siin on vähe inimesi ja kõik probleemid tuleb lahendada nende inimestega, kes siin on.

Kuna inimesed peavad tegelema rohkem igasuguste üldiste küsimustega, siis on spetsialiseeritus väiksem. Ma ise olen ka täielik universaal – ma teen kõike, müügitööst kuni tehniliste ülesanneteni. Kui kõrvutame Eesti ja mõne muu maa spetsialisti, on sügavust Eesti omal arvatavasti vähem. Samas on rohkem oskust, kuidas pisikese ajavaru, ressursi ja meeskonnaga midagi valmis saada. Kas see on hea või halb? Sõltub olukorrast.

— Nii et see on omamoodi väärarusaam, et IT-valdkond on üks meie suurema potentsiaaliga ekspordiartikleid?

— Ma ei tea, kuivõrd realistlik ekspordiartikkel see on, aga sellist promo eksporditakse küll kõvasti. Ma arvan, et see hakkab ennast kindlasti ära tasuma. Kui on teada, et Eestis on kõvad programmeerijad, kes teevad lahedaid asju, on see kõva plusspunkt juhul, kui näiteks Inglismaal peab keegi otsustama, kas palgata inimene Eestist või Malaisiast. Lihtsalt selle seose tekkimine ja otsustajateni jõudmine võtab natuke aega. Aga kindlasti on selline maine pingutust väärt.

— Sa lugesid Tartus informaatikatudengitele tarkvara projektijuhtimise kursust. Mida tudengitega töötamine sulle uue IT-põlvkonna kohta ütles või näitas?

— Ma arvan, et inimesed on üle maailma põhiolemuselt samad – ühesugune võimekus ja IQ. Lihtsalt digitaalses elus muutuvad olud väga kiiresti.

1960. aastatel oli IBM infotehnoloogia A ja O, nad olid võitmatud ja miski ei saanud neid kõigutada. 1990. aastate alguses oli firma aga katastroofi äärel, 1992 oli IBM-i kahjum 8,1 miljardit dollarit, mis oli tollal USA ajaloo rekord. Asi polnud selles, et IBM-i inimesed oleksid olnud rumalad (IBM-is töötas nobeliste ja Turingi auhinna võitjaid), ega ka selles, et IBM-il oleks olnud halb tehnoloogia.

Juhtus lihtsalt see, et tehnoloogia, millele IBM oli ise aluse pannud, hakkas muutma ühiskondlikke struktuure. Infotehnoloogia demokratiseerus ja peale kasvas uus põlvkond, kellel oli arvutitega hoopis teine suhe, tehnoloogia oli nende elu igapäeva osa, mitte enam miski, mida valge kitliga onud hooldama ja paigaldama pidid. Tehnoloogiauuenduse tulemusel toimus ka inimeste uuenemine. IBM ei osanud uut demograafilist gruppi enam kuidagi käsitleda ja kaotas liidrikoha.

Sama protsess kestab tõusulainena edasi. E-postist on saanud elu lahutamatu osa. Kogu see Rate.ee, Facebooki ja Orkuti asi pole mingi lastehaigus, millest inimesed välja kasvavad. See põlvkond jääbki selliseid vahendeid kasutama, vahetades ehk vaid keskkonna millegi „professionaalsema” vastu, aga see jääbki osaks nende igapäevasest elust ja tööst.

Kümne aasta pärast jõuavad paljud Rate.ee põlvkonna liikmed ühiskonnas ja IT-alal otsustajate sekka. Mina kuulun pigem e-posti põlvkonda, aga praeguste 16–20-aastaste jaoks on suhtlusvõrgustikud elu.

Inimesed on üldiselt samasugused, aga kommunikatsiooni-viisid ja kuidas igapäevaseid asju tehakse – see muutub arvatavasti pidevalt ja jääbki muutuma.

Kui ma üliõpilastega rääkisin, siis mõni leidis, et kirjandus, mida ma soovitan, on anakronistlik – nendel on uued iidolid peale kasvanud. Ma mõtlesin, et mis mõttes:  ma rääkisin ju ainult kümme aastat vanadest asjadest.

— Kas on ka mingid põhitõed, mis jäävad?

— Kindlasti. Siin tuleks rääkida, millega infotehnoloogia tegeleb… Väga paljudel inimestel on arusaam, et asi on tehnoloogias – mida vingem tehnoloogia, seda parem. Kõik probleemid on lahendatavad veel enama ja parema tehnoloogiaga, siis saab kõik korda.

Tegelikult on infotehnoloogia kõige suurem probleem hoopis infos, täpsemalt kommunikatsioonis. Ühes servas on ärimehed, kes tahavad raha teenida, teises masin, millele tuleb ülesandeid anda. Need on kaks absoluutselt erinevat maailma. Äriidee peab minema kõigepealt meeskonnale, kes peab selle konkreetsetesse sammudesse ümber panema. Peab olema IT-inimene, kes saab aru ärireeglitest ja peab olema võimeline äriidee mingisse vormi valama ja selle olemust detailselt analüüsima. Spetsifikatsioonist saavad omakorda aru programmeerijad, kes teevad selle arusaadavaks arvutile. Nii et selles ülesandes on väga mitu tõlkimise kihti.

IT-projektid võivad tihtipeale ebaõnnestuda seetõttu, et sellessamas „telefonimängus” läheb infot vahelt kaduma või see moondub. Niisiis – süsteem, mis valmis tehakse, võib hästi töötada, aga teeb täiesti erinevat asja kui see, mida inimene alguses tahtis.

Seetõttu ei ole tõhus IT-ettevõte tingimata see, kellel on kõige võimsam tehnoloogia, vaid see, kes suudab võimalikult hästi hallata tõlkimist. Kõige hinnatumad ja vajalikumad inimesed ei ole need, kes valdavad hullult tehnoloogiaid (mis on informaatikatudengite sage eksiarvamus), vaid need, kes suudavad haarata võimalikult laia osa ärimehe ja masina vahelt.

Ideaalne IT-mees on see, kes suudab rääkida firma direktoriga ja selle põhjal programmi kirjutada, aga selliseid inimesi peaaegu pole.

— Aga kui vaadata kas või popkultuuris levivaid IT-inimeste stereotüüpe, siis nad ei ole just väga suhtlusaltid…

— Selles probleem ongi. Selleks et selle masinaga töötada… see tuleb paremini välja teatud isiksusetüübil. Sellepärast ongi tüüpilises projektis kliendi nimel äriinimene ja äriprojektijuht, IT-inimesed ja IT-projektijuht ning täitja nimel projektijuht, süsteemianalüütik, süsteemiarhitekt ja programmeerija.

Kui rääkida karjäärist IT-alal, siis võtmeküsimus enamiku IT-inimeste jaoks on, kas nad suudavad end sellest patsiga asotsiaalse poisi stereotüübist välja murda ja rohkem suhelda või mitte.

— Millisena sa IT tulevikku näed?

— Ma ei usu, et näiteks Bill Gates ja Steve Jobs mõtlevad, kuhu võiks IT minna, või otsustavad, kuhu seda liigutada. Need muutused algavad enamasti kasutajatest, alt üles. Peamine on see, et IT demokratiseerumine jätkub.

Kui mõelda kas või Wikipedia fenomenile, siis seal on sündinud sünergia tehnoloogia ja inimeste vahel. Tehnoloogia loob uusi võimalusi ning hakkab inimeste elus suuremat rolli mängima. Muidugi oleneb inimesest, kes harjub sellega kiiremini, kes aeglasemalt. Iga järgmise põlvkonnaga – isegi mitte põlvkonna, vaid kümnendiga – moodustab tehnoloogia inimelust suurema osa, inimeste ja tehnoloogia põimumist on rohkem, mis tekitab uue sotsiaalse tellimuse uute tehnoloogiate järele, mis võimaldaksid suhtlust veelgi kasvatada.

Interneti algusaegadel poleks tänased sotsiaalsed võrgustikud Rate.ee, Facebook, Orkut olnud mõeldavad, sest interneti kasutajaid oli lihtsalt nii vähe. Aga nüüd, kui neid on kõvasti rohkem, on ka rohkem inimesi, kes kulutavad teatud tunnid nädalas internetis olemise peale. Nii on tekkinud sotsiaalne tellimus – näiteks kohvikus lobisemas käimise asemel saab nüüd suhelda sotsiaalses võrgustikus. See protsess läheb kindlasti edasi. Mis kuju see täpselt võtab, ei julge ma ennustada. Aga ma arvan, et pääsu sellest ei ole.

— Kaugele see minna võib? Skeptikud väidavad ju, et paradoksaalselt tekitavad sotsiaalsed võrgustikud antisotsiaalsust, inimesed ei suhtle enam…

— Kindlasti killustab see ühiskonda. 30 aastat tagasi ei saanud ükski radikaal (ükskõik, kas poliitikas, usu- või muus valdkonnas) kohvikus oma hulludest mõtetest rääkida, ta rahustati enne maha. Tänapäeval aga on väga lihtne leida interneti abil üle maailma endasuguseid radikaale, kes jagavad sinu mõtteid. Ja siis nad võimendavad vastastikku üksteist. Seega – selle asemel et radikaalid rahuneksid, annab internet neile ohtralt võimalusi end veel rohkem üles kütta.

Kui luusida ringi vandenõuteoreetikute, usuhullude või äärmuspoliitikute foorumites, paneb imestama, kust sellised inimesed tulevad. Sotsiaalne grupeerumine hakkab toimima hoopis teisi dimensioone mööda – samas majas elamine muutub oluliselt vähem tähtsaks kui see, et me käime samas foorumis.

Mul pole õrna aimugi, kas see on hea või halb ja mis mõõdupuuga seda peaks mõõtma, aga see on vältimatu ja sellele ei saa kuidagi kätt ette panna. Ühed struktuurid asenduvad teistega ja uued struktuurid on mitmes mõttes teistsugused, seal on oluliselt kitsam spetsialiseerumine, on oluliselt vähem sotsiaalset kontrolli, kas või radikaalide korralekutsumiseks. On muidugi ka positiivseid näiteid, kas või see, et inimesed „tulevad kokku” ja kirjutavad Wikipediat vms, mis on võimalik ainult tänu internetile.

— Euroopa Komisjoni tellitud uuringu järgi ei ole eurooplased nõus interneti sisu eest maksma, osa neist ka siis mitte, kui tasuta kvaliteetinternetti polekski.

— Kui palju neid ikka on, kes toodavad internetisisu raha teenimiseks? On tuhandeid inimesi, kes kirjutavad blogisid, mis on väga huvitavad ja sisukad ja sugugi mitte halvemad kui New York Timesis või Economistis ilmuvad artiklid. Sellepärast, et neil on sisemine tung seda teha.

Samamoodi võime rääkida muusikast. Suured muusikafirmad võitlevad hambad ristis internetipiraatlusega. Aga on selles midagi hullu, kui need suured firmad peaksid ära kaduma ja selle asemel oleks meil miljon korda rohkem võimalusi sõltumatute muusikategijate loominguga tutvuda?

Kultuuriski toimub tohutu killustumine. Selle asemel et meil oleks viis suurt valikut, on meil 5000 mikroskoopilist valikut.

— Aga kes võidab piraatide ja intellektuaalse omandi kaitsjate sõja?

— Ma arvan, et tehnoloogiliselt ei ole piraatlus põhimõtteliselt kontrollitav. Needsamad suured muusikafirmad ei ole peaaegu mingit edu saavutanud. Tõenäoliselt ei ole võimalik midagi teha. Meie moraalne seisukoht ei puutu seejuures asjasse.

Maailmas ei ole sellist jõudu, mis suudaks peatada info leviku. Täpselt samuti nagu tehnoloogilise arengu ja uute sotsiaalsete väärtuste tekkimise.

On arenguvestluste aeg. Praegu on neljas aasta, mil see ülesanne minu ametijuhendis seisab, ja panen sel teemal lõpuks mõned kogutud mõtted kirja.

Tarkvara tellija seisukohalt näeb projekt välja umbes selline:

Ehk siis nad eeldavad, et saavad mingi raha eest kaetud ära erinevate valdkondade kompetentsi mingite tarkvarakomponentide osas. Erinevaid komponente võib teostada sama või erinevad inimesed, eeldame siinkohal lihtsuse mõttes, et iga ruutu täidab erinev inimene.

Kui meil tuleb nüüd tööle ilma eelneva kogemuseta nooremarendaja, on tema kompetents tegelikult selline:

Selge see, et tellijale selline valgete laikude jätmine ei meeldi, sellepärast aitavad meie uut arendajat üldjuhul kolleegid kõrvalruutudest, näiteks inimesed, kes seonduvaid komponente haldavad, annavad tehnilist nõu, analüütik hoiab asjal rohkem silma peal jne.

Igal inimesel tekib mingi ala, mille raames ta projekti üldist käiku mõjutab. Ja kuna tellija maksab meile lõppkokkuvõttes kogu ruumi täitmise eest, on kasu, mida inimesed projektile toovad, otseselt seotud nende mõjuala suurusega. Teisisõnu, kui palju on teistel teda ümbritsevatel inimestel temast abi, võrreldes sellega, kui palju teised peavad teda järele aitama.

Tegelikus elus tuleb neid dimensioone veel juurde, näiteks saavad inimesed oma mõju avaldada projektijuhtimise ja kliendiga suhtlemise liinis, aga põhimõte jääb samaks.

Ja tavaliselt ei jää inimesed igaveseks ajaks abivajajaks, vaid arenevad nii kaugele, et täidavad oma valdkonna adekvaatselt ära ja hakkavad ise pigem teistele nõu andma:

Mis on jutu moraal:

See mudel annab meile ka automaatselt meetodi inimeste tulemuste ja kasutoomise hindamiseks. Meil pole vaja lugeda koodiridu ega bugisid ega function pointe ega spetsifikatsioonilehekülgi ega laua taga istutud tunde. Kõik need mõõdikud illustreerivad vaid pisikest lõiku sellest, mida inimene tegelikult teeb, kui paljude teiste projektiosalistega ta suhtleb ja millist kasu ta neile saab tuua, rääkimata asjaolust, et need andmed on väga kergesti võltsitavad

Vaja on ainult vestelda kõnealuse inimese kaastöötajatega erinevatest dimensioonidest (arendaja puhul näiteks teised arendajad, tema lähim analüütik, testija, projektijuht, klient jne) ja küsida, millist kasu on inimene X teie vaatekohalt nii projektile kui ka teile endale toonud, ning me saamegi hea pildi sellest, kes on tegelikult väärtuslik, kes mitte.

Kokkuvõtlikud järeldused:

1. Arendaja loomulik karjääriprotsess on, et ta vajab aja jooksul vähem kõrvalist abi ja hakkab järjest rohkem aitama teisi. Esimeseks sammuks on siin üldjuhul oma loomuliku ruudukese äratäitmine ning teiseks laienemine mõnda kõrvalasuvasse, vastavalt isiklikele huvidele ja projekti vajadustele.
2. Igal inimesel tuleb ette loomulik piir, millest alates ainult omaenda kitsas töövaldkonnas opereerimine pole piisav, et igal aastal palka juurde küsida, kuna ta on iseenese ruumi lihtsalt ära täitnud. Samas on igas projektis alati küllaga valgeid laike, mille täitmisega rohkem kasu tuua.
3. Ja kõige olulisemana minu isiklik põhireegel arenguvestluste osas: inimese väärtus projektile on võrdeline talle töökaaslastelt osaks saava respektiga.

Paljud lugejad mäletavad ehk 1990. aastate esimest poolt, kus iga endast lugupidav eestlane oma isikliku panga asutas. Mingil hetkel avastasid pankurid aga, et lihtsalt kilekottidega sularaha ühest kohast teise tarimisest ei piisa, ja algas buum Eesti IT-maastikul. Tarkvarafirma Joostes Marss oli tol vanal heal ajal loomisjärgus ning tegi suuremaid ja väiksemaid projekte Ahja Kommertspangale.

Tihti lõppesid Ahja Kommertspanga IT-juhi Ilmari ja Joostes Marsi projektijuhi Joosepi vahelised vestlused aga mõlemapoolse ärritusega. Tüüpiline telefonikõne oli näiteks järgmine:
Ilmar: Kas bugid on ära parandatud?
Joosep: Mis bugid?
Ilmar: Need, millest ma kuu aega tagasi telefonis rääkisin!!
Joosep programmeerija Priidule: On ära parandatud või?
Priit: Midagi ma vist parandasin jah…
Joosep Ilmarile: Jah, on küll parandatud.
Ilmar: Millal kätte saab?
Joosep: Homme saadame.

Mõned päevad hiljem:
Ilmar: No aga ikka ei ole ju kõik ära parandatud!?!
Joosep: Mis siis veel?
Ilmar kirjeldab.
Joosep Priidule: Mis värk sellega on?
Priit: Aa, selle ma unustasin.
Joosep Ilmarile: Teisipäevaks saadame uue!

Kolmapäeval: 
Ilmar: Aga IKKA ei ole ju kõiki asju!!
Joosep: Aga see polegi bug, see on feature.
Ilmar hakkab karjuma, et tema on klient ja tema otsustab, mis on feature ja mis mitte.

Lõppkokkuvõttes võttis projekt kahe kuu asemel kaheksa, Priit logeles enamiku päevi niisama ja tegi vahele meeleheitlikke spurte, et probleeme kontrolli alla saada, kui Ilmarilt järjekordne kõne tuli. Ebaregulaarse rütmi tõttu läks ta tüdruksõbraga tülli ja kirjutas koodi sisse Ilmari aadressil ebatsensuurseid kommentaare.

Milles asi? Nagu ühes eelnevas, projektijuhtimisele pühendet jutus mainitud, on projekti õnnestumise tagamisel peamine osa korralikul kommunikatsioonil. Arvatavasti kõige olulisem asi, mida projekti käigus tuleb kirja panna ja millest kõik osalised peavad ülevaadet omama, on see, kui palju ja milliseid vigu (ehk buge või puuke) meil parajasti koodist on leitud.

Vigade andmebaasi pidamine on tegelikult väga lihtne asi, selleks on loodud suurel hulgal nii vabu kui kommertsprodukte, enamasti on puuduliku veahalduse põhjused suhtumises.

Vahel tuuakse vastuväiteks näiteks, et oh, me suudame niisama ka oma vigu meeles pidada. Absurdne. Ma pole veel näinud ühtki inimest, kes suudaks korraga meeles pidada rohkem kui kolme vea üksikasju. Võib ju ka öelda, et me parandame vead kohe nende ilmnemisel ära, aga seegi ei tööta, sest parandamine võtab vahel paratamatult kauem aega, kui meil hetkel käepärast on.

Tegelikult olen ma leidnud, et isegi väikeste projektide puhul, millega ma vahel ise oma lõbuks tegelen (ehk siis 1 inimene, 1000-25 000 rida koodi), on väga kasulik vead kohe avastamisel kirja panna (kui tegemist pole just asjaga, mis sama päeva jooksul valmis saab), sest hiljem on suur osa vajalikust kontekstuaalsest teadmisest  kadunud.

Igas veakirjelduses peavad kindlasti olemas olema järgmised komponendid:

• Täielik info, kuidas viga reprodutseerida
• Soovitud tulemus programmi käivitamisel
• Tegelik tulemus
• Kellele viga on omistatud (mitte ei eelda kõik inimesed, et keegi teine asja korda teeb)
• Vea staatus (aktiivne, parandatud, kontrollitud/suletud)

Peale selle kasutavad erinevad organisatsioonid veel mitmeid väljasid, nagu

• Tõsidus (oluline vahe, kas programm crashib või on mõni ikoon pikseli võrra paigast ära)
• Prioriteet (erineb tõsidusest, vahel on avalehel oleva ikooni pikselid olulisemad kui kord 10 aasta jooksul juhtuv crash)
• Vea parandamiseks kuluv hinnanguline aeg
• Parandamise tähtaeg (kui meil on tegemist vahepealsete verstapostidega)
• jne.

Kui vigade andmebaasi 100% kasutatakse, siis nende andmete põhjal saab projektijuht teha juba väga võimsaid päringuid, kui palju tööd on veel jäänud, kas programmeerijad jaksavad testijatega sammu pidada, milline on produkti üldine kvaliteet (s.t kas leitakse tõsisemaid või vähemtõsisemaid probleeme) jne. Samas ei tohi lisaväljadega üle pingutada, sest siis ei viitsi keegi neid enam täita. Ülaltoodud 5 välja on aga esmase tähtsusega. Kui vigade registreerimine muutub nii vaevanõudvaks, et inimesed seda enam ei tee, tuleb meil oma protsess alati optimiseerida sellele, et 100% vigadest saaks kirja pandud.

Esineb ka psühholoogilist laadi vastuväiteid, näiteks võtavad mõned programmeerijad nende koodist vigade leidmist isiklikult ja peavad selle kirjapanemist veel eriti solvavaks. Ütle mulle lihtsalt, mis värk on, ja ma parandan asja ära, pole vaja midagi kirja panna, urisevad nad testijale. Siin saame teha kaks olulist tähelepanekut:

• Kas on parem, et vea leiab meie testija või klient? Testija peaks olema programmeerija parim sõber ja programmeerija peaks teda igal viisil julgustama, et ta rohkem vigu saaks leida, sest sel viisil päästab testija programmeerija piinlikkusest, mis leiab aset, kui hoopis klient või mõni muu tähtis tegelane vea avastab ja programmeerijal tulekahju kustutamiseks ületunde tuleb teha.
• Programmeerija produktiivsust ei tohi hinnata lihtsalt vigade arvu põhjal, sest see loob initsiatiivi mitmesuguseks sohitegemiseks ja lõpuks oleme lõhkise küna ees: vigade andmebaas valetab ja ka produktiivsust hindame ilmselt valesti.

Lisaks on vigade andmebaasil mitmeid sekundaarseid väärtusi, näiteks langeb ära vaidlus teemal, kas mingi asi on bug või feature, sest kõik on ilusasti kirja pandud ja kohe vea registreerimisel saab arutada, kas asjad peavad nii olema või ei.

Kokkuvõtteks võib öelda, et võrreldes projektiga, kus projektijuhtimisvahendid täielikult puuduvad, on vigade andmebaas ilmselt esimene asi, millest alustada, sest see annab lihtsa vaevaga kõige suuremat kasu. Lisalugemist muidu Joelilt.

Enamikule tarkvaraga kokku puutunud inimestele pole vist üllatuseks, et suur osa tarkvaraprojektidest lõpeb kas osalise või täieliku ebaõnnestumisega.

Samas ei ole projekti edukuse tagamine mingi must maagia, on loodud mitmeid metoodikaid, mis kohusetundliku projektijuhi kätes enamiku tavalistest riskidest korralikult ära maandavad ja edu tõenäosuse kolme-neljakümnelt protsendilt üheksakümne viieni tõstavad (muuseas, kui sa töötad firmas, mis teeb projekte alltöövõtu korras teistele organisatsioonidele, siis töö enamvähem edukas üleandmine ei tähenda veel projekti õnnestumist või seda, et tellija sinu juurde uuesti tagasi tuleb!). Häda on ainult selles, et enamik projektijuhtidest ei oma tegelikult spetsiifilisi projektijuhtimise alaseid teadmisi või siis on nendest kuulnud, aga ei oska või viitsi neid korralikult rakendada.

Allpool on toodud üks võimalik nimekiri eduka projekti koostisosadest, kasutatav mitte ainult tarkvara-, vaid ka igasuguste muude projektide puhul.

• Projekt peab olema osa laiemast visioonist, strateegiast või eesmärgist.

Kui projekt ei haaku organisatsiooni mingi laiema eesmärgiga, on ta enamasti ka raskesti piiritletav, valgub esialgsetest raamidest kergesti välja ning väljub kontrolli alt. Samuti on sellistel projektidel palju raskem saavutada juhtkonna huvi ja toetust. Eriti halb on muidugi olukord, kus organisatsioonil polegi mingit visiooni, sel juhul võib garanteerida, et ka projektidest ei saa enamasti asja.

IT-projektidel on siin spetsiifiline oht: kuna infotehnoloogiaga on põnev ka asjana iseeneses tegeleda, alustavad tehnoloogid “rohujuure tasandilt” tihtilugu mingeid oma projekte, mis vahel sobivad organisatsiooni üldkavaga, vahel aga mitte. Enamasti sellised “asjana iseeneses” projektid hääbuvad, kui esialgsetel tegijatel entusiasm otsa saab, sest projekti taga pole organisatsiooni jõudu.

• Ressursid, ajakava ja tarnitavad omadused (featured) peavad olema tähtsuse järjekorda seatud ja seda järjekorda tuleb kogu projekti vältel ohjata.

Ja kui siis Jänes veel küsis, mida külaline leiva peale sooviks, kas mett või kondenspiima, oli Puhhi erutus juba nii suureks kasvanud, et ta vastas: “Mõlemat!”

Kõik on ilmselt kuulnud trilemmast: kiire, odav, hea, vali üks (heal juhul kaks), sellegipoolest tahavad projektide tellijad Puhhi kombel kõike korraga saada. On äärmiselt oluline, et meil oleks selge pilt, milline nendest kolmest küljest on kõige olulisem, et me teaks, mida hädaolukorras ohverdada. Samamoodi peab olema selge, milline on näiteks erinevate featurete omavaheline prioriteedijärjekord, mitte ei ole nii, et kõik asjad on kõige tähtsamad.

• Projektil peab algusest peale olema sponsor ja seda sponsorlust tuleb hoida kogu projekti jooksul.

Sponsoriks on enamasti keegi juhtkonnast (alltöövõtu puhul siis tellija juhtkonnast), kellel on voli projekti jaoks raha ja muid resursse eraldada ning muul viisil toetust avaldada. Tihti juhtub aga, et kui esialgne raha on käes, unustatakse sponsor ära, temaga ei konsulteerita enam ja kui ta kuus kuud hiljem leiab, et ei-ei, see polnud üldse see, mida ma alguses mõtlesin, lõppeb nii mõnigi projekt enneaegse katkestamisega.

• Koguda peamiste huvituvate osapoolte nõuanded ja toetus ja seda terve projekti jooksul alal hoida.

Huvituvateks osapoolteks on juba mainitud sponsor, projekti läbiviijad, juurutajad, lõppkasutajad jne. Selleks, et projekt saaks olla edukas, peab igaüks neist asjaga rahul olema. Kui lõppsaadus näiteks kasutajatele ei meeldi, on kogu vaev asjata, keegi ei hakka seda kasutama, sellepärast on ka kriitilise tähtsusega, et iga osaline saaks igas projektifaasis sõna sekka öelda.

• Projekti ulatus (skoop) on selgelt piiritletud.

Olen ise näinud suurel hulgal projekte, millele muudkui lisatakse ja lisatakse uusi omadusi, kuni kõik lõpuks kraavi läheb ja tegijad on lõhkise küna ees. Üks võimalus selle vältimiseks on projekti alguses dokumenteerida mitte ainult see, mida on plaanis teha, vaid ka seonduvad omadused, mida ei ole plaanis teha, et kellelgi ei tekiks hiljem kaksipidi mõistmist.

• Ajakava ning ressurssid on selgelt paika pandud ja osaliste poolte heaks kiidetud.

Usalda, aga kontrolli (ja pane kirja) . Väga vajalik selleks, et kellelgi ei tekiks hiljem “valikulist amneesiat” ja hilisemaid vaidlusi “aga mina eeldasin, et A, B ja C on augustiks valmis”.

• Projektil peab olema plaan.

Plaani täpne olemus sõltub projektist, aga sealt peaksid kindlasti näha olema projekti etapid, vahetähtajad, osalised, kes mingi etapi või komponendi eest vastutab jne. Tihti jäetakse sellised asjad kirja panemata ja siis selgub jällegi mõne kriitilise osa kohta, et kõik eeldasid, et keegi teine teeb selle ära.

• Nõutav kvaliteet peab olema defineeritud ja projekti vältel ohjatud.

Veel üks teema, kus tarkvara on keerulisem kui enamik muid valdkondi. Põhimõtteliselt on tarkvaras võimalik leida peaaegu lõputult vigu ja võimalusi selle parandamiseks, alates sellest, et kasutajaliideses võiks mõnda jubinat pikseli võrra vasakule nihutada, et see esteetiliselt meeldivam oleks, kuni koodikirjutamisstiili ühtlustamiseni. Projekte, kus enam millegi kallal norida ei oleks, pole olemas, ning suur osa sellistest “vigadest” jääb parandamata (andes muuhulgas alust legendidele Windows 2000 65000st veast jne). Igasuguste vigade tõsidus on suuresti vaataja silmades ja sellepärast ongi tähtis, et näiteks tellija ja teostaja asjast samamoodi aru saaksid.

Asja teine pool on seotud tarkvara põhiteoreemiga. Meil peab kindlasti olema selge ülevaade, kui palju ja kui tõsiseid vigu projektis hetkel on, projektigraafikus peab olema eraldatud spetsiaalne aeg nende vigade parandamiseks ning meil peavad olema defineeritud vahetähtajad, mil kontrollitakse kvaliteedi vastavust projektis nõutavale.

• Rollid ja vastutusalad peavad olema selged ja dokumenteeritud.

Üks hea võimalus seda teha on koostada maatriks, kus ühel teljel on osad projekti plaanist, teisel aga osalised (arendajad, projektijuht, kasutajad jne). Igasse lahtrisse teeme märke, mis on vastava osalise roll antud aspekti puhul. Võimalikud rollid on näiteks “vastutaja”, “teostaja” (tihti erinev vastutajast), “konsulteeritav” (ehk me peame vastavalt isikult nõu küsima enne kui midagi teha) ja “informeeritav” (et keegi ei unustaks mõnd tähtsat osalist teavitamast). Kui tabel läheb liiga suureks, paneme teatud valdkonna lahtrid kokku, kirjutame sinna ainult vastutaja nime ning delegeerime alamtabeli koostamise juba tollele vastutajale.

• Eksisteerib muudatuste tegemise protsess, millega kõik nõus on ja mida nad ka kasutavad.

Tihedalt seotud skoobiprobleemiga. See on jällegi asi, mis tarkvaraprojekte iseäranis kollitab. Kui majale ekstra korruse lisamine on kõigile nähtav ja inimesed saavad kohe vastu vaielda, siis tarkvarale millegi lisamist võetakse tihti palju kergema südamega. Samas tingib tarkvara olemus selle, et muudatus ühes komponendis võib vahel põhjustada ettearvamatuid tagajärgi ja suuri probleeme hoopis teises komponendis.

Oluline! Ülaltoodu ei tähenda, et me keelame igasuguste muudatuste tegemise ära ja kliendile iga asja peale lihtsalt “ei” ütleme, sest siis võime projekti küll valmis saada, aga see jääb meile viimaseks selle kliendiga tehtud projektiks. Samuti on muidugi muudatusi, mida programmeerija lihtsalt omapäi võib teha, aga mõlemal juhul peab olema kokku lepitud, millised asjad vajavad kelle heakskiitu.

• Nii projekti alguses kui ka selle kestel uuritakse, millised on projekti ohustavad riskid ning valmistutakse nendeks.

Riske on mitmesuguseid ja nad on tihti seotud erinevate eeldustega. Kuna tarkvara alal toimub kogu aeg kiire tehnoloogiline areng, on siin palju rohkem tundmatus kohas vettehüppamist ja seega ka rohkem riske projektile.

Tarkvaraspetsiifilised riskid on näiteks uue tehnoloogia kasutamise risk, milleks saab valmistuda varase prototüüpimisega või võimalusega kasutada varuvariandina alternatiivset tehnoloogiat, või asendamatute inimeste sündroom (programmeerijad on enamasti unikaalsemate teadmistega kui näiteks ehitajad), mida saab vältida regulaarsete koodiülevaatuste abil. Nendest mõlemast teen kunagi ehk pikemalt juttu.

• On olemas kommunikatsiooniplaan, mida ka täidetakse.

Kommunikatsiooniplaani tegemine on nii lihtne, et on üsna kurb, kui vähe seda kasutatakse. Projektijuht teeb lihtsalt tabeli, kuhu ühte veergu kirjutab kõik olulised asjaosalised ja teise kommunikatsiooniaja ning -viisi. Näiteks: sponsor, saata emailiga ülevaade iga 2 nädala tagant. Arendajate juht, koosolek igal teisipäeval. Tellija esindaja, helistada esmaspäeviti ja neljapäeviti. Jne.

Sellisel viisil ei unune keegi ära ja ei teki situatsiooni, kus mitme kuu järel järsku teatatakse, et asjad ei kõlba kusagile ja tuleb ringi teha.

• Õpitakse vigadest.

Üks lihtne viis vigadest õppimiseks on iga vahetähtaja järel korraldada koosolek kõigi peamiste osalistega, kus arutatakse, mis läks hästi, mis halvasti. Selle “lahkamise” tulemuste põhjal tuleb muidugi teha ka vastavad muudatused, olgu siis järgmise etapi ajakavas, kommunikatsiooniplaanis või mõnes muus aspektis.

Kokkuvõtteks: üheski ülaltoodud punktidest pole midagi keerulist ja nende kohta võib lähemat teavet leida pea igast projektijuhtimise õpikust. Iga projektijuht saab küllaltki lihtsa vaevaga oma projekti ebaõnnestumitõenäosust mitmekordselt vähendada.

Huvitav on veel tähele panna, et projektijuhtimise seisukohalt pole erilist vahet, millist tarkvarametodoloogiat me kasutame. Ükskõik, kas me kasutame ekstreemprogrammeerimist või formaalseid meetodeid, aabitsatõed jäävad ikka samaks.

 

- Mis on programmeerija produktiivsus?

Paljud tarkvaraprojektide eest vastutavad inimesed vaatlevad programmeerijat kui masinat, kuhu ühest otsast lähevad sisse raha ja kofeiin ja välja tuleb programmikood, umbes nagu joogiautomaat: paned raha sisse ja vajutad nuppu ning tulemus ongi käes.

Puutudes kokku olukorraga, kus üks programmeerija või programmeerijate meeskond saavutab paremaid tulemusi kui teine, piirdubki enamik otsustajatest nende parameetrite timmimisega. Programmeerijat proovitakse ära osta, pakutakse talle nii palju tasuta kohvijooke, kui süda kannab, ning nõutakse selle eest iga päev tuhandet uut koodirida.
Selline lähenemine on muidugi vigane nii sisendi kui ka väljundi osas. Koodiridade hulk on küllaltki halb mõõdik, samamoodi nagu seda on tehtud vigade arv jms statistilised näitajad. Millised on paremad mõõdikud, sellest teine kord, praegu keskendume eelkõige sisendi poolele.

- Miks produktiivsuse üle muretseda? 

Teine tüüpviga on enamasti programmeerija produktiivsuse tähtsuse tohutu alahindamine. Õmbleja või müürsepa poolt tehtud töö hulk kõigub ehk paar korda ja tihti vaadeldakse programmeerijat samamoodi. Ahah, lõpetasid sama kooli? OK, paneme su sama palgataseme peale samu asju tegema. 
Tegelikult võib üks programmeerija ideaalolukorras produtseerida 100 või rohkem korda toodangut kui teine ning ilmselgelt peaks iga projekti eest vastutaja tähtsamate murede seas (tarkvaratootmise põhiteoreemi kõrval) olema produktiivsuse tõstmine. Millised komponendid produktiivsust mõjutavad, katsume allpool lahti kirjutada.

1. Motivatsioon

“Don’t work for a living, work for a reason” ütles Microsofti värbamissait, kui ma nendega liitumist plaanisin. Ja tõepoolest, Microsofti kultuur on täielikult läbi imbunud ideest, et me teeme midagi vägevat, mida miljonid inimesed kasutavad, ja oleme turuliidrid. Erinevatel firmadel on muidugi erinevad motivaatorid, mida selle koha peal välja pakkuda, kuid sellised ideed on tihti asjaolu, mis inimesi pärast kella viite tööl hoiab või laupäeval kontorist läbi astuma kutsub. Kui mul on valida, kas vaadata telekat või tegeleda projektiga, saab kaalukeeleks asjaolu, kas see projekt on miski, mis rahuldab minu kõrgemaid vajadusi Maslow hierarhias (eeldusel, et kõik programmeerijad saavad tänapäeval piisavalt raha, et esmased vajadused on rahuldatud). Näideteks neist hüvedest võivad olla teiste inimeste respekt, võimalus rakendada loovust, saavutuse tunne, huvitavate probleemide lahendamine, tähtsustunne vms.
Ma arvan, et kõigi muude asjaolude võrduse korral on hästi motiveeritud, innuka töötaja ja sunnitud, jalgu järel vedava töötaja produktiivsuse vahe kuni 3x.

2. Vahendid

Vahendite all pean ma silmas nii riistvara kui ka tarkvara, kusjuures mõlema kategooria alla kuulub ehk rohkem asju, kui inimesed tavaliselt mõtlevad. Näiteks on monitori suurus produktiivsuse seisukohalt enamasti olulisem kui protessori kiirus, tarkvara alla ei kuulu mitte ainult kompilaator/debugger, vaid ka hulk muid vidinaid profileerijatest source controlini jne.
Valede/kehvade vahendite valik on vahel põhjustatud kliendi veidratest soovidest, vahel teadmatusest, vahel ihnsusest. Olen ise kogenud variante kõigist, igal korral katastroofiliste tagajärgedega, halvimal juhul neist kulus teatud ülesannete sooritamiseks julgelt terve kuu, kui korralike vahenditega oleks läinud loetud päevad.

3. Keskkond

Kas programmeerijatel on olemas koht, kus nad saavad ukse kinni tõmmata ja segamatult oma tööle keskenduda, eemal mürast, tuuletõmbest ja kõrvalruume rentiva pontsikubaari aroomist? Või on fooniks telefonide pidev helin, inimeste sisse-välja traavimine, bossi õiendamine sekretäri kallal ja kõrvallauas anekdoote rääkiv kolleeg? Kõrge produktiivsuse tsooni jõudmine võtab vaimset pingutust nõudva töö puhul vähemalt 15 minutit ning iga segaja puhul tuleb nullist alustada. Suur segajate arv päeva jooksul kahandab kõrge produktiivsusega aega mitu korda.

4. Teadmised

Programmeerimine on asjana iseeneses põnev tegevus, inimene loob eimillestki midagi, mis on väga rahuldustpakkuv kogemus. Sellepärast ongi ehk maailmas rohkem programmeerijaid, kes ka hobi korras oma erialaga tegelevad, võrreldes näiteks juuksuritega.
Teiselt poolt on tegemist väga laia ning kiireltareneva valdkonnaga, kus on samas võimalik peaaegu igat probleemi paljudel erinevatel viisidel lahendada.
Seega pole olemas mingit konkreetset teadmiste kogu, mille inimene koolist kaasa saaks ja oleks “valmis programmeerija”, valdav enamik inimeste teadmistest pärineb lihtsalt niisama asjade kallal nikerdamisest ja nende vastu huvi tundmisest. Programmeerijat tööle võttes küsin ma talt alati näidet sellest, mida ta on lihsalt niisama oma lõbuks valmis teinud või milliseid probleeme lahendanud. Inimestel, kellel on harjumuseks tarkvaraga ka hobi korras tegeleda, on üldjuhul tohutult laialdasemad teadmised kui teistel. Kas ja millal neid teadmisi vaja läheb, on juhuse küsimus, aga kriitilisel hetkel võib leidlik lahendus hoida kokku mitmeid päevi “jõumeetodil” lahendamisele kulunud aega.
Sama kehtib ka akadeemiliste teadmiste kohta: andmebaaside loengut kuulates võib ju küll mõelda, et millal mul seda algrebrat vaja läheb, aga olles vastamisi keerulise päringuoptimiseerimisülesandega, on mul tihti hea meel olnud, et koolikogemus aitab mul mõista, mis andmebaasimootori sees tegelikult toimub.

Üldise tähelepanekuna paistavad kõige produktiivsemad ja mõjukamad inimesed projektis alati silma laialdase teadmistepagasiga, mis on suhteliselt lõdvas sõltuvuses lõpetatud koolide arvust või akadeemilise kraadi kangusest.

5. Projekti läbipaistvus

Kui programmeerija ei tea, mida klient tegelikult tahab, kui analüütik ei  tea, mida programmeerija parajasti teeb, ja bossi peal kasutatakse Jedivõtteid stiilis “these aren’t the droids you’re looking for”, pole midagi imestada, kui asjad venivad ja venivad, aga midagi valmis ei saa. Korralik projektijuhtimine garanteerib muuhulgas:
- spetsifikatsiooni, millest nii klient kui ka programmeerija samamoodi aru saavad
- source trackingu, mille põhjal igaüks saab vaadata, kui palju koodi on kirjutatud ja mida see teeb
- vigade andmebaasi, kust on võimalik igal hetkel vaadata, kas produkt on heas või halvas seisus
- muutuste kontrolli, kus koodimuutused üle vaadatakse, et vältida projekti isevoolu teed minekut
- põhifunktsionaalsuse pideva (soovitatavalt automaatse) testimise, mille pealt on alati võimalik vaadata, kas asi tegelikult töötab või ei.

Need asjad aitavad igal osalisel mõista oma rolli projekti üldises olekus ning võtta vastu optimaalseid otsuseid selles osas, mida parajasti on vaja teha (nt kas on praegu hea uut funktsionaalsust luua või hoopis vanad vead ära parandada, mida kuu aega hiljem juba palju raskem teha on).

6. Otsustusvabadus

Tänapäeva sõjavägedes ei pääse samuti tarkvarast üle ega ümber ja nii mõnigi mundrikandja väänab samas ka koodi. Samas pole tulemused enamasti just kiita. Ma arvan, et probleem on suuresti sõjaväe hierarhilises, vastuvaidlematus ülesehituses. Kui seersant Sigajenko ikka ütleb, et siia paned goto, siis hoiad suu kinni ja paned.

Enamik programmeerijaist õnneks mundrit kandma ei pea, aga tundub, et nii mõndagi firmat juhitakse sarnastel alustel. Programmeerija on siiski see, kes asja tehnilisest küljest kõige rohkem teab, ja nii mõnigi projekt on kihva keeratud sellega, et asjatundmatu juhtkond sunnib tehnilisi töötajaid ebaoptimaalsetele radadele. Leian, et inimene, kes tegelikult koodi valmis kirjutab, peab omama otsustusvabadust vahendite, tehnilise disaini ja muude sarnaste küsimuste osas. Kui projekti kallal töötab palju inimesi, on neil muidugi vaja ühte jalga käia, kuid ka siis peavad otsustajad olema programmeerijate endi esindajad. Kokkuhoitud aeg kaalub kindlasti üles mittetehnilise juhtkonna või tellija võimunäitamisvõimalused, inimeste moraali hoidmisest rääkimata.

7. Kogemused

Last but not least, eelmiste projektidega saavutatud kogemused on alati kulla hinda väärt. Infotehnoloogia on tohutult kiiresti muutuv valdkond ja projekti tegemise ajal õppimine on pigem reegel kui erand. Seda enam väärtustuvad juhused, kus eelmises projektis õpitut on võimalik uuesti kasutada, või veelgi parem, on olemas näiteks üldotstarbeline klassiteek, mida uuele projektile sujuvalt üle saab kanda.

Kogemused võivad olla mitut laadi, vahel on nad kogenud programmeerija peas, kes uutele inimestele oma nõuga palju päevi jalgratta leiutamist kokku võib hoida, vahel kristalliseerunud olemasoleva koodi näol. Oluline on selle kogemuse loomine ja säilitamine. Kui vana programmeerija uuele bossile ei meeldi ja lahti lastakse, või kui keegi leiab, et nüüd liigub kõik see mees uuele tehnoloogiale ning vana koodi viskame minema, on tagajärjeks üldjuhul paljude, paljude inimkuude kaotus.

Kokkuvõtteks, programmeerija produktiivsus sõltub paljudest faktoritest, lisaks ülaltoodutele on veel mitmeid teisigi. Edukad on üldjuhul ettevõtted, kes suudavad võimalikult paljud nupud õigesse asendisse pöörata ning hiljem imestavad nad isegi, et mis küll naabermaja inimestel viga on, et nad ka kümme korda rohkema aja ja raha kulutamise järel midagi valmis pole saanud.

Vea parandamise hind kasvab aja möödudes. 

• Näide 5: Programmeerija Priit läheb kuuks ajaks puhkusele, aga klient nõuab, et programmi kohe-kohe paar muudatust tehtaks. Peeter teeb asja ära, annab üle, aga siis selgub, et mingid teised asjad on samal ajal katki läinud. Klient Kustav poetab mürgiseid märkusi, kus võrdleb programmeerijate tööd kaardimaja ehitamisega.
• Metoodiline lahendus 1: Iga programmeerija kirjutab koos koodiga ka piisava hulga automatiseeritud unit teste, mis tagavad igas olukorras keerulisema funktsionaalsuse toimimise. Kui kellelgi teisel on vaja programmis parandusi ja muudatusi teha, kontrollib ta, kas unit testid endiselt töötavad, ja tal on võimalik viga kohe parandada. Testide kirjutamine võtab muidugi lisaaega, aga see tasub end peaaegu alati ära, eriti kui on tegemist pikema projektiga, mille kallal töötab palju inimesi. Unit testingust asjana iseeneses ja pikemate/suuremate projektidega seotud iseärasustest kirjutan kunagi hiljem veel pikemalt.
• Metoodiline lahendus 2: ettevõte peaks koodi kirjutamisel kasutama ühtseid standardeid, mis võimaldavad inimestel üksteise koodi paremini mõista ja täiendada.

• Näide 6: Kustavil on kombeks alatasa mitmesuguseid väikesi täiendusi nõutada. Priit korraldab asjad tavaliselt kiiresti ära ja annab asjad üle. Kustav ei ole aga sellegipoolest rahul, kord crashib üks vorm, kord teine, ja talle jääb üleüldiselt kehv tunne. Samuti kulub Priidu ajast 30% esialgsete paranduste tegemisele ning 70% paranduste järel parandamisele.
• Metoodiline lahendus: defineerida hulk teste, mis kontrollivad programmi põhiomaduste korrektse töö. Erinevates organisatsioonides kutsutakse neid erinevalt, ma kasutan siin ja edaspidi nimetust Build Verification Test (BVT). Ilma BVT-de töötamiseta ei tee ükski programmeerija check-ini ja kliendile ei näe samuti kunagi midagi mis poleks sellest sõelast läbi käinud. BVT-de automatiseerimise korral on nende kasutamisele kuluv ajakulu mõõdetav minutites, tühine aeg võrreldes tühja töö ja vaimunärimisega, mis kaasneb paranduste parandustele paranduste tegemisega.
• Näide 7: aastal 1999 kontrollisid tuhanded ettevõtted kogu maailmas paaniliselt oma infosüsteeme, et ennetada Y2K probleemi. Tihti oli tegu süsteemidega, mille esialgsed loojad olid ammu pensionil ja hallihabemelistele Cobolihäkkeritele maksti ränka raha lihtsalt koodi ülevaatamise eest. Kui vigu leiti, oli tihti tegemist olukorraga, kus kood jooksis juba tuhandetel arvutitel üle maailma ja paranduste installeerimine põhjustas kalleid tööseisakuid. Sellest, kas Y2K oli tegelikult probleem või ei, on palju vaieldud, aga lugu illustreerib hästi asjaolu, et viga (konkreetses süsteemis), mille parandamine oleks aastal 1976 võtnud tunni, võttis nüüd tuhandeid inimtunde.

Loo üldine moraal on see, et tarkvarategemise igas etapis peab toimuma kvaliteedikontroll, mis tuleb teha võimalikult kiiresti, siis kui inimestel on asjad veel korralikult meeles, dokumentatsioon pole kusagile ära kadunud ega moraalselt vananenud. Kvaliteedikontrollist läbi lipsanud vead (olgu nad siis vead kliendi soovides, spetsifikatsioonis, disainis, koodis või kasutajajuhendis) põhjustavad üldjuhul selle, et järgmise etapi töö on tehtud valesti ning tuleb uuesti teha, mis ei mõju enamasti kellegi tujule hästi.
Tegelikult kõik väga elementaarne jutt ja paljud ehk küsivad, miks ma sellele ruumi raiskan: ühelt poolt on põhiteoreemi teadvustamine vajalik selleks, et mõista teemasid, millest hiljem juttu tuleb, teiseks aga toimub tarkvaratööstuses selle epideeminiline eiramine.

Miks põhiteoreemi eiratakse? Tihti on asi selles, et inimesed ei tea, millised metoodikad eksisteerivad asjade paremini korraldamiseks. Kui nad teavad, on nad tihti liiga laisad selleks, et neid ellu viia (ja peavad hiljem mitu korda rohkem tööd tegema, kui põhiteoreemi tagajärgede likvideerimiseks läheb).
Pahatihti juhtub ka, et inimesed leiavad, et nende töö on nii hea, et mingit kvaliteedikontrolli pole vajagi. Mul on olnud õnn töötada koos mõnede maailma tasemel inseneridega ning peamine, mis nende tegevuses silma torkab, on see, et nad panevad tohutut rõhku kvaliteedi tagamisele ning otsivad alati võimalusi selleks, et keegi nende tööd üle saaks vaadata. Aga sellest tuleb ka juba kord eraldi teema.

Lisalugemiseks veel põhiteoreeme: http://en.wikipedia.org/wiki/Fundamental_theorem

Tarkvaratootmise põhiteoreem on ambitsioonikas pealkiri, aga tegemist on niivõrd fundamentaalse asjaoluga, et väiksemat nimetust pole ka mõtet kasutada. Pealegi, kui pokkeril võib oma põhiteoreem olla, olgu siis ka tarkvaral.
Sõnastus siis:

Vea parandamise hind kasvab aja möödudes.

Lihtne ja elementaarne, eks? Samas on praktiliselt kõik ebaõnnestunud tarkvaraprojektid võimalik taandada põhiteoreemi mingis vormis eiramisele ja enamik tarkvarametodoloogiaid tegelevad põhiteoreemi tagajärgede pehmendamisega.
Enamik tarkvaraga tegelejaid mõistab seaduspärasuse olemust intuitiivselt, kuid ei pruugi taibata selle täit ulatust. Näiteks programmeerija ei pruugi mõista, et juba analüüs ja disain, millel tema kood põhineb, on vigased ja nende parandamiseks tuleb suur osa koodist ümber kirjutada. Projektijuht ei taipa jällegi, et väga tähtis on värskelt kirjutatud koodile kohe ka mõned testid kirjutada, et vead saaksid parandatud, kui programmeerija peas kõik veel värskelt meeles on. Kasutajapoolsest mittetaipamisest saab juba eraldi artikli kirjutada

Sõna “maksumuse” definitsioonist: Tarkvara maksumuse all pean ma üldjuhul silmas inimtundide arvu, mis sellesse on pandud, olgu siis analüüsi, kodeerimise, parandamise, testimise või muuna. Efektiivne projektihaldamine minimiseerib seda tegelikku maksumust ja püüab ülesande lahendada minimaalse energiakuluga. See kehtib nii vaba kui ka kommertstarkvara puhul. Hind, mida tegelikult kliendilt küsitakse, on juba teine teema.

Kõige hullemad näited tarkvaratootmise põhiteoreemi eiramisest on enamasti seotud tellija vajaduste puuduliku tundmaõppimisega.

• Näide 1: Kurikuulsamaid näiteid ebaõnnestunud tarkvaraprojektidest oli FBI Virtual Case File süsteem. Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.
• Näide 2, natuke lähemalt: analüütik Albert (nimed ja muud konkreetsed faktid siin ja edaspidi muudetud, kuid põhinevad sellegipoolest tõestisündinud seikadel) Eesti tuntud tarkvarafirmast Joostes Marss vestles klient Kustaviga Hulkuvate Kasside Riiklikust Inspektsioonist, et luua infosüsteem kasside nummerdamiseks. Kustav oli igati asjalik ja pädev, rääkis, et on vaja seda ja seda, joonistas isegi tahvlile skeeme jne, aga Albert ei pannud mitte kõike juttu kirja, vaid eeldas, et oh, see on kõik lihtne, teeme ära. Projektijuht Joosep oli äsja lõpetanud majanduskooli ega tulnud selle peale, et Alberti tööd üle vaadata. Programmeerija Peeter aga, ilma konkreetse spetsifikatsioonita peale selle, et “see on kõik lihtne, tee ära”, oli aga teisel arvamusel lihtsusest ja loodu sarnases kliendi joonisega nagu raudteejaam lennujaamaga, pealtvaadates nagu sarnane, aga olemuselt midagi hoopis muud. Eesti riik on õnneks leplik ja asi tehti suurema pahanduseta ringi (ringitegemise kulu siis ka sarnane raudteejaama lennujaamaks ümber ehitamise kuluga). Parandamise hind oleks võinud olla mitu suurusjärku väiksem, kui analüütiku viga oleks korraliku projektijuhtimise poolt kinni püütud ja Albert kliendi juurde tagasi saadetud korralikke märkmeid tegema enne, kui Peeter ridagi koodi oleks jõudnud kirjutada.
• Metoodiline lahendus mõlema näite puhul: spetsifikatsioonide ülevaatamine, milles osalevad nii kliendi- kui ka tööettevõtjapoolsed projektijuhid, lõppkasutaja ja tehniliste teostajate esindajad.

Muidugi pole analüütikud ainsad, kes vigu teevad, programmeerijate elus võib pisikesi näiteid põhiteoreemi rakendamisest leida igal sammul:

• Näide 3: Peeter kirjutas just uue protseduuri ja vajutas nuppu Compile. Samal ajal küsis teine programmeerija, Priit, temalt, mis vahe on SendMessage‘il ja PostMessage‘il. Seletuse lõpetanud, leidis Peeter, et kompilaator oli leidnud tema koodist kolm viga, kuid kuna värskelt kirjutatud kood oli Peetri lühiajalisest mälust välja uhutud, kulus tal lisaks veel kümme minutit, et meelde tuletada, mida ta ennist oli tegemas ja vead parandada. Näide on eelmistega võrreldes mikroskoopiline, aga kui selliseid väikesi segajaid, mis takistavad programmeerijal vigade kohest parandamist, tuleb päevas ette palju, kahaneb tema produktiivsus mitukümmend protsenti.
• Metoodiline lahendus: töökeskkond, kus programmeerijal on võimalik vaikselt keskenduda, ja töökultuur, kus inimestel on kombeks lihtsatele küsimustele ise kiirelt MSDNist vastuseid leida.

• Näide 4: Priit leiab, et tema kirjutatav uus hulkuvate kasside andmebaasipäring teeb enamvähem sedasama, mis hulkuvate koerte päring, ja teeb kiire copy/paste. Päring on aga keeruline ja ühes kohas jääb “koer” kogemata “kassiga” asendamata, tekitades olukorra, kus varjupaigas pannakse marutaudis rotveiler Raudhamba asemel magama hoopis pärsia kass Viktooria, kellele omanik järgmisel päeval järele pidi tulema. Lisaks tarkvaraparandusega seotud kulule oleme jõudnud kahjudeni muudes valdkondades.
• Metoodiline lahendus: iga rida koodi vaadatakse kellegi teise poolt üle. Tihti juhtub, et kui inimene vaatab omaenda kirjutatud teksti, libiseb ta detailidest alateadlikult üle, aga teisele inimesele torkab kohe silma, kuhu koer on maetud. Koodiülevaatusele kulunud aeg: 30 minutit, vea parandamisele kulunud aeg: 3 minutit. Vea parandusele ja kliendi juures paigaldamisele kulunud aeg, kui ülevaatust ei toimunud: mitu inimpäeva, halvemal juhul veel palju rohkemgi, pluss kohtukulud. (Loomulikult on ka vahepealsed võimalused, kus viga tuleb testimises välja, aga ka siis on testimise+vea raporteerimise+diagnoosimise+parandamise kulu kõvasti suurem kui esialgne 33 minutit.)

(järgneb)