De belangrijkste les over softwareontwikkeling

Gepubliceerd op 2023-09-02 door William Visterin

Een gebruiksgerichte benadering van eisen en ontwerp voldoet beter aan de behoeften van de klant dan een feature-gerichte benadering. Begrip van gebruikers is de sleutel tot succes. Dat stelt Karl Wiegers, een Amerikaanse engineer, consultant en trainer op het gebied van softwareontwikkeling, en auteur van een tiental boeken over software.

Dit artikel verscheen oorspronkelijk in SAI Update 13, het digitaal magazine van SAI. Leden van SAI kunnen het magazine integraal lezen.

Er zijn verschillende problemen met een feature- of productgerichte benadering van het opstellen van requirements. “Gebruikers vragen stellen als ‘Wat wil je?’ of ‘wat wil je dat het systeem doet?’ opent de deur voor een stroom van willekeurige informatie die moeilijk om te zetten is in een bevredigende oplossing”, oppert Wiegers. Focussen op functies kan ertoe leiden dat het team functionaliteit toepast waarmee gebruikers niet alle dingen kunnen doen die ze moeten doen.
Wiegers vertelt op LinkedIn het verhaal van een van zijn klanten die een dag lang een workshop hield met ongeveer zestig deelnemers om ideeën te verzamelen voor een groot nieuw commercieel product. Ze bundelden de output van hun zes subgroepen en noemden het een eisenspecificatie. “Maar dat was het niet. Het was een allegaartje van functies, gebruikerstaken, gegevensitems en andere soms vreemde informatie. Simpelweg aan mensen vragen om te brainstormen over wat ze in het nieuwe product wilden zien, leverde geen bruikbare kennis van eisen op.”

Overbodige functies

Een featuregerichte aanpak kan leiden tot functionaliteit die ongebruikt blijft, ook al lijkt dat op dat moment een goed idee. Uit onderzoek van The Standish Group enkele jaren geleden blijkt dat 50 tot 80 procent van de softwarefuncties zelden of nooit gebruikt, waardoor ze weinig bedrijfswaarde bieden. De analyse rond requirements richten op features draagt volgens Wiegers bij aan deze proliferatie van slapende functionaliteit.

Op zich zit het probleem natuurlijk ook fundamenteler: softwareprojecten vereisen een duidelijke consensus van de gehele groep van stakeholders over de definitie van het bedrijfsprobleem en een robuuste uitvoeringsstrategie om software op te leveren die de bedrijfsdoelstellingen oplost. Een veel voorkomende reden waarom softwareontwikkelingsprojecten mislukken, is dat projectsponsors en -teams niet duidelijk op één lijn zitten qua de topprioriteiten, stelt Christiane Vandepitte, consultant, business analist, software designer en auteur van het boek Informatiseren zonder omwegen. Deze prioriteiten opdelen in must-haves, should-haves en could-haves kan bijvoorbeeld een houvast bieden voor de oplevering van bepaalde onderdelen.

Hoe moet het beter voor gebruikers?

Ook de gebruikers zelf zijn niet altijd duidelijk of missen houvast. Wiegers raadt businessanalisten alvast aan om de gesprekken over eisen te verleggen van het product zelf naar wat gebruikers met het product moeten doen. “We verleggen de nadruk van functionaliteit naar gebruik, van de oplossing naar de behoefte. Een gebruiksgerichte strategie helpt de analist en het ontwikkelingsteam om snel de context en de doelstellingen van de gebruiker te begrijpen. Vanuit die kennis kan men beter bepalen welke mogelijkheden en kenmerken een oplossing moet hebben, voor wie, waarom en wanneer.”

Gebruiksgerichte exploratie houdt een kleine, maar significante, verschuiving in van de vragen die een analist zou kunnen stellen. In plaats van te vragen ‘wat wil je?’ of ‘wat wil je dat de oplossing doet?’ vraagt de analist beter ‘wat moet je doen met de oplossing?’. De antwoorden hierop identificeren taken of doelen die de gebruikers moeten bereiken met behulp van de oplossing.

De kracht van use cases

Het idee erachter is duidelijk: gebruikers starten een app niet om een bepaalde functie te gebruiken, wel om een doel te bereiken. “Telkens wanneer ik mijn zakelijke boekhoudsoftware open, heb ik een bepaald doel voor ogen. Misschien wil ik een factuur maken, een ontvangen klantbetaling registreren, mijn creditcard reconciliëren of een rekening betalen”, stelt Wiegers.

“Elk van die doelen is een use case, een geval van gebruik. Use cases zijn een natuurlijke manier voor gebruikers om na te denken over hun behoeften. Ze bieden een gestructureerde manier om beschrijvingen van gerelateerde functionaliteit te organiseren. Sommige use cases zullen vaker en door meer mensen worden gebruikt. Binnen één use case heeft de normale stroom de hoogste prioriteit, samen met de bijbehorende uitzonderingen. De alternatieve flows hebben een lagere prioriteit en kunnen vaak later, of misschien wel nooit, worden geïmplementeerd”, stelt hij.

“Het is moeilijk voor gebruikers om de juiste functionaliteit voor een product te omschrijven, maar gemakkelijk om te praten over gebruiksscenario’s uit hun dagelijks leven.” Voor Karl Wiegers is het een van de belangrijkste lessen over softwareontwikkeling. Zo niet de belangrijkste.