Kui sa osaled tänapäeval mingis tarkvaraprojektis, on selle osalejad või juhid tõenäoliselt kusagil öeldud, et see on agiilne* projekt. Ütlemise kohaks võivad olla müügimaterjalid, värbamiskõned või muu koht, kus vaja end popi ja tublina näidata.

Võid selle väite kontrolliks teha väikese testi:

1. Kas teil on igapäevased standupid?

Sõltumata vastusest saad 0 punkti. Rituaalsed protseduurid, nagu kindla formaadiga koosoleku pidamine, ei oma mingit tähtsust.

2. Kas teie loodud kood on viimase 2 kuu jooksul päris kasutajateni jõudnud? Tellija projektijuht ei loe, loeb ainult reaalne kasutamine!

Kui jah, lisa 1 punkt. Pidev tarne (ja ka kasutusele võtmine) on agiilse arenduse üks tugisambaid.

3. Kas teie projekti liikmed on sertifitseeritud agiilsete meetodite praktiseerijad?

Vahet pole, punkti ei saa. Sertifitseerimine on sama kõva äri kui kokaiini müümine ja paljudel tublidel inimestel on mitmesuguseid sertifikaate. Ükski paber ei vii aga projekti ellu

4. Kas te saate (vajadusel) muuta nii töö skoopi kui ka tähtaega?

Kui jah, saad punkti. Kui tuuakse vabandusi, nagu „leping/projektiplaan ei luba“, siis pole tegemist agiilse arendusega. Plaani muutmine  vastavalt oludele on agiilse arenduse põhitunnus.

5. Kas teie töö on organiseeritud 2–4-nädalasteks sprintideks?

Taas 0 punkti. Tööd võib organiseerida kuidas iganes, kasvõi nõnda, et iga arendaja tarnib erineval päeval ja erineval viisil. Oluline on vaid see, et tarnimine oleks lühikeste vahedega. Sprintideks jagatud projekt, kus tegelikult antakse üle iga viies ja juurutakse iga viieteistkümnes sprint, ei ole agiilne.

6. Kas te olete saanud viimase 2 nädala jooksul lõppkasutajate tagasisidet (loeb ka automaatsete vahendite abil saadav tagasiside)?

Kui jah, liida veel 1 punkt. Projekti tuunimine  vastavalt kasutajate tagasisidele on üks peamisi vahendeid paindlikkuse ja efektiivsuse saavutamisel.

7. Kas teil on paigas rollid, nagu Scrum Master ja Product Owner?

See on ka nulli-küsimus. Selged rollid projektis tõstavad üldiselt õnnestumise tõenäosust, sest inimestel on selgem pilt, mida teha. Samas see, millised need rollid täpselt on ja kuidas me neid nimetame, ei anna inimestele kompetentsust ja olude mõistmist juurde.

8. Viimaseks kõige olulisem küsimus – kas projekti liikmed saavad vajadusel kehtestatud protsesse eirata ja asju teisiti teha?

Kui jah, pane 1 punkt juurde. Veel üks agiilsuse põhitunnus on see, et ei muututa reeglite orjaks, vaid vajadusel tehakse neid ümber või minnakse neist mööda.

Liida nüüd punktid kokku. Kui said 4 punkti, siis sinu projektis on agiilne arendus. Kui kogusid 2–3 punkti, siis sinu projektis kasutatakse agiilse arenduse olulisi elemente. Kui tulemuseks oli 0–1 punkti – sinu projekt ei ole agiilne. On võimalik, et selles mängitakse agiilsust.

Tegelikult on testimine veel lihtsam – vt http://agilemanifesto.org/ ja kontrolli, kas sinu projektis järgitakse reaalselt neid printsiipe või mitte. Olen aga näinud mitmeid projekte, kus arvestatakse  hoopis neid „põhimõtteid“: http://www.halfarsedagilemanifesto.org/. Riigihangetel ütlevad tänapäeval vist kõik pakkujad, et nad on agiilsed, seda isegi juhul, kui hanketingimused nõuavad fikseeritud skoopi, hinda ja tähtaega.

Mida täpsemalt tähendab agiilsuse mängimine? Klassikaline võrdlus on juba seitsekümmend aastat vana.

Pärast II maailmasõda, kui USA väed olid lahkunud, ehitasid mitmete Vaikse ookeani saarte elanikud puust maandumisradu ja lennukimakette. Rajati ka puust onne, kus sees istus mees, kaks kookospähklikoort kõrvaklappideks, millest bambustorud antennidena välja turritasid. Maandumisraja ääres süüdati lõkketuled ja jäädi ootama lennukeid valgete meeste ja imeliste kaupadega… Samamoodi teevad tarkvaraprojektides tuhanded inimesed entusiastlikult standup’e ja pügavad backloge ning ootavad siis suurepäraseid tulemusi.

Tulemusi aga mõistagi ei saabu, sest just nagu pärismaalased ei mõistnud lennukite saabumise põhjust, ei mõista ka paljud projektijuhid tarkvaraprojektide õnnestumise või ebaõnnestumise põhjuseid.

Reaalselt on hea tarkvara jaoks vaja kliendi vajaduste mõistmist või edukat tundmaõppimist, oma töövahendite ja platvormi head mõistmist, kõrget tööeetikat ning ootamatustega arvestamist. Kui need omadused on olemas (ehk me oskame lennukiga lennata), siis võime kasutada ükskõik millist metoodikat (ehk võime maanduda igal lennuväljal). Ja kui neid ei ole, siis kukume iga metoodikaga puruks või ei tõuse isegi mitte õhku.

Kõik need oskused tulevad enamasti kogemuse ja suures osas ka andega. Kui esineb telekokk Jamie Oliver, tundub hea toidu tegemine imelihtne ­– sortsuke seda, näpuga toda, tuli alla ja valmis. Kui aga mina prooviks lihtsalt tema efektseid liigutusi järele teha, poleks tulemus tõenäoliselt suurem asi. Ma oskan küll üsna hästi mõnesid tarkvara alaseid probleeme lahendada, aga toidu jaoks on minusugusel tarvis detailset retsepti, kus kraadid, grammid ja minutid täpselt kirjas.

Tarkvaraarenduses nimetatakse selliseid retsepte metoodikateks. Kirjutatakse näiteks ette spetsifikatsioonide formaat, koodistandardid ja tööde üleandmise-vastuvõtmise vormid. Kulinaarses maailmas on selle vasteks McDonald’s, kus iga liigutus on spetsifitseeritud, et ka ilma eelneva kogemuseta inimene hakkama saaks. Mingis ulatuses see asi töötab, aga võib erijuhtudel osutuda kohutavalt ebaefektiivseks ja osalised võivad teha palju asjatut tööd. Ja tulemus on ka nagu McDonald’s Jamie Oliveri kõrval – täidab ennustatavalt kõhtu, aga pole mingi kõrgtasemel elamus.

Mõni inimene ei taha aga McDonald’sis mööda nööri käia või range metoodika järgi tarkvara arendada. 15 aastat tagasi leidsid mõned hakkajad mehed, et tarkvaraarenduses on bürokraatiat liiga palju ja võiks saada lihtsamalt. Nende protesti tulemusena sündiski ülalviidatud agiilse arenduse manifest.

Paljud teised tublid inimesed võtsid õppust ja saavutasid häid tulemusi. Veel rohkem oli aga neid, kes vaatasid toimuvat nagu mina vaatan telekokk Oliveri. Nägid, et tehakse mingeid liigutusi, kuid ei osanud neid järele teha ning küsisid retsepti. Vastusena sellele küsimusele tekkisidki agiilse arenduse metoodikad ja eeskirjad. Konsultandid rääkisid, milline on hea koosoleku formaat, kui kaua peaks kestma iteratsioonid, millised rollid peavad olema defineeritud jne. Selline lähenemine on aga juba oma olemuselt vildakas, sest agiilne mõtteviis vastandub just nimelt detailsetele, fikseeritud metoodikatele. Ehk siis mida täpsemalt me oma „agiilset metoodikat“ järgime, seda vähem agiilsed me tegelikult oleme. Ja retsepte järgides ei saaks minust iialgi Jamie Oliveri, selleks peaks mõistma toiduvalmistamise olemust hoopis teisel tasemel.

Vahel tehakse asja isegi halvemaks. Vana ja tuntud waterfall ja sellest tulenevad metoodikad näevad ette mitmesuguseid dokumente. Nõuded, spetsifikatsioonid, testjuhtumid jne. Kõigi nende kirjutamine pole kuigi lõbus, koodi kirjutada on lahedam. Nüüd on aga lihtne vabandada laiskust agiilsusega. Me oleme agiilsed ja meil pole spekke vaja!

Tarkvara korralikult tegemine nõuab aga endiselt arusaamist, mida, miks ja kuidas tehakse. Selle teadmise hoidmiseks võib agiilses maailmas paberdokumentide asemel kasutada teisi vahendeid, nt TDD/BDD, aga enamik mängult agiilseid projekte jätab sellised ebamugavad asjad tegemata. Lõppkokkuvõttes saame halvima mõlemast maailmast: halva kvaliteediga puudulikult dokumenteeritud koodi, mille kohta keegi ei tea, miks ja mida seal tehti ning mis läheb eelarvest ja tähtajast üle.

Milles siis asi? Agiilsus ei ole metoodika, vaid mõtteviis. Kahjuks jõutakse agiilsuse vajaduse mõistmiseni alles pärast paljude kogemuste ja teadmiste omandamist. Agiilse manifesti autorid olid kõik kogenud, targad inimesed ja nad ei tulnud ehk selle peale, et kõigil tarkvaraarendajatel pole võrreldavat pagasit.

Mida aga teha? Vajalike reeglite hulk on pöördvõrdelises seoses inimeste kogemuse ja pädevusega. Kui sul on kompetentne meeskond, siis saad olla agiilne ja head koodi tuleb nagu Jamie Oliveri potist putru. Kui sul on aga vähem kogenud meeskond, siis pead asju tegema täpsete reeglite järgi, nii nagu mina pean piiluma retseptiraamatusse. Sel juhul ei tohiks sa aga nimetada oma tegevust agiilseks arenduseks. Parem on mitte lolli mängida, tunnistada, et oled pigem McDonald’si tüüpi koht, kookoskõrvaklapid peast võtta ning mitte inimesi püstijalakoosolekule kamandada.

*„agiilne“ on eesti keeles paras värdsõna, aga saanud de facto standardiks. Parema puudumisel ja üldise arusaamise huvides kasutan seda ka siin. Tähendusväljalt sobivad vasteteks nt sõnad „väle“, „osav“, „paindlik“, “nobe”.

PS Bondoras me skoorime minu hinnangul praegu 3,5 punkti neljast, töötan ise muuhulgas selle viimase poole punkti saavutamise kallal. Kui sinu sooviks on töötada dünaamilises, kiirelt tegutsevas ja reageerivas ettevõttes ning sul on tugev .NET arenduse kogemus, võid minuga ühendust võtta.

Aga kõigepealt väike viktoriin. Andke igale järgnevatest küsimustest vastusena 2 arvu: alampiir ja ülempiir. Püüdke teha nii, et olete 90% kindel, et õige vastus on nende 2 arvu vahel.

Väliseid abivahendeid ei tohi mõistagi kasutada. Kui vastused kirjas, võib neid kontrollida siit.

Kui vastata nii, et iga küsimuse puhul on 90% tõenäosus, et õige vastus jääb antud alam- ning ülempiiri vahele, peaks saama keskeltläbi 9 õiget vastust. Samas olen seda viktoriini aga päris mitu korda tegelikus elus korraldanud. Olukorras, kus inimesed häbenevad teiste kuuldes väga ebamääraselt vastata, on tavapärane õigete vastuste arv pigem 2.

Milles on point? Mõistagi mitte inimeste vaaladealaste teadmiste kontrollis. Pigem on asi selles, et enamvähem sellise metoodikaga antakse mahuhinnangud ka enamikule maailma tarkvaraprojektidest. Kuidas nii? Väga lihtne – iga projekt on tegijate jaoks uus. Kui järgmine projekt oleks täpselt samasugune nagu eelmine, poleks seal vaja midagi teha, vaid võiksime lihtsalt võtta olemasoleva koodi ja selle kopeerida. Väga tihti sisaldab uus projekt ka mingeid uusi tehnoloogiaid ja ärivaldkonda, mille kohta teostajatel pole vähimatki aimu.

Siiski leiab iga päev kusagil aset stseen, kus projektijuht näitab vanemarendajale mingit umbmäärast kirjeldust ja küsib, kui kaua sellega läheb. Vanemarendaja ei taha muidugi välja näidata, et tal on sellest sama vähe aimu kui Peipsi ruumalast, ning käibki mingi arvu välja. Sealjuures enamasti ühe arvu, mitte alam- ja ülempiiri.

Hinnang läheb pakkumisse, sealt lepingusse ja aasta-paari pärast kakeldakse, miks asjad õigeks ajaks valmis pole saanud. Samuti võivad tellija ja täitja esialgsed hinnangud olla radikaalselt erinevad.

Mis on tarkvaraprojekti tüüpilised mured?

• Asjad ei saa planeeritud eelarves ja ajakavas valmis.
• See, mida telliti, ei ole see, mida vaja oli.
• Projekti käigus muutuvad ja täienevad nõuded pidevalt.

Halvemal juhul võib juhtuda, et:

• “Teine pool” on laisk, loll jne.
• Projekt ei saagi valmis!
• Ja isegi raha juurde makstes ei saa valmis!!

Mispärast? See pole ju ometi esimene projekt, mida “te” teete? Te olete ju oma ala asjatundjad?! Professionaalid!?

Vaatleme järgnevat illustratiivset näidet (NB! Tegemist on üldistusega. Igasugune kokkulangevus reaalse elu sündmuste või tegelastega on juhuslik).

Oletame, et oled ehitusfirma omanik. Kui palju maksab see maja?

Pakkumise esitamise tingimused:

• Esitada fikseeritud hinnaga pakkumine 05.02.2013.
• Valmimise tähtaeg 15.06.2013.
• Täpsustavaid küsimusi saab esitada kirjalikult, vastame 3 tööpäeva jooksul.
• Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.
• Tööde käigus hinda suurendada ei ole võimalik, küll aga on Tellijal õigus vajadusel hinda vähendada.
• kaasas 10 lk-line maja „detailne“ kirjeldus.
• Kirjeldus sisaldab enamasti maja välimuse kirjeldust väljastpoolt vaadates. Erilist tähelepanu on pööratud detailse maja eestvaate kirjeldamisele (kuna see on tellija arvates eriti oluline osa!).
• Kirjelduses ka üldandmed. Näiteks: elamispind 200 m², maja taga terrass, 3 korrust jne.
• Kirjelduse on koostanud ehitusalase hariduseta ja kogemuseta isik.

Ainsaks valikukriteeriumiks on hind.
Hankega käib kaasas lepingu projekt.

Kui keegi nüüd arvab, et ma liialdan, siis valdav enamik tarkvarahankedokumente, mida ma olen elus lugenud, vastavad sellele kirjeldusele.

Aga egas midagi, hakkame tööga pihta!

Ainsateks muredeks on mõistagi vaid asjaolud, et kõik kaasatud osapooled on õnnetud ning ka lõpptulemini jõudmine ei tee kedagi õnnelikumaks.

Kirjeldatu oli praegu standardsituatsioon. Kui selline projekt juba alanud on, juhtub enamasti üks kahest variandist:

Esimene võimalus on see, et täitja projektijuht hoiab raudhammastega skoobist kinni. Aset leiavad järgmised tüüpilised dialoogid:

“Aga me tahaks seda ka.”
“Ei saa.”
“Aga kuidas sellega oleks?”
“Ei saa.”
“Aga…”
“Ei saa.”

Ja loomulikult kurdab tellija, et täitja on mõistmatu.

Siiski tuleb tähele panna, et see on pigem hea variant!

Alternatiiv on tavaliselt selline:

Kõigepealt tekivad haldamatud muudatused. Pärast mitmeid tähtaegadest üleminekuid on kaks võimalust: projekt ei valmigi mitte kunagi või siis tuleb seda saneerida, suurest osast ideedest (ja poolvalmis tööst) loobuda ning see, mis toodangusse antakse, võib olla isegi väiksem kui esialgne skoop ette oleks näinud.

Kõik tarkvaraprojektidega kokku puutuvad inimesed on ilmselt seda kolmnurka näinud. Samas keegi ei kasuta seda. Alati, kui kellegagi rääkida, et mida neist valida, saab sama vastuse nagu Karupoeg Puhhilt, kui küsiti, kas too soovib mett või kondenspiima: “Mõlemat!”

Tulemus on mõistagi selge: kui kolmnurga igat tippu väljapoole tirida, käriseb see seest ning ohverdatakse see, mida on kõige raskem mõõta – kvaliteet. On ka täiesti loomulik, et kui lepingusse ikka tähtaegade ületamise eest on trahv sisse kirjutatud, lükatakse kliendile ette mida iganes, et sellest pääseda – eks pärast jõuab klaarida.

Kuna senikirjeldatud probleemid on äärmiselt tavalised, on neile mõistagi ka mitmesuguseid vastumeetmeid leida püütud.

Üks levinumaid “lahendusi” on võimalikult põhjaliku nõuete loetelu koostamine enne projekti algust. Tavaliselt käib see nii, et tellija poolelt on keegi saatnud laiali ringkirja ja palunud kõigil huvilistel oma mõtted kirja panna. Tulemus copy-paste’itakse hankedokumenti ning öeldakse, et vaat, täpselt neid asju ongi vaja.

Selle lähenemise probleemid on muidugi ilmsed:

• Kirjapandu on prioritiseerimata – kuna igaühel on hirm, et tema soovid võivad välja jääda, fantaseeritakse kokku pigem rohkem kui vähem. Tulemuseks on süsteem, mille võimalustest rohkem kui 50% ei hakka keegi kunagi kasutama – enam kui pool tellija rahast läheb lihtsalt raisku! Halvemal juhul võib hankedokumendist leida ka omavahel risti vastu käivaid soove…
• Me välistame kõik head ideed, mis meil projekti käigus võivad tulla.
• Lõplikul süsteemil on kõik “design by committee” omadused.

Teine võimalus on, et lepingus fikseeritakse keerukas muudatuste haldamise protseduur. Iga muudatus tuleb kõigiga kooskõlastada, projektiplaani täiendada jne. See on natuke parem variant, aga toob kaasa äärmiselt koormava bürokraatia. Kui iga ettepanek nõuab projektiplaani mõjuhinnangut ja spetsifikatsioonide ümberkirjutamist enne muudatuse heakskiitu, võtab plaanide ümberjoonistamine ja kooskõlastamine lõpuks inimeste kogu aja ära ja keegi ei taha seda teha. Lõpuks jõuame olukorrani, kus muudatuste haldamise protseduurist on saanud muudatuste vältimise protseduur.

Täitja poolt pakutakse muidugi omi võimalusi. Raudhammastega projektijuhist oli juba juttu, aga kõige tüüpilisem on kõigi ajahinnangute korrutamine mingi konstandiga (näiteks π). Siin on muidugi tulemuseks, et tegelik ajakulu tuleb tõenäoliselt hoopis midagi muud, kui esialgu planeeritud, ning üks või teine pool tunneb paratamatult, et on pügada saanud.

Arendajate lemmikalternatiiv on mõistagi Time&Material – tellija maksab kogu aja eest, mis arendajal kulus. See on tellijaile tihti hirmutav ning õigusega – kulude kontrolli alt väljumine on arvestatav oht.

Kokkuvõttes jõuame arusaamisele, et:

• Mittetriviaalsed tarkvaraprojektid on põhimõtteliselt ennustamatud.
• Muudatused on vältimatud.
• Tarkvaraprojekti ei ole võimalik ega praktiline detailselt ette planeerida.
• Kombinatsioon “fikseeritud hind, skoop ja tähtaeg” lõpeb enamasti ebaõnnestumisega.

Järeldus: muudatustesse tuleb suhtuda nagu paratamatusse ning protsess tuleb üles ehitada nendega arvestamiseks, mitte nendega võitlemiseks.

Aga mida konkreetselt teha?

Peamine rohi, mida kirjeldatud probleemide vastu välja pakutakse, on agiilne arendus. Peaaegu kõigile tarkvaraorganisatsioonidele meeldib kirjeldada ennast kui agiilseid. Mis värk sellega aga tegelikult on?

Agiilse arenduse alustalad on:

• Suhtlemine on tähtsam kui protsess.
• Töötav tarkvara on tähtsam kui dokumentatsiooni täielikkus.
• Kliendi ja täitja koostöö on tähtsam kui lepinguläbirääkimised.
• Muudatustele reageerimine on tähtsam kui plaani järgimine.

Vaatlen siin lähemalt Scrumi, aga nimetatud printsiibid kehtivad ka kõigi teiste metoodikate (nt Kanban) puhul.

Scrumi peamine omadus on Product Backlog – tööde hulk, mille võiks ära teha. Kõik uued ideed lisatakse lihtsalt backlog’i. Iga alametapi ehk sprindi alguses valitakse tööde nimekirjast (tellijaga koostöös!) kõige olulisemad asjad, mida ära teha, ja tarnitakse selle tulemus mõned nädalad hiljem.

Siit on ka selgelt näha, et projekti lõplik skoop ja tähtaeg ei saa olla korraga fikseeritud! See tähendab ka loobumist konkreetseks tähtajaks valmivast detailsest projektiplaanist (ning selle pidevast ümberjoonistamisest).

Teine peamine omadus on sagedased (mõõdetavad nädalates, mitte kuudes) tarned ning see, et iga tarne tulemus peab olema kliendile kohe kasutatav.

Ja kolmas peamine omadus on kiire klienditagasiside. Siit tuleneb ka nimetus “agiilne” ehk väle. Asi pole mitte selles, et programmeerijad liigutaksid kiiremini näppusid, vaid selles, et klient vaatab tööde tulemusi kiiremini ja sagedamini üle!

Scrumi õnnestumise või ebaõnnestumise määrab üldjuhul see, kas tellija läheb metoodikaga kaasa või mitte. Tean paljusid projekte, kus tiimiliikmed ütlevad, et oh, meil on Scrum, sest nad teevad igapäevaseid koosolekuid, aga tegelikult on projektil ikka fikseeritud skoop ja tähtaeg. Kui projekti üks pool on agiilne ja teine mitte, on tulemus nagu absurdianekdoot:

See, et skoop pole fikseeritud, peab olema ka arenduslepingus kajastatud, vastasel korral ei tule asjast midagi välja.

Lisaks tagasisidele on vajalik ka tellija aktiivne osalus backlogi prioritiseerimises, mis nõuab detailset süvenemist ning inimesi, kellel on tegelikult ka võimalik panustada aega ja pingutust ning samas võtta vastu otsuseid prioriteetide osas. Kui iga otsust mingi komitee või juhtrühm kinnitama peab, ei tule jälle midagi välja.

Kuidas Scrumi hinnastada?

Heaks mudeliks on fikseeritud skoobi ja T&M vahepealne variant. Iga sprindi alguses lepitakse kokku mingi tulem ning vastava sprindi lõpus tasutakse selle eest. Enam pole vaja maagilisi konstante, millega hinnanguid korrutada ja mis emmale-kummale poolele kaotuse kaasa toovad!

Süsteem on õiglane, sest tellija maksab parasjagu selle eest, mis on kätte saadud (iga sprindi tulemus peab olema kasutatav!), ning täitja saab parasjagu nii palju raha, kui palju on tööd tehtud.

Siiski võib jääda kahtlus, et milleks see kõik? Tundub kangesti hirmutav, et kuidas me siis ei kirjelda kõiki nõudeid, kuupäevi ja eurosid algusest peale ära…

Agiilse arenduse konkreetsed kasutegurid, mida igaüks oma tuttavatele tarkvaratellijatele võib presenteerida, on:

Võtame kampa projektijuhi.

Tööülesanded:

• Tarkvaraarenduse projektide juhtimine
• Pakkumiste koostamine või konsulteerimine pakkumiste koostamisel
• Projektiplaanide koostamine ning osalemine projektirühmade töös
• Kliendisuhete loomine ja hoidmine
• Lepingute ettevalmistamine ja aruandluse tagamine
• Meeskonna juhtimine

Nõudmised kandidaadile:

• Eelnev kogemus IT valdkonnas projektide juhtimisel
• Hea planeerimise ja organiseerimise oskus
• Väga hea suhtlemis- ja läbirääkimisoskus
• Initsiatiiv ja tulemustele orienteeritus
• Valmisolek õppida ja areneda
• Väga hea eesti ja inglise keele oskus
• Valmisolek töölähetusteks

Kasuks tuleb:

• Eelnev kogemus avaliku sektori valdkonnas
• Varasem kogemus SharePointi tootega või dokumendihalduse valdkonnas
• Äri-ja/või süsteemianalüüsi kogemus
• Soome keele oskus

Tööaeg : täistööaeg

Tööle asumise aeg : niipea kui võimalik

Asukoht : Tartu (või valmisolek mõned päevad nädalas Tartus olla)

“Mida pakume” osas kustutasin tavalise HR-jutu ära ja ütlen selle asemel:

1. Meie inimesed on intelligentsed, optimistlikud, teotahtelised inimesed, kes viivad asju lõpuni. Olen kõiki, kes meie toas istuvad, ise intervjueerinud ja garanteerin nende kvaliteedi
2. Meie tiim on kõige kokkuhoidvam, kus ma kunagi olen töötanud. Kui sügisel Tartu linnamaratoni jooksin, jooksid-sõitsid tiimikaaslased lõiguti minuga koos, et toetust avaldada. Süda läheb härdaks kohe sellele mõeldes
3. Me teeme tehnoloogiliselt ägedat asja. Kui SharePointi arendus on enamasti üks rist ja viletsus, siis oleme loonud lahenduse, kus “SharePointi viisi” asemel saab kasutada pigem mõistlikke, arendajatele harjumuspärasemaid ja mugavamaid mustreid. Meie praegune tehnoloogia on kiireim ja töökindlaim SP ökosüsteemis töötav lahendus, millega ma olen kokku puutunud ning tõi meile eelmise aasta Microsoft Country Partner of the Year auhinna.
4. Igakordse jalgrattaleiutamise asemel on meie rõhk pigem kvaliteetsete, taaskasutatavate lahenduste ning komponentide väljatöötamisel. Eesmärk on kasutada ära tarkvara põhiomadust: loodud väärtust saab paljukordselt kasutada.
5. Inimestele, kes vastavad meie põhiprintsiipidele: “olla taiplik, teha asjad ära ning olla hea tiimikaaslane”, saab ka väärikas diil kokku pandud.

Kandideerimiseks saada CV careers.estonia@nortal.com.

Tarkvarafirmasse Joostes Marss tuli tööle uus ja uljas projektijuht Jaana. Jaanal polnud küll formaalset tarkvaraprojektide juhtimise alast haridust (mitte et kuigi paljudel projektijuhtidel seda oleks), aga ta oli seltskondlik ning omas palju tuttavaid. Muuhulgas oli tal sõber Jim, kellega Jaana oli kohtunud ühel JCI üritusel. Jim oli hiljuti tööle asunud IBMis ja rääkis Jaanale oma kogemustest. Meil vaadatakse kõik töötulemused ja dokumendid ühiselt üle ja kõik asjad on dokumenteeritud! Ja iga päev on koosolek, kus arutame päevaplaani, nii et kõik teavad, mis toimub! Niiviisi on kord majas ja tulemus kvaliteetne! Kuna Joostes Marsis taheti pahatihti parimat, aga välja kukkus nagu alati, avaldas see jutt Jaanale sügavat muljet ja ta tahtis samuti vastavat lähenemist juurutada. Me peaksime ka igapäevaseid koosolekuid korraldama ja rohkem dokumente kirjutama!

Vanem olija, projektijuht Joosep, laitis selle idee maha. Mis bürokraatiat sa tahad siin tekitada? Tõelised programmeerijad kirjutavad programme, mitte dokumentatsiooni, oli tema kindel seisukoht. Tuleb lihtsalt kõvasti tööle pihta anda ja asjad ära teha, küll siis kõik laabub. Just ütlesin progeja Priidule ka, et praegu on kiire aeg ja tuleb ohtralt tunde teha! Ja üleüldse, vaata näiteks Google’it, seal tehakse palju ületunde ja vaata kui edukad nad on! Kui me sunnime programmeerijaid koosolekutel käima ja oma tegevust dokumenteerima, ei jää neil päris töö jaoks piisavalt aega.

Tänane jutt on inspireeritud Steve McConnelli samateemalisest suurepärasest artiklist, aga ülaltoodud diskussioone toimub kogu aeg – vaieldakse viimse veretilgani selle üle, kas progejad peaksid ületunde tegema või ei, kas dokumente kirjutada on vaja või ei, kas nad peaksid koosolekutel osalema või mitte jne.

Perfektse illustreeriva näite leiame aga 70 aasta vanusest minevikust. II Maailmasõja ajal ehitas alguses Jaapani ja siis USA sõjavägi mitmetele Vaikse ookeani väikestele saartele lennuvälju ja muid rajatisi. Kohalikele elanikele tõi see kaasa enneolematu buumi, kuna sõdurid tõid kaasa imelisi riideid, tööriistu, toiduaineid ja muud kraami, millest ka pärismaalased natuke osa said. Aga siis sai sõda läbi ja lennukid lendasid ära. Kohalikud ootasid ja ootasid, aga ei midagi. Lõpuks ehitasid nad puust lennurajad ja juhtimistornid ning sooritasid oma lennuväljal rituaalseid toiminguid, mida olid näinud võõramaalasi tegemas, lootuses sel viisil lennukeid tagasi meelitada, nähtus, mida nimetatakse kaubakultuseks (cargo cult).

Sarnaselt püüavad paljud ettevõtted matkida edukamate firmade tegevuse väliseid jooni, lootuses saavutada samasugust edu. Nad panevad tähele, et mõnes kohas korraldatakse palju koosolekuid ja kirjutatakse palju dokumente, ning teevad ise siis sedasama. Need koosolekud on aga igavad ning ebapraktilised ning kellelegi ei meeldi seal kohal käia, sest neil pole tegelikult selgelt defineeritud eesmärki. Heas ettevõttes on igal koosolekul konkreetne eesmärk, mis aitab kaasa tarkvara efektiivsemale valmimisele, aga seda defineerida ning ohjata on palju raskem kui lihtsalt koosolekut kokku kutsuda.

Ka tehakse Google’is või Microsoftis tõesti palju ületunde, aga seda ei tehta mitte ülemuste nõudmisel, vaid seetõttu, et sinna on kokku kutsutud inimesed, kes armastavad tarkvarategemist, ning neile seejärel  võimalikult head tingimused loodud, mille tagajärjel kulutavad töötajad vabatahtlikult tööl rohkem aega.

Teistes ettevõtetes püütakse abi leida käesoleva hooaja imerohtudest, olgu need siis seotud lahendustega (nt SOA) või metoodikatega (nt Scrum). Iga paari aasta tagant kuulutatakse välja uhke initsiatiiv, kuidas kõik hakkab nüüd teisiti olema, puhutakse pasunaid, võtmeisikud käivad konverentsidel jne. Samas on põgusagi vaatluse järel selge, et nende tegelik probleem on hoopis selles, et nad ei tunne piisavalt hästi ei seda ärivaldkonda, milles nad tegutsevad, ega tehnoloogiaid, mida nad kasutavad. Uue buzzwordi kasutuselevõtt aitab neid sama palju kui istekohtade vahetus Krõlovi valmist tuttavas loomade orkestris.

Jaana ja Joosepi vaidlus on seega sama mõttetu kui pärismaalaste vaidlus, kas puust lennurada ehitada põhjast lõunasse või idast läände. Kui me ei mõista, miks edukas ettevõttes mingid asjad juhtuvad, ei saa me välise matkimise abil ka edu saavutada. Tegelik vaidlus peaks käima mitte “protsess” vs “heroism” või “dokumentatsioon” vs “väledus” teemal, vaid kompetentsus vs ebakompetentsus teemal.

Sellegipoolest on paljudes ettevõtetes puust lennurada juba valmis ja inimesed kirjutavad nt mingeid dokumente, mida mitte keegi kunagi ei loe. Hea test on siin neilt küsida, miks nad üht või teist dokumenti kirjutavad? Tihti on vastuseks midagi ebamäärast, et “meil näevad reeglid nii ette” või “alati on nõnda tehtud” (tuletan ka meelde lugu seitsmest ahvist). Sellise vastuse puhul on praktiliselt garanteeritud, et lennuk on puust.

Originaalslaidid siin.

Räägin teile kõigepealt ühe loo.

Üks kõige ohtlikumaid olukordi inimese jaoks on lahing sõjas. Piirkond on täis suurt kuumust, ohtlikke aineid, ülehelikiirusega ringi lendavaid metallitükke jne.

Samas, kõige olulisem mõjutaja inimese elus on enesealalhoiuinstinkt. Seega, kui sõduritel on vaja näiteks üle mingi lagendiku rünnaku joosta, on see nende jaoks kõige loomuvastasem asi maailmas.

Sellegipoolest, kui antakse vastav käsk, siis sõdurid tõusevad püsti ja jooksevad üle selle lagendiku.

 Miks?

 Peamiselt sellepärast, et neisse on pikkade ja raskete õppuste kestel sisse drillitud absoluutne sõnakuulamine. Nad teavad, et käsk on vanem kui meie ja et nende enda elu pole suures plaanis oluline. USA merejalaväelastel pole lubatud kasutada sõna “mina”.

Põhiväljaõppe käigus õpivad sõdurid oma ülemust kartma rohkem kui surma. Sest ülemus on suur ja hirmus (nagu mina). Ülemus ütleb, et jookse ja sõdur jookseb. Ütleb, et lama ja sõdur lamab. Ütleb, et lenda ja sõdur vehib kõigest hingest kätega, et lendu tõusta.

Paljudele tsiviilelu organisatsioonijuhtidele meeldiks oma organisatsiooni samamoodi juhtida. Et aina käsuta ja kõik kohe teevadki nii, isegi kui see nende isiklikele huvidele või enesealalhoiule vastu käib.

Paljud proovivadki nii teha. Paraku küll mitte väga edukalt. Sõjaväes pole sõduril kusagile pääsu – kui ta jalga laseb, siis püütakse ta kinni, pannakse vangi või lastakse maha. Tsiviilelus saadetakse nõme ülemus aga varem või hiljem pikalt või siis lihtsalt ignoreeritakse teda.

See suhtumine on tegelikult väga levinud, mul on endal ka tihti kiusatus olnud karmi käsutamise abil probleeme lahendada. Ja kui ma kunagi oma vennale rääkisin, et minu  tiimi liikmete töö tulemused ei vasta alati päris sellele nagu ma soovisin, oli tema esimeseks reaktsiooniks: kas sa nende suhtes mingeid sanktsioone ei saa rakendada?

Vabandust, vennas, see asi pole paraku nii lihtne.

Hoiatava näite sellest, kuidas väline halvaga ähvardamine ei aita, leiame tegelikult meditsiinist. Südameoperatsioonil käinud inimesi hoiatatakse üldjuhul, et kui nad oma eluviise (olgu siis liigse söömise, joomise, suitsetamise vms osas) ei muuda, siis nad surevad varsti ära. Kui paljud inimesed aga tegelikult ennast parandavad? Selgub, et 2 aastat pärast operatsiooni on 90% patsientidest tagasi endiste harjumuste juures!

Siit leiate slaidid. Ja siit audiosalvestuse.
Vaata ka eelmise aasta materjale.

Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt.

Millal me loeme projekti edukalt lõpetatuks?

Aga kes loeb XKCD-d? Ma võtan teid oma kampa!

Tuletame meelde seda 24 kuu vs 6 kuu juhtumit eespool.

Mida teha, kui sulle ikkagi survet avaldatakse, et asjad peavad saama kiiremini ära tehtud?

Enne, kui me edasi läheme, arutame, miks järgnevad asjad meile üldse vajalikud on.

Kommunikatsiooniplaani mõte on selles, et keegi ei unune ära ega teki situatsiooni, kus mitme kuu ärel teatatakse, et asjad ei kõlba kusagile ja tuleb ringi teha.

Näide: kui meil on olemas nõuete kogumise abivahend, siis see ei tähenda, et meil oleks äkitselt olemas ka adekvaatsed nõuded!
Nõuete saamiseks tuleb endiselt vaeva näha!

Siit leiate slaidid. Ja siit audiosalvestuse

Vaata ka eelmise aasta materjale.

Räägin teile kõigepealt ühe loo.

Juba antiikajal tegid inimesed vaatlusi ümbritsevate protsesside kohta.

Taigent sai muuta leivaks, savi tellisteks, puid söeks, rasva seebiks.

Mõistagi tekkis neil ka küsimus, et miks ei saaks näiteks raud muutuda kullaks?

Tuhanded alkeemikud nägid selle probleemi kallal sajandite jooksul vaeva. Kuna neil aga puudus arusaam sellest, millest erinevad ained ja materjalid tegelikult koosnevad ning kuidas nende omavaheline vastasmõju tegelikult töötab, ei saanud nende lähenemine ka kuigi süsteemne ja teaduslik olla.

Nad kuumutasid ja aurutasid, filtreerisid ja kondenseerisid, segasid kokku kõikvõimalikke aineid ning kirjeldasid oma tulemusi müstilises, allegoorilises keeles, et “asjasse pühendamata” inimesed millestki aru ei saaks.

Sagedased koostisosad olid näiteks väävel ja elavhõbe, usuti, et kui neid vaid õiges vahekorras lisada, saab nende abil kõike teha.

Ja alkeemikud kallasid ühest purgist väävlit ja teisest elavhõbedat ning laususid veel nõiasõnu peale – habbada-habbada-habbada.

Inimestel on siiski süüa ka vaja ja alkeemikud pakkusid tihti oma teenuseid kuningatele ja vürstidele, et viimased nende eksperimente rahastaks.

Ahnusel on suured silmad ja seetõttu maksiski nii mõnigi võimukandja alkeemikule heldelt, vähemalt esialgu. Pikapeale sai kuninga kannatus muidugi otsa ja ta hakkas konkreetseid tulemusi nõudma.

Kui muidu enam ennast välja keerutada ei õnnestunud, läks nii mõnigi alkeemik lõpuks võltsimise teed ning seadis üles demonstratsiooni, kus kullakangid olid algul näiteks tinaga kaetud, tina sulatati pealt ära ja nähtavale tuli kuld.

Kui nad aga sellega vahele jäid, oli karistus tavaliselt karm. Tihti rakendati sama karistust, mis valeraha tegijate puhul, ehk kallati õnnetule alkeemikule sulatina kurku.

Väga, väga ebameeldiv.

Aeg läks edasi. Matemaatikal oli tegelikult juba antiikajast saadik päris korralik ja range teaduslik põhi all olnud. Renessansi ajal tegi Galilei oma katseid, talle järgnesid Torricelli, Blaise Pascal ja Robert Hooke ja füüsika sai endale samasuguse range põhja.

Lõpuks jõudsid Robert Boyle, Lavoisier, Lomonossov ja Mendelejev ka keemiale range põhja loomiseni ja alkeemikute aeg oli lõppenud.

Sarnaselt juhtuvad revolutsioonid ka teistes teadustes, nad käivad alguses läbi oma “alkeemia faasi”, kus keegi täpselt ei tea, mida ta teeb. Vähehaaval saadakse asjad korda ja meil tekivad konkreetsed seadused, reeglid ja valemid.

Infotehnoloogia vallas käib tarkvaraprojektide juhtimise praktika käib praegu täpselt nagu alkeemia. Projektijuhid teavad, et tarkvara tegemiseks on vaja raha ja programmeerijatele meeldivad kohvijoogid. Ja nii nad lisavadki projektile erinevates vahekordades raha ning kofeiini, täpselt nagu vana aja alkeemikud lisasid erinevatele ainetele väävlit ja elavhõbedat. Ja siis lähevad kliendi juurde ja teevad kliendile habbada-habbada-habbada.

Ja nagu alkeemikute puhulgi, on üsna tõenäoline, et ilma teaduslikuma lähenemiseta lasete te üsna palju projekte kas põhja või viite kuidagi katse-eksituse teel lõpule.

Kui te seda piisavalt palju teete, siis lähevad teie projektiliikmed, ülemused ja kliendid samamoodi närvi nagu keskaegsed kuningad ja nendes tekib soov teid mingil väga ebameeldival viisil hukata.

Praeguse loengusarja eesmärk on teid sellest hullust saatusest päästa, ehk et keegi ei tuleks teile sulatinaga kallale.

See, et te kõik olete tulnud kuulama loengut projektijuhtimisest, ei tähenda veel, et te saate tingimata projektijuhiks, aga suure tõenäosusega hakkate te mitmesugustes tarkvaraprojektides mingis rollis osalema. Võib-olla tellija, võib-olla täitja poolel, vahest programmeerijana, vahest analüütikuna, vahest suure ülemusena.

Sellegipoolest, kuna projektijuhid on projektides kesksel kohal, puutute te nendega kindlasti kokku ja siis on väga hea, kui teil on olemas mingid praktilised nõuded, mida neilt projektijuhtidelt soovida ja kui nad sellega hakkama ei saa, siis saate ise esile astuda ja vajalikud asjad ära teha.

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.

Projektijuhi roll on tihti arusaamatuste ja segaduse allikaks.

Juhtkonna stereotüüp: klient ja programmeerija ei tohi kokku saada, projektijuht kaitseb neid teineteise eest

Tehniku stereotüüp: projektijuht on mingi pintsaklipslane, kes tegelikult asjadest midagi ei tea ja keda asjadest eemal hoida

Olen ise kuulnud programmeerijat halvustavalt mainimas “projektijuhtide invasiooni Eesti tarkvaramaastikul”. Probleem jällegi selles, et kui näiteks programmeerija töö on ka praktikas viidud küllaltki teaduslikele alustele, siis projektijuhid on tihti endiselt alkeemikud. Tegelikult on ka projektijuhtidel olemas täiesti teaduslikud reeglid, kuidas üht projekti edukalt lõpuni viia, täpselt nagu meil on olemas reeglid selleks, kuidas võrrandisüsteemi lahendada.

Iga risk mõjutab potentsiaalselt meie lõpptähtaega.
Riskid on potentsiaalselt vahetatavad aja vastu – projektiplaani saab lisada aega riski maandamiseks.
Alternatiivina saame riskifaktori lahendada enne projekti algust

Lugege lihtsalt neid teste ja mõelge, mida teha, et teie projekt mõnesse sellisesse auku ei kukuks.
Teadmiste omandamisel 70:20:10 suhe: 70% töö käigus omandatav, 20% raamatute lugemine jm iseseisev töö, 10% formaalsed koolitused, sealhulgas praegu siin loengus istumine! Selleks, et reaalselt mõni projekt ära teha, läheb teil tarvis palju rohkem teadmisi, kui see praegune loengukursus teile anda suudab -> lugege kindlasti oluliselt juurde, kursuse kodulehel on soovitatavat lugemismaterjali.

Aga kui te kunagi peaks minuga koos mõnd projekti tegema ja seal projektijuhina tegutsema, siis ma kindlasti eeldan, et te olete Software Project Survival Guide’i või mõne muu ekvivalentse raamatu läbi lugenud, muidu ei võta ma teid tõsiselt.

Need siin on näited, mitte täielik nimistu!

Riske pole kunagi võimalik täielikult välistada, aga neid saab oluliselt maandada kasutades vastavaid “filtreid”.

Kui kliendi ärilised eesmärgid jäävad täitmata, on nad lõpuks ikka õnnetud. Isegi kui teostaja oma raha kätte saab, võib projekti lugeda ebaõnnestunuks, kui keegi seda tegelikult kasutama ei hakka.

Loe lähemalt, Practical Project Initiation, lk 42-43
Huvide näiteid: juhtkond tahab suuremat käivet, andmesisestajad tahavad vähem käsitsitööd -> vähem vigu, müügiagendid tahavad kiiremat ligipääsu andmetele
Eelkujundatud suhtumiste näiteid: Andmesisestajad kardavad, et peavad mingitele uutele koolitustele minema, süsadminid arvavad, et ainult Solaris on õige asi
Võiduläve näiteid: Juhtkond tahab, et meie veebisait pakuks rohkem võimalusi kui konkurentide oma. Andmesisestajad tahavad automaatset veaparandust, andmebaasi administraatorid tahavad 3x suuremat andmebaasimahtu
Piirangute näiteid: juhtkonna eelarve on max 4 miljonit, andmesisestajatel on vanad arvutid ja uus kood peab nendel jooksma, samuti pole neil eelarves raha koolituseks

Sponsor on see, kelle käes on rahakott. Tema maksab nii minu laste leiva kui ka peadirektori Ferrari eest.

Kiviat diagram
Tihti juhtub, et tellija või mõni suur ülemus ütleb

Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt

Millal me loeme projekti edukalt lõpetatuks

Aga kui te saate need kõik valmis, on tulemuseks kuld.

Jätkuks eelmisele artiklile rääkisin SMITis eelmise aasta lõpupoole veel IT ja kommunikatsiooni teemal, refereerin erinevaid noppeid siin.

Fiasko näide: FBI Virtual Case File System

FBI infosüsteemist on ka varem juttu olnud, kuid meenutan põhilisi fakte:

• Projekt kestis 2000-2005
• Osa kolmeosalisest (riistvara, tarkvara ja arvutivõrk) projektist Trilogy
• Trilogy planeeritud maksumus $380M, tegelikult kulus üle $600M, sellest tarkvarale $170M – kõik maksumaksja raha (võrdle Eesti eelarvetega!)
• Riistvara ja võrgu hange õnnestusid üldjoontes (kuigi teatava ülekuluga)
• Tarkvaraprojekt katkestati viie aasta möödumise järel

Miks projekt ebaõnnestus? Põhjustena on mainitud:

• Puudulik spetsifitseerimine
• Korduvad spetsifikatsioonimuudatused
• Korduvad juhtkonnavahetused
• Mikromanageerimine
• Brooks’i seadus – hilinevale projektile inimeste lisamine suurendab hilinemist
• Tarnija ei kutsunud klienti korrale
• Klient sekkus “kuidas” küsimustesse, selle asemel, et piirduda “mida-ga”

Paneme tähele, et ükski ebaõnnestumise põhjustest polnud tehnoloogiline, kõigi puhul oli tegemist kommunikatsiooniprobleemidega!

Tulemuseks oli, et 11. septembril 2001 saatsid FBI agendid kahtlusaluste fotosid ja muud materjali endiselt faksi või kirja teel kuna puudusid piisavalt turvalised, heakskiidetud ja põhisüsteemiga liidestatud e-maili saatmise võimalused. Arvestades veel asjaolu, et juba ammu enne projekti algust olid FBI süsteemid lootusetult vananenud, oleks efektiivsem IT ehk üldse rünnakuid vältida aidanud ning maailm oleks tänapäeval hoopis teistsugune.

Möödarääkimise näide: erinevad edukriteeriumid

Tänapäeval on popp rääkida, kuidas IT-ettevõtted pakuvad teenust. Aga mida see tähendab? Vaatleme üht teist teenust: reisilennundust.

Nägin kunagi lennufirmade juhtide arvamusküsitlust, kus nad leidsid, et teenusekvaliteedil pole viga midagi, tuues argumentidena:

• Inimesed saavad (üldjuhul) punktist A punkti B
• Lennukid ei kuku (tavaliselt) alla
• (Liiga palju) lende ei katkestata

Ja ongi kõik korras!?

Tegelikus elus olen mina ilmselt üks miljonitest ja miljonitest inimestest, kes lendamist vihkavad. Minu (üldse mitte ülinõudlikud) edukriteeriumid on hoopiski:

• Lend on mugav (sealhulgas ka lennueelne ja -järgne kogemus!)
• Ma ei kannata liigset kahju (lennud ei hiline, minu pagas ei lähe kaduma)
• Teenus on terviklik (praegu pean lennujaama, lennuki, pagasi, lennujaamatranspordi jne osas eri inimetega sekeldama)

Viimasele aspektile on mõned nišitegutsejad ka pihta saanud. Nt Virgin pakub täisteenust koduuksest koduukseni ja saab selle eest ka oluliselt kõrgemat hinda küsida.

Samamoodi on tarkvaraturul tellija jaoks tohutu piin tegeleda eraldi riistvara, hostingu ja tarkvara pakkujatega selle asemel, et ühest ja samast kohast täisteenust saada.

Telefonimängu näide

Kommentaarid on vist liigsed, me kõik oleme sarnases situatsioonis olnud.

Või siis mustema huumoriga näide. Aga eks sedagi ole piisavalt juhtunud, et projektist on mingid inimesed lahkunud ja seejärel “eit teadis, aga eit suri ära”.

Prioriteetide näide: erinevad soovid

See kolmnurk on ilmselt kõigile tuttav:

Teooria ütleb, et meil pole võimalik kõiki kolme tippu korraga fikseerida, kusagile peab jääma mingi vabadusaste. Tegelikkuses aga nõuab tellija, et kõik peab nui neljaks fikseeritud olema.

Ja tulemuseks on, et:

• Kui kõik on prioriteet siis tegelikult pole ükski asi prioriteet
• Antakse järele aspektis, mis on raskemini mõõdetav, ehk siis kvaliteedis.

Komplitseeriva asjaoluna on meil tihti mitmed huvigrupid, igaüks tirimas projekti erinevas suunas.

Positiivsem näide: Microsoft Office

Office’i divisjon Microsoftis kasutab ülaltoodud probleemide vältimiseks üsnagi drakoonilist prioritiseerimist:

• Tähtaeg on kuningas
• Järgmise Office’i versiooni tähtajad võivad olla 2 aastat ette fikseeritud
• Mitukümmend allüksust elab sama rütmi järgi (planeerimine, analüüs, disain, koodikirjutamine, stabiliseerimine, beeta, release)
• Kui tähtaja ja kvaliteedi kriteeriume mingis etapis ei saavutata, jäetakse vastav feature lihtsalt tootest välja

Muidugi ei pea iga tarkvara just niiviisi tegema, aga vähemalt on siin ranged reeglid, mille järgi tegutseda ja edu saavutada.

Microsofti DNAs on üldse väga tähtsal kohal idee sellest, et “teeme asjad ära”. Mul endal on mälestuseks näiteks selline jurakas:

Iga valminud ja turule läinud toote eest, mille tegemisel inimene osaleb, saab ta vastava märgi. Lihtne värk, aga märgiks sellest, kuidas igal sammul rõhutatakse tulemuseni jõudmist.

Sellekevadine Tartu Ülikooli projektijuhtimise kursuse epopöa on vähemalt minu jaoks selleks korraks otsa saanud ja kõik eksamitööd parandatud.

Kokkuvõttena torkavad üliõpilaste töödes silma mitmed ühised jooned, millest mõned, kui neid päris elus rakendada, rohkem või vähem eepiliste projektifeilidega lõppeks (neil, kes korralikult loengus käisid, läheb muidugi paremini )

Eksamil tuli kirjutada järgmist (kõik punktid olid enne teada):

• Mingi tarkvaraprojekti kirjeldus
• Projekti etapid
• Projekti tehnoloogilised osad
• Projekti kalkulatsioonid
• Meeskonnamudel
• Ja lõpuks üks suur tabel kirjeldamaks, kes, mida ja miks projekti vältel teeb.

Esimese asjana jäi paljudele segaseks, millised kulud ühe projekti või ettevõtte juhtimisega kaasnevad. See tähelepanek ei ole isegi mitte tarkvaraspetsiifiline, aga rakenduks ka suvalisele muule projektile.

Erilist äramärkimist vajab siin see, et paljud ei tea, millised on tegelikult Eesti maksud. Mitmed tulid tulu-, aga mitte sotsiaalmaksu peale, mitmed eeldasid aga lihtsalt, et projekt täpselt nii palju maksabki, kui palju raha nemad koju viivad. Oleks elu vaid nii lihtne

Loengus oli toodud arvutus, mille järgi kujuneb programmeerimistöö tunnihind järgmistest komponentidest:

• Tehniliste töötajate netopalk.
• Tulu-, töötuskindlustuse ja sotsiaalmaks - Eesti ettevõtete tegelik palgakulu oli kuni viimase ajani 1,71*netopalk, aga maksud kipuvad viimasel ajal ebastabiilsed olema.
• Kontorikulud. Siia alla kuuluvad suurima kuluna mittetehniliste töötajate (juhtkond, raamatupidamine, müügipersonal, IT tugi, ilus tüdruk ees lauas jne jne) palgakulud ja teiseks üür, elekter, riistvara amortisatsioon jne. Kontorikulud kõiguvad ettevõttest ettevõttesse muidugi suuresti, aga võiks arvestada viiekohalise summaga iga tehnilise töötaja kohta kuus.
• Puhkuste ja haigepäevade tasu, kus väärtust ei toodeta, aga palgakulu jookseb edasi.
• Tööaja sisene ebaefektiivsus. Kui mingi asi võtab 10 tundi programmeerimist, siis ei tähenda see sugugi mitte kümmet tööl istutavat tundi. 70% efektiivsus on enamasti super tulemus, enamik organisatsioone jääb oluliselt alla selle.
• Ettevõtte kasumimarginaal.

Konkreetsed arvud võib igaüks siia nüüd ise asendada ja kokku korrutada – tulemuseks on nii mõnegi inimese jaoks ehmatamapanevalt suured käärid. Nende asjaolude mittearvessevõtmine oleks päris elus nii mõnegi särasilmse firma pankrotti viinud.

Teiseks, kui midagi kirjutad, siis tunne oma lugejaskonda.

Mitte ilmaasjata ei tulnud küsimustes projekti struktuuri mitu korda kirjeldada:

• Üks neist vaadetest on kliendile (kes tahab lihtsalt lühidalt ja konkreetselt teada, mida ja mis ajaks ta saab)
• Teine on juhtivale tehnilisele personalile (kes tahab teada, milliseid metoodikaid ja tehnoloogiaid me kasutame)
• Kolmas on projekti igapäevastele osalistele (kes tahavad teada, mida mingil päeval plaanitakse teha)

Ja last but not least, tuleb arvestada õppejõuga, kes selle kõik läbi vaatab, et kas inimene on kursusest ka midagi kõrva taha pannud või imes kogu jutu lihtsalt pastakast välja

Paljudes töödes oli näha suhtumist: mina olen vinge programmeerija, progemine on ainus asi, mis loeb, tean kõike kõige paremini ja ei pea teistele midagi selgitama. Bzzzt, selline suhtumine seab inimese karjäärile üldjuhul olulise tõkke, rääkimata olukordadest, kus projekt hävib seetõttu, et kliendile jäid asjad segaseks.

Ja lõpuks: sõbrad, õppige kirjutama.

• Ärge kirjutage poole lehekülje pikkusi lõike, neid ei viitsi ükski klient lugeda.
• Vaadake, et professionaalne tekst annaks edasi võimalikult palju konkreetseid detaile.
• Kasutage teksti ilmestamiseks jooniseid või kasvõi bullet pointe, et oleks võimalik ühe pilguga haarata, millest jutt käib.

Ja korrektne on kirjutada standardne, kontseptsioon, stsenaarium ja mõttetu, vastasel korral arvab iga haritum klient, et te olete lohakad ja kirjutate koodi ka üle jala.

Kokkuvõttes oli tegemist aga vähemalt minu enda jaoks hinnalise kogemusega, loodetavasti said ka kuulajad oma filosoofilisele potentsiaalile lisa. Ülaltoodud kaebustest hoolimata olid mitmed tööd täitsa head ja nende autorid (te teate, kes te olete ) võtan ma vajadusel kindlasti oma kampa.

Selle kevade projektijuhtimise loengute viimased materjalid!

Slaidid leiate siit. Audiosalvestus (r-click->save as): 1. osa, 2. osa, 3. osa, 4.osa.

Seekordses loengus pärinevad mõned slaidid originaalis minu võimekatelt töökaaslastelt Siim Puskailt ja Andre Krullilt.

 Eelnevalt on juttu olnud mitmesugustest projektijuhtimise aspektidest – riskid, nõuded, inimesed.

Täna räägime viimasest väga olulisest aspektist – see on raha.

Ja siis võtame selle kõik kokku.

Rahal on ühiskonnal küllaltki oluline kultuuriline roll, mis kajastub ka näiteks paberrahade disainis.

Mõned rahad pole siiski selgelt kunstipäraselt kõige õnnestunumad.

Selline etteulatuv habe jäi paraku ainult Aasia moeks.

Lõpuks pani see tüüp asjad paika.

Teistes kohtades leitakse jälle, et raha peal võiks olla võimalikult hirmuäratavad inimesed.

Kui kätte saan, tapan ära!

See on juba päris jube.

Siis on olemas rahad, mis näevad välja nagu värvipimeduse testid.

Või siis palavikuhallutsinatsioonid.

Diktatuuride rahadel on tihti sarnased jooned. Suur Vend jälgib!

Lihtne inimene (nagu meie!) suundumas kusagile, püstol käes. Tõenäoliselt tapma mõnda teist lihtsat inimest nagu meie, aga kes on meie silmis tehtud vaenlaseks või vaenlase käsilaseks.

Saddamil kasvab mingi asi pea seest välja, aga keegi ei julgenud talle seda ilmselt öelda.

Mõned rahad on lihtsalt mõistetamatud. Mis see on, kas äraraiutud haarmetega kaheksajalg?

Mida kauem ma seda vaatan, seda ebamugavamalt ma ennast tunnen.

http://www.targotennisberg.com/tarkvara/2008/05/31/miks-mulle-meeldib-raha/

Iga projekt taandub lõpuks rahale!

Tihti loetakse kokku ainult arenduse aeg.

Ei tohi unustada ka teiste inimeste aega sinna juurde liita.

Igaühel oma tunnihind!

Kes on seda reklaami näinud?

http://www.youtube.com/watch?v=at_f98qOGY0

http://www.youtube.com/watch?v=WOsylvrwo3I

http://www.youtube.com/watch?v=jAasManZ6IA

Minu enda ajahaldus