Targo tarkvara

Kolmas osa 2009 Projektijuhtimise loengutest.

Slaidid on siin. 2009 audiosalvestus: 1. osa, 2. osa, 3. osa, 4.osa (right-click -> Save As).

2010 kursuse tarvis täiendatud loengumaterjalid:
Inimesed ja juhtimine,
Meeskonnad.

Teine osa Projektijuhtimise loengutest.

Siit leiate slaidid. Audiosalvestus: 1. osa, 2. osa, 3. osa.

2010 täiendatud loengumaterjalid:
Vajadused ja nõuded,
Kasutajad ja spetsifitseerimine.

Loen Tartu Ülikoolis sel kevadsemestril Neeme Vooluga kahasse Projektijuhtimise ainet. Pidasin just oma esimese loengu ja siin on ka materjalid.

Olin nii lahke, et tegin loengust ka audiosalvestuse. 1. osa 2. osa 3. osa 4. osa
Vahepeal unustasin diktofoni sisse vajutada, nii et osa jutust on ilmselt puudu. Tulge teinekord loengusse korralikult

Loeng põhines osaliselt ühel minu varasemal ettekandel, aga lisasin ja täiendasin oluliselt materjali.

2010 täiendatud loengumaterjalid:
Tarkvaraprojekti alustamine ja riskid,
Tarkvaraprojekti planeerimine.

Hulkuvate Kasside Riiklik Inspektsioon tellis tarkvarafirmalt Joostes Marss täiendusi oma andmeregistrile. Ülesandepüstitus oli küllaltki selge ja põhjalik ning projektijuht Joosep küsis programmeerija Priidult, kui kaua asjaga läheb. Neli nädalat, vastas Priit, Joosep pani igaks juhuks puhvri mõttes veel nädala otsa ning teatas klient Kustavile, et viie nädala pärast saab asja kätte.

Priit hakkas asjaga hoolega pihta, Joosep käis regulaarselt pärimas, kuidas läheb, ja üldiselt asi sujus. Nagu programmeerimise puhul ikka ette tuleb, tekkis ka siin ootamatuid viivitusi, kuid viienda nädala lõpuks teatas Priit siiski, et kood on valmis.

Joosep helistas Kustavile, et asjad on korras, aga arvas seejärel, et vaatab ise ka siiski funktsionaalsust. Tulemused tõstsid tal ihukarvad püsti – enamvähem iga viie kliki järel rakendus crashis ja praktiliselt ühtki kasutusjuhtu polnud võimalik algusest lõpuni läbi käia.

Joosep tormas kõva kisaga Priidu juurde, et mis toimub. Aset leidis järgmine kahekõne.

Joosep: Mis bl*#¤% selle koodiga toimub??
Priit: Kood sai just valmis ja kogu funktsionaalsus on teostatud.
Joosep: No aga miks see crashib siis, jo*#¤ma*#¤% ?!?
Priit: No aga keegi pole ju seda testinud, loomulik ju, et koodis pole kõik asjad kohe päris õiged.
Joosep: Kas sa ise ei testinud siis oma asja?
Priit: Testimiseks polnud aega ette nähtud, ise küsisid, et kui kaua teostamisega läheb, mitte testimisega. Ja üldse oled ise üks hu*”%¤% !!

Oops.

Asi lõppes sellega, et Joosep istus ise järgmise paari nädala hilisõhtud töö juures ja testis erinevaid stsenaariume ning käis ka Priidul piitsaga kannul. Mõlemad olid stressis ja magamata, Kustav õiendas iga päev, et mis ikkagi toimub, pidi ju valmis olema, ning kui projekt lõpuks üle anti, tekkis seal ikkagi probleeme, sest testimine polnud nii põhjalik, kui vaja oleks olnud.

Lisaks süüdistasid Joosep ja Priit pidevalt ka teineteist asja nässukeeramise eest, Joosep leidis, et Priidu tulemus ei oleks tohtinud selline olla, Priit omakorda, et kõik on Joosepi süü selle pärast, et projektigraafikusse ei arvestatud testimise ja vigade parandamise aega.

Milles siis tegelikult asi? Minu isiklikus kogemuses ei hävi projektigraafikud mitte niivõrd sellepärast, et hinnangud oleksid ebatäpsed, kui sellepärast, et mingid tegevused unustatakse lihtsalt graafikusse lisamata.

Iidseks vaidluste allikaks on siin, et kes peaks tegelikult hoolt kandma, et kõik tegevused oleks arvesse võetud? Programmeerijad sõimavad enamasti projektijuhte, samas õppis Joosep Audentese koolis rahvusvahelist ärijuhtimist ja kuigi ta saab hästi hakkama kliendisuhtluse ja raha lugemisega, on temalt mõneti utoopiline loota, et ta täpselt teaks, mida kõike üks tarkvaraarendaja peab tegema, et asi valmis saaks. Seda enam, et “valmis” võib tegelikult erinevate inimeste jaoks tähendada väga erinevaid asju, näiteks:

• Funktsionaalsus on koodiridadena olemas
• Keegi on rakenduse peamised kasutajajuhud läbi käinud
• Programmeerija on rakendusele kirjutanud unit testid ja need töötavad
• Testija on mingi testimisplaani alusel kontrollinud, et funktsionaalsus töötab
• Tellija on formaalse kava alusel kontrollinud mitmesuguste nõuete täidetust

Jutu peamine moraal kõigile tarkvaraprojektides osalejaile on:

• Täpsustada, mida nimetatakse valmis olekuks, kuna see on olenevalt inimese taustast ja ametist väga suuresti vaataja silmades
• Teha vahet lubaduste (commitmentide), ligikaudsete esmärkide ja tõenäosuslike ajahinnangute vahel ning iga mainitava kuupäeva puhul täpsustada, millega on tegemist.

Konkreetselt programmeerijad on mitmel korral mulle kurtnud, et nende ajagraafikud on ebarealistlikud, sest ei võta kõiki tegevusi arvesse. Peamine nõu, mida ma neile olen andnud, on:

• Tavaliselt on ebarealistlik oodata, et projektijuht ise kõiki tehnilisi tegevusi meeles jõuab pidada ja nende kohta eraldi ajahinnanguid küsida. Seega peaks programmeerija tõusma oma positsioonilt natuke kõrgemale ja ise järele mõtlema, mis on tegelikult projekti õnnestumiseks vaja teha.
• Selle asemel, et keskenduda oma ajahinnangute kitsale definitsioonile ja anda ainult koodikirjutamiseks kuluv aeg, eelda, et niikuinii tuleb sul teha hulk muid asju nagu unit testide kirjutamine, komponenditestimine, süsteemitestimine, vigade parandamine jne. Kui on teada, et keegi teine mingi osa nendest tegevustest enda kanda võtab, on väga hea, aga üldiselt seda ei juhtu ja vaikimisi on parem need kohe hinnangutena kirja panna. Mõte siis selles, et lõpuks tuleb need tegevused niikuinii ära teha, iseasi, kas ületundidena või mingil mõistlikul ajal.
• Kuus kuud hiljem ei mäleta üldjuhul keegi, kui kaua see asi tegelikult aega võttis, küll aga mäletavad inimesed hästi, kas 1) tähtajad pidasid 2) kui hästi tulemus toimis. Töötasin kord koos ühe arendajaga, kelle ajahinnangud alati väga kõrged tundusid. Kui teda aga lähemalt üle kuulata, tuli välja, et tegelikult oli ta graafikusse lisanud ka väga täpsed ja detailsed ajahinnangud sellele, kui palju teste ta ise tahab kirjutada, kui palju võtab aega funktsionaalsuse testijale üleandmine ja tutvustamine, potentsiaalsete vigade parandamine jne. Ja tulemuseks oli, et kuigi ta lõpetas oma lõigu nominaalselt teistest hiljem, oli ta projekti testimis- ja stabiliseerimisfaasi lõpuks teistest ees ning tema kood töötas palju paremini kui kellelgi teisel. NB! See ei tähenda, et kõik võiks lihtsalt oma ajahinnanguid hakata kahega korrutama, vaid seda, et inimesel tuleb tõesti hoolikalt järele mõelda, kui palju nendele ekstra tegevustele kulub ja neid detailselt hinnata!
• Vahel väidavad ülemused või kliendid, et testimine pole oluline, või et selle eest niikuinii ei maksta. Ma arvan, et selline seisukoht on tihti tingitud valdkonna puudulikust tundmisest. Kui keegi tõesti ütleb, et ärme neid lisategevusi graafikusse pane, siis ma soovitan nad enda jaoks sellegipoolest kirja panna ning lihtsalt “koodikirjutamisele” juurde liita. Elu on näidanud, et lõpuks tuleb sellised tegevused nii või teisiti ära teha ja kuna shit flows downhill, näidatakse pärast ikka näpuga progeja peale, et tema tegi halvasti.

Pidasin hiljuti Webmedias ettekande sellest, mida tuleks teha tarkvaraprojekti alguses, enne kui me tegelikult ridagi koodi kirjutame.

Panen oma materjalid siia ka, ehk on kellelegi abiks. PowerPointi formaadis slaidid on siin.

Me kõik teame, et tarkvaraprojektides tuleb ette igasuguseid raskusi. Samas on põgusa pealevaatamisega küllaltki keeruline hinnata, millised probleemid meil tegelikult esinevad. Võtsin seega taaskord appi Steve McConnelli ja panin kirja lihtsa testi, millega hinnata, kas projektil läheb hästi, mitte nii hästi või oleks osalistel kohe aeg hakata uut töökohta otsima.

Aga siin siis test.

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.

Mitmesuguste uuringute põhjal on leitud, et ligi pooli alustatud tarkvaraprojekte võib lugeda ebaõnnestunuks. Seega, kui lugejal on olnud tegemist mõne tarkvaraprojektiga, on suure tõenäosusega olemas ka kogemus mõne puusse läinud projektiga. Huvitav on aga jälgida, milliseid abinõusid selle puhul ette võetakse. Selgub näiteks, et inimesed on õnnetud ja rahulolematud, mida teha? Juhtkond korraldab neile kõva peo, uskudes, et selle abil saab kõik korda, aga kas see oli tegelikult asi, mida vaja?

Steve McConnell laiendab oma suurepärases raamatus “Software Project Survival Guide” Maslow hierarhia ideed tarkvaraprojektidele.

Järgneval skeemil on klassikaline Maslow hierarhia inimeste kontekstis:

Laiendades sama ideed tarkvaraprojektile saame aga sellise diagrammi:

Ja nagu inimeste puhul, pole meil mõtet tegeleda hierarhia ülemiste osadega, kui alumised on rahuldamata. Oletame, et mul on paha tuju. Sõbrad kutsuvad mind kinno, et asja parandada, aga see ei muuda midagi, kui minu probleem on tekkinud hoopis sellest, et mul on kõht tühi! Samamoodi ei aita inimestele peo korraldamine, kui probleemiks on see, et tähtajad on ebarealistlikud ning inimesed peavad kogu aeg ületunde tegema.

Tarkvarafirma Joostes Marss ostis hiljuti AS HüperKonsultantidelt uue HüperGeneraatori(tm) versiooni. HüperGeneraator on kirjade järgi vahend, mis kirjutab programmeerija eest 97,4% koodist ise valmis, joonistad ainult diagrammi ette, vajutad nuppu ja voilà, rakendus ongi olemas.

Järgmises projektis otsustatigi HüperGeneraator täie hooga tegevusse rakendada. Nagu ikka, tehti pärast esialgset analüüsi valmis projekti graafik. Programmeerijad Priit ja Peeter vaatasid eeldatava mahu üle, lugesid vormid-päringud-moodulid kokku ja leidsid, et kuus kuud tööd tuleb kindlasti ära. Projektijuht Joosep polnud nõus: aga HüperKonsultantide demost oli ju näha, et need vormid, mis varem võtsid päeva, võtavad nüüd ainult pool tundi! Üle kahe kuu ei tohiks kindlasti minna! Priit ja Peeter ei osanud ka suurt midagi vastu kosta, Joosepil on uhkem ametinimetus, eks tema teab paremini.

Tippjuht Tõnis vaatas graafiku üle, imestas küll, et kas tõesti saab nii ruttu, aga eeldas, et küllap projektiga lähemalt seotud inimesed teavad paremini. Samamoodi imestas klient Kustav, aga lõpuks löödi siiski käed.

Tegelikkuses selgus muidugi näiteks, et

• HüperGeneraator genereerib koodi ainult positiivse stsenaariumi jaoks, igasuguste vigade käsitlemine tuleb hiljem juurde pookida.
• Vormide asetusest on HüperGeneraatoril küllaltki fikseeritud arusaam ja kui Kustav leidis, et tema töötajad kõiki vajalikke andmeid korraga ei näe, tuli need ringi teha.
• Sama päringute kohta.
• Kui midagi oli juba valmis genereeritud ja sinna seejärel muudatusi tehtud, aga äkitselt oli vaja andmemudelit kohendada, siis uuesti genereerimine hävitas muidugi olemasolevad muutused.
• jne. jne.

Asi lõppes muidugi sellega, et Priit ja Peeter tegid kõvasti ületunde, Joosep kutsuti mitu korda Tõnise juurde vaibale, Kustav sai omakorda ministeeriumi ülemuste käest pähe jne.

Küsimus, kas koodi genereerimine on üldse mõistlik idee, on eraldi teema (sellest millalgi tulevikus), aga praegu on huvitav tähele panna, millistele eeldustele kõik osalised oma tegevuse rajasid. Igas olukorras jaguneb otsuste alusmaterjal kaheks: info, mis tegelikult teada on, ja asjad, mida me eeldame. Olukorras, kus on tegemist millegi tundmatuga (olgu see siis tehnoloogia, teostaja, partner või klient), on teadaolev info suures vähemuses, jäämäe veealuse osa moodustavad eeldused.

Antud juhul:

• Kõik osalised eeldasid, et HüperGeneraator on antud projekt jaoks sobiv vahend.
• Priit ja Peeter eeldasid, et Joosepil on eelnev kogemus taoliste vahenditega.
• Joosep eeldas, et kui programmeerijad juba uue ajagraafikuga nõus on, siis saavad nad sellega ka kindlasti hakkama.
• Tõnis eeldas, et projektirühm on kava korralikult läbi mõelnud.
• Kustav eeldas, et Joostes Marsil on tekkinud uued võimalused projekte senisest kiiremini täide viia.

Üks eeldus viis teiseni ja kui projekt lõpuks kümne kuu pärast (sest liiga agressiivselt planeeritud projektid võtavad vahepealse ümbertegemise tõttu veel rohkem aega) valmis sai, ei jõudnud keegi ära imestada, kuidas asjad küll nii hulluks said minna.

Joostes Marss pole teab mis hiigelfirma, aga isegi seal oli halbadel eeldustel katastroofiline tagajärg. Suurtes, paljude inimestega organisatsioonides on eeldustel kriitiline roll. Töötan praegu Microsofti Office’i divisjonis, mis koosneb kümnetest väiksematest produktidest, igaühel omakorda kümned arendajad. Kõik need produktid on omavahel tihedalt integreeritud, kui näiteks SharePoint lisab uue andmetüübi, peavad inimesed Outlooki, InfoPathi, Accessi, ECMi, Searchi ja mitmetes teistes gruppides, mis SharePointist andmeid oskavad lugeda, mõtlema, kuidas seda kõige paremini toetada. Muidugi katsutakse sama ülesande mitmekordset lahendamist vältida, aga see põhjustab enamasti situatsiooni, kus mitmed tiimid ootavad kellegi järel, et need selle ühise lahenduse valmis teeksid, teised tiimid ootavad jällegi esimeste järel jne. Sellises ahelas on rohkesti võimalusi halbadel eeldustel põhinevate otsuste tegemiseks, olgu siis tegemist tehnoloogia, ajagraafiku, inimeste võimekuse või millegi muu valesti hindamisega. Sellepärast tuleb ka panna suurt rõhku uurimisele, mis meie edu jaoks kriitilistes lõikudes tegelikult toimub ja kuidas asjad töötavad. Olulisel kohal on siinkohal näiteks täpsusküsimise ja täpsusvastamise rakendamine.

Eeldused võib jagada mitmesse kategooriasse, millest igaühe kohta saab enamasti küsida häid, täpseid küsimusi. Vaatleme näiteks HüperKonsultantide reklaamlauset:

HüperGeneraator 5.0 on parim projektide läbiviimiseks! HüperGeneraator suurendab teie koodikirjutamiskiirust sada korda!!!

Juba ainuüksi seda lauset lugedes, ilma tehnilistesse detailidesse süüvimata, peaksime mõtlema järgmistele eeldustele, mis selles reklaamis peituvad:

1. Väärtuse eeldus: koodi kiiresti valmimine on hea. Küsimus: kas koodi kiire valmimine on meie projekti juures tegelikult kõige olulisem?

2. Mõõtmise eeldus: koodi hulka ja valmimiskiirust on võimalik mingi ühe mõõdupuu järgi mõõta. Küsimus: kas me saame koodi kirjutamise kiirust mõõta? Kuidas?

3. Võimalikkuse eeldus: koodi genereerimine on alati võimalik. Küsimus: kas koodi genereerimine on alati võimalik?

4. Sihtgrupi eeldus: HüperGeneraator suurendab konkreetselt meie koodikirjutamiskiirust. Küsimus: kas meie oleme toote õigeks sihtgrupiks? Või on tegemist raamatupidajatele, kes tegelikult programmeerida ei oska, mõeldud abivahendiga?

5. Eksistentsi eeldus: meie probleemiks on, et kood ei saa piisavalt kiiresti valmis. Küsimus: kas koodi kirjutamise kiirus on probleemiks? Või võtab mõni muu tegevus hoopis rohkem aega?

6. Kategooria eeldus: Kõik projektid on sarnased ja HüperGeneraatoriga lahendatavad. Küsimus: kas erinevad projektid on võrreldavad? 

7. Samalaadsuse eeldus: meie projektid on samasugused kui teised. Küsimus: kas meie projekt on samasugune kui teised HüperGeneraatoriga lahendatud projektid?

8. Unikaalsuse eeldus: HüperGeneraator on parim vahend koodivalmimiskiiruse suurendamiseks. Küsimus: kas HüperGeneraator on ainus vahend, mida me kasutada saaksime?

9. Ajalise kestvuse eeldus: ka meie tulevased projektid on HüperGeneraatori abil lahendatavad. Küsimus (juhul kui praegune projekt on tõesti HüperGeneraatori jaoks sobilik):  aga meie järgmine ja ülejärgmine projekt?

Sarnaseid eeldusi võib leida igasugustest situatsioonidest. Tulevad näiteks misjonärid ukse taha ja küsivad: “Kas te usute, et Jumal soovib teile head ja armastab teid kogu südamest?”. Selle kohta võiks kohe mitukümmend eeldust leida, aga jäägu see heale lugejale mõtlemiseks