Organisaties hebben vaak geen goede methodieken om de bedrijfsresultaten te meten van de software die zij ontwikkelen. Dit stelt advies- en onderzoeksbureau McKinsey in een rapport over het verbeteren van de efficiëntie van applicatieontwikkeling. Het gebruik van use cases, een beschrijving van gedrag van een systeem, is volgens McKinsey de beste manier om de bedrijfsdoelstellingen en de functionele eisen van een applicatie vast te leggen, zonder focus op techniek en in een taal die zowel door het management als ontwikkelaars wordt begrepen.
It speelt een steeds kritischere rol voor organisaties, zowel voor de interne als externe processen. Volgens McKinsey investeren de meeste grote organisaties veel in applicatieontwikkeling om een eenvoudige reden: hun toekomst kan ervan afhangen. Volgens de onderzoeker ontbreekt echter vaak een betrouwbaar middel, zoals het gebruik van use cases, om de bedrijfsresultaten van de opgeleverde functionaliteit te meten.
Blind vliegen
Veel bedrijven meten bij het ontwikkelen van nieuwe bedrijfsapplicaties voor hun organisatie vooral de kosten en inspanningen. Software wordt ontwikkeld op basis van ongestructureerde boodschappenlijstjes, een methode die vaak sterk verankerd is in de organisatie. Welke functionaliteit er door een team wordt opgeleverd in een bepaalde periode wordt nog vaak als moeilijk meetbaar afgedaan. McKinsey waarschuwt voor deze vorm van blind vliegen met een applicatieontwikkelaar, zeker als het onderscheidende vermogen van de organisaties op het spel staat.
De voordelen van de juiste methodieken en systemen zijn groter dan die overhead. De beste oplossing is volgens McKinsey om met use cases te werken. Met deze methode worden de eisen aan applicatieontwikkelingstrajecten vastgelegd in heldere taal en door middel van use case points, opgedeeld in stukken op te leveren functionaliteit. In een use case worden bijvoorbeeld de stappen beschreven die een gebruiker moet doorlopen om in te loggen op een bankapplicatie om zijn saldo te bekijken en wat de applicatie moet doen om de benodigde informatie uit de database te halen.
Toename kosten
Wat een ontwikkelproject oplevert voor een organisatie, wordt volgens McKinsey sterk bepaald door de gebruikte meetmethodiek. Is die afwezig, dan komt de opgeleverde functionaliteit vaak niet overeen met de wensen van de klant. Deze inefficiëntie zorgt er bovendien voor dat de kosten vaak met 30 tot 100 procent toenemen.
Ik begrijp de intentie van het artikel. Ben het er ook mee eens. Alleen de kop en de eerste zin zijn wat ongelukkig verwoord.
“Meet bedrijfsresultaat van (maatwerk)software” en “Organisaties hebben vaak geen goede methodieken om de bedrijfsresultaten te meten van de software die voor hun organisatie wordt ontwikkeld”.
Het lijkt me namelijk niet te gaan om het bedrijfsresultaat van de software-ontwikkelaar maar om het bedrijfsresultaat van de afnemer.
Of vergis ik me daarin?
Aanvullend: ik ben het er dus mee eens dat je meet wat een nieuw informatiesysteem oplevert voor de organisatie. Of dat nou juist via use cases bereikt zou moeten worden, daar heb ik wel mijn vraagtekens bij.
Hallo Machteld, ik denk dat het werken met Use Cases bij softwareontwikkeling twee kanten op werkt. Het idee is dat de ontwikkelaar en de klant samen met een dergelijke methodiek kunnen verwoorden wat de functionele eisen van een applicatie zouden moeten zijn. Dat is heel anders dan puur vanuit de techniek werken. Het komt dan neer op een lange lijst met technische specificaties, die geen directe toegevoegde waarde bieden voor de organisatie. Zeker voor vertegenwoordigers vanuit de business is dat vaak geen werkbare methode. Door de vastgelegde Use Cases op te delen in Use Case Points, kan de opgeleverde functionaliteit van het ontwikkelteam gemeten worden, maar ook de waarde die die elk stuk functionaliteit toevoegt aan de bedrijfsdoelstellingen. Wij werken als softwareontwikkelaar met User Stories, een iets modernere en minder bewerkelijke methode, die beter aansluit op agile-ontwikkelen.