Waarom, waarom, waarom, ...

Als ik aan mensen vraag wat voor aanpak of techniek ze gebruiken om requirements te achterhalen krijg ik in negen van de tien gevallen als antwoord dat ze het gewoon vragen in een gesprek of interview. Sommigen kennen geen andere methoden, anderen zeggen dat dit het snelste werkt, ook wordt gezegd dat je dan kan doorvragen zodat je ‘de vraag achter de vraag’ kunt ontdekken. Hoe ze dat doen kan niet iedereen vertellen, wat – hopelijk - deels te verklaren is door het feit dat ze onbewust bekwaam zijn. Toch blijken er twee methoden te zijn die de meesten wel kennen of herkennen.

De meest bekende aanpak is LSD, ofwel Luisteren, Samenvatten, Doorvragen. Een betere naam hiervoor is ‘actief luisteren’. Het klinkt heel eenvoudig, maar vereist toch wel wat oefening. Voordat je gaat luisteren moet je natuurlijk eerst een vraag stellen. Vaak is een open vraag prima om mee te beginnen. Dat nodigt de ge?nterviewde uit om te gaan praten. Een vraag als “Wat is het belangrijkste probleem dat het systeem moet oplossen?” kan niet met ‘ja’ of ‘nee’ worden beantwoord. Er moet dus een antwoord komen met meer informatie waarnaar je moet Luisteren. Dat was stap één. Samenvatten is daarna handig als er een spraakwaterval als antwoord is gegeven, maar wat belangrijker is, is ‘parafraseren’. Herformuleer het antwoord dat je kreeg in je eigen bewoordingen. “Ik begrijp dat het probleem zus-en-zo is. Klopt dat?”. Met de gesloten vraag aan het eind kun je verifi?ren of je het inderdaad begrepen hebt. Als dat zo is kun je naar de derde stap in het proces: Doorvragen. “Maar als het probleem zus-en-zo is, hoe zit het dan met …?”.

Actief luisteren, of LSD, is een veelgebruikte, goed werkende aanpak, niet alleen binnen Requirements Engineering. Veel coaches maken er ook gebruik van. Van zo’n coach leerde ik dat het niet altijd handig is om met een open vraag te beginnen. Bij sommige mensen, de meer extraverte personen, werkt dat meestal wel. Bij introverte personen en vooral bij wat meer verlegen personen, is het juist handig om met een paar gesloten vragen te beginnen. Door een paar keer ‘ja’ of ‘nee’ te kunnen antwoorden krijgen zij de tijd om aan hun actieve rol in het gesprek te wennen.

Een ander punt is het maken van aantekeningen. Een tip van een (andere) coach was om dit niet tijdens het gesprek te doen, althans niet tijdens de luisteren-samenvatten-doorvragen-luisteren-samenvatten-doorvragen cyclus. Door niet meteen te schrijven, maar je best te doen dingen te onthouden, laat je merken dat je echt ge?nteresseerd bent. Schrijven kan daarna, of liever nog, door iemand anders. En als je zelf even tijd nodig hebt om te schrijven, benoem dat dan en geef aan dat je hetgeen gezegd is belangrijk vindt en zeker niet wil vergeten.

De tweede gespreksaanpak, die misschien niet wordt toegepast, maar waar men wel van gehoord heeft, is het bekende “Five-times-why”. Als iemand zegt “Ik wil dit scherm kunnen afdrukken.” vraag je “Waarom?”. En op het antwoord dat je krijgt vraag je weer “Waarom?”. Dit is een veel beproefde methode afkomstig uit de Toyota processen voor problem solving en een vast onderdeel van Lean en Six Sigma. Het idee is dat als je vaak genoeg “waarom” vraagt, je uiteindelijk weet “hoe” je het probleem moet oplossen: 5W=1H. Er is wel wat kritiek op deze methode. Soms is vijf keer doorvragen te veel en weet je al genoeg na twee keer “waarom”. Bovendien, en dat is voor problem solving erg belangrijk, vraag je door in één richting waardoor je zou kunnen missen dat er meerdere oorzaken voor een probleem kunnen bestaan. In dat geval is het maken van een visgraat of Ishikawa diagram meer op zijn plaats. Ik denk dat bij het toepassen van Five-times-why in Requirements Engineering de grootste uitdaging is je gesprekspartner niet te ergeren door als een jengelend kind te klinken. Tip: je kunt ook doorvragen met andere woorden dan “waarom”, zoals “wat is daar de oorzaak van?” of “hoe ontstaat zo’n probleem?”.

Er zijn weinig gesprekstechnieken die je zo kort kunt omschrijven (LSD, 5xW) en die tegelijkertijd zowel uitdagend als effectief zijn. En zoals gezegd, voor beide technieken geldt dat het snel is uitgelegd, maar wel geoefend moet worden. Ik ben benieuwd welke interviewtechnieken er nog meer bekend zijn onder de lezers of waarover je nog meer zou willen weten. dan kan ik of een van mijn collega’s daar in een volgend artikel op in gaan.

Dit artikel is een artikel in de reeks over het veelzijdige vak van Requirements Engineering waarbij de komende maanden iedere week een collega van Improve Quality Services de lezer meeneemt in de zaken waar de Requirements Engineer vandaag de dag tegenaan loopt. Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.

Tot zover verschenen in deze reeks:

1.   Requirements (Piet de Roo, 1 december 2020)

2.   Shared Understanding (Kaspar van Dam, 8 december 2020)

3.   Context en requirements structuur (Patrick Duisters, 15 december 2020)

4.   Van Twin Peaks naar Twin Pines (Patrick Duisters, 22 december 2020)

5.   Modellen om te bouwen (Erwin Pasmans, 5 januari 2021)

6.   Minimaal Modelleren (Piet de Roo, 12 januari 2021)

7.   Begrip en Vertrouwen (Benjamin Timmermans, 19 januari 2021)

8.   En wat als de specialisten het niet met elkaar eens zijn? (Benjamin Timmermans, 26 januari 2021)

9.   Waar zijn we nou helemaal mee bezig?! (Erwin Pasmans, 2 februari)

10.  Soft skills? Keiharde wetenschap! (Kaspar van Dam, 9 februari)

11. … en nu enkele feiten: Requirement Attributen (Patrick Duisters, 16 februari)