Vilka nyckeltal säger sanningen om ditt projekt?

Som beställare vill du veta en enda sak: går projektet åt rätt håll? Problemet är att utvecklingsvärlden erbjuder en uppsjö av mätetal, och de flesta av dem är gjorda för utvecklarnas eget arbete – inte för att ge dig svaret. Väljer du fel nyckeltal drunknar du i siffror som ser imponerande ut men inte säger något. Väljer du rätt räcker en handfull mått för att sova gott om natten.

Mått som mäter värde, inte aktivitet

Grundregeln är enkel: mät vad som blivit gjort och fungerar, inte hur mycket som arbetats. En handfull robusta mått räcker.

• Levererad funktionalitet mot plan. Hur mycket av det som var tänkt till den här perioden är faktiskt klart, testat och godkänt? Det är det närmaste du kommer ett sanningsmått på framdrift.
• Felutveckling. Antalet kända buggar och, viktigare, om trenden pekar upp eller ner. Sjunkande fel betyder att kvalitet byggs in; stigande fel är en tidig varningssignal.
• Förutsägbarhet. Håller teamet ungefär vad det åtar sig från period till period? Ett team som levererar jämnt är lättare att planera kring än ett som svänger vilt, även om det svängiga ibland levererar mer.
• Riskbild. Inte en siffra, men en kort lista på vad som skulle kunna välta planen. Att risker syns tidigt är i sig ett tecken på ett moget projekt.

De här måtten har en sak gemensamt: de går inte att fejka genom att bara jobba hårdare. De speglar resultat.

Måtten som är teater

Vissa siffror ser ut att mäta framdrift men gör det inte. De vanligaste är nedlagda timmar och antal kodrader.

Timmar mäter ansträngning, inte resultat. Ett team kan visa full beläggning och ändå ha byggt fel sak eller ägnat veckan åt att laga sina egna misstag. Timmar är ett kostnadsmått, inget framdriftsmått – behandla det därefter.

Kodrader är än värre, för de belönar rakt fel beteende. Mer kod är mer att underhålla och fler ställen där fel kan gömma sig. Ofta är den skickligaste lösningen den som löser problemet med minst kod. Att mäta kodrader är som att bedöma en författare på antal sidor.

Var vaksam på “hälsosiffror” som alltid är gröna. Om varje rapport visar att allt är på plan, ända fram till veckan då allt plötsligt är försenat, mäter rapporten fasad snarare än verklighet.

Ett konkret exempel

Tänk dig två månadsrapporter för samma projekt. Den ena säger: “Teamet har lagt 320 timmar, skrivit 12 000 rader kod och stämningen är god.” Den andra säger: “Av de sex funktioner som var planerade är fyra klara och godkända, en är försenad på grund av en oväntad integration, och antalet öppna fel har gått från 18 till 11. Största risken framåt är betalningsleverantörens test.”

Den första låter aktiv men lämnar dig lika ovetande som innan. Den andra är kortare, men du vet nu exakt var projektet står, vad som skaver och vad du eventuellt behöver besluta om. Det är skillnaden mellan att mäta rörelse och att mäta riktning.

En enkel rapportmall att kräva

Du behöver inte specificera avancerade dashboards. Be i stället om en kort månadsrapport som svarar på fyra frågor:

Ryms rapporten på en sida är den lagom. Målet är underlag för beslut, inte en lunta som imponerar men ingen läser.

Vi på Weapp arbetar med korta cykler och öppen rapportering just för att du ska se riktningen tidigt, inte överraskas sent. Vill du ha den insynen i ditt projekt? Läs mer om våra tjänster eller hör av dig med en kort beskrivning av vad du vill bygga.