Er is een ongemakkelijk moment dat veel softwareleiders herkennen.
Op papier lijkt iets klaar. De planning is gehaald. Er is vakmanschap ingestopt. De woorden voelen stevig: stabiel, schaalbaar, production-ready, onderhoudbaar.
En toch begint de twijfel vaak pas ná de oplevering. Niet als groot drama, maar in kleine signalen. Een supportvraag die net te vaak terugkomt. Een release die onverwacht veel componenten raakt. Een Slack-thread waarin drie mensen tegelijk proberen uit te leggen waarom een eenvoudige wijziging toch ingewikkeld werd.
Dat moment is interessant, omdat het zelden over onwil gaat. Meestal hebben slimme mensen oprecht geprobeerd iets goed neer te zetten. Alleen was het kwaliteitsdoel te groot geformuleerd om onderweg echt te toetsen.
Grote kwaliteitswoorden geven rust, tot de werkelijkheid terugpraat
Veel teams spreken over kwaliteit alsof het een algemene staat is. Iets wat je “op orde” hebt of juist “moet verbeteren”. Dat klinkt logisch, maar in de praktijk helpt het vaak te weinig bij besluiten.
Want wat bedoelen we precies?
Bedoelen we dat een kernflow betrouwbaar blijft onder piekbelasting? Dat wijzigingen lokaal blijven en niet als verfspatten door het hele systeem trekken? Dat responstijden voorspelbaar blijven voor een gebruiker die gewoon zijn werk probeert te doen?
Zolang dat niet scherp is, ontstaat er een bekend patroon. Er is vertrouwen in vakmanschap, er zijn brede kwaliteitsclaims, maar het eerste echte bewijs komt pas laat. En laat bewijs is duur bewijs. Niet alleen in geld of tijd, maar ook in aandacht. Want zodra iets zichtbaar begint te schuiven, gaat de organisatie reageren op symptomen.
Dan zie je dezelfde bewegingen terug: extra afstemming, tijdelijke fixes, meer dashboards, nog een overleg, een tool die overzicht moet brengen. Allemaal begrijpelijk. Maar het onderliggende probleem blijft vaak staan: de eigenschap die ertoe deed, was nooit klein en concreet genoeg gemaakt om vroeg te zien of ze zich ook echt gedroeg zoals bedoeld.
De aanleiding is niet politiek, maar praktisch
Dat patroon zag je de afgelopen weken ook terug in een heel andere context. NOS beschreef hoe een prestigieuze renovatie van de Reflecting Pool in Washington al snel zichtbare problemen liet zien: algen, verkleuring en loslatende verf, kort nadat het project als degelijk afgerond was gepresenteerd.
De interessante les zit voor mij niet in de politieke laag, en ook niet in de vraag wie hier gelijk had. De stillere observatie is praktischer: een project kan omringd zijn met vertrouwen, expertise en grote woorden, en toch vroeg signalen geven dat de werkelijkheid anders reageert dan het plan.
Dat is precies waarom softwarekwaliteit zelden geholpen is met alleen intentie.
Niet omdat intentie onbelangrijk is, maar omdat systemen zich uiteindelijk gedragen zoals ze zich gedragen. Onder belasting. In onderhoud. In overdracht. In kleine wijzigingen op drukke weken, wanneer niemand tijd heeft voor theorie.
Voor een CTO of founder is dat vaak het echte dilemma. Je wilt kwaliteit serieuzer maken, maar zonder een nieuw ceremonieel programma op te tuigen. Je wilt ook niet direct vervallen in een breed traject waarin iedereen wekenlang labels plakt op problemen die nog niet scherp zijn.
Je zoekt iets rustigers: een manier om kwaliteit niet als gevoel te behandelen, maar ook niet als bureaucratie.
ISO 25010 is vooral nuttig als het je taal smaller maakt
Daar kan ISO 25010 behulpzaam zijn, maar alleen als je het niet gebruikt als afvinklijst.
De waarde zit niet in “we doen nu iets met een model”. De waarde zit in taal. Het model helpt je onderscheiden over welke eigenschap je het eigenlijk hebt. Betrouwbaarheid is iets anders dan onderhoudbaarheid. Performance-efficiëntie vraagt ander bewijs dan functionele geschiktheid. En zodra je dat verschil serieus neemt, worden beslissingen proportioneel.
Niet alles hoeft tegelijk beter. Niet elke zorg vraagt een audit. Niet elk signaal vraagt een platformmigratie of een nieuw kwaliteitstraject.
Soms is één vraag genoeg.
Bijvoorbeeld:
Als we eerlijk kijken naar de komende drie maanden, welke eigenschap verdient het eerst klein bewijs?
Misschien is dat betrouwbaarheid op een gebruikerskritische flow, omdat een terugkerende storing direct voelbaar is voor omzet of vertrouwen.
Misschien is het onderhoudbaarheid, omdat elke kleine wijziging inmiddels uitloopt in onverwachte afhankelijkheden, extra reviewtijd en release-spanning.
Misschien is het performance-efficiëntie, niet breed over het hele landschap, maar op één pad waar gebruikers afhaken zodra een handeling te stroperig voelt.
Dat is een andere beweging dan “kwaliteit verbeteren”. Het is specifieker, menselijker en bestuurbaar.
Eén eigenschap, één pad, één signaal, één eigenaar
De meeste rust ontstaat niet wanneer je meer ambities opschrijft, maar wanneer je één eigenschap koppelt aan één plek waar die zichtbaar moet worden.
Dat kan verrassend klein zijn.
Eén flow in het product. Één observatiepunt. Één eigenaar die het signaal begrijpt. Één afgesproken drempel die helpt bij de volgende beslissing.
Stel dat je onderhoudbaarheid kiest. Dan hoef je niet te bewijzen of de hele codebase “goed onderhoudbaar” is. Je kunt veel kleiner kijken: blijft een wijziging in dit onderdeel lokaal, of raakt ze telkens onverwacht veel services, tests en teams?
Kies je betrouwbaarheid, dan hoeft de eerste stap niet te zijn dat je het hele incidentlandschap herontwerpt. Het kan genoeg zijn om zichtbaar te maken of een kritische flow zich onder reële omstandigheden gedraagt zoals je verwacht, op momenten die ertoe doen.
Kies je performance-efficiëntie, dan hoeft dat niet meteen te eindigen in een optimalisatieprogramma. Eerst wil je weten: blijft deze handeling binnen een gedrag dat acceptabel is voor echte gebruikers, of stapelen kleine vertragingen zich op tot frictie die in geen roadmap-item terugkomt?
Dat soort signalen heeft een prettige eigenschap: ze maken het gesprek rustiger.
Niet omdat ze alle discussie wegnemen, maar omdat ze de discussie begrenzen. Je hoeft minder te geloven en meer te kijken. Minder te verdedigen en beter te kiezen. De vervolgstap verdient zichzelf op basis van iets zichtbaars, niet op basis van volume of overtuigingskracht.
Dat is vaak precies wat softwareleiders zoeken: eigenaarschap zonder overreactie.
De eerste goede stap is zelden groter, maar preciezer
In veel organisaties is de reflex nog steeds om breed te starten zodra kwaliteit aandacht krijgt. Er komt een inventarisatie, een set aanbevelingen, een lijst met thema’s en vaak ook een impliciete verwachting dat tooling de versnelling brengt.
Maar breedte is niet altijd volwassenheid. Soms is het vooral uitstel in nette vorm.
Een preciezere start vraagt minder energie en geeft sneller houvast. Niet omdat klein altijd beter is, maar omdat klein zichtbaar kan worden. En zichtbaarheid is wat een besluit bruikbaar maakt.
Als je daar deze week iets mee wilt doen, hoeft het niet ingewikkeld te zijn.
Kies één eigenschap uit ISO 25010 die op dit moment het meest schuurt met de praktijk. Kies één flow of component waar die eigenschap ertoe doet. Bepaal welk eerste signaal je wilt zien. En spreek af wie eigenaar is van dat signaal, nog vóór je beslist of er meer nodig is.
Dat is geen groot programma. Het is een kleine investering in helderheid.
Welke kwaliteitseigenschap zou jij liever eerst klein en zichtbaar maken in plaats van breed te “verbeteren”: betrouwbaarheid, onderhoudbaarheid, performance-efficiëntie of iets anders?
Als je dit voor je eigen context rustig wilt verkennen, is Pathfinder Signal een logische route: één eigenschap kiezen, het eerste waarneembare signaal bepalen en pas daarna besluiten welke vervolgstap wel of niet nodig is.