1 010758000 Ohjelmistotekniikka - Projektinhallinta (osa 2) Kevät 2003 Hanna-Kaisa Lammi LTY/Tite.

Esitys aiheesta: "1 010758000 Ohjelmistotekniikka - Projektinhallinta (osa 2) Kevät 2003 Hanna-Kaisa Lammi LTY/Tite."— Esityksen transkriptio:

1 1 010758000 Ohjelmistotekniikka - Projektinhallinta (osa 2) Kevät 2003 Hanna-Kaisa Lammi LTY/Tite.

2 2 Sisältö Työmäärien arviointi Riskien hallinta Mikä ohjelmistotyössä maksaa? Kansanviisauksia

3 3 Työmäärien arviointi Edellytys aikataulun ja budjetin laatimiselle Vaikeaa mm. koska – ihmisten työn tuottavuus vaihtelee (edes 10-20 - kertaiset erot eivät ole harvinaisia) – työn vaativuus vaikuttaa tuottavuuteen (kerroin 1-20) – yllättävät ongelmat eivät ole harvinaisia – tuotteen kokoa on vaikea arvata

4 4 Tuotteen koon arviointi Yksinkertaisimmat menetelmät perustuvat arvaukseen, joko projektin tekijöiden, asiantuntijoiden tai esimerkiksi kilpailijan antamaan tarjoukseen Kehittyneemmät menetelmät perustuvat historiatietojen hyväksikäyttöön Kannattaa käyttää useampia menetelmiä paremman lopputuloksen saamiseksi Arvioista ei tulisi tehdä kovin tiukkoja, sillä arviot ovat helposti liian optimistisia

5 5 Yksinkertaisia menetelmiä Koodirivien lukumäärä – esim. kalenteripalvelu < kaupan varastonhallintajärjestelmä < paperitehtaan tehdasjärjestelmä – riippuu käytetystä ohjelmointikielestä, korkeamman tason kielissä aina vähemmän koodirivejä kuin matalan tason Loogisten lausekkeiden lukumäärä Dokumentointisivujen lukumäärä

6 6 Kehittyneempiä menetelmiä työmäärien arviointiin Matemaattisia menetelmiä, esim. – Kolmen arvion malli – Cocomo (Constructive cost model) – FPA (Function Point Analysis) Kokemukseen perustuva arvaus Historiatietoon perustuva arvio Murheellinen paradoksi: kaupan saa usein se, joka arvioi työmäärän eniten väärin.

7 7 Riskien hallinta Riski on uhka, että projekti ei mene suunnitelmien mukaan, esim. – tavoitteita ei saavuteta – projekti maksaa enemmän kuin suunniteltiin – projekti ei toteudu sovitussa aikataulussa Riskit kartoitetaan kunkin vaiheen alussa, jotta niihin voidaan ennalta varautua ja kehittää varautumissuunnitelmat

8 8 Riskienhallinnan eteneminen Riskit tunnistetaan, analysoidaan, luokitellaan ja priorisoidaan – luokittelu: tekniset, asiakkaaseen liittyvät, omaan henkilöstöön liittyvät Tehdään varautumissuunnitelmat Riskejä seurataan ja hallitaan – riskien ennakointi, eliminointi, vaikutusten minimointi tai vaikutusten hyväksyminen

9 9 Top risks, USA Avainhenkilö vaihtaa työpaikkaa Epärealistiset aikataulut ja budjetit Kehitetään ohjelmistoon vääriä toimintoja ja turhia piirteitä Huono käyttöliittymä Muutokset määrittelyssä: "liikkuva maali" Ongelmat muualta hankituissa komponenteissa ja/tai palveluissa Tekniset ongelmat (suoritusteho, reaaliaikaisuus, muistitila) Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

10 10 Toteutuneita riskejä Lappeenrannasta MITÄ TAPAHTUI? – aikataulu petti – kustannukset ylittyivät – asiakas oli tyytymätön tuotteeseen (tuote ei vastaa tavoitteita, liiketaloudelliset menetykset): jälkihoidon työmäärä valtava MIKSI ? – työmääräarvio virheellinen – määrittely puutteellinen – liian suuri projekti – asiakkaan/toimittajan asiantuntemattomuus – suunnittelematon käyttöönotto – henkilöstön vaihtuvuus – huono projektipäällikkö – ongelmat työvälineissä/laitteissa

11 11 Johtopäätös Projektien ongelmat eivät niinkään ole teknisiä, vaan liittyvät projektinhallintaan, ihmisten johtamiseen, ryhmätyöhön, kommunikointiin, asiakastarpeiden ymmärtämiseen…

12 12 Mikä ohjelmistotyössä maksaa? Työvoimakustannukset (palkat, henkilösivukulut), yleensä 50-70% kaikesta yleiskustannukset (tilojen vuokra, konttorikustannukset, puhelin,…) alihankinta kalusto- ja tilajärjestelyt koulutus palkitseminen projektiryhmän huolto, edustus (syöttäminen, juottaminen, saunotus, seminaarit korpihotellissa) matkakustannukset kirjallisuus yms. tiedonhankinta laitteet pääomakustannukset katetavoite…

13 13 Ihmistyön kustannustekijät palkka (kk-palkka, ylityöt, palkkiot) pakolliset henkilösivukulut (lomakorvaukset, sosiaaliturva, eläke- yms. vakuutukset, palkalliset sairauspäivät, arkipyhät, yhteensä 50-60% palkasta) vapaaehtoiset henkilösivukulut (ruoka, auto, terveydenhoito, virkistys...) koulutus rekrytointi (voi olla merkittäväkin, esimerkiksi 6- 10 kk palkka).

14 14 Kansanviisauksia 1 On tyhmää toistaa samoja virheitä (tai toisten virheitä) Valitse projektiin mahdollisimman harvoja ja mahdollisimman hyviä tekijöitä jotka kykenevät kiinteään yhteistoimintaan Projektin tarkempi suunnittelu on tehtävä uudestaan vähintään kahden kuukauden välein, koska vain tällä aikamarginaalilla tehtävät voidaan tuntea etukäteen tarkasti Asiat joita seurataan (palkitaan) tulevat tehdyiksi Projektin osallistujat osallistuvat myös työmääräarvioiden tekemiseen Älä esitä (edes) alustavaa aikatauluarviota liian aikaisin, tai tuo ainakin selkeästi esille mihin arvio perustuu, arvion epävarmuustekijät ja se, että arvioon ei voi mitenkään sitoutua.

15 15 Kansanviisauksia 2 Käytä työmääräarvioijina aina useampia kuin yhtä henkilöä Älä hyväksy muutoksia ja lisäyksiä määrittelyyn projektin aikana ilman, että niiden vaikutus aikatauluun ja kustannuksiin arvioidaan ja tehdään selväksi kaikille osapuolille Projektiin osallistuvat seuraavat itse omaa ajankäyttöään Seuraa toteutumatietoja, päivitä projektisuunnitelmaa Tee jälkiarviointi: mitä opit projektista (loppuraportti) Palkitse hyvät suoritukset (aika-arvioiden alitukset). Mieti mitä palkitset (toivottu suoritus). "Tee tärkeät asiat ennen kiireellisiä." "Kahvipöytä on firman tärkein projektinhallinnan apuväline."

16 16 Kansanviisauksia 3 Aina ei kannata paljastaa todellisia aikataulutavoitteita Julkistetut tavoitteet voi asettaa esimerkiksi siten, että niistä 50% myöhästynyt projekti ei todellisuudessa ole täysin epäonnistunut Projekti täyttää aina sille varatun ajan, varataanpa aikaa sitten kuinka paljon hyvänsä Jos projektinhallinta on liian byrokraattinen, töitä aletaan tehdä salaa projektihallinnan ulottumattomissa Raportointi on määriteltävä projektisuunnitelmassa riittävän formaaliksi, muuten se unohtuu projektikiireiden keskellä 80% maailman ongelmista johtuu pohjimmiltaan puutteellisesta kommunikoinnista. Lisää projektisuunnitelmaan suunnitelma tiedottamisesta sekä projektin sisällä että projektin ja ulkomaailman välillä: kuka kertoo, mitä, kenelle ja kuinka usein. Tiedottaminen on yksisuuntaista, viestintä kaksisuuntaista.

17 17 Tekevälle sattuu... Verohallitus aloitti syyskuussa 1988 ATK-projektin verotusohjelmistojen uudistamiseksi. Vanhat FAS-kielellä kirjoitetut ohjelmistot päätettiin korvata kokonaan uusilla Projekti oli erittäin laaja. Parhaimmillaan projektin kimpussa hääräsi yli 100 henkeä Kesäkuussa 1989 määrittelyvaihe oli valmis (muutamalla kuukaudella myöhästyneenä) Marraskuussa 1989 toteutusvaihe alkoi, mutta määrittelyt osoittautuivat epätäsmällisiksi. Tammikuussa 1990 tekijät havaitsivat aikataulun epärealistiseksi, mutta eivät raportoineet tästä riittävän äänekkäästi: edes johtoryhmä ei saanut tietoa tästä Huhtikuussa 1990 projektin piti päättyä, mutta loppua ei ollut näkyvissä.

18 18 …tapaus Verohallitus Kesäkuussa 1990 projektista tuli suosittu uutisaihe Joulukuussa 1990 viimeiset osat laskentaohjelmistosta valmistuivat Huhtikuu 1991: vuoden 1989 verotus valmistuu? Myös vuoden 1990 verotus viivästyi SYYT: – epärealistinen aikataulu – paloittelu ja vaiheistus unohtui – riskejä ei analysoitu – poikkeamista ei raportoitu tai niitä ei havaittu – "uudet" työkalut: Cobol ja Oracle – Oracle-konsultit eivät tunteneet sovellusalueen kieltä.