Jun 06 2008

Eduka projekti retsept

Published by Targo at 5:08 am under Projektijuhtimine, Põhialused

ingredients.jpg

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.

vision.jpg

  • 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.

irontriangle.jpg

  • 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.

sponsor.gif

  • 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.

stakeholders.jpg

  • 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.

scope_creep.jpg

  • 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.

resources.jpg

  • 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”.

plan.jpg

  • 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.

wine.jpg

  • 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.

responsibility.jpg

  • 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.

change.jpg

  • 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.

risk.jpg

  • 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.

communication.gif

  • 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.

mistake.jpg

  • Õ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.

No responses yet

Trackback URI | Comments RSS

Leave a Reply