Je hebt een broek nodig en je loopt hiervoor een kledingzaak binnen. Maar wat voor een soort broek zoek je? De verkoper stelt je vakkundig een paar simpele vragen waarmee hij precies denkt te weten wat voor een broek je zoekt. Uiteindelijk verlaat je verlaat de winkel met een broek die voldoet aan je eisen. Zo simpel gaat dat binnen de infra-wereld helaas niet. Je zal eerst oplossingsvrij moeten specificeren aan welke eisen de “broek” moet voldoen. Vervolgens zal je ook bij verschillende winkels dezelfde vraag moeten voorleggen voordat je de definitieve keuze gaat maken.

Oplossingsvrij specificeren is best lastig als je dat niet vaak doet en ook helemaal niet leuk als je al weet dat je een spijkerbroek nodig hebt. Begin eerst maar eens simpel om een user story te maken. Past op een post-it en is ook heel handig als je gewone kleinere projecten wilt uitvoeren.

 

Overheid heeft moeite met oplossingsvrij specificeren

Bij oplossingsvrij specificeren ligt de nadruk meer op specificeren als een proces en de oplossingsruimte die de ontwerpende partij moet krijgen. Het wordt vaak toegepast bij een UAV-gc contractvorm. Maar de lokale overheid zit meestal niet te wachten op een UAV-gc contactvorm. Te ingewikkeld en door de onbekendheid te arbeidsintensief.

De overheid zit echter wel op een kantelpunt omdat het steeds lastiger wordt, mede door het gebrek aan kennis om aan te geven hoe iets in de openbare ruimte gemaakt moet worden. Als opdrachtgever zal je steeds vaker moeten kunnen aangeven wat er in de openbare ruimte gemaakt moet worden. Dit vraagt om andere vaardigheden waarbij je in staat moet zijn om een vraagspecificatie te maken. Dit doe je door wat je wilt laten maken ‘functioneel te specificeren’.

Een makkelijke tussenstap is om eerst eens aan de slag te gaan met het maken van een user story. Een user story is in feite niets anders dan een klein verhaaltje waarin kort wordt omschreven waar een specifieke functionaliteit aan moet voldoen.

Wat is een goede user story?

De componenten van een user story: wie, wat en waarom. Het beste kun je er een zin van maken zoals: Als [wie] wil ik [wat] zodat ik [waarom].

Een goede user story kent de volgende eigenschapen:

1. het heeft een pakkende, goed beschrijvende titel, zodat iedereen weet over welk ‘verhaal’ het gaat als erover gepraat wordt;
2. het kent duidelijke acceptatie-criteria, op basis waarvan je na afloop kunt testen of de vraag goed ingevuld is;
3. het vertelt altijd wie iets wil, wat deze persoon wil bereiken en waarom hij of zij dat wil. Het antwoord op de waarom-vraag geeft de toegevoegde waarde voor de gebruiker aan.

Het is ook in een gebruikerstaal geschreven en bij voorkeur opgeschreven door de initiatiefnemer van het project. Het is ook vooral een discussie-stuk (en geen contract). Dat laatste punt is erg belangrijk! Een user story is niet zo gedetailleerd dat vastgelegd is wat er precies gemaakt moet worden. Een goede user story biedt voldoende informatie om over te discussiëren, zodat samen gezocht kan worden naar de beste oplossing om functioneel aan de wens van de gebruiker te voldoen.

Het is in feite dus een eerste opstap om een uitvraag aan de markt functioneel te specificeren zonder het gelijk ingewikkeld te maken. Een project bestaat altijd uit verschillende onderdelen (wegen, riolering, groen etc) dus er zijn meerdere user stories.

Kenmerken van een user story

• User stories zijn klein en overzichtelijk en ze voegen waarde toe.
• Een user story gaat maar over één functionaliteit.
• User stories zijn onafhankelijk van elkaar, dus projectteams kunnen los van elkaar één specifieke functionaliteit ontwikkelen.
• Omdat ze zo klein zijn, zie je snel resultaat en kun je snel terugkoppelen en bijsturen.
• Je kunt goed inschatten hoeveel tijd het kost om een user story tot functionaliteit te ontwikkelen en daarmee een betere planning maken.
• De klant kan bij elke user story en bij elk stukje functionaliteit terugkoppeling geven. Zo is de (interne)klant veel meer betrokken bij het eindresultaat.

Hoe schrijf je een goede user story? Een aantal tips.

Wees altijd zo specifiek mogelijk als je de [wie] omschrijft. Gebruik geen algemene termen zoals ‘gebruiker’. Je moet weten welke ‘persona’ of groep gebruikers precies de functionele wens heeft.

Gebruik werkwoorden als je de [wat] omschrijft. Dat geeft namelijk aan wat de gebruiker wil bereiken. Dus niet “ik wil een overzicht”, maar “ik wil een overzicht inzien”.

Wat vaak gebeurt, is dat er niet omschreven wordt ‘waarom’ een bepaalde gebruiker iets wil bereiken, maar ‘hoe’ hij dat wil doen. Probeer niet in die valkuil te stappen. Het beantwoorden van de ‘hoe-vraag’ laat je namelijk juist aan de markt over.

Gebruik geen jargon, tenzij daar afspraken over gemaakt zijn. Het kan anders snel leiden tot interpretatieverschillen.

Enkele voorbeelden van user stories

• Als wegbeheerder wil ik de betrokken worden bij het ontwerp proces van de weg zodat ik na afloop de kwaliteit van de werkzaamheden kan beoordelen.
• Als fietser wil ik met een snelle elektrische fiets van A naar B kunnen fietsen zonder gevaarlijke kruispunten te moeten oversteken.
• Als bewoner wil ik het regenwater van mijn dak afkoppelen van het riool zonder dat ik de kans loop dat mijn tuin bij hevige regenval onderwater komt te staan.
• Als aanbestedende partij wil ik mijn aanbestedingen online beheren zodat ik minder fouten maak in het aanbestedingsproces en het uiteindelijk sneller verloopt.

Kijk ook even op www.lbbrhzn.nl als je nog meer wilt lezen over duurzaamheid, innovatie en aanbesteden.