Rizikos analizė: projekto vadovo reikalaujamas stropumas

 Rizikos analizė: Projekto vadovo reikalaujamas stropumas. vertė Eduardas Česnavičius 1999.05.15 Šioje knygoje Robert Charette riziką apibrėžia taip: Pirmiausia rizika susijusi su būsimais įvykiais. Šia diena ir vakar yra labai domimasi, nes jau dabar mes susilaukiam savo praeities darbo vaisių. Klausimas yra toks, ar mes galime, keisdami savo šiandienos veiksmus, sukurti kitokią ir tikėkimes geresnę mūsų pačių padėtį rytoj. Antra, tai reiškia, kad rizika sukelia pasikeitimus, tokius kaip mūsų minčių, nuomonės, veiksmų pokyčius. Trečia, rizika reikalauja daryti (sukelia) pasirinkimus ir mes nesame tikri prie ko šis pasirinkimas privęs (kokių islaidų pareikalaus). Tokiu būdu, parodoksalu, bet rizika kaip mirtis ir mokesčiai, yra dar vienas gyvenimo faktas. Kai rizika yra naigrinėjama programų inžinierijos kontekste, Charette'o trys konceptualus pagrindai visad yra kaip įrodymas. Ateitis yra mūsų interesas - kokia rizika gali priversti mūsų projektą pakrypti bloga linkme. Mūsų interesų pasikeitimai - kaip jie pakeis mūsų klientų reikalavimus, technologijos vystimasį, pagrindinius kompiuterius ir visa tai kas susije su projektu, kokia įtaką tai padarys projekto grafikui ir bendram jo pasisekimui. Galiausiai mes turime susidurti su pasirinkimais - kokius metodus ir įrankius reiketų naudoti, kiek žmonių turi būt įtraukta, kiek dėmesio reikia skirti kokybei. Peter Drucker kartą pasakė, "Rizikos eliminavimas yra bergždžios pastangos, reiketų stengtis ją minimizuoti, svarbiausia yra tai, kad ta rizika, kurios imamės būtų teisinga rizika." Prieš nusprendžiant, kuri iš rizikų yra teisinga, reikia nustatyti visas galimas rizikas tiek vadovams tiek ir praktikuojantiems. Su kokiais rizikos tipais susiduriama projekte? Ar yra budas juos kategorizuoti? Įmanoma kategorizuoti riziką įvairiais būdais. Makroskopiniame lygyje gali buti apibrėžtos, projekto rizika, technine rizika ir biznio rizika. Projekto riziką nusako potencialus biudžetas, suplanavimas, personalas, resursai, kientas, reikalavimų problemos ir jų įtaka projektui. Techninė rizika nusako plano, įgyvendinimo, sąveikos, patikrinimo ir palaikymo problemas. Be to, specifikacija, dviprasmiškumas, techninis netikrumas, techninis senejimas, ir "leading edge" (pirmaujanti) technologija irgi yra rizikos faktoriai. Technine rizika įvyksta kai problemą daug sunkiau išspresti nei mes manėme. Biznio rizika yra klastinga nes gali išgadinti net geriausio projekto rezultatus. Biznio rizikos kandidatai top'o penketuka yra šie: 1) daryti labai gerą produktą, kurio niekam nereikia (rinkos rizika) 2) daryti produktą, kuris jau neatitinka bendrą kompanijos strategiją 3) daryti produką, kurį prekiautojai nežino kaip parduoti 4) prarasti vyresniojo vadovo pagalbą, dėl dėmesio centro ar žmonių pasikeitimo 5) prarasti biudžetą ar personalo įsiparegojimą. Labai svarbu pastebėti, kad paprastas kategorizavimas ne visad veikia. Tam tikra rizika kartais nenuspejama. Kitas rizikos kategorizavimas buvo pasiūlytas Charette. Žinoma rizika yra ta, kurią galima atskleisti po atidaus projekto plano, biznio ir technines aplinkos, kurioje projektas buvo vystomas, ir kitų patikimų šaltinių (nereali pristatymo data, reikalavimus aprašančių dokumentų trukumas) įvertinimo. Nuspejama rizika yra extrapoliuojama is praeities projektų patirties (pvz. medžiagos apyvarta, prastas bendravimas su užsakovu, personalo pastangu trukumas). Nenuspėjama rizika yra joker'is kortų kaladėje. Ji gali atsitikti ir atsitinka, bet ją labai sudetinga ateityje identiofikuoti. Ar yra sistemingas būdas projekto rizikai nustatyti? Rizikos identifikavimas yra sistemingas ketinimas specifikuoti projekto plano (įvertinimas, tvarkaraštis, “resource loading”) grėsmes. Įdentifikuodamas žinomą ir nuspėjamą riziką, projekto vadovas daro pirmus žingsnius tam, kad išvengti jos kai įmanoma ir kontroliuoti kai galima. Kiekviena aukšciau pamineta rizikos kategorija turi du skirtingus tipus: bendra ir projektui specifinė rizika. Bendra rizika yra potenciali grėsmė kiekvienam projektui. Vėliau paminėsiu keleta kontrolinių sąrašų (checklist). Projektui specifinę riziką gali identifikuoti tik tie žmonės, kurie gerai supranta technologiją, ir esant specifinei aplinkai. Tam, kad nustatyti projektui specifinę riziką, jums reikia ištirti projekto planą ir “software statemenrt of scope” ir paklausti saves "Kokios specifinės projekto savybės gali sukelti grėsmę projeklto planui?". Mes turime sugaišti daug laiko, kad sistemingai nustatytume riziką. Jei jus planuojate projektą manydami, kad viskas bus gerai, tai jums bus daug sunkiau adaptuotis kai rizika iškils. Kontrolinis sąrašas. Kokias temas jis apima? Riziką galima klasifikuoti įvairiai, bet pagrinde visa tai susiveda į šias kategorijas: • Produkto dydis: Rizika susijusiu su bendru programos dydžiu. • Biznio įtaka: Rizika susijusiu su prievarta sukelta management'o (vadovavymo) ar rinkos. • Užsakovo savybės: Rizika susijusi su užsakovų sumoderninimų ir gamyntojų galimybe bendrauti su užsakovais tinkamu būdu. • Processo aiškumas: Rizika susijusiu su tuo, iki kokio lygio programų sistemų inžinierijos processas turi būti apibrėžtas ir ant kiek jo laikysis organizacijos gaminančios programinę įrangą. • Vystymosi aplinka: Rizika susijusi su įrankiais ir priemonėmis, kurios bus naudojamos darant produktą. • Technologija, kuri bus kuriama: Rizika susijusiu su kuriamos sistemos sudėtingumu ir technologijos "naujumu", ateinančiu su sistema. • Personalo dydis ir patirtis: rizika susijusiu su bendra inžinieriu technine bei projektų darymo patirtimi. Rizikos kontrolinis sąrašas gali būti sudarytas įvairiai. Atsakydami į klausimus susijusius su kiekviena kategorija, jus galite įvertinti rizikos įtaka jūsų projektui. Detaliau aptarsime kiekvieną iš punktu. Kokia yra rizika susijusiu su produkto dyždiu? Kai kurie patyre vadovai pasakė, kad projekto rizika yra tiesiogiai proporcinga produkto dydžiui. Šis sąrašas padės jums identiofikuoti įprastą (generic) riziką susijusia su produkto dyžiu: • Apytikris produkto dydis matuojant ESK (eilučiu skaičius kode) arba “FP”? • Apytikris produkto dydis skaičiuojant programas, failus ir tranzakcijas. • Procentinis produkto dydžio nuokrypis nuo vidutinio dydžio, kuris skaičiuojamas pagal ankščiau darytus produktus. • Duomanų bazės dydis sukurtas produkto. • Produkto vartotojų skaičius. • Pakeitimų skaičius produkto reikalavime. • Pakeitimų skaičius prieð ir po pristatymo. • Pakartotinio naudojimo programų kiekis. Kiekvienu atveju informacija apie produktą turi būti suliginta su praities produktų informacija. Jei nuokrypis procentiðkai didelis arba skaičiai vienodi, bet rezultatas praeityje nebuvo patenkinamas, tai rizika didelė. Kokia yra rizika susijusiu su biznio įtaka? Kartais biznio dėsniai konfliktuoja su technine tikrove. Šie punktai padės išsiaiðkinti kokia rizika yra susijusi su biznmio įtaką: • Produkto įtaka kompanijos pajamoms. • Produkto aiðkumas vyresniajam vadovui. • Neprotingas produkto pristadymo (užbaigimo) laikas. • Vartotojų kiekis, kurie pastoviai naudos šį produktą. • Kitų produktų kiekis su kuriuo mūsų produktas dirbs kartu. • Vartotojo sumoderninimas. • Produkto dokumentacijos kiekis ir kokybė, kuri turi but pateikta užsakovui. • Įstatyminiai aprybojimai konstruojant produkatą. • Kaina susijusi su pavėlavusiu produkto pristatymu. • Kaina susijusi su netobulu (blogai pagamintu) produktu. Velgi, visus atsakymus reikia sulyginti su praity gamintais produktais. Jei nuokrypis procentiškai didelis arba skaičiai vienodi, bet rezultatas praityje nebuvo patenkinamas, tai rizika didele. Kokia yra rizika susijusi su užsakovo savybės? Visi užsakovai nėra vienodi. Pressman'as ir Herron'as aptarę šį išsireiškimą kostatavo: • Užsakovai turi skirtingus poreikius. Kai kurie žino ko jiems reikia, kai kurie žino ko jiems nereikia. Kai kurie nori žinoti visas detales, kiti yra patenkinti miglotias pažadais. • Užsakovai yra įvairios asmenybės. Kai kurie džiaugiasi budami užsakovais - įtampa, derybos, filologinis atpildas už gerą produktą. Kiti visai nenori buti užsakovais. Kai kurie bus patenkinti bet kuo, kas bus pateikta, net ir blogu (menku) produktu, kiti aštriai paaiškins, kai produkto kokybė bus per maža. Kai kas parodis savo pagarba už gera produkto kokybę, kiti skųsis bet kuo, koks produktas bebūtų. • Užsakovai turi įvairias asocoacijas jų tiekėjams. Kai kurie žino produktą ir jų gamintojus gerai. Kiti yra beveidžiai, bendrauja su gamintojais siusdami laiškus ir trumpais skambučiais telefonu. • Užsakovai dažnai yra prieštaraujantys. Jie visko nori jau vakar ir už dyką. Dažnai gamintojas pats susipainioja dėl užsakovų prieštaravimų. "Blogas" užsakovas turi gilią įtaką produktui, t.y. jo pagaminimo terminui ir biudžetui. Blogas užsakovas sukelia didelę grėsmę projekto planui ir realią riziką projekto vadovui. Šie punktai padės jums išsiaiskinti kokia gali buti rizika susijusi su skirtingais užsakovais: • Ar dirbote su užsakovu preityje? • Ar užsakovas tvirtai žino ko reikalauti? Ar sugaišo bent kiek laiko, kad tuos reikalavimus surašyti? • Ar sutinka užsakovas susitikti su vykdytoju, kad išsiaiskinti projekto užmojį. • Ar užsakovas nori užmegzti gerus ryšius su vykdytoju? • Ar užsakovas nori dalyvauti produkto peržiūrose? • Ar užsakovas pakankamai patyręs iš techninės pusės gaminamo produkto srytyje? • Ar leis užsakovas daryti jūsų žmonėms savo darbą, t.y. ar nekyš nosies kur nereikia kai bus dartomas detalus techninis sprendimas? (žodžiu ar nesipainio po kojom) • Ar užsakovas supranta kas yra programų sistemų inžinierijos processas? Jei bent vienas atsakymas "Ne", tai tolimesnis darbas turi būti nukreiptas į rizikos vertinimą. Kokia yra rizika susijusi su processo aiškumu ir aplinka, kurioje produktas bus daromas? Jei programų sistemos procesas yra blogai apibrėžtas; jei analizė, dizainas ir testavimas yra tvarkomas padrikai (nesistemingai) arba jei su kokybės koncepcija visi sutinka, bet nieks nesielgia taip, kad tai pasiekt, tada jūsų projektas yra rizikingas. Atsakykiter į šiuos klausimus • Ar jūsų vyresnysis vadovas laikosi rašytinės strategijos formuluotės, kuri nusako programos gamybos procesą? • Ar jūsų organizacija vystė arba ar buvo įvykusi serija tobulinimosi kursų vadovams ir techniniam personalui? • Ar yra išpublikuoti standartai, skirti kiekvienam programų kūrėjui ir programų vykdytojui? • Ar dokumentacija žemiau pamynėtų objektų turi savo formatą? a. projekto planas b. reikalavimų specifikacija c. projekto dokumentas d. pradinis kodas e. testavimo planas ir procedūros f. programos problemų ataskaitos g. programos keitimo/patobulinimo užklausos • Ar reikalavimų specifikacijos, dizaino ir kodo valdymo taisiklingumas turi formalią techninę priežiūrą? • Ar reguliariai atliekamos formalios testavimo procedūrų ir priemonių peržiūros. • Ar formaliai kiekvienos techninės peržiūros rezultatai yra dokumentuojami, įskaitant rastus defektus ir panaudotus resursus? • Ar yra mechanizmas užtikrinantis, kad projekto vykdymas atitinka programų inžinierijos standartus? • Ar konfiguracijos valdymas yra naudojamas palaikyti darną, tarp systemos/programos reikalavimų, dizaino, kodo ir testavimo priemonių? • Ar yra mechanizmas kontroliuojantis tuos užsakovo reikalavimų pakeitimus, kurie turi įtakos programai. • Ar yra dokumentuotas(-a) darbo tvirtinimas, programos reikalavimų specifikacija, programos vystymo planas kiekvienai subrangos sutarčiai? • Ar yra procedūra sekanti ir prižiūrinti subrangos sutarčių eigą. • Ar palengvinančių vartojimą specifikacijų technika naudojama tam, kad pagerinti bendravimą tarp užsakovo ir vykdytojo? • Ar naudojami specifinia metodai programos analyzei? • Ar naudojate specifinius metodus duomenų ir architektūros dizainui? • Ar 90% jūsų kodo parašyta auškto lygio kalba? • Ar kodo dokumentacija rašoma naudojantis specifiniu susitarimu, t.y. ar yra kažkuo ypatingas ir ar to laikomasi? • Ar naudojate specifinius metodus testavymo primonėms gaminti? • Ar naudojamos konfiguracijos valdymo priemonės kontroliouoti ir sekti pasikeitimus visame programinės įrangos gamybos procese? • Ar naudojamos CASE priemonės kūriant programos prototipus, analyzuojant programinę įrangą, palengvinti testavymo eigą? • Ar naudojamos CASE priemonės dokumentacijos gamybai ir valdymui? • Ar renkamos visų projektų kokybės metrikos? • Ar renkamos visų projektų produktyvumo metrikos? Jei į dagumą šių klausimų jus atsakėte "Ne" tai jūsų programos kūrimo procesas yra silpnas ir rizika yra didelė. Kokia yra rizika susijusi su technologija, kuri bus daroma? Šie punktiai padės jums suprasti kokia rizika yra susijusi su technologija: • Ar technologija, kurią darysite yra nauja jūsų organizacijai? • Ar užsakovo reikalavimai reikalauja naujų technologijų kurimo? • Ar programa sąveikauja (dirba) su nauja ar neišbandyta technine įranga? • Ar programa sąveikauja (dirba) su užsakovo pateiktomis pogramomis, kurios nėra patikrintos? • Ar programa gerai diba su DB'ėm, kurios nebuvo testuotos darbui būtent su šia programa? • Ar naudojamas specialus vartotojo interfeisas? • Ar reikalavimai reikalauja, kad būtų naudojami tam tikri analizės, dizaino ir testavimo metodai? • Ar reikalavimai reikalauja naudoti neįprastas programas ar metodus, kaip pvz. dirbtinis intelektas ir neuroninia tinklai? • Ar reikalavimai nesukelia per didelių apribojimų programos efektivumui? Jei bent į vieną iš klausimų atsakyta "Taip", tai tolimesnis darbas turi būti nukreiptas į rizikos vertinimą. Kokia yra rizika susijusi su personalo dydžiu ir patirtimi? Šie klausimai padės įvertinti šią rizika: • Ar geriausi žmonės yra laisvi? • Ar žmonės turi pakankamai įgudžių? • Ar yra pakankamai laisvų žmonių? • Ar personalas įsipareigojęs išbūti visa projekto gamybos laiką? • Ar yra personalo dalis, kuri dirbs tik dali laiko prie šio projekto? • Ar personalas pakankamai gerai žino koks bus darbas ir ko tikėtis? • Ar personalas gavo reikiamą apmokymą? • Ar personalo kaita bus pakankamai maža, kad užtikrinti projekto vientisą eigą? Jei bent į vieną iš klausimų atsakyta "Ne" tai tolesni tyrimai turi įvertinti rizikos galimumą. Apie rizikos komponentus ir draiverius. Rizikos komponentai yra suskirstyti tokiu būdu: • Vykdymo rizika: Netikrumo rizika, kad produktas atitiks reikalavimus ir jis tikrai tiks tiem vartotojam, kuriems buvo daromas? • Kainos rizika: Netikrumo laipsnis, kad projekto biudžetas ne bus viršitas. • Palaikymo (paramos) rizika: Netikrumo laipsnis, kad pagamintą programą bus lengva taisyti, prytaikyti ir plėst? • Tvarkaraščio rizika: Netikrumo laipsnis, kad bus laikomasi proceso tvarkaraščio ir kad produktas bus pristatytas laiku. Rizikos įtaka yra padalinta į 4 dalis: nereikšminga, ribinė, kritinė ir katastrofinė. Lenteleje parodyta kiekvieno rizikos komponento ir iš to sekančios pasekmes tikibybė. Komponentas Kategorija Vykdymas Kaina Parama Tvarkaraðtis Katastrofinė 1 Nepasisekimas įgynedinant reikalavimus, gali privesti prie pačio projekto nepasisekimo Kainos virđijimas ir tvarkarađ-čio nesilaikymas, padidina projekto kainą $500K. 2 Gan didelis nuokrypis nuo techniniu (greičio ir t.t.) reikalavimų. Produktas už kurį nieks neatsako ir kurio nieks neprižiūri. Neilgas finansavimas, biudţeto iđeikvojimas. Nepasiekiamas IOC Kritinė 1 Reikalavimų neatitikimai, kurie gali nulemti projekto sekmę. Kainos virđijimas ir tvarkarađčio nesilaikymas, padidina projekto kainą nuo $100K iki $500K. 2 Kai kurių techninių savybių sumažėjimas Nedidelės pauzės modifikuojant programą Mažas finansavimas gali privesti prie biudžeto iššvaistymo Galimas IOC atsilikimas Ribinė 1 Neįvykdžius reikalavimų antrinių tikslų įgyvendinti nepavyks Tvarkaraščio nesilaikymas sukeliantis projekto kainos padidėjimą nuo $1K iki $100K. 2 Minimalus arba smulkus nuokrypis nuo techninių sąvybių. Tolesnė programos priežiūra. Pakankamas finansavimas. Tikroviðkas ir pasiekiamas iðplanavimas (tvarkaraðtis). Nesvarbi 1 Reikalavimų neatitikimas gali sukelti nepatogumus arba padaryti neesminę įtaką. Tvarkaraščio nesilaikymas sukeliantis projekto kainos padidėjimą mažesni nei $1K. 2 Jokių nuokrypių techninėse savybėse Lengva programos priežiūra. Galima pereikvoti biudţetŕ. Anksti pasiekiamas IOC. Pastaba: (1) Šie padariniai atsiranda dėl nerastos programos klaidos ar trūkumų joje. (2) Ðie padariniai kyla kai negaunamas norimas rezultatas. Jei jau rizika buvo identifikuota, kaip apskaičiuoiti išlaidų, kurių atsiradusi problema pareikalaus, tikymybę. Norint įvertinti riziką, reikia pačią rizika padalinti į dvi dalis - jos tiketinumą (tikrumą) ir pasekmės, kurias ji gali sukelti. Apsisaugojant nuo rizikos projekto vadovas ir visas personalas turi atlikti šiuos keturis žingsnius: 1) sudaryti skalę kuri atspindėtų rizikos tikėtinumą 2) aprašyti rizikos galimas pasekmes 3) įvertinti rizikos įtaką projektui ir produktui 4) išsiaiškinti visus rizikos apsisaugojimo būdus, kad nebūtų jokių neaiškumų Skalė gali but apibrėžta loginiais, kokybiniai ar kiekybiniai terminais. Geriausias metodas būtų įvertinti rizikos sukelejus (draiverius) pagal tikymybę ir padalinti tai i keturias grupes: neimanoma, neįtikima, galima ir dažna. Kaip alternatyva, galima rizikos tikimybę matuoti ir matematiškai. Pvz. tikimybė nuo 0.7 iki 1.0 atitinka dažną rizikos atsiradimo tikimybę. Kaip pavyzdį pateiksiu lentelę, kurioje išrašyta rizikos sukelėjų (draiverių) įtaka rizikos komponentams. Programos charakteristikų įvertinimas Charekteristikos veiksnys Nuo neįmanomo iki neįtikėtino (0.0

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!