Projektijuhtimine

1. Projektijuhtimine • Teema 7: • Tarkvaraprojektide üldküsimused • Peeter Normak

2. IKT kui kõiki valdkondi läbiv valdkond • Kaasaegse majanduse ja ühiskonna arengusuundumused: • Majandustegevuse sisu muutumine: • Teenuste osakaalu kasv tootmise suhtes (1970 – 1:1; 2010 – 3:1), • Teenuste vahenduskeskkond – Internet, • Teenuste individualiseeritus (tarbija osalus endale teenuse kujundamisel). • Ettevõtete-organisatsioonide toimimismudelite muutumine: • Tekivad institutsioonide ökosüsteemid (koostoimivad võrgustikud/klastrid), N: Opel • Majandusruum globaliseerub, • Järjest enam protsesse standardiseeritakse ja automatiseeritakse. • Arengusuundumuste realiseerumisel on oluline roll IKT vahenditel: tootlikkuse kasvust ligikaudu 50% tuleneb IKT vahendite rakendamisest. • Määravaks on töötajate e-oskused (e-skills).

3. Tarkvaraprojekti spetsiifika - üldised nõuded • Tarkvaraprojekti spetsiifika tuleneb tulemile esitatavatest üldnõuetest, mille järgi peaks tarkvara: • üldjuhul toimima erinevatel platvormidel ja erineva riistvara korral; • olema muu tarkvaraga koostoimevõimeline; • toetama rakendusvaldkonna põhiprotsesse; • vastama laia (ja reeglina mittehomogeense!) kasutajaskonna vajadustele; • olema kergesti kohandatav spetsiifilistele vajadustele vastavaks (näiteks seadusandlusele, asutuse regulatsioonidele või kasutatavate tehnoloogiatele/metoodikatele). • Üldnõuetest tulenevaid erinõudeid tarkvarale: • rangelt järgima standardeid; • olema visuaalselt (graafiline disain) ja loogiliselt (kasutatavus) optimeeritud, kooskõlaline kasutajate käitumismustritega; • võimeline adekvaatselt reageerima tahtlikele (näiteks ründed) ja tahtmatutele (näiteks voolukatkestus) häiretele.

4. Tarkvaraprojekti spetsiifika - süsteemsus • Tarkvaraprojektide arendamisel muutusid teatud ühtsed alused ja sellest tulenev süsteemsus kriitiliseks lokaalsete ja globaalsete arvutivõrkude massilise kasutuselevõtuga. • Tegevussuunad: • Arendusprotsessi süstemaatiline analüüs ning arendusmetoodikate ja –vahendite loomine, aga samuti tarkvaratehnika meetodite arendamine. • IKT-alaste standardite ja spetsifikatsioonide loomine. • Erinevate raamistike (sh CC2001, SE2004, SWEBOK jmt) ja küpsusmudelite loomine. • IKT-pädevuste alaste sertifikaatide ja sertfitseerimisasutuste massiline loomine. • IKT-juhtimise professionaliseerumine.

5. Tarkvaraprojektide edu kriitilised faktorid • Näiteid (TLÜ/TPÜ poolt täidetud) tarkvaraprojektidest: Tähelinn, õpetajate analüüs, õpitarkvara, IVA, VIKO, ePortfoolio, … . • Fundamentaalne: minimeerida tarkvara ümbertegemise osakaal. • Selleks on oluline, et projekti tegevused oleksid kavandatud äärmiselt läbimõeldult (eriti projekti algfaasis, mil võetakse vastu kõige kaalukamad otsused). • Oluline on (vt ka konspekti Lisa nr 6): • Kasutajate kaasamine kogu projekti jooksul; • Muudatuste efektiivne juhtimine; • Kvaliteedikindlustus ja probleemitundlikkus; NB! Vigade parandamist mitte edasi lükata! • Komponentide õigeaegne integreerimine; • Ajagraafiku vajadustele vastav korrigeerimine; • Sobiva arendusprotsessi mudeli määratlemine/kujundamine ja järgimine. • NB! Natuke rohkem protsessijuhtimist projekti algfaasis hoiab projekti lõppfaasis kokku võrratult rohkem aega vigade paranduselt; probleemid tuleb lahendada koheselt peale nende tekkimist. Esimese 10% indikaator.

6. Projektikonkursil osalemise otsustamine (arendaja vaade) • Projekti planeerimise kulud on 5-10% projekti maksumusest. • Otsustamiseks olulised aspektid (Smith, 2001): • Nõuete selgus ja konkreetsus. • Kooskõlalisus taotleja strateegiaga. • Varasemad koostöösuhted tellijaga. • Moodulite olemasolu, mis sobivad taotluses kasutamiseks. • Taotluse koostamiseks ja täitmiseks vajalike oskustega täitjate olemasolu. • Kõrgetasemelise/võitva taotluse koostamiseks vajaliku ajaressursi olemasolu. • Tellija maksevõime ja valmisolek adekvaatse hinna tasumiseks. • Konkurentide arvust ning nende kvaliteedist tulenev võidu tõenäosus. • Konkurentidest positiivse eristumise määr. • Võime pakkuda konkurentidest odavamaid lahendusi. • Võimalused tellijaga tema nõudeid, prioriteete, võimalusi, hindamise põhimõtteid ja taotleja võimalikke lahendusi arutada.

7. Kolm põhiküsimust (arendaja vaade) • Enne projektikonkursil osalemise otsustamist tuleb saada selgus järgmistes küsimustes: • Võidame projektikonkursi, kuna … (võimaldab rõhuda tugevustele) • Kui me kaotame, siis selle põhjuseks on … (võimaldab elimineerida võimalike kaotuste põhjuseid) • Taotlemise kolm põhilist riski on … (võimaldab maandada riske)

8. Tarkvaraprotsessi faasid ja esialgne kavandamine • Lihtsaim üldine arendusmudel: ADDIE (Analyse, Design, Development, Implementation, Evaluation). • Tarkvaraarenduse puhul : nõuded, disain, kodeerimine, testimine, juurutamine. • SWEBOK (SoftWare Egineering Body Of Knowledge): 10 põhifaasi + alafaasid. Näiteks nõuete põhifaasi alafaasid: 1) nõuete määratlemise protsess, 2) nõuete määratlemine, 3) nõuete analüüs, 4) nõuete spetsifitseerimine, 5) nõuete fikseerimine, 6) nõuete haldamine • Tarkvaraprojekti esialgse kavandamise tulem: tarkvaraarenduskava. • Projekti visiooni määratlemine, • Põhiotsustaja määratlemine, • Projekti eesmärkide määratlemine, • Riskihaldus, • Efektiivsete personalikasutuse strateegiate kujundamine, • Ajaarvestus.

9. Tarkvaraptojekti kestvuse määramatus • Projekti kestvuse hinnangu määramatuse kordajad: • Nõuete väljatöötamise järel 2,0 0,5 • Nõuete analüüsi järel 1,75 0,57 • Esialgse disaini järel 1,4 0,71 • Detailse disaini järel 1,25 0,80 • Kodeerimise järel 1,1 0,91 • Testimise järel 1.05 0,95

10. Ülesanded • Tuua näiteid tarkvaraprojekti ebaõnnestumise põhjustest. • Iseseisvalt: loetle olulisemad töötajate väheste IKT-alaste oskustega seonduvad probleemid, mis pärsivad tootlikkuse kasvu (tutvu ka Euroopa Komisjoni dokumendiga 52007DC0496). • Iseseisvalt: veebiallikate põhjal määratle tarkvaraprojektijuhtide olulisemad isiksuslikud omadused. • Iseseisvalt: veebiallikate põhjal leia IKT-alaseid müüte. • Iseseisvalt: analüüsi Standish Group poolt välja töötatud IT-projekti kaalutud tulemusmudelit (weighted scoring model). Iseseisvalt: leida ADDIE eestikeelne akronüüm.

11. Personalivajadus ja personalijuhtimine • Personalivajadus sõltub kasutatavast arendusmudelist; üldjuhul nõuab nõuete analüüs rohkem aega ja kõrgemat kvalifikatsiooni, mistõttu mõned mudelid jätavad selle hoopis kõrvale. • Brooksi reegel: 1/3 kavandamisele, 1/6 kodeerimisele, 1/4 üksuse testimisele, 1/4 integreerimisele. • Probleem: teadmiste, oskuste ja kasutatavate praktikate mittevastavus. N: GP magistritöö. • Arendaja vahetus on väga kulukas  personali säilitamine ja professionaalne kasv on projektijuhi oluline kvaliteedinäitaja. • Projektimeeskonna koostamisel tuleks arvestada rollide esindatust ja tasakaalustatust; rollid võivad olla näiteks järgmised (võrdle XP-metoodika rollidega, p 7.6): esimees, vormistaja, ideede generaator, kriitik, töömesilane, meeskonna tugi, varustaja, lõpuleviija.

12. Soovitused personalivajaduse arvestamiseks • Kavandada tööjõud 75% ulatuses. • Pigem investeerida kogenud eksperti kui värvata “odav” algaja ja loota tema koolitamisse ja arengusse. N: ±3σ • Projektimeeskonna kooskõla on olulisem kui individuaalsed teadmised/oskused. projektimeeskonna sagedaim etteheide projektijuhile. • Isiksuslikud omadused on olulisemad kui teadmised/oskused: esimesed on raskemini kujundatavad kui teised. • Projektijuht peab olema vaba projektimeeskonna kujundamisel; selles ei tohi avaldada survet. • Projektimeeskonna kujundamisel peab jälgima, et muus kontekstis kujunenud rollid ei pärsiks projektis olulisi rollivahekordi. N: Victori ülikooli üliõpilasprojektid.

13. Muudatuste haldamine • Projektiplaan vajab pidevat kohandamist/täpsustamist. Muudatuste sisseviimine peab käima kindla protseduuri järgi; näiteks: • Muudatuste kavandajad peavad koostama vastava kirjaliku Muudatusettepaneku, kus on kavandatav muudatus ning selle läbi saavutatavad tulemused kirjeldatud, • Juhtrühm saadab Muudatusettepaneku arvamuse saamiseks muudatusest puudutatud osapooltele, • Esitatavates arvamustes hinnatakse nii muudatuste sisseviimise kulusid kui ka selle läbi saavutatavat kasu, • Arvamuste alusel võtab juhtrühm vastu asjakohase otsuse ja teavitab sellest asjakohaseid osapooli. • Arvestatavad faktorid, näiteks: • Kuidas mõjutab muudatus projekti ajakava, kvaliteeti ja ressursijaotust (näiteks kas suurendab eriti hõivatud inimeste töökoormust); • Kas muudatuse tegemist on otstarbekas edasi lükata; • Millised on muudatuse sisseviimisega kaasnevad riskid jne.

14. Riskihalduse aspekte • Hästi korraldatud muudatuste haldus vähendab ebaõnnustumise riske, kuna: • Otsused on läbi räägitud, rohkem aktsepteeritud ja paremini põhjendatud, • Projekti käik on paremini dokumenteeritud, • Osapooled on üksteise tööst paremini informeeritud, misläbi saavutatakse parem koostöö. • Riskihaldus on sisuliselt optimeerimisülesande lahendamine; üldjuhul on optimaalne 5-10%. • Soovitatav on koostada põhiliste riskide tabel (riski kirjeldus, realiseerumise tõenäosus ja potentsiaalne kahju, selle vähendamise teed, vastutajad,...).

15. Koostöö juhtkonnaga • Standish Group: Koostöö juhtkonnaga on IT-projektide õnnestumise olulisuselt 2. kohal olev tingimus, vähene koostöö ebaõnnestumise 4. kohal olev põhjus. • Koostööks on oluline juhtide informeerimine ja kaasatus (juhid peavad projekti pidama “omaks”, mitte “võõraks”). Hea koostöö nimel peaks vältima järgmiseid olukordi: 1) Juhtide kahtlused projekti adekvaatse kavandamise (eelkõige selleks kuluva aja) suhtes. Selle vältimiseks peaks projekti olulised aspektid olema põhjalikult ja veenvalt põhjendatud ning juhtidega läbi räägitud. 2) Juhtide poolt vähesest informeeritusest tulenevalt projekti täitmist pärssivad tegevused (kokkulepped kolmandate osapooltega, oluliste ressursside kavandamine muude projektide peale jmt). • “Alkoholitest” projekti kavandamise ja täitmise kvaliteedi üle otsustamiseks: oluliste küsimuste (ootamatu) esitamine projektijuhile ja projektimeeskonna liikmetele. Selle eesmärk: veenduda, et projekti täitjad on projektist, selle täitmisest ja enda rollist põhjalikult aru saanud. • Testi edukaks läbimiseks vajalik projektijuhi ennetav tegevus: endale võimalike küsimuste esitamine, neile vastuste leidmine (vajadusel koostöös projektimeeskonna teiste liikmetega) ning vastuste projektimeeskonnas läbiarutamine.

16. Nõuete väljatöötamine ja analüüs • Standish Group: Nõuete kvaliteet on IT-projektide õnnestumise olulisuselt 3. kohal olev tingimus, nõuete mittetäielikkus ebaõnnestumise 3. kohal olev põhjus. • Fundamentaalne: kasutajate kaasamine. • Probleemid: • Liiga üldine/ebamäärane ülesandepüstitus. Võtted: seonduvate protsesside määratlemine ning nendest lähtuvalt nõuete konkretiseerimine, kasutuslugude koostamine. • Kaasatavate kasutajate määratlemine. Kõik olulisemad profiilid peavad olema esindatud. N: õppetööle registreerumine. • Kasutajatega ühtse keele leidmine. Võtted: koolitused, seminarid. • Kasutajate poolt oma vajaduste teadvustamine. Võtted: intervjuud, kasutuslugude koostamine. • Efektiivse kasutatavuse (usability) tagamine. Võtted: ühtne stiilijuhis (sh arusaadavad ikoonid), prototüübid, kasutusjuhend. • Nõuete muutumine projekti täitmise jooksul. Võtted: paindlike arendusmetoodikate kasutamine, muudatuste juhtimise tagamine.

17. Tarkvaraprotsessi alane kogemus • Tutvusta tarkvaratoodet tarbijaile võimalikult vara. Ükskõik kuidas ka ei püüa nõuete formuleerimise faasis tarbija vajadusi tundma õppida, efektiivseim viis selleks on anda talle toode ja lasta tal sellega tööd teha. • Kasuta sobivat protsessimudelit. Iga projekt peab valima protsessi, mis on sellele projektile sobivaim antud organisatsioonikultuuri, riskivalmiduse, nõuete selguse, rakendusvaldkonna jne korral. • Minimeeri intellektuaalset distantsi (arendusprotsessi osapoolte vahel). Tarkvara struktuur peab olema võimalikult lähedane reaalse maailma struktuuridele; see on tinginud objekt-orienteeritud tehnikate, komponent-tehnoloogiate ja visuaalse modelleerimise kasutuselevõtu. • Enne programmi kiiremaks tegemist tee see korrektseks. Palju lihtsam on teha töötav programm lihtsamaks kui teha kiire programm korrektseks, st ei tasu algse kodeerimise juures programmi optimiseerimise üle väga muretseda.

18. Tarkvaraprotsessi alane kogemus II • Hea juhtimine on olulisem kui hea tehnoloogia. Halba juhtimist ei kompenseeri hea tehnoloogia ja küllaldased ressursid, küll aga hea juhtimine kompenseerib halba tehnoloogiat ja väheseid ressursse. Vähe sellest, hea juht tõmbab häid inimesi, saavutab nende vajaliku pädevuse ja kujundab hea meeskonna. • Saa aru ja järgi tarbija prioriteete. Tarbija lepib sellega, et 90% funktsionaalsusest hilineb, kui ainult kõige olulisem 10% valmiks tähtajaliselt. • Disaini muutmisvalmina. Muutusi peab võimaldama nii arhitektuur, komponendid kui ka kasutatavad spetsifikat­sioonitehnikad. Seejuures muutmine ei tohi oluliselt kaasa tuua keerukuse kasvu. • Tarkvaraarenduse käigus loodav peab enamuses olema isedokumenteeruv. Disain ilma dokumenteerimata ei ole disain, neid peab looma paralleelselt (sageli kohatav ütlus “Disain on lõpetatud, tuleb see vaid veel dokumenteerida” viitab protsessi nõrkusele).

19. Ülesanded • Tuua näiteid tarkvarast, mida on ebamugav kasutada või mis on liiga piiratud või ülepaisutatud funktsionaalsusega. • Iseseisvalt: veebiallikatele (näiteks http://www.keirsey.com/) tuginedes analüüsi erinevaid isiksuslike tüüpide ja rollide klassifikatsioone. • Iseseisvalt: veebiallikate põhjal formuleeri IT projektimeeskonna koostamise alaseid soovitusi/seisukohti. • Iseseisvalt: leida internetiallikaid, milles käsitletakse IT-projekti skoobi liigsest laiendamisest (scope creep) tingitud ebaõnnestumisi. • Iseseisvalt: sõnast tehnoloogia omaksvõtu mudeli (Technology Acceptance Model) ja vajadustele vastavuse mudeli (Task-Technology Fit) põhijooned.