De aanleiding kwam deze week uit het nieuws: in het publieke bestel kan kwaliteit onder druk komen te staan als er te veel koershouders tegelijk aan het stuur zitten. Niet als bewijs dat softwareteams in dezelfde situatie zitten, wel als herkenbare observatie. Zodra eigenaarschap diffuus wordt, verandert kwaliteit al snel van iets concreets in iets waar iedereen een gevoel bij heeft.
In software gebeurt dat meestal zonder groot moment.
Niet in een crisisoverleg, maar in kleine verschuivingen. Een roadmap die sneller beweegt dan de afspraken eromheen. Een Slack-thread waarin drie definities van “goed genoeg” door elkaar lopen. Een release note die optimistisch klinkt, terwijl supportvragen iets anders laten zien. Een demoaanvraag die veel enthousiasme oproept, maar ook nieuwe spanning op performance of veranderbaarheid legt.
Dan is kwaliteit er nog steeds. Alleen niet meer scherp genoeg om samen op te sturen.
Kwaliteit wordt vaag zodra niemand het klein maakt
Veel leiders voelen vrij goed wanneer kwaliteit belangrijker begint te worden in een product. Alleen is dat gevoel niet altijd genoeg om een proportionele beslissing op te baseren.
Dat is vaak het lastige midden.
Je hoeft niet meteen een groot traject op te starten. Je wilt ook niet doen alsof er niets aan de hand is. Er zit iets tussenin: een kleine, toetsbare manier om kwaliteit zichtbaar te maken voordat het gesprek verzandt in voorkeuren, aannames of tooldiscussies.
Precies daar gaat het in de praktijk vaak mis. Niet omdat teams kwaliteit onbelangrijk vinden, maar omdat kwaliteit als woord te breed is geworden.
De één bedoelt betrouwbaarheid. De ander bedoelt snelheid van leveren. Een derde bedoelt dat nieuwe mensen het systeem nog moeten kunnen begrijpen.
Allemaal legitiem. Maar als die betekenissen door elkaar lopen, krijg je geen eigenaarschap. Dan krijg je interpretatie.
En interpretatie helpt zelden als je wilt besluiten wat nu de volgende verstandige stap is.
ISO 25010 is vooral nuttig als het het gesprek kleiner maakt
ISO 25010 klinkt voor veel teams zwaarder dan het hoeft te zijn. In de praktijk is het vooral bruikbaar als taal om kwaliteit op te delen in eigenschappen die je apart kunt bekijken.
Niet “is de software van goede kwaliteit?”
Maar bijvoorbeeld:
- is ze betrouwbaar genoeg voor dit gebruik,
- veranderbaar genoeg voor deze roadmap,
- functioneel passend genoeg voor deze klantvraag,
- of efficiënt genoeg onder deze belasting?
Dat lijkt een klein verschil, maar het verandert het gesprek behoorlijk.
Want zodra je kwaliteit niet meer als algemeen oordeel behandelt, ontstaat er ruimte voor iets veel rustigers: kijken welke eigenschap op dit moment het meest helpt om beter te beslissen.
Dat hoeft niet groot te zijn.
Soms is één signaal al genoeg. Bijvoorbeeld dat incidenten niet zozeer toenemen, maar langer onduidelijk blijven. Of dat een kleine wijziging telkens meer afstemming vraagt dan verwacht. Of dat een feature in demos goed werkt, maar in productie opvallend veel uitzonderingen vraagt.
Dat soort signalen zijn zelden spectaculair. Maar juist daarom zijn ze bruikbaar. Ze maken zichtbaar wat eerder alleen als onderbuikgevoel aanwezig was.
Begin niet met een breed oordeel, maar met één bewijsstuk
Veel kwaliteitsgesprekken worden onnodig zwaar geopend.
Er komt een breed onderzoek. Een lang wensenlijstje. Een dashboard met alles tegelijk. Of een tool die belooft overzicht te brengen, terwijl de echte vraag nog niet scherp is.
Dat is begrijpelijk. Als kwaliteit belangrijk voelt, is de reflex vaak om het volledig te willen vangen.
Alleen helpt volledig niet altijd. Zeker niet aan het begin.
Een sterkere eerste stap is vaak kleiner: kies één kwaliteitseigenschap waarvan je vermoedt dat die schuift, en zoek daar één bewijsstuk bij dat je samen kunt beoordelen.
Niet om de hele organisatie te overtuigen. Niet om een definitief oordeel te vellen. Maar om een volgende beslissing proportioneel te maken.
Denk aan vragen als:
- Waar merken we als eerste dat betrouwbaarheid begint te schuiven?
- Bij welk type wijziging wordt veranderbaarheid ineens duurder dan verwacht?
- In welk moment zie je dat functionele geschiktheid onder druk komt: tijdens onboarding, support of verlenging?
- Welke performancevraag komt steeds terug, zonder dat iemand hem echt bezit?
Zo’n signaal werkt pas echt goed als er ook een eigenaar en een besliscontext aan vastzitten.
Dus niet alleen: “we zien iets.” Maar ook: “wie kijkt hiernaar, en welke beslissing kan dit ondersteunen?”
Dan wordt kwaliteit geen abstract thema, maar een praktisch instrument voor sturing.
Een klein signaal geeft rust, omdat het het gesprek eerlijker maakt
Er zit nog een voordeel aan deze aanpak dat vaak onderschat wordt: een klein signaal verlaagt de sociale druk in het gesprek.
Zodra kwaliteit groot en vaag blijft, komen teams sneller in posities terecht. Engineering verdedigt technische ruimte. Product verdedigt tempo. Sales verdedigt marktvragen. Leadership probeert overzicht te houden.
Dat zijn geen verkeerde reflexen. Ze horen bij groei.
Maar ze maken het moeilijker om samen te zien wat er feitelijk gebeurt.
Een klein, toetsbaar signaal helpt omdat het minder vraagt.
Geen volledig gelijk. Geen groot veranderprogramma. Geen schuldige.
Alleen genoeg helderheid om te kunnen zeggen: dit zien we, dit betekent het waarschijnlijk, en dit is een passende vervolgstap.
Dat maakt eigenaarschap lichter in plaats van zwaarder.
En vaak ook eerlijker.
Want soms blijkt dat een gevoel over kwaliteit klopt. Soms ook niet. Beide uitkomsten zijn nuttig, zolang je snel genoeg van gevoel naar zicht gaat.
De eerste goede stap is meestal kleiner dan je denkt
Voor softwareleiders is dat misschien wel de meest bruikbare gedachte: kwaliteit hoeft niet eerst volledig gemodelleerd te worden om er beter op te kunnen sturen.
Je hoeft niet te wachten tot alles meetbaar is. Je hoeft ook niet meteen een breed kwaliteitsprogramma op te tuigen.
Vaak is de eerste volwassen stap veel eenvoudiger:
kies één eigenschap, maak één signaal zichtbaar, koppel daar één eigenaar aan, en gebruik dat voor één beslissing.
Dat klinkt bescheiden, maar het doet iets belangrijks. Het haalt kwaliteit uit de sfeer van losse meningen en brengt het terug naar observeerbaar gedrag.
En precies daar ontstaat meestal voortgang.
Welke kwaliteitseigenschap wil jij in je product het liefst eerder zien schuiven dan voelen — betrouwbaarheid, veranderbaarheid, performance efficiency of iets anders?