År 2018 skrev jag om varför dagliga commits är viktiga inom mjukvaruutveckling . Responsen var överväldigande – både positiv och kritisk. Vissa utvecklare anammade disciplinen med dagliga commits, medan andra protesterade och menade att sådana mätvärden kan bli fåfänga siffror.
De har båda rätt. Att mäta utvecklarproduktivitet är ett mycket komplext ämne, och det går långt utöver commits och PR.
I åratal har teknikledare jagat den heliga graalen av utvecklarnas produktivitetsmått. Kodrader? För lätta att manipulera. Antal commits? Som jag diskuterade i min tidigare artikel spelar de roll – men de är bara en pusselbit. Färdigställda story points? Blir ofta ett förhandlingsspel snarare än ett mått på verkliga framsteg.
Låt mig dela med mig av en historia som lärde oss en dyr läxa om att förlita sig för mycket på enkla mätvärden.
För några år sedan introducerade vi daglig commitfrekvens som ett av våra kriterier för prestandagranskning. Avsikten var god – vi ville uppmuntra kontinuerlig integration och regelbunden kodleverans. Vissa utvecklare anammade omedelbart denna praxis och gjorde det till en vana att integrera sitt arbete dagligen samtidigt som de levererade små delar av verkligt värde till användarna. Andra hittade dock kreativa sätt att manipulera systemet för att få sitt bidragsdiagram att se bättre ut.
En seniorutvecklare började dela upp sitt arbete i små commits. Istället för att göra meningsfulla integrationspunkter, commitade de mindre ändringar separat – ett variabelnamn här, en formateringsändring där. Deras commit-graf såg fantastisk ut, ett hav av gröna rutor på GitHub. Under deras prestationsgranskning såg siffrorna fantastiska ut.
Men när vi grävde djupare upptäckte vi att även om antalet commits var högt, var commits kraftigt manipulerade och det fanns inget verkligt värde i många av dem, vilket omintetgjorde hela poängen med kontinuerlig leverans.
Denna erfarenhet lärde oss att även välmenande mätvärden kan vara kontraproduktiva när de används isolerat. Det måste finnas ett bättre sätt att tänka på utvecklares produktivitet.
DevOps är ett mer avancerat sätt att tänka kring mjukvaruutveckling, som är mycket fokuserat på team (och inte individuell) leverans och verkliga resultat. Tanken är att förkorta utvecklingslivscykeln samtidigt som man kontinuerligt levererar högkvalitativ mjukvara till slutanvändarna som ett team.
Googles DevOps Research and Assessment (DORA)-team har gett oss fyra viktiga prestationsmått som ger en solid grund för att mäta teamets prestation:
Dessa mätvärden är kraftfulla eftersom de mäter resultat, inte bara aktivitet. När vi arbetar med dussintals kunder inom olika branscher har vi upptäckt att team som fokuserar på dessa mätvärden tenderar att leverera mer värde konsekvent.
”De bästa teamen driftsätter 973 gånger oftare och har 6750 gånger snabbare ledtider jämfört med lågpresterande team.” — State of DevOps Reports
Men här är haken – DORA-mätvärden ensamma berättar inte hela historien eftersom de är väldigt fokuserade på kod, infrastruktur och leverans, men inte nödvändigtvis på andra viktiga mänskliga och samarbetsaspekter.
Det är här SPACE-ramverket kommer in i bilden och lägger till viktiga dimensioner som DORA inte fångar upp:
Genom att arbeta med både startups och företag har jag sett hur dessa mänskliga faktorer ofta är viktigare än rena implementeringsmått. Ett team med perfekta DORA-poäng men låg nöjdhet och dåligt samarbete kommer inte att upprätthålla sin prestation på lång sikt.
Ett exempel på dålig praxis som skulle kunna visa varför DORA inte räcker till är "Deploy Friday"-syndromet. Det uppstår när produktchefer insisterar på att pusha viktiga funktioner varje fredagseftermiddag för att möta godtyckliga sprintdeadlines, trots driftsteamets oro över helgsupport och utvecklarnas varningar om testtid. Även om implementeringsstatistik kan se imponerande ut, skapar detta en toxisk cykel av brandbekämpning på helgerna, förhastad testning, ackumulerad teknisk skuld och teamutbrändhet – vilket i slutändan leder till högre felfrekvenser, långsammare leverans, ökade kostnader och talangförlust. En del av detta kan dyka upp i DORA-statistiken över tid eller kanske inte, men det skapar problem och risker med personalledning.
Ett annat exempel är "kravvattenfallet"-fällan som uppstår när en affärsanalytiker spenderar veckor eller månader på att samla in krav i isolering, producerar ett 200-sidigt specifikationsdokument som ingen läser och kastar det över väggen till utvecklingsarbetet. Dokumentet blir omedelbart föråldrat när marknadsförhållandena förändras, saknar teknisk kontext eftersom ingenjörer inte konsulterades och innehåller motstridiga krav som inte validerades med faktiska användare. När utvecklingsarbetet oundvikligen stöter på vägspärrar finns det ingen tydlig process för förtydligande, vilket leder till förseningar, felaktigt anpassade funktioner och pekande mellan team.
Många exempel som detta visar att dålig planering, kommunikation och samarbete kan skapa en miljö och ett sammanhang där det blir riktigt svårt att ha ett korrekt utvecklingsflöde och en god ingenjörskultur.
Även om DORA och SPACE är relativt populära, ville jag också nämna en riktigt intressant bok som är mindre känd. Jonathan Alexanders "Codermetrics" (O'Reilly, 2011) förändrade hur jag tänkte på att mäta utvecklares produktivitet.
Till skillnad från många böcker som enbart fokuserar på kvantitativa mätvärden introducerar Alexander människocentrerade mätvärden som beaktar både de sociala och tekniska aspekterna av mjukvaruutveckling. Han presenterar praktiska metoder för att mäta saker som kunskapsdelning, kodhantering och mentorskap – aspekter som traditionella mätvärden ofta missar.
Till exempel tittar hans "Samarbetskvot" på teamdynamik genom mätvärden som:
Det är bara ett litet exempel på hur Jonathan betraktade samarbets- och kommunikationsmetoder som go sträckte sig långt bortom enkla resultat som kodrader eller commit.
Även om principerna i Codermetrics är något äldre nu, är de fortfarande förvånansvärt relevanta, särskilt dess betoning på att använda mätvärden för att förbättra teamdynamiken snarare än att bara mäta output (t.ex. kodrader och commits).
För att sammanfatta vår granskning av gamla och nuvarande mätsystem är det viktigt att nämna DX Core 4 – ett enhetligt ramverk som kombinerar de bästa aspekterna av DORA, SPACE och utvecklarupplevelse. Det mäter fyra nyckeldimensioner:
Det som gör DX Core 4 annorlunda är dess balans. Team som utmärker sig inom alla fyra dimensioner presterar konsekvent bättre än de som bara fokuserar på ett eller två områden. Denna helhetssyn hjälper organisationer att undvika den vanliga fällan att optimera för hastighet på bekostnad av kvalitet eller utvecklarerfarenhet.
Developer Experience Index (DXI) är särskilt intressant eftersom det mäter hur effektivt utvecklare kan utföra sitt arbete. Det tittar på faktorer som flödesstatus, feedback-loopar och kognitiv belastning. Tänk på de dagar då du är i zonen, dina tester går snabbt och du levererar kvalitetskod – det är så en bra DXI ser ut. Men det går utöver individuell produktivitet. Indexet fångar också upp samarbetsmönster: hur väl team delar kunskap, kvaliteten på kodgranskningar och effektiviteten i tekniska diskussioner. Programvaruutveckling är trots allt en lagsport.
Planeringsrutiner spelar en avgörande roll i alla fyra dimensioner av ramverket. God planering minskar kognitiv belastning (effektivitet), möjliggör förutsägbar leverans (hastighet), förhindrar förhastade implementeringar (kvalitet) och säkerställer att vi arbetar med det som är viktigt (effekt). Ramverket hjälper till att avslöja när planeringen inte fungerar – som när berättelserna är för stora, kraven är oklara eller den tekniska upptäckten är otillräcklig. Dessa planeringsproblem visar sig som minskade effektivitetspoäng, ökade ledtider och lägre effektmått. Genom att koppla planeringsrutiner till konkreta mätvärden hjälper DX Core 4 team att identifiera och åtgärda processproblem innan de påverkar leveransen.
Ramverket är utformat för att förhindra de vanliga fallgroparna vid produktivitetsmätning genom att säkerställa att ingen enskild mätmetod kan manipuleras utan att påverka de andra. Varje dimension ger kontrollmekanismer gentemot de andra.
En viktig aspekt av DX Core 4 är att det fungerar på alla nivåer i organisationen. Från VD:ar som vill förstå den tekniska effektiviteten till teamledare som vill eliminera flaskhalsar, ger dessa mätvärden meningsfulla insikter utan att bli fåfänga mätvärden.
AI-utvecklingsverktyg som GitHub Copilot, Cursor, Claude med flera har förändrat hur vi tänker på och mäter utvecklares produktivitet. Även om dessa verktyg kan generera stora mängder kod snabbt, gör detta det viktigare, inte mindre, att mäta utvecklares effektivitet.
Traditionella mätvärden blir otillräckliga när AI kan producera hundratals rader kod på några sekunder. Med AI som hanterar rutinmässiga kodningsuppgifter blir de mänskliga aspekterna av utvecklingen av största vikt. De mest produktiva utvecklarna utmärker sig i att bryta ner komplexa problem, dela effektiva kodningsmönster, fokusera på arkitektur/systemdesign och upprätthålla höga dokumentationsstandarder. Team som trivs med AI lägger ofta mer tid på design och samarbete än kodning, vilket gör icke-kodande mätvärden allt viktigare.
Denna förändring betonar vikten av att spåra nya indikatorer: tid som spenderas på diskussioner om problemdefinition, kvaliteten på tekniska designdokument, effektiviteten i kunskapsdelning om AI-verktyg och samarbetsmönster i team.
SPACE-ramverket (Satisfaction, Performance, Activity, Communication, Efficiency) och liknande holistiska ramverk får ny betydelse i takt med att team anpassar sig för att integrera AI i sina utvecklingsprocesser, med särskild uppmärksamhet på hur dessa verktyg påverkar utvecklarnas tillfredsställelse och teamdynamik.
Även de bästa mätsystemen misslyckas utan ordentligt organisatoriskt stöd. Genom att skala upp vårt företag har vi lärt oss att produktivitetsmätning måste backas upp av genomtänkt organisationsdesign och ledarskapspraxis.
Detta överensstämmer med Googles banbrytande forskning genom Project Oxygen och Project Aristotle, som visade att teameffektivitet inte primärt handlar om individuella prestationsmått eller teknisk expertis. Deras forskning fann att psykologisk trygghet, pålitlighet och struktur/tydlighet var mycket viktigare för teamets framgång än individuella prestationsmått.
Ledare behöver skapa miljöer där produktiva beteenden kan blomstra. Det innebär:
Vi har sett fall där team med perfekta DORA-mått har haft problem på grund av organisatoriska silos, medan team med "sämre" mätvärden levererat mer värde tack vare bättre anpassning till affärsmål och starkare tvärfunktionellt samarbete. Googles forskning fann att framgångsrika team behöver "struktur och tydlighet" - med tydliga roller, planer och mål. Deras resultat visade att högpresterande team har väldefinierade förväntningar och förstår hur deras arbete bidrar till organisationens bredare mål.
De mest framgångsrika organisationerna vi arbetar med behandlar produktivitetsmätning som en del av ett bredare system som inkluderar organisationsdesign, ledarskapsutveckling och kulturbyggande. De förstår att mätvärden är verktyg för förbättring, inte vapen för verkställighet – en princip som återspeglar Googles resultat om vikten av att skapa en kultur av förtroende och kontinuerligt lärande.
Den här artikelns mål är inte att föreskriva en specifik lösning utan att bevisa att det finns ett behov av att utvärdera många olika mätvärden och att se på programvaruutveckling mer holistiskt.
Nyckeln är inte att välja mellan DORA, SPACE eller andra mätvärden, utan att använda dem i kombination och att lära av dem:
Behöver du hjälp med att utforma en holistisk produktivitetsstrategi?
Som ledare måste vi motstå frestelsen att reducera utvecklarnas produktivitet till enkla siffror. Detta blir ännu viktigare i AI-eran. Visst, mätvärden som dagliga commits har sin plats – men de bör vara samtalsämnen, inte slutsatser.
Nästa gång du känner dig frestad att mäta produktivitet genom att räkna kodrader eller commits, ta ett steg tillbaka och fråga dig: Mäter vi det som är viktigt, eller bara det som är lätt att mäta?
Verklig produktivitet inom mjukvaruutveckling handlar inte om hur mycket du producerar – det handlar om hur mycket värde du skapar för en kund. Ibland är det mest värdefulla en utvecklare kan göra att ta bort kod, förbättra dokumentation eller hjälpa en kollega att förstå ett komplext system.
Vissa saker är svårare att mäta, och vi bör fokusera på resultat framför output när det är möjligt och fokusera på teamet framför individen.
För er som är intresserade av att fördjupa er i ämnet rekommenderar jag: