+372 56 21 1146 info@agilecoach.ee

Merle Randlepp

Agile Coach

Merle Randlepp

Agile Coach

Tarkvaraprojekti riskid. Riskiplaani näidis.

sept. 17, 2020 | Tarkvaraarendus

2,929 Views
Rodeo

Dialoog elust enesest, ühe tarkvara auditi läbiviimise käigus.
Mina: “Hästi, vaatame nüüd üle projekti riskid hetkeseisuga.”
Nooremapoolne projektijuht: “Tead, ega mind need riskid tegelikult üldse ei huvita, ma tahaks ainult asja ägedalt valmis teha.”

Ütlen ausalt, et ohkasin mõttes ikka sügavalt. Projektijuht, kes ei saa aru riskide teadvustamise ja jälgimise tähtsusest, lihtsalt ei ole veel Projektijuht. Võib panna kogu oma noorusliku poweri ja entusiasmi projekti vedamisse – kaasata, suhelda, läbi rääkida, koordineerida jne, aga pahatihti ei lähe projekt ikkagi ägedalt. Kui sa riskide realiseerumiseks valmistunud ei ole, tabavad nad sind alati ootamatult ja löövad jalad alt kogu su tiimil.

Allolev jutt on päris pikk, sest tahtsin olla põhjalik. Olen nooremana läbi käinud samasuguse faasi nagu ülaltoodud projektijuht ja täna ma tean, et just professionaalne riskihaldus on see, mis on vähegi suurema projekti eduks hädavajalik.

Riske ei ole võimalik kunagi täielikult vältida, aga neid saab suures mahus varakult maandada. Kindlasti peab riske hindama regulaarselt kogu projekti jooksul ja nii kui mõni neist pead tõstab, tuleb kiirelt tegutseda ja see pea maha raiuda.

Tegelikult ei ole risk midagi hirmsat ja seda ei pea kartma. Kogenud tiimis ei realiseeru paljud riskid üldse. Samas ei ole ma näinud seni ühtegi projekti, kus ainsatki riski poleks realiseerunud.

Riskide teadvustamine ja õigete meetmete kasutamine on juba pool võitu.

Ootamatu rong

Levinumad tarkvaraprojekti riskid

Iga projekti riskid, esinemise tõenäosused ja mõjud on erinevad, aga esineb ka palju sarnasusi. Siin on ülevaade tarkvaraprojektide enim levinud riskidest, mille hulgast saad enda projekti jaoks valiku teha ja oma projekti spetsiifilisi riske juurde lisada.

Planeerimine ja juhtimine

  • Nõrk kommunikatsioon ja projektistaatuse ebapiisav läbipaistvus
  • Ebareaalne ajakava
  • Tellija projektijuhi (PO) liiga väike ajaressurss
  • Tellija projektijuht lahkub töölt
  • Täitja meeskonna liige lahkub töölt
  • Puhkuseplaanid on kooskõlastamata
  • Täitja meeskonna liige haigestub
  • Tellijapoolsete osaliste hulk on suur

Nõuded ja skoop

  • Täitja jaoks on nõuded ebaselged või ta ei ole neist õigesti aru saanud
  • Erinevad ootused projekti skoobi ja tulemite suhtes
  • Tööde üleandmine kuhjub projekti lõppu
  • Arenduste maht on oodatust suurem
  • Nõuded muutuvad tihti, muudatuste juhtimine on nõrk
  • Tellijapoolne vahetulemuste kinnitamine hilineb

Kompetents

  • Täitja meeskonnas puudub vajalik kompetents
  • Tellija projektijuhil puudub vajalik kompetents

Liidestused

  • Liidestuse nõuded on ebaselged ja suhtlus kolmandate osapooltega aeglane
  • (Siin all saab olla rohkelt eri riske, sõltub kui palju keerukust ja liidestusi arenduses on)

Enamasti realiseeruvad riskid nõrga planeerimise ja projektijuhtimise tulemusel, seetõttu on arendusmetoodika ja tööprotsessi kvaliteet tarkvara projektis tähtsusega number üks.

dilberti koomiks

Alusta riskide kirja panemisest

Riskiplaan tuleb koostada täitja projektijuhi poolt kohe projekti alguses. Jah, see tuleb teha kirjalikult. Ei, sellest ei piisa absoluutselt kui sa ainult oma peas riskidele mõtled. Esimese riskiplaani võid koostada üksi, järgmise sammuna saad selle tiimiga läbi arutada – milliseid riske nemad näevad ja kuidas neid hindavad?

Kui tegu on riigihankega ja pakkumises küsiti riskiplaani, siis on sul mingi põhi juba olemas. Aga pakkumises sisaldunud plaan on ainult oletus, tegelikult sa ei tea millised on tõenäolised riskid enne kui oled kohtunud kõigi osapooltega. Lisa projekti avakoosoleku agendasse riskiplaani arutelu  ja varu selle läbivaatamiseks ja hindamiseks piisavalt aega. 

Blogiposti lõpus on allalaetav näidis riskiplaanist, sellega koos on vahest kasulik koostada ka riskimaatriks, mis annab sulle visuaalse ülevaate. Näiteks võib riskimaatriks näha välja selline:

Planeeri, hinda ja tegutse!

Täitja projektijuhi kohustus on koordineerida riskide hindamist ja maandamise tegevusi alates projekti esimesest päevast. Juhul kui tegevused on tehtud ja need ei andnud soovitud tulemusi, tuleb proovida teisi tegevusi. Kaasa alati ka oma tiimi liikmed, et saada kõigilt ettepanekuid ja ideid. Kui ka need tegevused ei toimi ja risk läheb järjest punasemaks, tuleb risk eskaleerida juhtgrupi või juhtkonna tasemele. On ääretult tähtis, et ei jäädaks probleemse olukorra otsa lihtsalt istuma või nö kummi venitama. Kui probleemi lahendada ei õnnestu, siis eskaleeri ja lahenda see kõrgemal tasemel. Kiiresti.

Hinda riske perioodiliselt iga 2 nädala tagant, see on paras aeg, et jõuaksid riskide esile tõusmisel neile õigeaegselt reageerida. Mõni risk ilmutab end äkitselt, aga tihemini esineb nö hiilivat punasesse minemist ja sa märkad ning tegutsed liiga hilja. Selle vältimiseks lisa riskide hindamise slaid igasse juhtgrupi või projektikoosoleku agendasse. Nii on sul riskid silme ees, teadvustatud ja on kerge hetkeseisu üle hinnata.

Riskide slaid võib välja näha näiteks selline:

Isegi pärast põhjaliku riskiplaani koostamist ja jälgimist võib juhtuda, et pauk tuleb nö luuavarrest ja keegi ei näinud seda ette. Seda juhtub, aga suhteliselt harva. Sellisel juhul tuleb tegutseda veel kiiremini 🙂

Lõpetuseks: Kaardista oma riskid, hinda nad regulaarselt üle ja ole valvel! Kui risk hakkab ilmnema, tegutse kohe!

Riskiplaani näidis

Riskiplaani dokumendis on järgmised lehed:

  • Riskiplaan – tuleb koostada kohe projekti alguses
  • Riskimaatriks – aitab riskiplaani visualiseerida ja paremat ülevaadet saada
  • Esiletõstetud riskid /kuupäev/ – hetkeseisuga kõige tõenäolisemad riskid, vastutajad ja tegevused, kasuta regulaarseks jälgimiseks

Head kasutamist!

Käesolev dokument on loodud näidisena ja on koostatud minu isikliku kogemuse põhjal. Kasuta seda dokumenti ainult abimaterjalina ja koosta lõpptulemus oma organisatsiooni vajadustest lähtuvalt.
Subscribe
Notify of
guest
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments

Samal teemal

Mis on RICE mudel tootearenduses?

Mis on RICE mudel tootearenduses?

Tootearenduses ei ole meil kunagi piisavalt aega ega raha, et kõiki soove ellu viia. Tooteomanikud kaaluvad pidevalt, milliseid arendusi teha ja millised tegemata jätta ning õigeid otsuseid ei ole sugugi lihtne teha. RICE mudel aitab meil tööde prioriseerimisel kiiremini õigemaid otsuseid teha.

82 Views

Tooteomaniku 8 suurimat viga

Tooteomaniku 8 suurimat viga

Tooteomaniku roll on kõige tähtsam roll tarkvaraarenduse meeskonnas. See roll ei ole kaugeltki lihtne, vastutusvaldkond on suur ja kirju, töökoormus tavaliselt samuti ja nii võibki juhtuda, et kuskilt hakkavad “õmblused kärisema”. Olen kokku pannud kaheksa enim levinud tooteomaniku viga, mis on tootearenduses kõige suurema mõjuga.

1,999 Views

Agiilne mõtteviis ja müüdid selle ümber

Agiilne mõtteviis ja müüdid selle ümber

Mõistet “agiilne” on ilmselt paljud inimesed kuulnud erinevates kontekstides – nii koerte treeningutest rääkides, IT ja tarkvaraarenduse juttudes, organisatsiooni juhtimise teemades, ja mujal. Kirjutan lahti 9 müüti, mis mõiste “agiilne” ümber ringlevad ja mida olen oma töö käigus tihti kohanud.

2,654 Views

Merle profiilipilt väike

Iga uus kontakt on võimalus uueks ja põnevaks koostööks - kirjuta või helista mulle ja arutame kuidas saaksin Sind aidata. 

Esimene konsultatsioon ja pakkumise tegemine on alati tasuta. 

Ole kursis agiilse maailmaga - liitu uudiskirjaga

Ole kursis agiilse maailmaga - liitu uudiskirjaga

Teavitan Sind värsketest blogipostitustest, uuringutest ja trendidest agiilse tarkvaraarenduse teemadel.

Aitäh, et liitusid!