Melissa Perry har introdusert meg for en god praksis for å kunne drive med målinger og beregninger innenfor digital produkt- og tjenesteutvikling: The Metrics Lenses Framework. Rammeverket brukes til å analysere ytelse i produktteam fra flere synsvinkler, og hjelper med å få en mer helhetlig forståelse av resultatene teamet skaper. En unngår "tunnelsyn" ved å vurdere data fra forskjellige vinkler.
Metrics Lenses Framework
Rammeverket består totalt av 6 hovedlinser:
Process Lens: Hvordan går det med teamene våre? Med dette objektivet kan du få svar på spørsmål som "Hvordan vet jeg at teamet leverer kvalitetsprogramvare?"
Product Lens: Hvordan bruker folk produktet vårt? Få svar på spørsmål som "Fungerte vår nye brukerflyt?"
Quality Lens: Hvor fornøyde er brukerne våre? Få svar på spørsmål som "Får brukerne/kundene den tjenesten de forventer?"
Commercial Lens: Hvordan skaper vi lønnsomhet? Få svar på spørsmål som "Hva tjener vi på å få en ny kunde/en intern avdeling i gang på tjenesten vår?"
Market Lens: Hvem bruker produktene våre? Bidra til å svare på spørsmål som "Hvem er våre mest verdifulle kunder, og hvordan samhandler ulike markedssegmenter med produktet vårt?"
Strategic Lens: Hvordan fungerer produktstrategien vår? Få svar på spørsmål som "Fungerer overgangen til et abonnementsbasert tilbud?"
I denne korte juleartikkelen har jeg bare prosesslinsen på.
Prosess Linsen
Prosessmålinger skal hjelpe deg med å forstå hvor godt og hvor ofte teamet vårt leverer programvare. Det finnes mange metoder innenfor området, men personlig liker jeg Accelerate-målinger best. Det er et evidensbasert sett med beregninger som gir mindre rom for synsing og tolkninger. I Accelerate måler vi:
Deployment Frequency (DF): Hvor ofte går programvaren live? Høyytelsesteam distribuerer minst ukentlig, ofte mye oftere. Hvis et team kan gjøre dette vellykket, reduserer du risikoen for at teamet introduserer feil som ødelegger for sluttbrukerne.
Lead Time for Changes (LTC): Gjennomsnittstiden mellom en Commit blir foretatt, og koden kommer i produksjon. Jo kortere dette er, desto mer sannsynlig er det at teamet har få flaskehalser, og leverer små deler av arbeidet trinnvis. Team med høy ytelse har gjennomsnittlig LTC på mindre en dag.
Mean Time To Restore (MTTR): Måler hvor lang tid det tar for teamet å komme seg etter en produksjonsfeil. Dette avslører mye om hvor robust det totale systemet er. Høypresterende team løser ofte problemer innen minutter eller få timer.
Change Failure Rate (CFR): Forholdet mellom mislykkede deployments og suksessfulle deployments for en tjeneste. Hvis vi deployer 8 ganger i løpet av en dag, og 2 av distribusjonene våre mislykkes (for eksempel ved å introdusere feil), vil vår CFR være 25%. Høypresterende team har generelt en CFR under 15 %.
Det er også innført en femte parameter som bør følges med på: Reliability (Pålitelighet). Faktorer som tilgjengelighet, latens, ytelse og skalerbarhet skal analyseres, men her har en ikke satt noen bechmark.
Ønsker du å lære mer om metoden kan du lese mer her: https://dora.dev/
Her kan du også sjekke ditt eget team sin ytelse. Prøv DORA-sjekken på: https://dora.dev/quickcheck/
Userstory-målinger
En annen målemetode er userstory målinger. For å måle ytelsen i teamet, måles hastighet ved å telle hvor mange (user)-story points som teamet fullfører i en sprint. En bruker dette som basis for å planlegge neste sprint, og følger med på utviklingen over tid.
Jeg må innrømme at jeg ikke er fan av denne måten. Det kan føre til at teamet fokuserer på å “fullføre” poeng i stedet for å levere og fokusere på kvalitet og verdi. En bør være forsiktig med å bruke slike etterfølgende indikatorer, som en proxy-beregning for virkelige bruker- og kundeverdier. Jeg ville flyttet samtalen i disse teamene fra «Hvor mange poeng er denne historien?» til "Forstår vi denne historien godt nok til å bygge den?" eller "Hvordan kan vi best levere verdien i denne historien?"
Avslutning
Uavhengig av metode, er det viktig å huske på at gode beregninger må være:
Forståelig – alle involverte forstår definisjonen av beregningen og hvordan den brukes
Sammenlignbar – du kan sammenligne tallene du har nå med samme beregning på et annet tidspunkt
Handlingsbar – teamet ditt må kunne ta avgjørelser basert på beregningen.
Et siste råd jeg har, er at en ikke bør begynne med målinger FØR en MVP/første versjon er produksjonssatt. Jeg er fan av å måle, men ikke begynn å mål ytelsen til teamet før en faktisk har utviklet noe med kunde- og/eller virksomhets-verdi som er satt i drift. Fokuset i den første design- og utviklingsfasen må konsentrere seg om å skape product-market fit og ikke målinger. Du må først fokusere på å utforske problemet og levere for å lære, deretter optimalisere.
Ha en riktig god førjuls tid - uten å bli målt!