Hvilke nøgletal fortæller sandheden om dit projekt?
Gode KPI’er for et udviklingsprojekt måler leveret værdi, ikke aktivitet. Følg leveret funktionalitet i forhold til planen, fejltrenden over tid og hvor forudsigeligt teamet leverer. Undgå timer og kodelinjer: De måler indsats, ikke resultat. Som kunde behøver du kun en håndfuld robuste mål i en enkel månedsrapport for at se om projektet er på rette vej.
Som kunde vil du vide én ting: Går projektet i den rigtige retning? Problemet er at udviklingsverdenen byder på et væld af målinger, og de fleste af dem er lavet til udviklernes eget arbejde, ikke til at give dig svaret. Vælger du de forkerte nøgletal, drukner du i tal der ser imponerende ud, men ikke siger noget. Vælger du de rigtige, er en håndfuld mål nok til at du kan sove godt om natten.
Mål der måler værdi, ikke aktivitet
Grundreglen er enkel: Mål hvad der er blevet gjort og virker, ikke hvor meget der er arbejdet. En håndfuld robuste mål er nok.
- Leveret funktionalitet i forhold til planen. Hvor meget af det der var tiltænkt denne periode, er faktisk færdigt, testet og godkendt? Det er det tætteste du kommer på et sandhedsmål for fremdrift.
- Fejltrenden. Antallet af kendte bugs og, vigtigere, om tendensen peger op eller ned. Faldende fejl betyder at kvaliteten bygges ind. Stigende fejl er et tidligt advarselssignal.
- Forudsigelighed. Holder teamet cirka det det lover fra periode til periode? Et team der leverer jævnt, er lettere at planlægge efter end et der svinger voldsomt, selv hvis det svingende team nogle gange leverer mere.
- Risikobillede. Ikke et tal, men en kort liste over hvad der kan vælte planen. At risici bliver synlige tidligt, er i sig selv et tegn på et modent projekt.
De her mål har én ting til fælles: De kan ikke pustes op ved bare at arbejde hårdere. De afspejler resultater.
Målene der er teater
Nogle tal ser ud til at måle fremdrift, men gør det ikke. De mest almindelige er brugte timer og antal kodelinjer.
Timer måler indsats, ikke resultat. Et team kan vise fuld belægning og alligevel have bygget den forkerte ting eller brugt ugen på at rette sine egne fejl. Timer er et omkostningsmål, ikke et mål for fremdrift. Behandl dem derefter.
Kodelinjer er endnu værre, for de belønner direkte forkert adfærd. Mere kode er mere at vedligeholde og flere steder hvor fejl kan gemme sig. Ofte er den dygtigste løsning den der løser problemet med mindst kode. At måle kodelinjer svarer til at bedømme en forfatter på antal sider.
Vær på vagt over for “sundhedstal” der altid er grønne. Hvis hver rapport viser at alt følger planen, helt frem til den uge hvor alt pludselig er forsinket, måler rapporten facade snarere end virkelighed.
Et konkret eksempel
Forestil dig to månedsrapporter for det samme projekt. Den ene siger: “Teamet har brugt 320 timer, skrevet 12.000 linjer kode, og stemningen er god.” Den anden siger: “Af de seks funktioner der var planlagt, er fire færdige og godkendte, én er forsinket på grund af en uventet integration, og antallet af åbne fejl er gået fra 18 til 11. Den største risiko fremover er betalingsleverandørens test.”
Den første lyder aktiv, men efterlader dig lige så uvidende som før. Den anden er kortere, men nu ved du præcis hvor projektet står, hvad der driller og hvad du eventuelt skal tage stilling til. Det er forskellen mellem at måle bevægelse og at måle retning.
En enkel rapportskabelon at kræve
Du behøver ikke at specificere avancerede dashboards. Bed i stedet om en kort månedsrapport der svarer på fire spørgsmål:
| Spørgsmål | Hvad du får ud af det |
|---|---|
| Hvad blev færdigt i forhold til planen? | Faktisk fremdrift |
| Hvordan ser fejlsituationen og tendensen ud? | Kvalitet over tid |
| Hvilke risici kan ses fremover? | Tidlig advarsel |
| Hvad er næste skridt? | Retning og forventning |
Kan rapporten være på én side, har den den rette længde. Målet er et beslutningsgrundlag, ikke en tyk bunke papir der imponerer, men som ingen læser.
Vi hos Weapp arbejder med korte cyklusser og åben rapportering netop for at du skal se retningen tidligt, ikke blive overrasket sent. Vil du have den indsigt i dit projekt? Læs mere om vores ydelser, eller kontakt os med en kort beskrivelse af hvad du vil bygge.
Ofte stillede spørgsmål
Hvorfor er antallet af brugte timer et dårligt mål?
Timer måler hvor meget der er arbejdet, ikke hvad der er opnået. Et team kan bruge hundredvis af timer på de forkerte ting eller på at rette egne fejl og alligevel vise fuld belægning. Timer siger noget om omkostning, men intet om fremdrift eller værdi. Følg hellere hvad der faktisk er blevet leveret og virker.
Er kodelinjer et mål for produktivitet?
Nej, snarere tværtimod. Flere kodelinjer betyder ofte mere kode at vedligeholde og flere steder hvor fejl kan opstå. Ofte er den bedste løsning den der kræver mindst kode. At måle kodelinjer belønner forkert adfærd og siger intet om hvorvidt produktet gør det det skal. Undgå det helt som styringsmål.
Hvilke nøgletal er nok for en ikke-teknisk kunde?
Tre til fire rækker langt: leveret funktionalitet i forhold til planen, antallet af åbne fejl og om det stiger eller falder, samt hvor godt teamet holder det det lover pr. periode. Tilføj et kort risikobillede. Flere mål giver sjældent bedre beslutninger, bare mere at tolke og mere at gemme sig bag.
Hvad er fejltrenden, og hvorfor er den vigtig?
Fejltrenden er udviklingen i antallet af kendte bugs over tid. Et faldende antal tyder på at kvaliteten bygges ind. Et støt stigende antal er en tidlig advarsel om at der hober sig gæld op under overfladen. Tendensen siger mere end det enkelte tal: En kort stigning op til en lancering kan være helt normal.
Hvor ofte bør jeg få en rapport?
Månedligt er nok for de fleste projekter, med kortere statusmøder ind imellem hvis noget kræver en beslutning. Rapporten skal være kort og forståelig: hvad der er leveret i forhold til planen, fejlsituationen, risiciene og hvad næste skridt er. Bliver rapporten en tyk bunke papir, er den blevet teater i stedet for et beslutningsværktøj.