Eindgebruikers horen
De snelste weg naar tevreden gebruikers, is door goede software te bouwen die doet wat het moet doen.
Dat klinkt makkelijk en dat is het niet. Waarom niet? Omdat software bouwen niet een kwestie van bouwen alleen is. Als dat zo zou zijn, dan zou de beste softwareontwikkelaar een mensenschuwe programmeur zijn, iemand die je het best met rust kunt laten, terwijl ‘ie als een razende specificaties omzet in code.
Sociale vaardigheden
Maar dat cliché is al lang niet meer van deze tijd. Natuurlijk, softwareontwikkelaars zijn geen softwareontwikkelaar geworden omdat ze zo graag met mensen werken, dat is nog steeds waar. Maar goede sociale vaardigheden zijn essentieel om dit werk te kunnen doen.
Dat is zo, ten eerste, omdat je vrijwel altijd in een team werkt. Het klinkt misschien aantrekkelijk om een meesterprogrammeur te zijn die alle problemen in zijn eentje oplost - ook zo’n cliché -, maar dat idee is al net zo achterhaald als de mensenschuwe variant. Je moet constructief kunnen overleggen met je teamleden over welke problemen je op wil lossen en hoe je dat wil doen. Wie niet goed kan samenwerken, is geen goede softwareontwikkelaar, klaar.
Eindgebruikers
Maar je hebt als ontwikkelaar niet alleen met teamleden te maken. Het contact met eindgebruikers is minstens zo belangrijk. Sterker nog, het is zelfs essentieel voor het bouwen van goede software.
Want ook de tijden dat softwarespecificaties in een vuistdik document werden aangeleverd, zijn definitief voorbij. Specificaties ontstaan tegenwoordig meer en meer in gesprek met businessexperts en eindgebruikers. (Die laatste kun je opvatten als experts in het gebruik van je applicatie - ook en vooral wanneer ze je applicatie niet snappen.)
Dat is één van de pijlers van Agile softwareontwikkeling: gesprekken boven documentatie, oftewel nauw contact met je doelgroep.
Drempel
Dat gezegd hebbende, merk ik dat er in mijn team - en ook bij mezelf - een drempel blijft bestaan om direct naar onze eindgebruikers te stappen. Alle achterhaalde clichés ten spijt, als ontwikkelaars kunnen kiezen tussen een gesprek - face to face, met rommeligheid die erbij komt kijken - of een gestroomlijnde lijst specificaties, dan kiezen ze voor het laatste.
Dat is een stukje cultuur dat met de tijd vast zal veranderen - maar nu nog niet.
Contact
Des te dankbaar ben ik voor onze functioneel beheerder, die bij elke melding van een nieuwe bug direct contact zoekt met degene die ’m ingeschoten heeft. Dat doet ze in eerste instantie om diegene uit te kunnen vragen, natuurlijk. Het is een stuk efficiënter om iemand direct te vragen waar hij of zij mee bezig was toen de applicatie onverwacht gedrag vertoonde, dan deze te verzoeken eigenhandig een repropad uit te schrijven.
Maar ze zoekt dat contact ook - en dat is misschien nog wel belangrijker - om een luisterend oor te bieden, om de gebruiker te laten weten dat hij of zij gehoord wordt en dat het team ermee aan de slag gaat. Misschien niet onmiddellijk - die garantie heb je nooit, zeker niet in een Agile omgeving -, maar wel zo snel mogelijk.
Tevreden
Dat onze gebruikers enigszins tevreden zijn met ons, het ontwikkelteam - ook als de opgeleverde functionaliteit niet helemaal werkt zoals verwacht, zelfs als onze bugs productieverstoringen veroorzaken -, is voor een groot deel te danken aan het uitstekende klantcontact van met name onze functioneel beheerder.
De snelste weg naar tevreden gebruikers, is door goede software te bouwen die doet wat het moet doen. Maar omdat we niet allemaal meesterprogrammeurs kunnen zijn, is het goed om een sluiproute in het achterhoofd te houden. Gehoord worden is net zo goed een weg naar tevredenheid.
agile ontwikkeling · bedrijfscultuur · communicatie · empathie · samenwerking · stakeholders · waarde