Dutch post: Meer heldere requirements: Kies de juiste verpakking

Mijn collega Kurt Bittner heeft afgelopen juni  tijdens IBM Innovate 2010 (Florida) zijn visie gegeven op de nieuwe rol en verantwoordelijkheden van de nieuwe generatie informatieanalisten. Wanneer je geen kans hebt gezien om zijn presentatie bij te wonen, bekijk die dan via Slideshare: Transforming the role of the Business Analyst. Hieronder volgende enkele observaties of veel voorkomende problemen die hebben geleid tot zijn visie:

  • Gebruikers verwachten andere  functionaliteit dan waar ze oorspronkelijk om hebben gevraagd.
  • Gebruikers eisen functionaliteit die ze nooit zullen gebruiken
  • Gebruikers geven tegenstrijdige of conflicterende requirements

Om meer succesvol te zijn, zijn een aantal veranderingen noodzakelijk. Eén daarvan is dat informatie-analisten meer gefocust moeten zijn op gewenste resultaten in plaats van systeemeigenschappen (features). Een andere is dat informatie-analisten zich meer moeten verdiepen in de onderliggende oorzaken in plaats van zich tevreden te stellen met een lijst wensen. Gefocust zijn op resultaat en het boven water krijgen van de onderliggende oorzaken kan een heel karwei zijn en het is gemakkelijk om de twee door elkaar te halen of vast te lopen. Een slimmere manier waarbij meer rekening wordt gehouden met taalgebruik, vraagstelling en (on)bewust gebruikte van kaders of context frames biedt dan uitkomst.

De term context frame is jargon, maar heel gemakkelijk uit te leggen met een voorbeeld. Ik ben er namelijk zeker van dat jij mensen kent die altijd en soms tot vervelens toe antwoorden met “ja, maar”. En hoewel er zelden een negatieve intentie achter, voelt het maar al te vaak wel degelijk zo. Communicatie-experts zeggen dat je beter met “ja, en” kunt antwoorden om zodoende de negatieve lading er af te halen. Maar als je het mij vraagt, is het beter om (on)bewust steeds het juiste kader of frame te kiezen om zo het gewenst resultaat of de gewenste respons te krijgen. Vergelijk bijvoorbeeld de onderstaande zinnen:

  • Met het project gaat het prima, maar we moeten deze risico’s wegnemen
  • Met het project gaat het prima en we moeten deze risico’s wegnemen
  • Met het project gaat het prima alhoewel we deze risico’s moeten wegnemen

Wanneer je deze zinnen leest, merk dan op wat naar boven komt. En merk dan dat iedere zin iets anders aanvoelt of een andere focus aanbrengt?

Wanneer maar wordt gebruikt, dan hebben de meeste mensen de neiging om vooral aandacht te geven aan het tweede of laatste deel van zin, ofwel dat risico’s moeten worden weggenomen. En wanneer en wordt gebruikt, dan ervaren de meeste mensen beide zinsdelen als even belangrijk. En wanneer alhoewel wordt gebruikt, dan neigen de meeste mensen ernaar vooral stil staan bij het eerste deel van de zin, ofwel de status van het project. Het feit dat risico’s moeten worden weggenomen wordt dan als minder tot irrelevant ervaren.

Wat we hieruit kunnen leren is dat het wijzigen van één woord een bepaald aspect meer of minder kan belichten en daarmee de wijze waarop we dingen ervaren kan veranderen. “Kaders (frames) sturen de aandacht en beïnvloeden hoe gebeurtenissen worden geïnterpreteerd” (R. Dillts, 1999).

Binnen taal kom je veel verschillende soorten kaders of frames tegen. Welke activiteit zou je bijvoorbeeld liever op jouw softwareproject willen aantreffen: herstelwerkzaamheden (rework) of refactoring? Hoewel ze in essentie hetzelfde zijn, gok ik op de laatste (met dank aan Craig Lucia voor het voorbeeld).

Wanneer je wilt ingaan op resultaten in plaats van wensen, dan wil je juist niet diep ingaan op probleemgebieden. En andersom geldt dat wanneer je wilt ingaan op problemen of achterliggende oorzaken, dan wil je het juist niet hebben over visievorming. Het gebruik van het juist kader is een manier om daarvoor te zorgen. Wanneer je gewenste resultaten wilt identificeren, dan dien je ervoor te zorgen dat de focus ligt op het behalen van één of meer doelen, gewenste toestanden of het vinden van een bepaalde oplossing. Gebruik hiervoor vragen zoals:

  • Wat heb je nodig?
  • Hoe is het om….te hebben?
  • Hoe kunnen we merken of meten dat we …….hebben waargemaakt?
  • Welke middelen hebben we beschikbaar om ......mogelijk te maken?

Merk op dat de eerste vraag uit de lijst gevaarlijk kan zijn wanneer die in isolatie wordt gesteld omdat je dan namelijk de kans loopt te blijven zitten met die ongewenste lijst met wensen. Gebruik het dus alleen als startpunt en vraag dan door, bijvoorbeeld met de overige vragen uit de bovenstaande lijst. Let er tevens op dat alle geïdentificeerde resultaten positief worden geformuleerd en zijn gericht op de toekomst. We zullen straks ingaan waarom dit verstandig is.

Wanneer je oorzaken wilt identificeren, zorg er dan voor dat je focust op ongewenste symptomen en hun effecten. Gebruik hiervoor vragen zoals:

  • Wat is het probleem?
  • Wat mankeert er aan de huidige situatie?
  • Waarom is het een probleem?
  • Hoe weet je dat het een probleem is?
  • Wie heeft het probleem veroorzaakt?
  • Wat heeft het probleem veroorzaakt?

Realiseer dat te veel blijven hangen in problemen en oorzaken op zichzelf geen waarde heeft omdat het uiteindelijk gaat om het oplossen van problemen in plaats van ze te hebben. Zorg er daarom voor dat problemen, symptomen en oorzaken altijd wordt geanalyseerd in het licht van gewenste resultaten.

Zoals aangeven is het herkennen en kiezen van het juiste kader en het positief en toekomstgericht formuleren van gewenste resultaten belangrijk. Het komt namelijk vaak voor dat gewenste resultaten op een negatieve manier worden beschreven en dit leidt in de meeste gevallen tot onverstandige beslissingen. Neem bijvoorbeeld de eis of wens “Ik wil minder fouten ten gevolge van onduidelijke requirements”. In veel gevallen hebben organisaties geprobeerd om dergelijke problemen op te lossen door middel van meer formele processen en meer gedetailleerde beschrijvingen. In de praktijk blijkt echter dat dit in de meeste gevallen alleen maar leidt tot meer problemen. De oorzaak is de focus op het voorkomen van fouten of zoals in dit geval beter proberen te doen wat al is geprobeerd. Een alternatieve vaak meer succesvolle oplossing is te kiezen voor een ander samenwerkingsmodel met achterliggende disciplines en snelle terugkoppeling. Dit komt vaak pas in beeld wanneer je meer alternatieven gaat zien en een manier om dat te doen is door negatief geformuleerde resultaten eerst positief om te kaderen (reframe). Dit kun je doen door vragen te stellen als: “Wanneer je minder fouten hebt tengevolge van onduidelijke requirements, wat ervaar je dan?”.

Uiteindelijk gaat het er om (on)bewust het juiste kader te kiezen en slim gebruik te maken van taal. Je hoeft me niet op mijn woord te geloven, maar ik stel voor dat je proef op de som neemt. En wanneer je dat doet, dan zou je wel eens verrast kunnen zijn met het resultaat.