Angst voor statistieken: Statistieken als stok v.s. Statistieken als testcase

Ik had deze week een gesprek met een collega. We bespraken een statistiek gegeven dat erg slecht uitviel. Onmiddellijk ging het gesprek een bekende kant op. Er werd geprobeerd mij te overtuigen dit statistiek gegeven vooral niet te delen. Maar deze eerst uitgebreid te checken en controleren. Want dit kon niet correct zijn. En waarschijnlijk onuitgesproken: dit kon gebruikt worden om mensen te beschuldigen van slecht werk.

Statistieken worden vaak gebruikt als stok om mensen mee te slaan. Om mensen te beschuldigen van het leveren van slecht werk. Om mensen te vertellen dat ze niet genoeg verbeteren of niet voldoende verbeteringen doorvoeren. De gevolgen hiervan kunnen zeer groot zijn. Mensen houden geen statistieken bij, omdat ze managers geen stok willen geven om mee te slaan. Of nog erger: mensen gaan statistieken manipuleren. Maar wat als we nu de statistieken niet meer als stok zouden zien, maar als testcase?

Statistieken manipulatie

Om hier het nut van te bewijzen, eerst even twee situaties, die ik werkelijk heb gezien. De meest bekende is: gewoon geen statistieken maken. Statistieken maken kost tijd, soms veel tijd. Het aantal fouten meten of de gemiddelde oplostijd van een fout berekenen is zeker niet altijd eenvoudig. Als dit voordeel voor je heeft, zal dit geen reden zijn om het te laten. Maar als een manager ze wil (of zal gebruiken) om te ontdekken of jij je werk goed doet of niet, zal de motivatie heel erg laag zijn. Hoewel niemand ooit openlijk toegeeft hierdoor geen statistieken te maken, heb ik genoeg managers meegemaakt, waar dit bijna wel het geval moet zijn geweest. Statistieken werden gebruikt om onderscheid te maken tussen goede en slechte medewerkers. En tussen goede en slechte afdelingen of teams. Soms zelfs om een zondebok te kunnen vinden.

Statistieken manipuleren lijkt minder voor te komen, maar gebeurt regelmatig. En je zou denken, dat de gevolgen ook niet zo erg zouden zijn. De gevolgen kunnen echter zeer groot zijn. Neem nu bijvoorbeeld een veelvoorkomende manier van statistieken manipuleren: het veranderen van definities. Stel je hebt een bugregistratie en je krijgt te horen dat er teveel bugs zijn. Een oplossing hiervoor kan dan een andere definitie van een bug zijn. Normaal is een bug vaak omschreven als een handeling of groep handelingen, dat een fout resultaat of een ongewenste situatie oplevert. Maar je kan een bug ook zo omschrijven: een melding van een fout resultaat of ongewenste situatie voor goedkeuring (acceptatie) van de wijziging door de klant. De redenatie hierachter: als de klant geaccepteerd heeft, is de software dus goed. Alles wat ervan afwijkt kan daarom geen bug zijn. Wat is het nadeel hiervan? Bugs bijhouden doe je onder andere om na te gaan of je testprocessen goed werken. Als je de bugs maskeert als wijzigingen, zie je veel minder goed of je testprocessen goed genoeg zijn.

Een andere veelvoorkomende manier van statistieken manipuleren, is correcties toevoegen. Als ik 40 uur in de week werk en ik krijg er elke week onverwachts 10 uur bij, dan plan ik 30 uur week in. Dat zal niemand vreemd vinden. Maar als ik deze eenheid vervang door een andere eenheid, bijvoorbeeld taken, mensen, storypoints, wordt het verhaal regelmatig anders. Als ik elke week 40 taken in plan en ik krijg er elke week onverwachts 10 bij, dan plan ik voor de week erna niet 30 taken in. Nee, ik plan weer 40 taken in. Want ik weet dat ik 40 taken heb afgerond: 30 geplande en 10 onverwachtse. Dus ik kan 40 taken in een week uitvoeren. Dus ik plan 40 taken in. Want stel je voor dat mijn manager denkt, dat ik maar 30 taken kan uitvoeren in een week. Gevolg: heel veel niet gehaalde planningen.

Statistieken als testcase

Stel nu dat je statistieken als testcase zou beschouwen, wat houdt dat dan in? Een testcase is een serie van handeling, waarbij gecontroleerd wordt of het resultaat gelijk is aan het beschreven resultaat. Als een testcase faalt, kijkt een goede tester naar 3 mogelijkheden:

• De testcase is fout
• De eisen, waarop de testcase gebaseerd is, zijn fout
• De software is fout

Als ik dit vertaal naar statistieken, krijg ik de volgende mogelijkheden bij slecht uitvallende statistieken:

• De statistieken hebben een probleem
• De stappen voorafgaande aan de gemeten situatie hebben een probleem
• De gemeten stap heeft een probleem

Een goede tester gaat niet over tot de aanval, maar heeft geleerd om falende testcases te bespreken. In samenwerking met alle betrokkenen wordt bepaalt of er sprake is van een fout in de testcase, de eisen of de software. Daarnaast bepaalt de tester zelf of verder onderzoek nodig is.

Dus in mijn ogen pak je statistieken op de volgende wijze goed aan: je bespreekt ze met de betrokken om na te gaan of de statistieken, de voorafgaande stappen of de situatie zelf een probleem heeft of hebben. Daarnaast bepaal je zelf of verder onderzoek nodig is.

Het grote verschil: statistieken zijn nu niet meer om te bepalen wie goed werk heeft geleverd of wie niet. Net als een testcase niet tot doel heeft om te bepalen of een programmeur goed werk heeft geleverd of niet. Een testcase is een hulpmiddel om de kwaliteit van de software te bewaken. En statistieken worden zo een hulpmiddel om de kwaliteit van het proces te bewaken.

Statistieken moeten geen angst oproepen. Er moet geen neiging zijn statistieken te vermijden of te manipuleren, om te voorkomen, dat je op het matje geroepen wordt. Statistieken moeten gebruikt worden om het proces te bewaken en te verbeteren. Om problemen te vinden, door ze met mensen te bespreken, niet door de cijfers te laten spreken. Pas dan leiden ze tot een verbetering en niet tot stilstand of zelfs een verslechtering.