Perplex Oy

Kuinka suuri urakka?

Etusivu
7 tähden projekti
6 portaan prosessi
39 askelen Inter-set
Julkaisut
Yhteydenotto

Edellinen artikkeli

Seuraava artikkeli

ARVIOT TYÖN MÄÄRÄSTÄ

On helpompi päättää toteutuksesta ja sopia hinnasta, jos urakan kokoluokasta on käsitys jo ennalta.

Menetelmät arvioiden tekemiseksi vaihtelevat hurskaiden toiveiden ja matemaattisten laskenta-algoritmien välillä.

Toive

Suunnitelman tarkastaja: "Miksi panit tähän näin pienen työmäärän? Eihän tämä voi pitää paikkaansa."

Projektipäällikkö: "Johtoryhmä halusi, että se valmistuu nopeasti."

FPA

Tietojärjestelmien kehityksen työmääriä on hankala arvioida. Mitään aukotonta erilaisiin tilanteisiin sopivaa menetelmää ei ole löytynyt. Paras tunnettu on toimintopistelaskenta eli FPA (sanoista Function Point Analysis; korvautumassa termillä 'functional size measurement'). Sillä saadaan aikaan mittaluku, joka kuvaa lopputuloksen kokoa numerona. Laskennan lähtökohtana on viisi suuretta:

1. montako syötettä järjestelmässä on

2. montako tulostetta järjestelmässä on

3. kuinka monta liittymää (tietovirtaa järjestelmään tai siitä ulos) siinä on yhteensä

4. minkä verran siinä on järjestelmän sisäisiä tietorekistereitä

5. kuinka monta erilaista kyselyä järjestelmään tulee.

Lukuja painotetaan 14:llä tekijällä, joita ovat esimerkiksi tehtävän vaikeusaste, monimutkaisuus ja laatuvaatimukset. Laskennan tuloksena on sovelluksen koko toimintopisteinä.

Saatua tulosta voidaan käyttää työmäärien arvioinnissa, kun jatketaan laskentatyötä soveltamalla välinevalintoihin ja tilannetekijöihin kuten työntekijöiden osaamiseen ja tehtävän tuttuuteen liittyviä kertoimiaan. Laskenta on monipolvinen ja vaatii koulutusta soveltajaltaan, mutta sen avulla eri henkilöiden arviot osuvat väittämän mukaan tyypillisesti 10 prosentin haarukkaan, siinä missä perinteisemmät arvausmenetelmät voivat heittää satoja prosentteja.

Toimintopistelaskennan käyttäjäkerhossa (IFPUG, International Function Point Users Group) on yli1200 yritystä, mikä lienee epäsuora todiste menetelmän hyödyllisyydestä.

Kokemuspohjainen arvio

Kokemuspohjaisen arvion tarkkuuteen vaikuttaa tietysti ratkaisevasti, kuinka tuttuja samankaltaiset toteutukset ovat ennestään. Tietojärjestelmien tapauksessa kokoluokka on helpoin määrittää projekteissa, jotka pohjautuvat valmispaketin käyttöönottoon ja sovittamiseen asiakkaan olosuhteisiin ohjaustietojen avulla.

Mikäli toteutus tehdään systeemityönä eikä valmispaketin sovituksena, kokemuspohjaisessa arvioinnissa käytetään periaatteessa samoja suureita kuin FPA:ssa, mutta tulos syntyy enemmän kokemuksen ja intuition kuin kerätyn tilastoaineiston ja matemaattisten yhtälöiden kautta. Olisi hyvä saada ainakin pari toisistaan riippumatonta arviota. Kokemusperäinen arvio on hyvä ristiintarkistus myös FPA-laskennalle.

Ratkaisu voi pohjautua myös olemassa olevalle järjestelmärungolle, jota täytyy muokata voimakkaasti sen sisuskaluja myöten, kun ei tulla toimeen pelkällä ohjaustietojen asettelulla. Eräskin nyrkkisääntö ehdottaa, että jos 20 prosenttia rungosta täytyy laatia uusiksi, vähimmällä työllä pääsee, kun uusii kaiken. Järjestelmien sisäiset riippuvuudet ovat kavalampia kuin arvaakaan, vaikka ottaisi tämän varoituksen huomioon.

Arvaus

Kun määritystyö ei ole edennyt riittävän kauas, tai kun asia on tavanomaista vieraampi tai tekniikat uusia ja arvaamattomia, saattaa olla silti tarpeen heittää pöytään joku arvaus. Pohjana voivat olla joillakin kriteereillä samankaltaisiksi luokitellut toteutukset. Niidenkin työmäärät saatetaan joutua arvioimaan jälkikäteen, jos kehityksestä ei ole pidetty tuntikirjanpitoa, mutta menneisyyden arvaaminen on sentään helpompaa kuin tulevaisuuden. Jälkikäteisarvion saa tehdyksi ainakin karkeina lukuina.

Kokonaisuus osiksi ja osien summa kokonaisuudeksi

Eräs yksinkertainen mutta samalla systemaattinen tapa saada hehtaariluku ennalta tuntemattoman hankkeen työmäärästä on tehdä ensin jako tehtäviksi niin, että kukin niistä voidaan selittää ytimekkäästi muutamana virkkeenä suorasanaista tekstiä. Sitten arvioidaan, kestääkö tehtävä viikon, kaksi vai kolme. Tämän tarkempia numeroarvoja ei käytetä. Pitempikestoiset täytyy jakaa pienemmiksi paloiksi ja viikkoa lyhyemmät niputtaa yhteen muiden kanssa.

Kuvatulla tavalla pääsee oikeaan suuruusluokkaan, eikä energia mene hukkaan sen miettimiseen, kumpi mahtaisi olla tarkempi arvio, 4½ vai 5½ päivää. Samoin kaikenlaisen pikkusilpun kanssa ihmismielelle on luontevaa antaa järkevä arvioi minkä suuruinen paketti siitä on mahdollista koota viikossa. Tällä tavalla syntyy luotettavampi arvio kuin käyttää standardina vaikka jotain päivän puolikasta ja saada kerto- ja yhteenlaskulla yhteissumma pikkutehtävien kokonaistyölle.

Ristiintarkistus

Arviointi on joskus vaikeaa ja toisinaan vielä vaikeampaa, mutta vaikeus ei ole mikään syy ohittaa arviointi kokonaan. Arvioiden tarkkuus paranee, mitä enemmän niitä tekee, ja niiden luotettavuus on sitä varmempi, mitä useammalla rinnakkaisella tavalla kukin yksittäinen arvio on tehty. Yksi lukuarvo kerätään esimerkiksi matkaamalla tyvestä puuhun eli summaamalla yksittäisten tehtävien työmääräarviot. Toinen lukuarvo johdetaan hankkeen karkeista mittaluvuista, kuten tietojärjestelmien input- ja output-lukumääristä ja vastaavista. Kolmas kiintopiste on jonkin vastaavanlaisen hankkeen toteuma, jos tällainen on saatavilla.

Lähde: Tehosta projektityötä