Gelukkig kan ik geen huizen bouwen

  • Posted on:  donderdag, 20 september 2018 09:28
  • Written by 

Vlak voor een presentatie van een collega over de vergelijking tussen testautomatisering en de architect Frank Gehry, werd ik gewezen op dit artikel* waarin wordt verteld dat de vergelijking tussen softwareontwikkeling en huizenbouw losgelaten moet worden.  En toch kwam er toen een metafoor mijn brein binnen gewandeld over, jawel, de vergelijking tussen softwareontwikkeling en het bouwen van huizen...

Echt wel waar gebeurd?

Stel, je bent aannemer en hebt een opdracht uitgevoerd voor een rijke klant. Het huis is gebouwd. Compleet met gouden randjes om het hekwerk, automatische zonwering, garage voor drie auto's en uitschuifbaar kelder-zwembad. Kortom, aan alles is gedacht en tot in de puntjes netjes afgewerkt voor de klant. Echter, je hebt de klant nooit gezien. Wel vaak gesproken via telefoon en in nauwe samenwerking met de architect en andere stakeholders een prachtige woning afgeleverd waar de kersverse eigenaar vast zeer gelukkig mee zal zijn. Trots sta je op een maandagmorgen, een week voor (!) de deadline, voor de dubbel uitgevoerde eikenhouten voordeur, op de derde trede van de toegangstrap te wachten met de sleutel in je hand om deze te overhandigen aan je klant. Glimlachend zie je hem aan komen rijden in zijn Bentley. Je herkent zijn gezicht van de foto's en neemt met genoegen waar dat meneer zelf achter het stuur zit. Aan het eind van de oprijlaan stopt de wagen, waarna de assistent als eerste uitstapt, de achterklep opent en tot jouw stomme verbazing een rolstoel uit de auto tilt. De bestuurder gooit zijn deur open en klimt handig in de rolstoel. Duidelijk is dat de klant dit vaker heeft gedaan en dit geen tijdelijke rolstoel is. Terwijl je gezicht wit wegtrekt en je sterk afvraagt wie de eigenaar de trap op gaat tillen, zie je beide heren met opgetrokken wenkbrauw naar de trap kijken die toegang biedt tot de woning. Hoe konden we dit missen...?

De vergelijking

Ik weet niets van het bouwen van woningen en de samenwerking tussen aannemer, architect en klant in dit soort gevallen. Ik hoop dan ook dat bovenstaand voorbeeld nog nooit is voorgekomen. Ik kan me niet voorstellen dat zo'n gigantisch project uitgevoerd zal worden zonder de allerbelangrijkste requirement over het hoofd te zien: "De woning moet goed toegankelijk zijn met een rolstoel."

Toch zie ik regelmatig IT projecten waar requirements die achteraf voor de gebruiker of voor de productowner overduidelijk waren, niet in software terecht zijn gekomen. Wat zou hiervan de reden kunnen zijn? 

Men kent elkaar niet

Zoals de aannemer de klant niet persoonlijk kende, zo kennen veel ontwikkelteams hun gebruikers niet. Ik snap dat je als ontwikkelteam soms ook liever niet de gebruiker dichtbij hebt. Laat me een aantal vooroordelen nieuw leven inblazen: 

  • Gebruikers weten niet wat goed is voor ze. Omdat ze geen verstand hebben van hoe software gebouwd wordt, komen ze regelmatig met de vreemdste verzoeken.
  • Als je een gebruiker een concrete vraag stelt, komt er geen antwoord op je vraag, maar wel drie bugreports, twee change requests en één niet-reproduceerbaar probleem dat wordt omschreven als "Gisteren deed ie iets raars".
  • Ze gebruiken de software niet zoals de bedoeling is. Ze hebben workarounds die niet nodig zijn en werken omslachtig. 

 Sorry, beste gebruikers. Ik snap dat ook die IT'ers niet altijd (of 'altijd niet'?) prettig zijn om mee te werken. Wat dacht je van:

  • Ontwikkelaars zitten graag op hun eigen eilandje. Heeft je probleem niets met hun werk te maken, dan besta je niet voor ze.
  • Jouw probleem heeft nooit met hun werk te maken.

Tot zover de platvloerse vooroordelen. We weten allemaal dat je mensen niet zomaar in hokjes kan stoppen, maar toch zal je als lezer wel enige herkenning zien bij jezelf of bij anderen als je bovenstaande punten leest. Ik heb in verschillende organisaties rond-gelopen en regelmatig gaten geconstateerd tussen wat er is ontwikkeld (of ontwikkeld gaat worden) en wat de gebruiker nu echt nodig heeft. Bepaalde functionaliteit wordt bijvoorbeeld in stand gehouden, terwijl de gebruikers al een jaar lang een andere manier van werken hebben. Ze zijn trouwens anders gaan werken omdat er een bug in de software zat die zonder dat ze het wisten een half jaar geleden al is opgelost.

Een ander voorbeeld: Een nieuw scherm wordt ontwikkeld en de lijst met backlog items voor dat scherm is gigantisch. Er moet geprioriteerd worden. Diverse mensen in het IT-team buigen zich hierover, waarbij bepaalde items niet meegenomen worden in de eerste release, terwijl later blijkt dat dit showstoppers zijn waardoor het nieuwe scherm vertraagd is.

De oplossing

Communicatie.

En nu niet met z'n allen in een hokje gaan zitten, heel veel praten, schouders ophalen en weer terug aan het werk gaan, maar doelgerichte samenwerking tussen klant en opdrachtnemer. Zet er desnoods een productowner, scrummaster en/of business analist tussen die de vertaalslag kan maken tussen de stakeholders. Maak heldere afspraken over welke persoon/rol welke verantwoordelijkheid heeft in de communicatie. Is de productowner de enige die met stakeholders mag praten buiten het scrumteam? Het gevaar ligt op de loer dat er dan een bottleneck ontstaat en er niet genoeg informatie het team bereikt. Laat teamleden zelf contact opnemen met stakeholders om zaken te verduidelijken. Zorg voor een scrummaster om het proces in de gaten te houden. Worden de teamleden te veel afgeleid door vragen van stakeholders en komt het sprintdoel in gevaar? Gebruik de demo en sprintreview om ruimte te creëren voor deze vragen en helderheid te geven over hoe het volgende increment eruit komt te zien. Het team kan moeite hebben met het vertalen van de klantwens in werkende software. Klanten denken immers in vormen, developers in pixels. In dat geval is het handig om een business analist in het team op te nemen, zodat de vertaling beter wordt. Het is natuurlijk aan de scrummaster om het management te overtuigen dat het team dit nodig heeft om optimaal te functioneren.

Tijdens verschillende opdrachten was ik in de gelegenheid om te investeren in de communicatie tussen gebruikers en developers en ik was op verschillende manieren verrast:

  1. Men weet echt verdacht weinig van elkaar. Toen ik voor het eerst iets leerde over het vak van software tester werd mij verteld dat je als tester tussen business en IT in staat en als het ware een spin in het web bent. Omdat ik makkelijk met beide groepen mee kan was ik me niet bewust van het feit dat sommige gebruikers geen idee hebben wat er allemaal met hun verzoek gebeurt in een software development proces. En nadat ik een halve dag met een administratief medewerker had meegelopen dacht ik "Dit moet de proceseigenaar weten. Hier kan zoveel van geleerd worden!"
  2. Liever vervelende communicatie dan geen communicatie. Zodra je nieuwe vormen van communicatie gaat introduceren binnen een bedrijf, kom je blokkades tegen. En bij mij zitten die blokkades vaak in mezelf. Ik hou niet van slecht nieuws brengen of de confrontatie aangaan. "Wat als mensen hier niet blij mee zijn?", dacht ik. Toch was ik blij verrast dat deze blokkades vooral in mijn hoofd zaten. Het vreemdste vond ik nog dat gebruikers het op prijs stelde dat ik het liet weten als we een verzoek niet gingen inwilligen. Gewoon een keiharde 'Won't fix'. We doen het niet, verzoek gaat de prullenbak in. Gaat gewoon niet gebeuren. Daar kreeg ik een bedankje voor. Waarom? Vanwege de duidelijkheid. Ik vraag om feedback, ik krijg feedback. Wel zo prettig voor de gebruiker om te weten wat er met die feedback gebeurt.
  3. Liever een slechte planning dan geen planning. We kunnen geen seconde in de toekomst kijken, laat staan een driemaandenplanning opleveren. Toch wordt dat soms van ons verwacht. Ik heb gemerkt dat als ik bang ben om mijn verwachtingen te communiceren, ik regelmatig mezelf teleurstel omdat ik het gevoel heb bepaalde (niet uitgesproken) deadlines niet haal. Ik heb ook gezien dat als we als projectteam geen langetermijnplanning opleveren, de verwachtingen van de stakeholders vaak positiever zijn dan dat wij in ons hoofd hebben. Gevolg: teleurstelling, bochten afsnijden en functionaliteit opleveren van lagere kwaliteit. Lever die planning op. Zet een datum. Wijk ervan af als het nodig is. Maar geef duidelijkheid.

Gaat heen in vrede en communiceer

Ik zeg niet dat het gemakkelijk wordt. Alle problemen verdwijnen als sneeuw voor de zon? Absoluut niet! Het wordt zelfs lastiger, want je moet gaan praten en dingen uitleggen aan mensen waar je doorgaans niet zo gemakkelijk of graag mee spreekt. Op de lange termijn zal het je veel tijd en geld opleveren. De ontwikkelaars zullen items oppakken die begrepen worden en minder snel teruggekaatst worden. De gebruikers zullen beter begrijpen wat ze in hun schoot geworpen krijgen en zullen doeltreffender feedback geven. Software gaat écht waarde toevoegen en gebruikers zullen sneller verbetering in hun werk zien door de nieuwe functionaliteit. Ontwikkelaars zullen merken dat ze minder 'issues' voorgeschoteld krijgen die eigenlijk weer wijzigingsverzoeken zijn.

Een paar weken geleden zag ik op nos.nl een juriste in een rolstoel die Amsterdam doorkruiste op zoek naar slecht of niet begaanbare toegang voor mensen met een beperking. En ook al was er soms een rolstoelhelling, als deze een te grote hellingshoek heeft is het leuk geprobeerd, maar niet te doen om veilig omhoog te rijden. Waarschijnlijk een snelle oplossing om een inspecteur of gemeenteambtenaar tevreden te stellen, maar echt werkbaar is het niet. Als de aannemer uit mijn inleidend verhaaltje dit had gedaan, was de bewoner waarschijnlijk niet blij geweest. Stel dat hij binnen was gekomen, wat voor drempels en andere problemen hadden hem dan te wachten gestaan?

Zie jij in je project gaten ontstaan, omdat de stakeholders elkaar niet kennen? Zie je dat er oplossingen worden bedacht die in de praktijk niet gaan werken? Geef het aan, stel de strikvragen, waarschuw, doe er wat aan. Zo word jij degene die laat zien dat software echt waarde heeft wanneer zowel gebruiker als developer begrijpt waarom het moet werken zoals het werkt.

*https://itexecutive.nl/management/verkeerde-metaforen-zijn-hardnekkig-ook-in-de-it/

Richard Dekker

Tester, Apple fanboy, docent, muzikant en vader. Maar nu even schrijver.

Volg me ook op LinkedIn