Feedback-blokkades doorbreken

Feedback verbetert samenwerking tussen mens en software. We werken niet altijd samen met degenen die onze software bouwen: Programmeurs mógen soms zelfs geen contact opnemen met de klanten. Minstens zo vaak durven ze zelf niet contact te leggen met buitenstaanders. Toch smacht elke programmeur ernaar software te maken die de eindgebruiker helpt. Vertel ze dus zo vaak mogelijk wat u vindt van het product!

Feedback op software: vanzelfsprekend?

Hoe meer feedback op software (in ontwikkeling en in beheer) je geeft, hoe beter de programmeur de software kan “kneden” naar je wensen. Zonder die feedback, is het ontwikkelteam gedwongen te fantaseren over wat je wilt. En dat leidt tot sub-optimale resultaten.

Iedereen weet dat dit zo werkt, maar in de praktijk krijgen nog veel gebruikers iets anders dan ze nodig hebben. Als feedback dan zo goed werkt, waarom komt de feedback dan niet aan?
Nou, daar zijn redenen voor:

• Op het moment van signalering is er geen communicatiekanaal voor de feedback
• Directe communicatie is verboden/afgeremd, dit is via-via feedback
• Gebruikers zijn te bescheiden om feedback te uiten

Op elk van deze drie ga ik wat dieper in.

Geen communicatiekanaal als ‘het mis is’

Als je software pruttelt, of zelfs “crasht”, verrast hij je: Je bent ontdaan en weet je even geen raad. Snel daarna ben je woedend, omdat software de taak verstoort die je nu wilt volbrengen. Die taak is veel belangrijker voor je dan die software, dus vergeet je waarschijnlijk rustig je stappen na te gaan om te rapporteren wat er gebeurde: “Het rotding is fout, mijn werk is weg en nu moet ik ook nog extra tijd investeren in het opschrijven van wat er foutging? Het raam uit met die troep!”
Heel begrijpelijk, maar alléén die stapsgewijse beschrijving (feedback!) maakt de softwarefout herhaalbaar en die heeft de bouwer nodig om het op te lossen.

Zo’n gedetailleerde vastlegging van (verstorende) softwarefouten kent een technisch alternatief:  automatische crash rapportage. Een zelf-feedback-module in het systeem registreert wat je aanklikt en intypt. Als de software crasht stelt hij zèlf een stapsgewijs rapport op en stuurt dit direct naar de bouwers. Steeds meer software, zoals Windows zelf, heeft zelf-feedback ingebouwd.

Als software niet crasht, maar toch fouten maakt, weet de gebruiker niet aan wie ze de klacht kan richten. In het gunstigste geval komt de feedback tot de drukke afdeling automatisering: een notoir zwart gat. Het is zeldzaam als de bouwers er ooit van horen.

Laat voor deze feedback een feedbackformulier inbouwen, met uitleg over hoe men een schermfoto toevoegt. Elke gebruiker krijgt zo een direct communicatiekanaal naar de bouwers/beheerders. Nog mooier is het als gebruikers onderling elkaars feedback inzien, steunen en een dialoog ontstaat met de bouwers. (voorbeeld: UserVoice met een video-demo).

De uitdaging ligt dus bij progammeurs en opdrachtgevers: verwerk feedbackkanalen waarnaar de bouwers luisteren. Geef de gebruikers de mogelijkheid om zich te laten horen als het hèn uitkomt.

Verboden direct te communiceren: via-via feedback

Goedbedoelende managers kanaliseren soms feedback: “Alles gaat via mij.” In formele onderhandelingen is dat begrijpelijk, maar het is schadelijk om feedback op software te leiden via een tussenpersoon. Iedere tussenpersoon kleurt de boodschap verder. Het is wèl goed als iemand het overzicht behoudt en taken prioriteert, net zoals het ontwikkelteam niet rücksichtlos àlle feedback moet verwerken tot “verbeteringen”.
Het is pertinent verkeerd om de feedback te onthouden van de bouwers: kennisneming ervan voorkomt toekomstige fouten.

Met name het aantal keer dat dezelfde fout wordt opgemerkt is een graadmeter die verloren gaat in de ‘trechter’ van één tussenpersoon zonder industrieële softwaretestexpertise.
Stuur de ruwe feedback zowel naar de bouwers als naar iemand die overzicht houdt.

Bescheidenheid remt

Uw meest ervaren medewerker weet dat de optelsom die het ERP systeem oplevert niet klopt, maar ze zegt er niks over, want ze “weet niks van computers“. Zonder dat u het weet doet zij dubbel werk vanwege die softwarefout. Dit komt vaker voor dan u denkt! En dat is nog is maar intrinsieke bescheidenheid, er bestaat ook veel aangeleerde bescheidenheid:

Mussolini-systeembeheerders hebben sinds jaar en dag patent op dictatoriale automatisering: Intussen is het normaal dat de printer het niet doet en dat je koffie kunt halen terwijl je je computer start. Desgevraagd vertelt Mussolini de “technische” reden die in de weg staat, die je alleen begrijpt als je zelf systeembeheerder bent. Gebruikers zijn geconditioneerd om hun feedback in te slikken.

Bouwers weten minder van de taak dan de gebruikers. Net zo min weet de baas het fijne van de taken op de werkvloer. Ontzag voor expertise (techneuten) en status (de baas) staan eerlijke feedback in de weg. Overtuig je medewerkers dus altijd dat hun inzicht klopt en dat software gebouwd wordt om hun taak te vergemakkelijken. Zwengel die discussie maar aan en geef elke domeinexpert het zelfvertrouwen dat nodig is om zijn bescheidenheid te overwinnen.

De volgende vraag dient zich aan als toegift: Als we de drie voornoemde feedbackblokkades wegnemen, krijgen we dan niet meer feedback dan we aankunnen?

Misvatting: teveel feedback

Soms zeggen mensen dat ze geen feedbacksysteem willen, uit vrees voor lawines feedback. Welnu, die angst is ongegrond.

Hoe vaak vult u zelf een online klachtenformulier in als u een spelfout ziet in een online nieuwsartikel? En hoeveel lezers zullen gebruik maken van het reactieformulier bij het artikel dat u nu leest? Laten we ons geen illusies maken: software interesseert de meeste mensen bar weinig. Slechts een enkeling is zo lyrisch/boos dat hij zich laat horen. Door de drempel voor feedback te verlagen, mengt zich hopelijk ook wat “normaler” publiek (in de statistische zin).

Maar stel dat je verzuipt in je feedback. Is dat een probleem? Als het positieve feedback is is iedereen dolblij. Als je lawines negatieve feedback verwacht, doe je sowieso iets fout. Dan is het maar goed dat je er van hoort.

Meer lezen?

Feedback als softwareverbeterinstrument is ruimschoots beschreven in de literatuur. Een toegankelijk startpunt is het boek Why Software Sucks, D. Platt. Platt suggereert om het niet bij feedback te laten, maar ook publieke vernedering van- en frontvorming tegen bouwers die niet luisteren in te zetten.

Anecdotes over Mussolinis (BOFHs) lees ik graag op de online verzamelplaats Worse Than Failure.