Onderhandelen

Stel: je bent een week geleden aangenomen als tester in een nieuw team. En je komt erachter dat de ontwikkelaars in het team nauwelijks tot geen unittests schrijven voor hun eigen code. Nu is het voor de kwaliteit van de op te leveren software wel zo belangrijk dat er hoogwaardige unittests geschreven worden. Als je jezelf serieus neemt in je baan, moet er dus wel wat gebeuren.

Wat doe je?

Als ik me deze situatie voorstel passeren er verschillende scenario’s de revue. Een willekeurige greep:  ik zie mezelf het onderwerp tijdens een retro met veel passie en overredingskracht in de groep gooien, of eender welk figuur met gezag beinvloeden met teksten als ‘dat er toch echt iets mee moet gebeuren’, of ik zie mezelf een zwartboek maken van alle bugs die ik vind die ik kan relateren aan het gebrek aan unittests om het team daarmee later mee om de oren te slaan. Alles voor de goeie zaak natuurlijk.

De oorlog is, kort samengevat, al tussen mijn oren begonnen.

Eén van de grootste problemen rondom potentiële conflictsituaties is dat het startpunt om tot actie over te gaan wordt gedaan in de vorm van een standpunt waar een oordeel in opgesloten ligt. In dit geval is het standpunt dat unit tests een belangrijke voorwaarde zijn voor kwalitatief goede software, en dat deze dienen te worden gemaakt door de software developers. Vanuit deze overtuiging wordt de strijd begonnen, waarbij ik al een oordeel over mijn teamgenoten heb geveld (“Idioot dat ze dit niet doen!”), meedraag en im- of expliciet in mijn communicatie laat doorschemeren. Het belooft een strijd met winnaars en verliezers, en een hoop verstoorde verhoudingen.
Het behoeft weinig betoog dat dit nou niet direct de meest effectieve manier is om samen te werken. Maar wat dan wel?

Onderhandelen

Nog steeds als ik het woord ‘onderhandelen’ hoor krijg ik buikpijn. De persoonlijkheid die ik meedraag vindt het onderhoud van elke relatie belangrijker dan bijna eender welk resultaat, waardoor de neiging om toe te geven groot is, ten koste van mijn eigen zorgen, wensen en verlangens. En ik ben niet de enige. Maar wat ik hiermee eigenlijk doe is gehoor geven aan een innerlijke stem die me influistert dat het gevaarlijk is om mijn wensen, verlangens en zorgen op tafel te leggen, om me transparant op te stellen. Om er toe te doen. Het gevolg is dat ik me geen eerlijke kans geef om te realiseren wat ik nodig heb. En, in bovenstaand voorbeeld, gehoor te geven aan wat mogelijk zeer goed zou zijn voor het team en het hoger liggende doel, namelijk de levering van een kwalitatief goed product.
Aan de andere kant zijn er ook volksstammen die hun eigenbelang vooraan zetten en zich niet al te druk maken over het afbreukrisico ten aanzien van de relatie die ze met hun gesprekspartner hebben. Omgekeerd evenredig aan mijn eigen verhaal kan ik me voorstellen dat deze mensen het link vinden om tegemoet te komen aan andermans wensen en verlangens, en daarmee telkens de pijn moeten pakken dat relaties teloor gaan. Bang om er niet toe te doen. Wat dan natuurlijk dezelfde negatieve gevolgen heeft voor het eindresultaat.

Samenwerken is makkelijk als alle partijen dezelfde doelen met dezelfde processen voor ogen hebben. Maar samenwerking vereist onderhandeling als (tussentijdse) doelen en processen elkaar (lijken te) bijten.

In het vermaarde boek over onderhandelen, “Never split the difference” van Voss en Raz, wordt onderhandelen gedefinieerd als ‘result driven communication’. Maar is de definitie niet te mager? Er wordt weinig tot geen rekening gehouden met de relatie, terwijl deze in heel veel onderhandelingssituaties wel meespeelt. Wellicht dat de volgende definitie ook voor onderhandeling-ontwijkers zoals ondergetekende beter aanvoelt: “Onderhandelen = samenwerken in situaties met (ogenschijnlijk) botsende belangen.”

Maar hoe dan?

Goed onderhandelen vraagt om nogal wat kennis en oefening. Maar de absolute voorwaarde is om wijd open te staan voor de overwegingen van de ander. In het eerdere voorbeeld: wat zijn de redenen dat er geen unit tests worden geschreven? Is het onwetendheid? Tijd en geld? Geen zin? Bedrijfspolitiek?  Anders? Als de vraag wordt gesteld, is het belangrijk om de term ‘root cause analysis’ in gedachte te houden. Een eerste antwoord is vaak onbevredigend, en dan wordt doorvragen een vereiste die je jezelf moet opleggen. Wanneer zegt je gevoel je dat de kern van de oorzaak is blootgelegd? En vind je gesprekspartner dat dan ook? Daarnaast is het uitermate belangrijk dat je, voordat je überhaupt het gesprek ingaat je eigen wensen, zorgen en belangen goed weet te beheersen, zodat deze geen belemmering vormen voor je nieuwsgierigheid. Een vraag als ‘Heeft er iemand ideeën hoe we de software naar een nog hogere kwaliteit krijgen, bijvoorbeeld door kwaliteit al vroeg in te bouwen?’ krijgt heel andere antwoorden dan de vraag ‘Hé prutsers, waarom schrijven jullie geen unit tests?!’: de eerste zinsnede nodigt uit tot samenwerking, de tweede euh…. niet.

Alleen als je een klimaat weet te vormen dat de gesprekspartners uitnodigt om overwegingen in vol vertrouwen op tafel te leggen  ontstaat er zicht op het gehele plaatje en kunnen er gezamenlijk routes worden gevonden om de wensen, zorgen en verlangens die in het team leven te integreren, met bovengemiddelde resultaten als gevolg.

De uitgebreide module ‘Onderhandelen’ is onderdeel van de training Agile-United Certified Specialist in Agile Testing. Wil je hier als software tester meer over weten of beter in worden, kijk dan op onze site.

 

Naar het overzicht