Produktet som ikke kan målbindes

Produktet som ikke kan målbindes

Produktiviteten for it-utviklere har økt krafig de siste tiårene, men har ikke blitt enklere å måle. For hva er egentlig produktet?
Det liten tvil om at vi i dag utvikler og vedlikeholder it-systemer mer effektivt enn for 40 år siden.

Barry Boehm (en av de store guruene innen fagfeltet "software cost economics") hevder at i programvareutviklingens barndom var det vanlig at en heltids programmerer hadde kapasitet til å ha vedlikeholdsansvar for ca. 8.000 linjer (hullkort) med assembly-kode.

Antar vi at fire linjer assembly-kode maksimalt tilsvarer funksjonaliteten i en linje moderne høynivåspråk, vil det si at en heltids programmerer kun hadde ansvar for funksjonalitet tilsvarende max 2.000 linjer programvarekode.

I en studie vi gjennomførte ved en større norsk it-organisasjon fant vi at ca. 3 millioner linjer kode ble vedlikeholdt av godt under 100 personer. Uten en økning i produktiviteten ville dette fort krevd hele godt over 1.000 årsverk.

Bremser opp

Hva så med it-produktiviteten i dag målt mot den for noen få år siden? Blir vi stadig bedre? En undersøkelse publisert i Business Week i Januar 2004 viste at produktiviteten i it-prosjekter i USA hadde blitt redusert med nesten 1% hvert år de siste fire årene.

I Norge, på den annen side, har vi tall som indikerer at forholdet mellom verdiskapning og sysselsetting i ikt-sektoren er blitt stadig bedre. Betyr disse undersøkelsene at den jevne utvikler de senere årene har blitt stadig mindre produktiv i USA og mer produktiv i Norge?

Det viktigste spørsmålet her er hva vi mener med produktivitet og om målingene samsvarer med dette. Ved Simula Research Laboratory har vi gjort flere studier der vi har forsøkt å måle produktivitet.

To viktige konklusjoner fra dette arbeidet er at: 1) Vi har tilgode å se noen gode målestørrelser for produktivitet i it-prosjekter, 2) De fleste målinger av økning/reduksjon av it-produktivitet er i beste fall kun svake indikator på en eller annen forbedring eller forverring. I mange tilfeller kan målingene være nokså villedende.

Mangler måleverktøy

Hovedårsaken til at det er så vanskelig å måle produktivitet i it-prosjekter er at vi ikke har noe god enhet for produktet i it-prosjekter. Mens en oljeprodusent kan måle produktet i antall liter olje produsert, har ikke et it-firma tilsvarende meningsfulle enheter.

Forsøk som er gjort på å måle produktivitet i it-prosjekter har i hovedsak enten vært basert på linjer kode utviklet per timeverk, funksjonalitet per levert timeverk, eller verdiskaping relativt til kostnader.

Svakhetene med linjer kode per timeverk som et mål på produktivitet er velkjente. For eksempel fant vi i en studie at produktiviteten til de mest erfarne utviklerne var vesentlig lavere enn de helt uerfarne dersom vi målte produktivitet som linjer kode per timeverk.

Dette skyldes i hovedsak at de beste utviklerne skrev mer kompakt kode og løste de vanskeligste programmeringsoppgavene, og hadde ikke noe med produktivitet å gjøre. Et bedre navn på linjer kode per timeverk vil derfor være 8skrivehastighet8.

Timeverk

De fleste internasjonale benchmarkings-firmaer baserer produktivitetsmålingene på varianter av levert funksjonalitet per timeverk. Denne typen målinger av produktivitet er en forbedring sammenlignet med linjer kode per timeverk, men viser seg også å ha store svakheter.

En vesentlig svakhet er for eksempel at det er uklart hva som måles. Mens vi har et visst begrep om hva "10 linjer kode" eller "1000 kr" er, så er "10 funksjonspoeng" svært abstrakt. Ingen har noen gang sett et funksjonspoeng. Vi har selv gjennomført studier, holdt opplæring i, og innført bruk av funksjonalitetsbaserte produktivitetsmålinger i flere organisasjoner og kjenner problemene fra innsiden.

En økning i antall funksjonspoeng per timeverk skyldes ofte annet enn det vi vanligvis vil legge i produktivitetsøkning. Benchmarkings-firmaene vi har sett nærmere på har dessverre ikke hatt noen gode metoder til å gi produktivitetsmålingene meningsfullt innhold. Vi har til og med opplevd benchmarkings-firmaer som ikke engang vil oppgi hvordan produktiviteten er målt. Informasjonsverdien blir da særdeles lav.

Kostnad og verdi

I mange sammenhenger, som i Business Week, er produktivitet målt som varianter av verdiskaping relativt til kostnader. Dette høres greit ut, men fører også til en rekke tolkningsproblemer.

For eksempel, USAs produktivitetsnedgang på it-utvikling kan godt skyldes at en økende andel it-utviklerne gikk uten inntektsgivende arbeid. Hvert it-prosjekt som ble gjennomført kunne dermed godt være mer effektiv enn før, selv om verdiskapning per ansatt gikk ned.

Et annet problem er at sammenhengen mellom reell verdiskaping og målt verdiskapning innen it kan være noe tvilsom. Et it-system som koster mye, men er ubrukelig for kunden, vil i de fleste målinger gi mer verdiskaping enn et svært nyttig system som koster mindre.

Det er gjort utallige forsøk på å måle produktivitet i it-prosjekter. Ingen av dem er særlig gode. Dette må vi trolig leve med i mange år fremover. Av den grunn bør vi ikke vektlegge små endringer i produktivitet og vi bør alltid vite hvordan målingene er gjennomført før vi tolker resultatene.