Wat is mijn definitie van succes?

Bij het bouwen van nieuwe software worden veel vragen goed beantwoord. Wat wil de eindgebruiker met de nieuwe software? Welke problemen lost de software op? En hoeveel tijd denken we dat het kost om de software te ontwikkelen? Maar verrassend genoeg hoor je zelden iemand vragen om te definiëren wanneer de software geslaagd is.

En nóg zeldzamer is het, dat er wordt nagedacht over objectieve meetcriteria die kunnen bewijzen dat de doelstellingen zijn gehaald. Hoe meet ik of de nieuwe feature gebruikt wordt? Welke opbrengsten verwacht ik van de nieuwe feature (stijging van aantal productverkopen, tevredenere klanten)? En nog voordat besloten wordt om überhaupt een feature te bouwen, is het belangrijk dat je je afvraagt: wat is mijn definitie van succes?

Naar een definitie van succes
In software zijn verschillende soorten informatie te vinden die interessant zijn. Denk aan de algemene demografische informatie. Andere belangrijke gegevens hebben betrekking op hoe vaak een bepaalde functie wordt gebruikt en hoe vaak bepaalde informatie wordt opgevraagd. Welke informatie het belangrijkst is, hangt natuurlijk vooral af van wat voor dienst de software verleent. Bij een rekenmachine, bijvoorbeeld, gaat het vrijwel exclusief om functioneel gerichte software. In het geval van een filmstreamingdienst is de content weer veel belangrijker. De samenhang van functionaliteit en het opvragen van data levert natuurlijk ook interessante informatie op.

Agile
Als je vanuit de Agile/Scrum-methode werkt, dan werk je meestal met user stories. Deze hebben een duidelijke scope: ‘Als gebruiker van de applicatie met een bepaalde rol, wil ik een bepaalde handeling kunnen uitvoeren die me helpt mijn dagelijkse werkzaamheden te ondersteunen’. Of: ‘Door deze functionaliteit toe te voegen, verwachten we dat de gebruiker de informatie of het product sneller kan vinden’. Zo’n user story wordt gevolgd door een aantal acceptatiecriteria die de voorwaarden voor de volledige implementatie van de user story duidelijk uitsplitst voor de ontwikkelaar en de tester.

Vaak vindt er een inschatting plaats van het belang van bepaalde functionaliteit, bijvoorbeeld in de vorm van de prioriteit die het krijgt in de sprintplanning. Meestal wordt er aan de story ook een punteninschatting toegevoegd, waarmee we aangeven hoeveel werk we denken dat het implementeren van de story is voor een ontwikkelaar. Hierdoor weten we naderhand dus impliciet ook de benodigde investering.

Kortom, eigenlijk ligt in het Agile-proces meestal al een definitie van succes klaar. We hebben een voorspelling gedaan van hoe belangrijk bepaalde functionaliteit is voor een bepaald soort gebruiker of voor de business. Nu willen we dus eigenlijk alleen maar kunnen meten of dat in de praktijk ook daadwerkelijk blijkt te kloppen, zodat we die feedback later weer kunnen gebruiken om te bepalen of de doelen gehaald zijn of dat er vervolgstappen nodig zijn.

Wat ga ik meten?
Eigenlijk hebben we het antwoord al gegeven: we willen het liefst kunnen volgen of de user story door de eindgebruiker wordt gebruikt en op welke manier en hoe vaak deze wordt doorlopen. Stel dat we hebben vastgesteld dat vijf van de tien keer een projectmanager naar de projectentab gaat om een nieuw project aan te maken. Dan kunnen we hem tijd besparen door bijvoorbeeld op zijn startpagina een snelkoppeling naar een nieuw project te plaatsen in onze applicatie. We verwachten immers dat het toevoegen van de snelkoppeling de projectmanager tijd bespaart en dus vaker gebruikt wordt dan het huidige alternatief. Kortom, we zorgen ervoor dat we beide trajecten kunnen meten. Als de nieuwe knop is toegevoegd, kunnen de meetwaarden ons vertellen of deze het gewenste resultaat heeft.

Zo komen we er ook achter of gebruikers de nieuwe functionaliteit weten te vinden (wellicht heeft de projectmanager inmiddels een snelkoppeling of iets degelijks in zijn browser toegevoegd). Iets wat je van tevoren zeker zou weten als je vanaf dag één met meten begonnen was. In dat geval liep het traject van de user story al meteen anders.

Dit betekent dat je niet zozeer activiteiten wilt meten, maar specifieke trajecten, waar meerdere handelingen in voor kunnen komen. In het bijhouden van een gebruikerstraject hebben we dus baat bij het kunnen volgen van bepaalde handelingen, gegroepeerd op een bepaalde functionaliteit of user story.

Een ander doel kan zijn om te valideren dat alleen projectmanagers deze functionaliteit gebruiken. Hiervoor moet je zelf beslissen of je de rol van de gebruiker als custom property direct meeneemt in je analytics, of dat je alleen een user id gebruikt – een en ander hangt natuurlijk af van de situatie.

Veel managers denken misschien: waarom moeilijk doen, ik wil toch alleen maar weten of ik meer verkoop of minder? Maar als je een piek of dal in de verkoop niet kunt correleren met gebruikersstatistieken om te zien welke functionaliteit toen net nieuw was (en/of ook veel gebruikt werd), dan heb je al gauw geen idee meer waarom er een piek of een dal was. Die correlatie met verkoop zal niet altijd betekenisvol zijn (zo zijn statistieken nu eenmaal), maar het kunnen zien of bepaalde functionaliteit wel of niet gretig wordt gebruikt, verbetert gegarandeerd de kans op betekenis en is vrijwel altijd nuttig.

Welke meettools zijn er?
Dit vraagstuk is niet nieuw, want het verzamelen van anonieme gebruikersstatistieken of het gebruik van tracking cookies zijn inmiddels bekende fenomenen in softwareland. En natuurlijk zijn er daarom diverse tools en platforms om dit te bewerkstelligen.

In Application Insights bijvoorbeeld – een tool van Microsoft – kun je met TrackEvent een eigen event doorgeven. Hierbij kun je via de context opgeven op welke operation (handeling of user story) de TrackEvent betrekking heeft. In de oude situatie van de projectmanager (zoals hiervoor besproken) begint de handeling van de user story dus met StartFromButton, daarna bijvoorbeeld EnterProjectDetails en vervolgens Done of UserCancelled of ServerValidationCancelled. Deze plaatsen we allemaal in dezelfde context van CreateProject als operation name, of je user story-referentie, of allebei – je kunt in Application Insights custom properties toevoegen of de Operation.Id gebruiken voor je User Story-nummer en de Operation.Name voor de omschrijving.

Nu gaan we in deze story een StartFromLandingPageButton toevoegen. Als we straks het traject van CreateProject gaan bekijken in Application Insights, dan kunnen we zien of gebruikers nu inderdaad direct vanaf hun startpagina een nieuw project aanmaken.

Voor websites worden meestal tags gebruikt. Dit zijn kleine stukjes script die functionaliteit toevoegen aan een website. Zo’n tag gaat van het simpel registreren van welke pagina’s werden bekeken, vaak gecombineerd met wat demografische statistieken, tot het toevoegen van complexere functionaliteit, zoals informatie over de cookie-wet tonen, feedbackinteractie met de gebruiker in de vorm van chats of vragenlijsten en a-b trajecttesten.

Google Tag Manager verdient hier speciale aandacht. Met het toevoegen van slechts één stukje script aan de site, kun je via tagmanager.google.com uitgebreid beheren welke extra tags je allemaal wil inzetten voor je site. Hiermee kun je vervolgens veel van de tag-functionaliteit beheren, zonder de site verder aan te passen.

Eventuele extra data die tags nodig zouden hebben, kunnen worden gecommuniceerd via de GTM ‘datalayer’, een mooi stukje abstractie die je vanuit de site vult met algemene gegevens over de getoonde pagina, die je dan vervolgens in de online tagmanager kunt koppelen aan specifieke tags. Specifieke events (zoals hierboven) kun je nog mooier in je site integreren met bibliotheken, zoals angularlytics.

CQRS en Command Sourcing
Alhoewel het dus absoluut mogelijk is om achteraf meer functionaliteit toe te voegen, zijn er wel degelijk software-architecturen die meten beter faciliteren dan andere. Een van de allerbeste is zonder twijfel Command en Query Responsibility Separation (CQRS). Bij deze opzet worden handelingen waarbij de gebruiker data wegschrijft (command) en handelingen waarbij de gebruiker data opvraagt (query) goed van elkaar gescheiden. De details zijn voor een andere blog, maar heel simpel gezegd wordt er één kanaal opgezet waarop commands binnenkomen. Daarnaast worden er aparte kanalen opgezet die kunnen voldoen aan de querybehoefte.

Een van de krachtige toepassingen van commands is dat het command zelf opgeslagen kan worden. Dit heeft tal van voordelen, zoals het historisch kunnen reconstrueren van de status van een object op een bepaald tijdstip. Voor ons onderwerp is de belangrijkste het op elk moment kunnen draaien en toevoegen van verschillende soorten zogenoemde projecties van de data, inclusief over de gebruikte Commands zelf; welke worden het meest gebruikt, door wie, hoe snel worden ze verwerkt, et cetera.

Tracking commands
De basisopzet van CQRS geeft direct al een hoop mogelijkheden voor het meten van een deel van de activiteiten van de gebruiker van software voor het command gedeelte. Dit dekt natuurlijk lang niet alle functionaliteit en soms zelfs helemaal geen functionaliteit. Maar ook dat is eenvoudig op te lossen. We kunnen hier natuurlijk alsnog iets als een TrackEvent van bijvoorbeeld Application Insights inzetten, maar we kunnen ook een nieuw type command definiëren die puur bedoeld is voor het registreren van een handeling, zelfs al heeft deze geen directe wijziging tot gevolg.

Deze vuren we af bij het uitvoeren van een query of het gebruik van een bepaald stukje userinterface. Deze tracking commands kunnen we eventueel ook lagere prioriteit geven door deze een eigen (goedkoper) afhandelkanaal te geven. Het posten van deze commands kan altijd asynchroon en heeft dus in de regel weinig tot geen invloed op de werking van de software. En UI Commands kunnen verder eventueel ook nog lokaal gecached worden en periodiek in batches worden doorgegeven aan een backend.

SoC/Dependency Injection
Wat je ook doet, zorg dat het ontwikkelteam netjes met dependency injection en separation of concern (SoC) werkt, zodat je later makkelijk van implementatie kunt veranderen. Ik zet zelf meestal een ITrackingClient-interface op, waarbij de implementatie daarvan weer een IClientRepository geïnjecteerd krijgt die voor het daadwerkelijk opslaan van de events gaat. Of daar een test-mock, wegschrijven naar een bestand of posten naar Google Tag Manager of Azure Application Analytics achter zit, maakt voor de rest van de applicatie dan niet meer uit en je kunt altijd op een later moment van gedachte veranderen. Onderschat nooit het belang van unit tests, ook hier niet – niets laat beter zien of je je SoC goed op orde hebt dan het schrijven van een unit test. Gaat dit moeilijk of heb je teveel test-setup nodig, dan weet je eigenlijk meteen dat je iets fout gedaan hebt.

Conclusie
We hebben genoeg mogelijkheden voorbij zien komen om objectief te meten of je user story voldoet aan de verwachtingen. Maar er zijn er natuurlijk altijd meer. Onthoud wel, dat welke oplossing je ook kiest, het belangrijkste is te weten dat de investering inderdaad terugverdiend wordt. Op zijn minst kun je met die informatie in de toekomst een betere inschatting maken, makkelijker bewijzen dat investeringen daadwerkelijk wat opleveren en (veel) kortere discussies hebben over prioriteiten.

Deze blog verscheen eerder op www.centric.eu/craft
Arwin van Arum is werkzaam bij Centric en actief als Craft Expert.