Alles wat u moet weten over het meten van de productiviteit van ontwikkelaars

Wat is de indicator die de efficiëntie van het softwareontwikkelingsteam bepaalt? Het zouden de prestatiecijfers van een team en van elke ontwikkelaar afzonderlijk kunnen zijn, als we die nauwkeurig meten. En dat zouden we moeten doen. De productiviteit van ontwikkelaars is van invloed op de kwaliteit van de gecreëerde digitale oplossing en de snelheid waarmee die op de markt komt. Als u IT-taken uitbesteedt, dan is het ook belangrijk om het succes van de dienstverlener voor softwareontwikkeling te controleren. Dus wat is ontwikkelaarsproductiviteit, en waarom besteedt de IT-gemeenschap zoveel aandacht aan dit onderwerp?

De productiviteit van een IT-team bestaat uit drie aspecten:

1 — in de kortst mogelijke tijd software van hoge kwaliteit maken,

2 — streef naar een zero-bug-product,

3 — gemakkelijk schaalbaar en onderhoudbaar zijn.

Het is eenvoudig te begrijpen, maar lijkt onmogelijk te meten, toch?

Laten we eens kijken hoe realistisch het is om een objectieve beoordeling te krijgen van de efficiëntie van een IT-ingenieur. We zullen bespreken welke metrieken daarvoor gebruikt moeten worden en wat een bedrijf dat aandacht besteedt aan zulk nauwgezet werk zal bereiken.

# Het meten van de productiviteit van ontwikkelaars: werkelijkheid of mythe?

In de huidige IT-omgeving is er een stevig debat gaande over hoe realistisch het is om deze metriek objectief te beoordelen. Sommige deskundigen menen dat dit onmogelijk is omdat elke metriek slechts benaderende resultaten toelaat die de analyse eerder vertekenen dan helpen. Sommige deskundigen verzekeren dat er geen manier is om de prestaties redelijk te meten. Anderen hebben een tegenovergesteld standpunt.

Volgens de resultaten van de Software Developer Productivity Survey gelooft meer dan 89% van de ontwikkelaars dat er weinig effectieve manieren zijn om de productiviteit te meten. Bovendien - 91% van de specialisten zou liever de resultaten van hun eigen werk meten... op de een of andere manier.

# Mogelijke belemmeringen bij het meten van de productiviteit van de technische teams

De eerste taak waar een bedrijf mee te maken krijgt bij het meten van de productiviteit van IT-ers is de keuze van de metriek. Het is zeker de moeite waard hier aandacht aan te besteden. Als dit stadium echter achterblijft, kan een manager te maken krijgen met deze drie uitdagingen:

1.Gebrek aan objectiviteit. Sommige statistieken, zoals het aantal geschreven coderegels, kunnen de productiviteit van de ingenieurs niet objectief weergeven. De hoeveelheid verricht werk betekent immers niet altijd dat de kwaliteit ervan hoog is.

2.Geen duidelijk verband tussen de indicator en het financiële voordeel. Het is het gemakkelijkst om de productiviteit te evalueren als er een duidelijk verband is tussen de metriek en de omzetgroei van het bedrijf. Het is duidelijk dat de fouttolerantie van de software en de zero-bug-status helpen om geld te besparen op het repareren ervan, de loyaliteit van de gebruiker te vergroten, en daardoor de winst van het bedrijf te verhogen. Maar dit is slechts het eindresultaat. Het proces dat daartoe geleid heeft hangt meestal af van de communicatie tussen medewerkers. Het heeft geen directe invloed op de financiën. Daarom is het beoordelen van de kwaliteit van de communicatie binnen het team uiterst moeilijk, maar ook deze indicator is essentieel.

Volgens de resultaten van een onderzoek van het adviesbureau Gartner is het optimaal dat 56% van de indicatoren betrekking heeft op de bedrijfsresultaten van het team. Dat wil zeggen, ze moeten de toename van de inkomsten, het rendement op investeringen en de uitvoering van de bedrijfsstrategie van het bedrijf weergeven.

3.Tegenstrijdigheid in sommige statistieken. Als u wilt dat het team snel werkt, wees er dan op voorbereid dat de productkwaliteit eronder kan lijden. Als u wilt dat de ontwikkelaars zo min mogelijk softwarefouten maken, stel dan geen onrealistische deadlines. De wens om snelheid en kwaliteit te combineren is begrijpelijk, maar het moet wel haalbaar zijn. Luister naar uw CTO of tech partner als zij zeggen dat de taak niet uitvoerbaar is.

Als u de mogelijke moeilijkheden bij de evaluatie van de prestaties van IT-ingenieurs kent, kunt u zich van tevoren voorbereiden om ze te overwinnen en in de kortst mogelijke tijd een digitale oplossing van hoge kwaliteit te creëren.

# Waarom heeft u een systeem van metrieken nodig om prestaties te evalueren

Het meten van de productiviteit van ontwikkelaars stelt ons in staat te begrijpen wat en hoe het proces van het maken van een softwareproduct wordt beïnvloed. Als gevolg van het verkrijgen van dergelijke informatie is het mogelijk om elk van de metrieken te beïnvloeden om de productiviteit van het team te verhogen, de kwaliteit van de geleverde software te verbeteren, en de snelheid van het uitbrengen ervan te verminderen. Door de nodige aandacht te besteden aan gedetailleerd onderzoek binnen het team, verkrijgt de bedrijfsleiding de volgende voordelen:

# Effectieve planning van de workflow

Met een gedetailleerde analyse van de activiteiten van het ontwikkelingsteam kunt u het project evalueren in termen van:

• financiën: bereken hoeveel elke ontwikkelingsfase (ontwerp, ontwikkeling zelf, testen, enz.) kost en optimaliseer de kosten;
• tijd: analyseer hoeveel tijd het kost om dezelfde hoeveelheid hoogwaardige code te schrijven met behulp van verschillende tech stacks of methodieken, en implementeer de optimale variant;
• kwaliteit: controleer de kwaliteit van de digitale oplossing en gebruik nieuwe technologieën om die te verbeteren.

Met een grondige analyse van het team kunt u de uitvoering van het project plannen, rekening houdend met de kenmerken en complexiteiten ervan.

# De productiviteit van het team verhogen

Duidelijk gedefinieerde maatstaven stellen ontwikkelaars in staat te begrijpen wat er van hen verwacht wordt en voortdurend te werken aan betere resultaten. En de manager kan teamproblemen opsporen en werken aan het overwinnen van uitdagingen om de prestaties te verbeteren.

# Verbetering van het softwareproduct

Dit voordeel is een direct gevolg van de vorige twee punten. Effectieve workflowplanning en verhoogde productiviteit van uw ontwikkelaars zullen helpen het hoofddoel van elk team te bereiken - het uitbrengen van kwaliteitssoftware binnen het budget en zonder de deadlines te schenden.

# Hoe kies u de juiste KPI's?

Er zijn enkele universele aanbevelingen voor het kiezen van metrieken om de productiviteit van programmeurs te meten. Sommige deskundigen adviseren bijvoorbeeld de SMART-methode te gebruiken. Deze staat voor:

• Specifiek: bepaalde indicatoren bereiken en meten gaat gemakkelijker als ze duidelijk en concreet geformuleerd zijn;
• Meetbaar: het is beter om KPI's te kiezen die u objectief kunt meten (bijv. tijd om een taak te voltooien, aantal defecten in de software, etc.);
• Haalbaar: eis niet dat het team in een week een app van hoge kwaliteit maakt; het is beter om een realistische deadline te stellen, dan zal de kwaliteit er niet onder lijden;
• Realistisch: het is belangrijk om aandacht te besteden aan de haalbaarheid van de indicator, niet alleen aan de haalbaarheid ervan. Het team kan misschien de deadline halen door 24 uur per dag en 7 dagen per week te werken. Maar is het realistisch, en is het echt nodig?
• Tijdgebonden: het is noodzakelijk om voor elke taak op het project een duidelijke deadline te stellen. Zonder deze voorwaarde is het onmogelijk om hun productiviteit te meten, omdat het onduidelijk zal zijn of het team ten volle werkt.

Als u de indicatoren hebt geselecteerd waarin u geïnteresseerd bent, bepaal dan welke geschikt zijn om de productiviteit van het hele team te meten en welke beter de prestaties van individuele medewerkers laten zien. Er is een mening dat het niet redelijk is om het werk van elke ontwikkelaar te evalueren, omdat het succes van het project wordt beïnvloed door het hele team. Deze mening zou geldig zijn in een ideale wereld, maar in werkelijkheid kunt u zonder elke IT-ingenieur te evalueren niet begrijpen wat het probleem van het team is als er iets fout gaat.

# Metrieken om de effectiviteit van ontwikkelaars te bepalen

De meest duidelijke metrics die u kunt meten zijn:

• aantal regels code,
• werktijden,
• aantal herstelde bugs
• aantal voltooide taken.

Hoewel deskundigen aanvoeren dat alleen op deze statistieken vertrouwen inefficiënt is vanwege de volgende.

# Regels code

Veel regels code kunnen de kwaliteit van het eindproduct niet garanderen. Integendeel, haast bij de ontwikkeling leidt meestal tot slechte kwaliteit van de code en problemen later.

# Werktijden

Vaak werken de beste programmeurs sneller, wat niet tot uiting komt in de productkwaliteit. Tegelijkertijd kan de wens om de index te verhogen specialisten aanzetten tot overwerk. Dit kan het tegenovergestelde effect veroorzaken - een afname van de productiviteit door professionele burn-out en vermoeidheid.

# Aantal herstelde bugs

Ook hier wordt niet ingezet op kwaliteit maar op kwantiteit. Het gebruik van zo'n indicator kan leiden tot het negeren van complexe defecten, die veel tijd kosten om te repareren. Dit heeft uiteraard invloed op de kwaliteit van de code.

# Voltooide taken

Alle taken op een project verschillen in hun complexiteit, de moeite die het kost, de mate van belangrijkheid, en de tijd die het kost om ze te voltooien. Het zou oneerlijk zijn om te zeggen dat een specialist die vijf eenvoudige taken afwerkt productiever is dan een IT-ingenieur die een hele dag bezig is met het implementeren van één lastige functie.

Deze vier indicatoren zijn gemakkelijk te meten, maar ze moeten in combinatie worden gebruikt. Elk van hen afzonderlijk zal niet het juiste voordeel opleveren voor uw team, en soms kunnen ze zelfs schadelijk zijn en een verkeerde indruk vormen over het werk van programmeurs.

# KPI's voor het meten van de teamproductiviteit

Elk team moet metrieken kiezen afhankelijk van de doelen en bijzonderheden van hun project. Hieronder presenteren we een lijst van te meten meetgegevens in algemene situaties.

# Codekwaliteit en bugs

Volgens de statistieken besteden ontwikkelaars gemiddeld 20% van hun werktijd aan het repareren van bugs. Dus hoe meer bugs in de broncode, hoe minder efficiënt het team is. Dit maakt dat managers de kwaliteit/defecten-metriek bovenaan het belang van meten zetten.

# Teamsnelheid

Naast de kwaliteit van het uitgebrachte product is het belangrijk om de tijd te meten die nodig is om het te ontwikkelen. Deze metriek wordt veel gebruikt in teams die de Agile-methode beoefenen; zo evalueren projectmanagers de hoeveelheid werk die tijdens één sprint is verricht. De resultaten zijn nuttig voor het plannen van verder werk en het voorspellen van de resultaten daarvan.

Let op: Het is niet redelijk om de prestaties van verschillende teams te vergelijken op basis van deze metriek, omdat hun taken kunnen verschillen in complexiteit, en het resultaat van de vergelijking vertekend zal zijn.

# Burndown

Deze metriek toont de voortgang van het Agile team tijdens de sprint. Bewaak de verhouding tussen voltooide en resterende taken met de Sprint Burndown Chart. Deze grafiek is speciaal gemaakt voor Scrum en is ontworpen om de huidige status van het project duidelijk te laten zien.

# Cyclustijd

Deze metriek toont de mate van flexibiliteit van uw team en de bereidheid tot verandering. Met andere woorden, met deze metriek kunt u bepalen hoeveel tijd ontwikkelaars nodig hebben om wijzigingen in het project aan te brengen.

# MTBF en MTTR: gemiddelde tijd tussen storingen en gemiddelde hersteltijd

De metrieken laten zien hoe lang de gemaakte software kan werken tussen storingen, of hoe vaak deze storingen voorkomen, en hoe lang het team de problemen oplost.

We hebben deze maatstaven samengevoegd omdat de deskundigen van vandaag het onpraktisch vinden om ze afzonderlijk te gebruiken. Bovendien is het beter om ze samen met andere statistieken te meten om een nauwkeuriger beeld te krijgen van de productiviteit van het IT-team.

# Defecten geopend en gesloten

We zouden het aantal defecten dat op het project is gemeld en de defecten die zijn gesloten in de gaten moeten houden. Dit helpt niet alleen bij het meten van de prestaties van de ontwikkelaars, maar zorgt er ook voor dat er geen bugs over het hoofd worden gezien. Per slot van rekening kost het repareren ervan na de release 100 keer meer dan in de beginfase van de ontwikkeling.

# Frequentie van inzetten/vrijgeven

De metriek helpt bijhouden hoe vaak het team code uitzet of vrijgeeft naar de productieomgeving. Teams kunnen continuous deployment instellen om de resultaten te verbeteren en de metriek meer dan één of zelfs twee keer per dag te halen. Dit zal hun duidelijk voordeel zijn als ze kunnen werken aan projecten die frequentere releases vereisen.

# Doorvoer

Deze metriek is een meer gedetailleerde analogie van de "Team Snelheid" indicator. Hij toont ook de hoeveelheid werk die in een bepaalde periode is verricht, maar dan in termen van specifieke functies, taken, fouten enz. Met deze KPI kan de projectmanager begrijpen waar de tijd tijdens de iteratie werd verspild en het vervolgwerk plannen.

# WIP — werk-in-uitvoering

In tegenstelling tot de throughput, die de prestaties van een team in het verleden meet, wordt deze metriek gebruikt om de huidige prestaties te meten.

# Communicatie-index

Dit hulpmiddel voor het meten van de productiviteit van ontwikkelaars helpt de projectmanager te bepalen hoe goed de communicatie binnen het team verloopt. Dit is vooral relevant als ontwikkelaars van derden in het team aan een uitbestedingsmodel werken, en ook voor verschillende teams die bij hetzelfde project betrokken zijn. Hier is het belangrijk om de Engelse taalvaardigheid, cultuurverschillen, tijdsverschillen en communicatievaardigheden te beoordelen. Als een van deze parameters op een laag niveau blijkt te staan, kan bij problemen met de code worden aangenomen dat dit de oorzaak is.

# Beveiligingsreacties

Deze indicator wordt gebruikt om de effectiviteit van het ontwikkelingsteam op het gebied van beveiliging te evalueren, omdat het de winstgevendheid van het IT-project en de vraag naar de app in de markt bepaalt. De weerbaarheid van software tegen cyberbedreigingen is een belangrijk onderdeel van de kwaliteit ervan. Immers, volgens de statistieken is het niveau van cybercriminaliteit sinds het begin van de wereldwijde pandemie met 600% gestegen.

# Tevredenheid van de eindgebruiker

U kunt verschillende kanalen gebruiken om deze indicator te meten, waaronder gespecialiseerde tools (NPS, CES, en CSAT), maar ook consumentenfeedback in app stores (voor mobiele ontwikkeling), reviewsites, en thematische fora. Als de beoordeling van een softwareproduct hoog is, kan u concluderen dat het team productief werkt en voordelen oplevert voor het bedrijf.

Naast deze metrieken moet de projectmanager ook de algemene processen binnen het team in de gaten houden:

1. Hoe betrokken zijn ontwikkelaars tijdens retrospectives en andere bijeenkomsten?
2. Melden IT-ingenieurs opkomende problemen?
3. Hoe hoog is de motivatie van het team, en is er een neiging tot burn-out?

Die aandacht voor details zal de manager in staat stellen om tijdig problemen in het team op te merken en ze onmiddellijk weg te werken om het uiteindelijke doel van het project te bereiken.

# Methoden om de effectiviteit van ontwikkelaars te meten

Om de productiviteit van werknemers in IT-bedrijven te meten, wordt vaak gebruik gemaakt van methoden die in de praktijk hun doeltreffendheid hebben bewezen. Ze maken het mogelijk de nodige meeteenheden en hun combinaties te selecteren, en de verkregen resultaten correct te interpreteren. Tot de bekendste methoden behoren SPACE en OKR, maar veel bekende bedrijven gebruiken ook andere methoden.

# TPАCE

Dit kader is gemaakt met inachtneming van het feit dat het onmogelijk is om de productiviteit van ontwikkelaars te meten met één enkele metriek. Om objectieve resultaten te verkrijgen stellen de ontwikkelaars van het platform voor om het werk van IT-ingenieurs in een complex te evalueren, namelijk:

1. Tevredenheid van specialisten. Werknemers die zich moreel tevreden voelen met hun werk zijn productiever en minder vatbaar voor professionele burn-out en vermoeidheid. Daarom stellen de makers van SPACE voor om de emotionele toestand van ontwikkelaars, hun beschikbaarheid van noodzakelijke hulpmiddelen voor het werk en het niveau van de werkbelasting van elke specialist voortdurend in de gaten te houden.
2. Prestaties van het team als geheel, niet alleen van individuele werknemers. De auteurs van het platform menen dat het ingewikkeld is om de bijdrage van een individuele programmeur aan een project te evalueren. Immers, een hoge snelheid van werken kan een lage kwaliteit van de code betekenen, de waarde van het product kan niet alleen liggen in de afwezigheid van defecten, en veel voltooide taken kunnen wijzen op hun gemak.
3. WerknemersActiviteit. Hoewel het moeilijk is om de prestaties van IT-technici te kwantificeren, zijn sommige metrieken toch meetbaar. Ze kunnen belangrijke informatie opleveren in combinatie met andere metrieken. Het kan gaan om het aantal pull requests, samenstellingen in CI/CD, testdekking, gedetecteerde defecten, en meer
4. Communicatie binnen het team. We hebben het al gehad over zo'n metriek als de communicatie-index. Deze metriek wordt ook gemeten in SPACE.
5. Effectiviteit en doorstroming. Met deze metriek kunt u bepalen hoe gereed het team is om een bepaalde actie af te ronden, met zo min mogelijk stilstand en vertraging. Om deze metriek te beoordelen meten we de tijd van onderbrekingen in het werk, het vermogen van het team om wat ze begonnen zijn tot voltooiing te brengen, enz.

Let op: U moet niet te veel metrieken opnemen in uw lijst met prestatiemetingen. Dit kan ontwikkelaars de indruk geven van een onmogelijke taak, waardoor hun productiviteit kan afnemen.

# OKR

OKR staat voor Objectives and Key Results en is een methode die veel gebruikt wordt in projectmanagement om strakke controle te houden over de vervulling van toegewezen taken. Het is gericht op het meten van de productiviteit van de ontwikkelaars op basis van een reeks metrieken die elke organisatie voor zichzelf kan definiëren. Het kan gaan om de frequentie of het aantal codecontroles, het aantal commits, en andere.

Het is vermeldenswaard dat de methode niet altijd voldoende informatie geeft om de effectiviteit van het hele team te evalueren, maar het stelt u wel in staat om verschillende IT-ers te vergelijken.

# Ervaring van bekende bedrijven

Elk bedrijf kan een hulpmiddel kiezen om de productiviteit van ontwikkelaars bij te houden op basis van individuele behoeften en doelen. Bekijk welke wereldberoemde bedrijven niet nalaten de productiviteit van hun IT-ingenieurs te meten.

1. Uber creëerde Eng Metrics tool

Onlangs introduceerde Uber een IT-productiviteitsmeetinstrument genaamd Eng Metrics Dashboard in hun workflows. Dit dashboard helpt de productiviteit te meten op basis van pull requests, code checks en concentratietijd per engineer.

2. Google heeft het GSM-kader geïmplementeerd

Google heeft een speciaal team van onderzoekers samengesteld om de prestaties van ontwikkelaars te meten, dat bestaat uit sociale wetenschappers en software-ingenieurs. Aan het begin van het werk kiezen ze welke metrieken geschikt zijn om te meten met behulp van het GSM-raamwerk: Doelen/Signalen/Metrieken. Dat wil zeggen, ze bepalen:

• Het doel dat ze moeten bereiken.
• Het signaal waaruit zal blijken dat het doel bereikt is.
• Metrics die helpen die doelen te bereiken.

3. Samsung, eBay, Nestle, Spotify kozen voor de tool Jellyfish

Ja, al deze wereldberoemde bedrijven gebruiken één hulpmiddel bij hun projectbeheer: Jellyfish. Het platform wil het digitaliseringsproces vereenvoudigen voor bedrijven die dit als hun prioritair ontwikkelingsgebied hebben aangewezen. Het biedt productiviteitsmeters (waaronder DevOps Metrics), adviesdiensten en trainingsprogramma's om bedrijfsdoelen zo snel mogelijk te bereiken.