Nieuwe software releases en hun effectiviteit: meten is weten
In dit deel ga ik in op het meten van de effectiviteit van de verbeteringen doorgevoerd in een nieuwe software release (het resultaat van een iteratie). In de online software wordt vaak nauwkeurig gemeten hoe en wat binnen het product gebruikt wordt en wat niet, maar ook softwareleveranciers van besturingssystemen willen graag weten hoe hun product wordt gebruikt: wat zijn bijvoorbeeld de meest gebruikte features?
[caption id=”” align=”alignnone” width=”555.0"]
Voorbeeld van metingen om features te verbeteren in Microsoft Windows[/caption]
De verbetercyclus op basis van metingen is als volgt te visualiseren:
[caption id=”” align=”alignnone” width=”693.0"]
Verificatie van verbeteringen[/caption]
Als onderdeel van het design van de verbetering wordt bepaald wat de beoogde meetbare resultaten moeten zijn, bijvoorbeeld minimaal 10% meer gebruik van feature X. Na de release wordt gemeten of deze resultaten daadwerkelijk gehaald zijn en de maatregel daarmee effectief is. Indien dit niet het geval is, zal gekeken moeten worden naar acties om dit alsnog tot een succes te maken. In sommige gevallen zijn hier geen veranderingen in het product voor nodig, bijvoorbeeld een melding naar gebruikers dat feature X verbeterd is. Indien er wel een verandering nodig is, komt dit op de product backlog als enhancement.
In deel 1 van deze serie blogs hebben we drie categorieën verbeteringen behandeld:
- Features (vergelijkbaar met nieuwe proces stappen op de werkvloer)
- Enhancements (procesoptimalisaties)
- Bugs (inperkende maatregelen).
Iedere categorie kent zijn eigen methodiek om verbeteracties en verificaties te bepalen. Er bestaan verschillende varianten die, soms impliciet, door productmanagers gebruikt worden. Uiteindelijk gaat het erom dat er een model gebruikt wordt dat voorspelbaar en toepasbaar is.
Nieuwe features
Om nieuwe features goed met elkaar te vergelijken in waarde wordt de inspanning (hoeveelheid arbeid, eventuele investeringen, te verwachten onderhoud, etc.) uitgezet tegenover de waarde voor de gebruikers (past het binnen de visie, is het waardevol voor alle gebruikers, etc.). Dit ziet er dan als volgt uit:
[caption id=”” align=”alignnone” width=”696.0"]
Features uitgezet tegen waarde en inspanning (bron: aha.io)[/caption]
Deze methode kan ook uitstekend worden toegepast bij het verbeteren van een productieproces of het verbeteren van de veiligheid op de werkvloer.
Nadat de feature gelanceerd is, wordt er gemeten of de ingeschatte waarde en inspanning overeenkomen met de werkelijkheid. Nieuwe features blijven vaak experimenten; het is moeilijk goed de waarde en inspanning te voorspellen. Juist daarom is het zo belangrijk om zowel de ingeschatte waarde zo goed mogelijk te classificeren als het meten van de daadwerkelijke resultaten. Op basis van deze verificatieslag kunnen de doorgaans vaak kwalitatieve inschattingen voor toekomstige features verder verbeterd worden.
Enhancements
Bestaande features kunnen als volgt verbeterd worden:
- Doelbewuste verbeteringen. Vanuit je bestaande feedback van gebruikers heb je voldoende overtuiging en zie je mogelijkheden om een feature te verbeteren
- Verbeteringen zodat gebruikers een feature vaker gaan gebruiken
- Verbeteringen zodat een feature door een grotere hoeveelheid gebruikers benut wordt
Duidelijke doelen helpen zowel de juiste maatregelen als de juiste metrics te bepalen om de effectiviteit van een interventie te meten. Soortgelijke doelen voor bijvoorbeeld een productieproces zouden bijvoorbeeld efficiëntieverhoging en reductie van het aantal fouten kunnen zijn.
Bugs
Bugs zijn het beste te vergelijken met inperkende maatregelen. Afhankelijk van de complexiteit en de root cause van de bug kan het zijn dat er, naast een hotfix om het productieproces weer te herstellen, ook een structurele oplossing moet komen. Deze wordt dan als enhancement opgenomen in een volgende iteratie.
Bugs hebben doorgaans technische foutmeldingen tot gevolg. Dit maakt ze eenvoudig meetbaar. Hierdoor kunnen we, naast gebruikerstests, ook geautomatiseerd verifiëren in onze virtuele ‘controlekamer’ of de foutmeldingen verdwenen zijn.
Om daadwerkelijk continu te verbeteren is het meten van de effectiviteit van de maatregelen onmisbaar. Op basis van deze feitelijke data kunnen kwalitatief betere en objectievere beslissingen genomen worden en sluit je daarmee de feedbackcyclus. Doe je dit niet en dus impliciet de ‘wait and see what happens’-strategie hanteert, slaag je weliswaar altijd (je wacht immers enkel af wat er gaat gebeuren), maar je hebt vervolgens geen feedback en niet geleerd waarom een interventie nou succesvol is.
In deel 3 van deze serie laat ik zien hoe wij met ons Safety Changer platform continu en iteratief verbeteren op de werkvloer ondersteunen.
