Empathie met je stakeholders
Software ontwikkelen is meer dan alleen code schrijven. Sterker nog, één van de leukste dingen aan het vak is het scala aan competenties dat erbij komt kijken - en de ontwikkelmogelijkheden (no pun intended) die dat met zich meebrengt.
Zo las ik onlangs bijvoorbeeld Articulating Design Decisions van Tom Greever en vond daar een schat aan informatie in, ondanks dat ik geen designer ben.
In gesprek met je stakeholders
Wat een designer en een softwareontwikkelaar met elkaar gemeen hebben, is dat ze het gesprek met hun stakeholder aan moeten gaan.
Designers hebben daarin een nadeel ten opzichte van softwareontwikkelaars. De meeste stakeholders hebben weinig kaas gegeten van programmeren. Daarom hebben ze geen bijzonder sterke mening over de code die je elke Sprint oplevert.
Op het gebied van design is iedereen echter zijn eigen ervaringsexpert. Het gevolg daarvan is dat stakeholders zich graag bemoeien met de plaatsing van knoppen op een scherm, of de manier waarop een navigatiemenu is opgebouwd.
Dat kan frustrerend zijn voor een designer. Hij1 kan het gevoel hebben dat zijn expertise in twijfel wordt getrokken, elke keer als zijn keuzes door een stakeholder overruled worden.
Het is alsof de CEO er tijdens een meeting ineens op staat dat je een event-gedreven architectuur ombouwt naar een microserviceslandschap. Denkt hij1 soms dat de keuze voor die architectuurstijl uit de lucht is komen vallen?
Wat te doen?
Articulating Design Decisions biedt een breed palet aan handige tips om dit soort situaties in goede banen te leiden.
“Welk probleem los je op?”
Een voorbeeld. Je kunt je stakeholder vragen: welk probleem probeer je nu op te lossen? Door hem ertoe te verleiden zijn gedachteproces bloot te geven, kun je inspringen op zijn wensen en behoeften. En omdat je een professional bent (en hij maar een ervaringsexpert), kun je dat beter dan hij zelf.
Misschien kan die eenvoudige vraag het kwartje bij hem doen vallen dat er voor zijn oplossing überhaupt (nog) geen probleem bestaat.
Wat je op dat moment doet, is de lens veranderen waardoor je stakeholder naar je ontwerp kijkt. Je verlegt de focus van zijn persoonlijke smaak, naar een op te lossen taak.
Toon de oplossing
Nog een voorbeeld. Wie zijn stakeholder een beetje kent, kan voorspellen wat voor designvoorstellen hij tijdens een meeting zal doen. Greevers suggestie is voor de hand liggend, maar wordt maar zelden in de praktijk gebracht: werk dat voorstel uit.
In het gunstigste geval blijkt het een beter voorstel te zijn dan je oorspronkelijke idee. Het uitwerken van meerdere oplossingsrichtingen dwingt je om geïnformeerde keuzes te maken, in plaats van te gaan voor het eerste idee dat in je opkwam.
In elk ander geval ben je in elk geval goed voorbereid als je stakeholder de suggestie doet. Je kunt haarfijn uitleggen wat de voor- en nadelen van je oorspronkelijke ontwerp zijn ten opzichte van deze nieuwe variant. Soms is het tonen van de voorgestelde oplossing al voldoende om te laten zien waarom deze niet zal werken.
De kern
Wat deze tips met elkaar gemeen hebben, is dat je je inleeft in je stakeholder. Dit is de kern van Greevers boek.
Deze gewoonte is in de IT-wereld inmiddels redelijk ingeburgerd voor eindgebruikers. Maar het is schokkend om te zien hoe moeilijk designers en ontwikkelaars - ikzelf niet uitgezonderd - datzelfde empatisch vermogen wensen in te zetten voor de mensen die hun projecten financieren.
Dat terwijl het aan het eind van de dag zonneklaar is: software ontwikkelen is meer dan alleen code schrijven. Voor een geslaagd project, heb je de steun van je stakeholders nodig. Ik kan Articulating Design Decisions dus aan elke designer én ontwikkelaar aanraden.
Of zij, natuurlijk. Maar voor het gemak houd ik in deze blog de mannelijke variant aan. ↩︎
boeken · communicatie · empathie · software ontwikkelen · stakeholders