PROJEKTIN HALLINTA
Yleistä
Projekti on työ, joka tehdään määritellyn kertaluonteisen tuloksen saavuttamiseksi. Projekti ei voi olla luonteeltaan jatkuvaa toimintaa, vaan sillä on aina jokin tavoitepäivä, johon mennessä projektin olisi oltava valmis.
Ohjelmistotuotannossa projektityöskentelyä varten tarvitaan useita eri suunnitelmia:
- projektisuunnitelma
- laatusuunnitelma
- testaussuunnitelma
- versiohallintasuunnitelma
- hyväksymissuunnitelma
- tarvittaessa myös muita
Projektin aluksi on tehtävä projektisuunnitelma ja laatusuunnitelma, jotka voidaan kirjoittaa joko kahdeksi eri suunnitelmaksi tai yhdeksi paperiksi; jatkossa ajatellaan yhtä paperia, jota kutsutaan lyhyesti projektisuunnitelmaksi.
Projektisuunnitelman sisällys:
Projektisuunnitelmassa on käsiteltävä seuraavia asioita:
- Johdanto
- yleiskuvaus projektista ja tuotteesta
- viittaukset olemassaoleviin dokumentteihin (esim. vaatimusmäärittelyyn)
- Viitteet
- Määritelmät
- Käytettävä elinkaarimalli
- vaiheet
- etapit aikatauluineen
- syntyvät dokumentit
- luettelo versiohallinnan alaisista asioista
- Vaiheiden ositus tehtäviksi; jokaisesta tehtävästä on kuvattava
- tulos
- arvio tuloksen koolle
- työmääräarvio
- arvio muiden (kuin henkilö)resurssien tarpeesta
- riippuvuus muista tehtävistä tai aloitusehto
- päättämisehto
- suunniteltu aloitus- ja lopetusajankohta
- vastuuhenkilö
- Projektiorganisaatio; myös asiakkaan osalta
- työskentelyyn osallistuvat henkilöt ja heidän työpanoksensa eri ajankohtina
- laadunvalvontaan osallistuvat henkilöt työpanoksineen (valvojat, tarkastajat, kirjurit)
- Nuodatettavat menettelyt
- suunnittelumenetelmät yms.
- käytettävät apuvälineet
- Käytettävät mittarit
- tuotteen mittaaminen
- työskentelyn mittaaminen
- Laatutavoitteet (mitattaville asioille)
- Tarkastusmenettelyt (niiltä osin kuin eivät liity aiemmin kuvattuihin etappeihin)
- Viittaukset muihin suunnitelmiin (testaussuunnitelma, ...)
- Riskit ja niihin varautuminen
- Alihankintasuunnitelma
- Edistymisen seuranta
- seurantamenettelyt
- projektikokoukset
- projektisuunnitelman muuttamismenettely
Tehtävänä voi esiintyä myös oman tai asiakkaan henkilöstön kouluttaminen käytettävien työskentelymenetelmien hallintaan tai rakennettavan järjestelmän tuntemiseen.
Osituksen muodostamisperiaatteita:
- rakenteellinen ositus: jokainen suunniteltava palikka, jokainen ohjelma, jokainen koulutustapahtuma jne. omaksi tehtäväkseen; normaalisti käytetään tätä
- työlajin mukainen ositus: ohjelmointi, asennus, koulutus, projektihallinto jne.; voidaan käyttää hienosäätönä edellisen perusteen mukaiselle jaolle
- vaiheittainen ositus: karkean tason elinkaarimallin mukainen jako; johtaa yleensä liian suuriin tehtäviin; sopiva tehtäväkoko on parista päivästä muutamaan viikkoon
Tehtävien ajoitus esitetään usein janakaaviona ("Gantt-kaavio"), joka voi myös näyttää tehtävien ajoituksessa olevat pelivarat. Tästä voidaan muodostaa kriittinen polku eli tehtäväketju, jossa pelivarat ovat pienimmät.
Aikataulun nopeuttamiseen on kaksi periaatteellista keinoa:
- yksittäisten tehtävien lyhentäminen
- tehtäväketjun keston lyhentäminen
Nopeuttamisen yhteydessä kriittinen polku voi muuttua.
Aikataulua laadittaessa on muistettava, että osa työntekijöiden ajasta kuluu muihin projekteihin, hallintoon, tarjouksien tekoon, lomiin yms.
Resurssien riittävyys eri vaiheissa on varmistettava; moniprojektitilanteessa on resurssien yhteinen riittävyys varmistettava.
Etappien asettaminen parantaa työskentelyä, koska lähellä oleva tavoite kannustaa työskentelemään tehokkaammin kuin kaukainen tavoite.
Projektisuunnitelman käsittely
Projektipäällikkö laatii projektisuunnitelman ja tuo sen projektin johtoryhmän hyväksyttäväksi. Projektisuunnitelma asetetaan dokumenttien hallinnan alaisuuteen ja sitä pidetään jatkuvasti yllä.
Projektipäällikön on laadittava myös
- testaussuunnitelma, sisältönä mm.
- testien suunnitteluohjeet
- testien suorittamisohjeet
- luettelo suoritettavista testeistä
- versiohallintasuunnitelma, sisältönä mm.
- yleisten versiohallintaperiaatteiden soveltamistapa tässä projektissa
- luettelo versiohallinan alaisista asioista
Ohjelmiston koon arviointi
Lähestymistavat:
- "alhaalta-ylös": komponentit arvioidaan erikseen
- "ylhäältä-alas": arviointi perustuu ohjelmiston sisältämälle toiminnallisuudelle
Henkilöresurssien tarpeen arvioiminen
Henkilöstön tuottavuuden arviointi on mahdollista vain, jos tuottavuudesta on kerätty historiatietoja; kuitenkin
- historiatiedoissa on aina suuri hajonta
- resurssitarvetta arvioitaessa ihminen käyttää luonnostaan parhaimpia arvoja; tätä on erityisesti varottava
Tuottavuus vaihtelee ohjelmien koon ja vaikeusasteen mukaan. Samoin tuottavuus riippuu siitä kuinka suuri osa ohjelmasta on uusia tai muutettuja rivejä.
COCOMO (COnstructive COst MOdel) on uuden ohjelmistotuotteen suunnittelussa käytettävä malli kustannusten, työmäärän ja aikataulun arvioimiseksi. Malliin kuuluva työkalu antaa näistä tiedoista lukuisia arvioita sekä mahdollistaa "entä jos"-skenaarioiden tutkimisen.
Projektin seuranta
Kiinnostuksen kohteet, jotka on esitettävä määräajoin tehtävässä projektin seurantaraportissa:
- aikataulussa pysyminen
- työmääräarvioissa pysyminen
- kokonaisbudjetissa pysyminen
- laatutavoitteissa pysyminen
- projektisuunnitelmasta puuttuneet työt
- tulossa olevat lähiajan ongelmat
Projektin pienistäkin tapahtumista (kokoukset, palaverit, neuvottelut, puhelinkeskustelut, päätökset, havaitut ongelmat jne.) on pidettävä päiväkirjaa ("koska, ketkä, mitä"), koska niihin voidaan joutua viittaamaan myöhemmin.
Riskien hallinta
Riski on ei-toivotun tai vahingollisen tapahtuman mahdollisuus.
Riskin ominaisuudet:
- nimi
- mahdolliset syyt
- tapahtumisen todennäköisyys
- vahingon suuruus
Riskien hallinta:
- riskien tunnistaminen ja priorisointi
- riskien analysointi
- varautuminen seurauksiin
- riskien ehkäisy
- tilanteen seuranta
Riskien alkuperät:
- tuotteen kokoon liittyvät riskit
- markkinatilanteesta johtuvat riskit
- asiakkaasta johtuvat riskit
- ohjelmistotuotantoprosessiin liittyvät riskit
- tuotantoympäristöstä johtuvat riskit
- teknologian uutuudesta johtuvat riskit
- henkilöstöstä johtuvat riskit
Projektien pahimmat ongelmat
Henkilöpula; lääkkeinä yrityksen laajuinen resurssisuunnittelu, bonuspalkkio projektin lopussa (ehkäisee eroamisia), asiantuntemuksen jakaminen usealle henkilölle.
Epärealistinen aikataulu tai budjetti; lääkkeinä yksityiskohtainen projektisuunnittelu, hyvät työmäärän arviointimenetelmät.
Väärien toimintojen toteuttaminen järjestelmään; lääkkeinä asiakkaan kouluttaminen, asiakkaan mukanaolo tarkastuksissa, prototyypit, käyttöohjeen aikainen julkistaminen.
Kullalla päällystäminen; lääkkeinä vaatimusmäärittelyn paisumisen varominen, taloudellisuuteen tähtäävä suunnittelu.
Määrittelyjen jatkuva muuttuminen; lääkkeinä muutosten hallinta, versiointi.
Ongelmat ulkopuolisissa komponenteissa; lääkkeinä alihankkijan referenssien tarkastaminen, alihankintatuotteiden kunnollinen katselmointi.
Vasteaikaongelmat (omassa tuotteessa); lääkkeinä simulointi, prototyypit, mittaus ja virittäminen.
Nykytekniikan ylittämisvaatimukset; lääkkeinä asiakkaan kouluttaminen, vaatimusten tekninen tarkastaminen, kustannus-hyöty-analyysi.
Puutteellinen testaus; lääkkeenä kouluttaminen, testausapuvälineiden käyttöönotto, testauksen suunnitteleminen.
Tuottavuuden parantaminen
Tuottavuutta voidaan parantaa
- tehostamalla työntekijöitä: koulutus, johtaminen
- tehostamalla työtehtäviä: apuvälineet, työasemat
- vähentämällä työtehtäviä: sovelluskehittimet, automaattinen dokumentointi
- vähentämällä saman asian uudelleentekemistä: koodin uudelleenkäyttö, kirjastot
- rakentamalla yksinkertaisempia tuotteita: prototyypit
Tuottavuuteen vaikuttavat myös työolosuhteet.
Vain jäsenille: