Enne iga arendusprojekti algust lepitakse kliendi ja arenduspartneri vahel kokku projekti skoop: mida täpselt arendama hakatakse, kui suur ja mitmete kasutusvõimalustega see olema saab ning mis hetkel saab öelda, et projekt on nüüd valmis. Selle pealt valmib ka hinnapakkumine (töötundide hulk ja tunnihind) ning kui kõik sobib, saab koostöö alata.
Kui kõik kulgeb plaanipäraselt, siis valmibki täpselt selline lahendus nagu kokku lepitud pea täpselt nende töötundide jooksul, mis algselt kokku lepitud. Küll aga võib projekti eelarve hakata eest jooksma, kui projekti käigus muutub märgatavalt loodava lahenduse skoop.
Mida skoobi muutumine tähendab?
On selge, et projekti käigus tuleb ette muutuseid ning mõistlikul määral on nendega ka juba hinnapakkumises arvestatud. Arendusprotsessi käigus leitakse alati midagi, mida võiks teha teisiti, paremini või millegi muu arvelt veidi uhkemalt. Murekohad tekivad siis, kui soovitud muutused enam algselt kokku lepitud skoobi sisse ei mahu.
Kõige sagedasem näide skoobi suurenemisest ehk scope creepist on uute funktsionaalsuste lisamine, mida algselt laual ei olnud. Kui vaadata asja lihtsustatult, siis näiteks luues ilmaäppi, mis pidi algselt näitama vaid temperatuuri ja vihmasaju tõenäosust, soovitakse arendusprotsessi keskel lisada ka võimalus äpi abil lumisest ilmast pilte jäädvustada ning neid sotsiaalmeedias jagada.
Kuigi muutus võib pealtnäha tunduda väike, siis reaalsuses võib see nõutavate töötundide hulka märkimisväärselt tõsta, kuna lisaks uue funktsionaalsuse enda loomisele tuleb üle vaadata ka juba kõik varem loodu ning muuta neid komponente selliselt, et need arvestaks ka uut funktsionaalsust.
Scope creep või projekti kimbutada ka mitmes teises vaates. Näiteks võis algselt olla juttu vaid Androidi äpi loomisest, kuid ühel hetkel otsustakse, et tarvis oleks ka iOSi äppi. Niisamuti võib tulla ette juhtumeid, kus mõne projekti kallal on juba tükk aega töötatud, kuid projekti keskel liitub ettevõtte juhtkonnaga uus liige, kes soovib, et loodav lahenduse kasutajaliides näeks välja hoopis teistsugune.
Erinevaid viise, kuidas projekti skoop plahvatuslikult kasvada võib, on kümneid, seega on sellele oluline mõelda juba enne projektiga alustamist.
Mis scope creepi põhjustab?
Scope creepi võivad tekitada mitmed majasisesed ning -välised faktorid, kuid enimlevinud põhjusteks on:
Vähene kaardistamine. Enne iga arendusprojektiga alustamist tuleks võrdlemisi täpselt kaardistada, millised on erinevate osapoolte ootused loodud lahendusele. See väldib olukordi, kus arendusega on pihta hakatud, kuid juhtkonnas või tiimis on inimesed, kes ootavad loodavalt lahenduselt midagi sootuks teistsugust, kui arenduspartneriga kokku lepitu.
Muudatused meeskonnas. On mõistetav, et kui projekti eest vastutava meeskonnaga liituvad uued inimesed, siis jõuavad tiimi ka värsked ideed. Need ideed ei pruugi aga alati mahtuda algselt kokku lepitud projekti skoobi sisse, seega tasuks nende rakendamisel kaaluda, kas nende skoopi lisamine on õigustatud.
Olukorra muutumine. Ei ole harv, et majasisesed- või välised tegurid tingivad muutuseid selles, mida tarkvaralahenduselt oodatakse ning millist funktsionaalsust see peab pakkuma. Sellistes olukordades on ka skoobi muutmine ning laiendamine igati õigustatud, kuid seejuures tuleb meeles pidada, et see võib muuta ka projekti eelarvet.
Kuidas skoopi kontrolli all hoida?
Teatud määral on projekti käigus skoobi laienemine eeldatav ning sellega tasuks ka arvestada. Kuid selleks, et see ei laieneks plahvatuslikult, tasuks tähelepanu pöörata:
Korralikule eeltööle. Mida põhjalikumalt on loodavast lahendusest eeldatud funktsionaalsust kaardistatud, turuolukorda uuritud, majasiseste stakeholderite ootused õigele tasemele juhitud ning täpsete vajaduste olemus läbi töötatud, seda suurem on tõenäosus, et projekti skoop ei lähe projekti käigus “jooksu”.
Otsustusvõimelisele ja iseseisvale projektimeeskonnale. Mida rohkem inimesi on projekti jooksva kulgemisega seotud, seda suurem on tõenäosus, et skoop hakkab arendusprotsessi käigus muutuma. Kui korralik eeltöö on tehtud ning kõik vajadused kaardistatud, siis tasuks jooksvalt projektiga tegelev toimkond hoida nii väiksena kui võimalik. See toimkond peaks olema õigusega langetada otsuseid ning esindata tervet ettevõtet või lahendust kasutama hakkavat segmenti.
Arendusetappidele. Kui ühel hetkel hakkab tunduma, et juba kokkulepitule oleks vaja külge pookida veel mitmeid funktsioone, erilahendusi ja muid kellasid-vilesid, siis tasuks kaaluda, kas arendusprojekt tuleks jagada etappideks: esimestes etappides tehakse valmis kõik, mis algselt kokku lepitud ning samal ajal lepitakse kokku juba järgmise etapi eesmärgid ja skoop – seeläbi on võimalik märksa efektiivsemalt kontrollida projekti ajaraamistikku, eelarvet ja funktsionaalsust.
Samuti ei tasu karta küsida arenduspartneri poolselt projektijuhilt/analüütikult, kas mõni soovitav täiendus mahub juba kokkulepitud skoobi sisse, või peaks see kokkulepitule lisanduma. Selle pealt saab projektitoimkond otsustada, kas ideega edasi minna või jätta see tulevikku ootama.
Agiilne arendus aitab skoopi paigas hoida
Suureks abiks scope creepi vältimisel on ka agiilsete arendusmetodoloogiate viljelemine. Kui klassikalises arendusprotsessis võetakse terve projekt tervikuna ette, hakatakse seda ühest otsast arendama ning seejärel jõutakse lõpuks valmistooteni, siis agiilse arenduse puhul lüüakse arendusprojekt paljudeks väikesteks kildudeks, mis aitab projekti skoobi hästi kontrolli all hoida.
Kui võtta näiteks tellimushaldussüsteem, siis lüüakse agiilse arenduse puhul arendusprotsess mitmeks erinevaks etapiks ning igat süsteemi käsitletakse kui omaette väikest toodet: tellimuste sisestamise komponent, tellimuse verifitseerimise komponent, maksekomponent, ja nii edasi.
Sellise lähenemise abil on igal osapoolel projekti käigust alati selge pilt ees, kulud ning ajagraafiku saab hõlpsasti kontrolli all hoida ning ei pea kartma, et “mustas kastis” arendatakse midagi sellist, mis skoopi märgatavalt paisutama hakkab.
