Så länge jag kan minnas har vi diskuterat produktiviteten inom mjukvaruutveckling, men jag har inte sett något bra sätt att mäta den. I olika sammanhang har man tagit fram metoder där alla bygger på att vi uppskattar värdet av det som utvecklats. Men hur säkerställer vi att vi bedömer värdet av det som utvecklats korrekt? I de metoder jag sett ser jag följande scenario när metoden användes. För att visa att organisationen blir bättre värderas varje ny sak allt högre. Det införs inflation i uppskattningarna av värdet och på det sättet stiger produktiviteten.
Andra metoder varav den enklast är att räkna antalet rader kod i systemet, bygger på att analysera koden och på det sättet få fram ett värde på produktiviteten. Den första svårigheten är att analysera koden korrekt så att bra kod, vad det nu är, ger mer produktivitet än kod som bara är en massa copy&paste. Om någon lyckas ta fram ett bra värde på hur mycket funktionalitet som producerats uppstår nästa svårighet. Hur vet vi att koden som producerats är den kod vi vill ha, alltså är det kod som ger oss de funktioner vi som produktägare efterlyser. Det kan finnas mycket kod som inte bidrar till användarupplevelsen. Nyligen såg jag ett fall där det var mycket kod och väldigt komplicerade konstruktioner för att hantera ett användargränssnitt, men problemet var att det bara gjorde det svårare att använda. Genom att ta bort mycket kod blev också programmet lättare att använda. Här ser jag följande scenario, utvecklarna anpassar sig successivt till hur koden skall se ut för att få hög produktivitet, samtidigt som kod som inte har högst prioritet men som är enkel att skriva produceras. Riktigt komplicerad kod värderas högt vilket organisationen då automatiskt producerar för att öka sin produktivitet.
Vad innebär då hög produktivitet egentligen för programvaruutveckling? Om vi skall kunna mäta den så måste vi veta vad vi skall mäta. Här ser jag en annan aspekt som också påverkar som inte tas med i de två tidigare försöken ovan. Hur ser egentligen den koden ut som skrivits? Refactoring har blivit ett begrepp inom utveckling och frågan är hur ändringsbar, underhålsbar osv koden är, ofta kallad kodens inre kvalitet. Det känns väsentligt att ställa krav på att vissa värden uppnås här samtidigt som den yttre kvaliteten, alltså hur buggfria funktionerna är och om vi implementerat det som kunden efterfrågar.
Om vi mäter ovanstående för en mängd kod som producerats i ett visst sammanhang kan vi ge den ett värde. Däremot har vi fortfarande svårt att jämföra värdena mellan två helt oberoende program som inte implementerar samma funktionalitet, alltså två team kan inte jämföras med varandra om de inte utvecklar samma funktionalitet vilket oftast inte är fallet inom en organisation. Om dessa mätningar görs kommer troligen de flesta organisationer att jämföra produktiviteten mellan olika team och då får man felaktigt beteende.
Men trots allt skulle vi kunna börja jämföra produktiviteten mellan två team om de får i uppdrag att producera samma funktioner. Det känns dock som ganska bortkastat men kanske kan vara intressant i vissa fall för att utvärdera olika gruppers förmågor osv ur ett forskningsperspektiv, t ex under utbildning kanske man bättre kan bedöma en persons eller grupp av personers förmåga att utveckla mjukvara.
Om man är beställare av programvara och har möjlighet att välja vilket team av utvecklare som skall genomföra uppdraget kan det var idé att fundera vidare. Om vi kan ställa tydliga krav på yttre och inre kvalitet kan vi skicka ut en offertförfrågan till olika företag för att implementera det vi vill ha. Den som ger lägsta budet har kanske då också högsta produktivitet, eller? Dessa upphandlingar är ofta dyra och komplicerade avtalsmässigt och många stridigheter om vad som egentligen sagt och hur förändringar och/eller missförstånd skall hanteras ställer till det. Samtidigt går vi mot ett allt mer agilt behov av utveckling eftersom kravbilden ändrar sig fort och produktägaren måste kunna ta snabba beslut. Då kommer det första avtalet som skrivs visa väldigt lite av den produktivitet som kommer efter den första leveransen. Har företaget bara kommit in som leverantör är det svårt att byta ut det och det som förlorades på första avtalet tas igen på sikt.
Vad vi behöver är flera team som kontinuerligt kan bjuda parallellt på samma uppdrag. Då måste också koden vara ”open source” bland dem som är intresserade och de olika teamen får ta över utefter dess produktivitet som nu bedöms utefter kostnaden för en viss funktion. Frågan är hur genomförbart detta är. Min erfarenhet är att det tar lång tid att sätta sig in i kod som man själv inte skrivit och att hela tiden byta utvecklare kan helt enkelt inte bidra till produktiviteten även om det kanske uppfattas som det men egentligen är det endast en prispress som vi inför och vem vinner på det i längden. Utvecklarna kommer att gå till andra uppdrag eftersom de är mer lönsamma och mer tillfredsställande att jobba med.
Finns det egentligen något sätt att mäta produktivitet på ett vettigt sätt? Kan vi använda en icke optimal metod eller kommer vi då bara få en organisation att jobba mot ett felaktigt mål? Är denna felaktiga styrning bättre eller sämre än att inte mäta produktivitet alls? Kan vi styra mot bättre produktivitet med magkänslan i stället, t ex genom olika metoder för att motivera personalen att skriva bra kod? Hur vet vi att dessa metoder för att motovera personalen är bra. Kanske genom forskning på team som hanteras olika i en tillrättalagd miljö där grupperna tar fram samma funktionalitet? I en sådan forskning skulle även olika kontorsmiljöer jämföras.