Hvilke nøkkeltall forteller sannheten om prosjektet ditt?
Gode KPI-er for et utviklingsprosjekt måler levert verdi, ikke aktivitet. Følg levert funksjonalitet mot plan, feilutviklingen over tid og hvor forutsigbart teamet leverer. Unngå timer og kodelinjer, som måler innsats, ikke resultat. Som kunde holder det med en håndfull robuste mål i en enkel månedsrapport for å se om prosjektet er på rett vei.
Som kunde vil du vite én eneste ting: Går prosjektet i riktig retning? Problemet er at utviklingsverdenen byr på et hav av måltall, og de fleste av dem er laget for utviklernes eget arbeid, ikke for å gi deg svaret. Velger du feil nøkkeltall, drukner du i tall som ser imponerende ut, men ikke sier noe. Velger du riktig, holder det med en håndfull mål for å sove godt om natten.
Mål som måler verdi, ikke aktivitet
Grunnregelen er enkel: Mål det som er gjort og fungerer, ikke hvor mye som er jobbet. En håndfull robuste mål er nok.
- Levert funksjonalitet mot plan. Hvor mye av det som var tenkt for denne perioden, er faktisk ferdig, testet og godkjent? Det er det nærmeste du kommer et sant mål på fremdrift.
- Feilutvikling. Antallet kjente feil og, viktigere, om trenden peker opp eller ned. Synkende feiltall betyr at kvalitet bygges inn. Stigende feiltall er et tidlig varselsignal.
- Forutsigbarhet. Holder teamet omtrent det det lover, fra periode til periode? Et team som leverer jevnt, er lettere å planlegge rundt enn et som svinger voldsomt, selv om det svingende teamet av og til leverer mer.
- Risikobilde. Ikke et tall, men en kort liste over hva som kan velte planen. At risikoer blir synlige tidlig, er i seg selv et tegn på et modent prosjekt.
Disse målene har én ting felles: Du kan ikke pynte på dem ved bare å jobbe hardere. De speiler resultater.
Målene som er teater
Noen tall ser ut til å måle fremdrift, men gjør det ikke. De vanligste er påløpte timer og antall kodelinjer.
Timer måler innsats, ikke resultat. Et team kan ha fulle timelister og likevel ha bygget feil ting eller brukt uken på å rette egne feil. Timer er et kostnadsmål, ikke et fremdriftsmål. Behandle dem deretter.
Kodelinjer er enda verre fordi de rett og slett belønner feil atferd. Mer kode er mer å vedlikeholde og flere steder der feil kan gjemme seg. Ofte er den smarteste løsningen den som løser problemet med minst kode. Å måle kodelinjer er som å bedømme en forfatter etter antall sider.
Vær på vakt mot statusindikatorer som alltid er grønne. Hvis hver rapport viser at alt er i rute, helt frem til uken da alt plutselig er forsinket, måler rapporten fasade snarere enn virkelighet.
Et konkret eksempel
Tenk deg to månedsrapporter for det samme prosjektet. Den ene sier: «Teamet har brukt 320 timer, skrevet 12 000 kodelinjer, og stemningen er god.» Den andre sier: «Av de seks funksjonene som var planlagt, er fire ferdige og godkjente, én er forsinket på grunn av en uventet integrasjon, og antallet åpne feil har gått fra 18 til 11. Den største risikoen fremover er testen hos betalingsleverandøren.»
Den første høres aktiv ut, men lar deg være like uvitende som før. Den andre er kortere, men nå vet du nøyaktig hvor prosjektet står, hvor det butter og hva du eventuelt må ta stilling til. Det er forskjellen på å måle bevegelse og å måle retning.
En enkel rapportmal du kan kreve
Du trenger ikke å spesifisere avanserte dashbord. Be i stedet om en kort månedsrapport som svarer på fire spørsmål:
| Spørsmål | Hva du får ut av det |
|---|---|
| Hva ble ferdig mot plan? | Faktisk fremdrift |
| Hvordan ser feilbildet og trenden ut? | Kvalitet over tid |
| Hvilke risikoer ser dere fremover? | Tidlig varsel |
| Hva skjer videre? | Retning og forventninger |
Får rapporten plass på én side, er den passe lang. Målet er beslutningsgrunnlag, ikke en bunke som imponerer, men som ingen leser.
Vi i Weapp jobber med korte sykluser og åpen rapportering nettopp for at du skal se retningen tidlig, ikke bli overrasket sent. Vil du ha det innsynet i prosjektet ditt? Les mer om tjenestene våre, eller ta kontakt med en kort beskrivelse av hva du vil bygge.
Ofte stilte spørsmål
Hvorfor er antall påløpte timer et dårlig mål?
Timer måler hvor mye som er jobbet, ikke hva som er oppnådd. Et team kan bruke hundrevis av timer på feil ting eller på å rette egne feil og likevel ha fulle timelister. Timer sier noe om kostnad, men ingenting om fremdrift eller verdi. Følg heller med på hva som faktisk er levert og fungerer.
Er kodelinjer et mål på produktivitet?
Nei, snarere tvert imot. Flere kodelinjer betyr ofte mer kode å vedlikeholde og flere steder der feil kan oppstå. Ofte er den beste løsningen den som krever minst kode. Å måle kodelinjer belønner feil atferd og sier ingenting om hvorvidt produktet gjør det det skal. Unngå det helt som styringsmål.
Hvilke nøkkeltall holder for en ikke-teknisk kunde?
Tre til fire kommer du langt med: levert funksjonalitet mot plan, antall åpne feil og om de øker eller minker, og hvor godt teamet holder det det lover per periode. Legg til et kort risikobilde. Flere mål gir sjelden bedre beslutninger, bare mer å tolke og lettere å gjemme seg bak.
Hva er feilutvikling, og hvorfor er det viktig?
Feilutvikling er hvordan antallet kjente feil endrer seg over tid. Et synkende antall tyder på at kvaliteten bygges inn. Et jevnt økende antall er et tidlig varsel om at teknisk gjeld hoper seg opp under overflaten. Trenden sier mer enn det enkelte tallet. En kort økning før en lansering kan være helt normal.
Hvor ofte bør jeg få en rapport?
Månedlig rapportering holder for de fleste prosjekter, med kortere statusmøter innimellom hvis noe krever en beslutning. Rapporten skal være kort og forståelig: hva som er levert mot plan, feilbildet, risikoene og hva som skjer videre. Blir rapporten en tykk bunke, har den blitt teater i stedet for et verktøy for beslutninger.