Agile software-ontwikkelmethodieken hebben een concept dat User Stories heet. Dit is een requirement of feature van het systeem dat iets oplevert voor de gebruiker. Maar waar is de gebruiker in dit proces?

Het meeste contact met fysiek aanwezige gebruikers was bij de ontwikkeling van projecten voor NedTrain, Cobra Personeelssystemen en voor Macaw zelf (de Macaw XP internet site). In die periode was Usability nog het buzzword. In onze usabilitytests confronteerde we eindgebruikers aan het einde van het proces met wat we gemaakt hadden en haalde zo de scherpe randjes er af. In recente projecten die via SCRUM uitgevoerd werden, zag ik een grote rol voor SCRUM-masters weggelegd, maar echte eindgebruikers waren nergens te bekennen.

Volgens het boek “User Stories Applied” van Mike Cohn moet 1x per maand overleg met echte gebruikers plaatsvinden. Maar in dat zelfde boek staat dat het team ook een brainstorm sessie kan houden om User Stories te verzamelen:

“By now the team might have spent an hour (...) and they will have put more thought into the users of their software than probably 99% of all software teams.”

Minder dan 1% van de software-ontwikkelteams maakt dus gebruik van meer dan een brainstormsessie om de gebruikers van het systeem te leren kennen. Dat komt wel ongeveer overeen met mijn ervaringen.

In agile methodieken is het de bedoeling dat gebruikers er vanaf het begin tot het einde bij betrokken zijn. En dat is een goede zaak, want alleen zo kunnen de mening, ervaring en kennis van een gebruiker daadwerkelijk in het product terecht komen. Verschillende typen gebruikers krijgen in het Customer Team een representatie. Dit team hoort te bestaan uit de productmanager, testers, interactieontwerpers en echte gebruikers. Maar hier ontstaat wat verwarring: richten we ons op de gebruiker of op degene die de software aankoopt? Wie is eigenlijk belangrijker: de Product Owner of de Customer? Vaak wordt de rol van de User overgenomen door iemand anders in het Customer Team. Dat is de User Proxy.

Mike Cohn komt met verschillende mogelijkheden om de User Proxy in te vullen:

• Bij interne projecten de manager van de gebruiker, maar deze gebruikt de software niet op dezelfde manier.
• Een development manager, maar die heeft andere belangen die conflicteren met de belangen van de gebruiker.
• Consultants en vertegenwoordigers spreken vaak rechtstreeks met klanten, maar kennen niet het hele verhaal dat gebruikers kennen.
• Domain experts zijn een geweldige bron van informatie, maar hoeven nog niet de software zelf te gebruiken.
• Marketeers weten alles van markten, maar minder van gebruikers.
• Inkopers kopen de software in, maar kijken naar heel andere eigenschappen van software dan echte gebruikers.
• Trainers en supportmedewerkers praten met gebruikers, maar zullen de nadruk leggen op verkeerde features.
• Business analisten praten niet altijd met echte gebruikers en hebben voor in het proces veel tijd nodig.
• Voormalige gebruikers hebben ervaring die meestal is verouderd en niet meer aansluit op wat er nu gebouwd moet worden.

Kortom, aan alle User Proxies kleeft wel een nadeel. Kan je als developer niet gewoon zelf User Proxy zijn? Mike Cohn zegt hierover:

"While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user."

De vraag is dus: Hoe kom je aan gebruikers?

• In een zakelijke omgeving leiden rollen en functies tot mensen, die via de organisatie gemakkelijk benaderbaar zijn.
• Als je met stakeholders praat, kan je leren welke gebruikers representatief zijn en die rechtstreeks benaderen.
• Buiten een organisatie kan je marketing, consultants en buitendienstmedewerkers vragen of ze mensen kennen die willen meewerken.
• Je kunt vrijwilligers vragen via een nieuwsbrief, website of helpdesk van de klant.
• Je kunt bedrijven in de arm nemen die mensen voor je gaan inhuren. Hiervoor moet je een profiel opstellen.

Het is gebruikelijk om gebruikers een incentive te geven om ze te bedanken en te belonen voor hun medewerking, want echte gebruikers leveren een echte bijdrage aan de ontwikkeling van software.

En ook Mike Cohn weet het:

"...a real user beats a proxy any time."