Archive for January, 2013

Jan 22 2013

Kuidas tellida tarkvaraprojekti

Published by Targo under Projektijuhtimine, Raha

Eelmise aasta lõpupoole korraldas Äripäev seminari Kuidas korraldada edukaid tarkvarahankeid, kuulajaskonnaks mitmesugused avaliku ja erasektori esindajad, kellel aeg-ajalt vaja tarkvara tellida. Tegin ise ettekande agiilse arenduse teemal, refereerin nüüd ka siin. Osaliselt on kasutatud kaastöötajate Tiit Anmanni ja Aet Rahe koostatud materjale.

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.

  1. Mis on Päikese pinna temperatuur?
  2. Mis on Šanghai laiuskraad?
  3. Mis on Aasia pindala?
  4. Mis aastal sündis Aleksander Suur?
  5. Kui palju on ringluses eurosid (sularaha)?
  6. Mis on Peipsi järve ruumala?
  7. Kui palju teenis film Titanic kinodes?
  8. Mis on Vaikse Ookeani rannajoone pikkus?
  9. Kui palju raamatuid on USA ajaloo jooksul välja antud?
  10. Kui palju kaalub raskeim sinivaal?

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.

  • Lepinguks on Tellija tüüpleping, mis ei kuulu arutluse alla!
  • Tellijal on õigused, Täitjal kohustused.
  • Tähtajad on kivisse raiutud ning nende ületamisega kaasnevad märkimisväärsed sanktsioonid Täitja suunas.

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

Esialgse ettekande väline kommentaar: enne seda seminari olin vahel imestanud, kust sellised hanked ometi tulevad? Üritusel hakkasin asjale pihta saama – paljudes asutustes on tööl spetsiaalne hankespetsialist, kes hangibki ühel nädalal ekskavaatoreid, teisel tarkvara, kolmandal põrandakütet jne. Selline spetsialist tunneb hästi riigihangete seadust ja oskab nt õiges vormis maksuvõlgnevuste puudumise tõendeid küsida, kuid asjade reaalsest sisust ta enamasti ei tea ja projekti elluviimisega kokku ei puutu. Siit tuleb ka hangete hinnapõhisus – hindu on palju lihtsam võrrelda kui pakkujate sisulist võimekust.
Minu jaoks kõige nutusem asjaolu oli aga mõnede kohalviibinute suhtumine – et mis sellest siis on, kui hange on ähmaselt sõnastatud? Las pakkujad lähevad riigihangete vaidlustuskomisjoni ja räägivad seal, kui mingi probleem on! Avaliku sektori töötaja käest sellist repliiki kuulda oli kahekordselt valus – esiteks on kahju oma maksuraha pärast, millega kõigi osalevate ametnike vaidlemiseks kuluv aeg kinni makstakse, teiseks aga on kummastav see mõistmatus. Erafirmale läheb riigihanke vaidlustamine juba õigusabikuludena maksma tuhandeid eurosid, rääkimata spetsialistide ajast, kes selle asemel millegi kasulikuga võiksid tegeleda. Nii tõstab see teenuse turuhinda ja lõppkokkuvõttes jällegi maksumaksja kulusid.
Mõistagi püüab ka täitja oma juriidilist tagumikku kaitsta. Tavaliselt koostatakse selleks mitmesuguseid lepingulisasid, kus on kirjas ka tellija kohustused, näiteks kohustus ise täpseteks tähtaegadeks teatud sisendid anda jne. Ehk toimub võidurelvastumine, mille käigus kumbki pool katsub endale võimalikult palju laskemoona varuda.

Aga egas midagi, hakkame tööga pihta!

Projekti käigus selgub, et:
  • 10 lk-ses dokumendis kirja pandu oli enam-vähem korrektne.
  • Küll aga on palju detaile, millele keegi hanget ega pakkumust kokku pannes ei tulnud.
  • Pole hullu! Hind on ju lukus ja õnneks mahub lause „Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.“ taha palju, isegi väga palju!

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:

K: “Mitut sürrealisti on vaja, et lambipirni vahetada?”
V: “Kaelkirjak.”

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:

  1. Tellija saab selle, mida ta tegelikult tahab – pool tööst ei lähe enam raisku!
  2. Arendus on efektiivsem – pidevatele plaanimuutustele läheb vähem auru -> suurem kasu nii tellijale kui täitjale
  3. Ebaõnnestumisel pole vaja kogu projektist loobuda – suur eelis klassikalise waterfalli ees!
  4. Dramaatiliselt kõrgem kvaliteet – enam pole vaja nui neljaks konkreetseks tähtajaks midagi tarnida.
  5. Ning last but not least, vähem inimestevahelisi konflikte – projektijuhid ei pea enam pärast projekti lõppu otsejoones Anonüümsetesse Alkohoolikutesse suunduma.

12 responses so far