De illusie van kwaliteitsdenken in softwareontwikkeling

Auteur: Rob van Steenbergen

We zeggen vaak dat we kwaliteit belangrijk vinden in softwareontwikkeling.

Maar wat bedoelen we dan eigenlijk?

• "Security is belangrijk"
• "Het moet snel zijn"
• "Gebruikersgemak is topprioriteit”

En hoewel ze klinken als kwaliteitsdoelen, zijn het vaak niet meer dan vage intenties. Ik bedoel hiermee dat er zelden een gestructureerde uitwerking wordt gedaan over wat kwaliteit werkelijk betekent voor het product dat we aan het bouwen zijn.

Zonder een concrete discussie en gesprek over kwaliteit bouwen we vooral problemen in. Wat er vaak op neerkomt dat we in productie “issues aan het fixen” zijn, terwijl we zelf vinden dat we aan kwaliteitsverbetering bezig zijn op dat moment.

 

Denk er eens over na:

• Als je zegt “security”, bedoel je dan bescherming tegen hackers van buitenaf? Of goede toegangscontrole binnen de organisatie?
• Als je zegt “performance”, gaat het dan om hoeveel gebruikers tegelijk actief kunnen zijn? Of om het verwerken van grote hoeveelheden data?
• Als je zegt “usability”, bedoel je dan dat het intuïtief in gebruik moet zijn, of dat het ook toegankelijk moet zijn voor mensen met beperkingen?

 

We zullen hier vanaf het uitwerken van een idee scherp  op moeten zijn .  Anders lopen we het risico dat iedereen er iets anders onder verstaat. We zijn dan misschien wel het verkeerde aan het testen en maken we iets wat niet voldoet aan wat echt nodig was.

"Je kunt kwaliteit niet inbouwen als het product al live is — op dat moment ben je niet bezig met kwaliteitsverbetering, maar ben je “issues aan het fixen”

 

Dus wat moeten we wél doen?

Begin met praten over kwaliteit — op een gestructureerde manier.

Gebruik een internationale norm zoals  het ISO 25010:2023 kwaliteitsmodel, dat kwaliteit opdeelt in 40 concrete attributen verdeeld over negen categorieën.

Pak die lijst er eens bij met je team en bespreek per attribuut:

• Is dit relevant voor ons product?
• En wie is er verantwoordelijk voor? Is de juiste persoon verantwoordelijk? Ben jij dat? Je team? Een andere afdeling? Een product owner of projectmanager?

Sommige attributen lijken misschien niet zo belangrijk in bepaalde contexten — en dat is prima.  Maar je bent in elk geval begonnen met het gesprek. Je maakt van kwaliteit iets concreets met een gezamelijke inzicht  in plaats van iets vaags of impliciets.

 

En bezoek die lijst later opnieuw.

Gebruik de lijst in een refinement of brainstormsessie. Na verloop van tijd raakt het hele team vertrouwd met wat begrippen als “usability”, “functionality” of “safety” echt betekenen binnen jullie context.

Als iedereen een gedeeld beeld heeft van wat belangrijk is op kwaliteitsniveau, ben je écht bezig met het inbouwen van kwaliteit, in plaats van achteraf fouten te fixen in een fase die we dan “verbetering” noemen.

Want wanneer kwaliteit:

• een gedeelde taal is,
• een gedeelde verantwoordelijkheid wordt,
• en een gedeelde zorg is…

Dan ben je in plaats van een illusie van kwaliteit te creëren, kwaliteit aan het inbouwen.

Naar het overzicht