Hoe ik hopelijk (nóg?) betere presentaties geef
Laatst verzorgde ik een Developer Meet-up over het schrijven van (nóg betere) unittests. (De inhoud van die presentatie had ik al eerder uitgeschreven, in deze, deze en deze blog.) Volgens mij ging de presentatie heel aardig (jeej!), maar ik heb het meest geprofiteerd van alles wat er niet goed aan ging. Liever gezegd: ik heb het meest geprofiteerd van de woorden die mij die ochtend waren aangereikt om te kunnen duiden waarom sommige dingen beter konden.
Want toevallig volgde ik die ochtend een (online) masterclass online presenteren van Serge van Rooij - waar ik veel meer aantekeningen bij maakte dan ik op voorhand verwacht had. En omdat deze blog nu eenmaal het product is van een verwoede kennishamsteraar, deel ik met alle liefde de inzichten die ik graag nét een weekje eerder had willen weten.
Althans, de tien procent die ik heb weten te onthouden - want wat blijkt: dat is hoeveel mensen gemiddeld meenemen na een presentatie.
De drie B’s
Elke goede masterclass heeft een “drie-letter”-dingetje nodig om de aandacht van de managers in het publiek vast te blijven houden. In het geval van van Rooij zijn dat de drie B’s, de drie dingen die elke goede presentatie moet hebben:
Beleving
Behoefte
Boodschap
Omdat ik negentig procent vergeten ben, zal ik van Rooij vast vreselijk verkeerd citeren als ik zeg dat beleving slaat op de manier waarop je je verhaal overbrengt, behoefte gaat over het probleem dat je voor je publiek oplost, en dat de boodschap de feitelijke inhoud van je presentatie omvat.
Een interessante observatie is dat de meeste mensen relatief veel tijd steken in de boodschap van hun presentatie. De beleving blijft dan onderbelicht of wordt, in het ergste geval, zelfs vergeten. Men is zo druk bezig met het overbrengen van kennis, dat bijvoorbeeld er niet over nagedacht wordt de boodschap in een toegankelijke vorm te gieten. PowerPoints worden zo lange lappen tekst met aantekeningen.
Wat is het probleem?
Of de boodschap wordt zo belangrijk gemaakt, dat men glad vergeet om uit te leggen waarom er behoefte aan die boodschap zou zijn. Welk probleem los je hiermee op? Dat blijft onderbelicht. Toehoorders lopen de zaal uit met een hoofd dat niet verder rijkt dan: “Oké, interessant.” Terwijl je als presentator mikt op iets als: “Waarom heeft niemand me dit ooit eerder verteld?!” of “Dit wil ik onmiddellijk zelf toepassen!”
Deze valkuil valt makkelijk te ondervangen door het probleem expliciet op te nemen in de opbouw van een presentatie. Dat doe je als volgt. Deel je presentatie op in enkele hoofdstukken. Elk hoofdstuk begint met de stelling van een probleem. De rest van het hoofdstuk besteed je aan de oplossing ervan.
Om de presentatie tot een vloeiend geheel te maken, moet elke oplossing eindigen in een opstapje voor het volgende probleem. Wie de aandacht van zijn publiek vast wil houden, eindigt elk hoofdstuk met een verbale cliffhanger: een vraag die de toehoorder prikkelt om het volgende probleem aan te willen pakken. Een goede presentatie transformeert een luie toehoorder in iemand die actief (dat kan hardop zijn, maar ook in stilte) meedenkt over elk hoofdstuk.
Veel meer handige tips
Van Rooij had uiteraard nog veel meer handige tips, die ik niet verloren wil laten gaan (maar waarvoor ik te lui ben ze in een goed lopend verhaal uit te werken):
Start je presentatie met een ultakorte uitleg van het probleem. Leg daarna kort uiteen waarom uitgerekend jij degene bent die dit probleem op kan lossen. Het is fijn voor je publiek om te weten waarom ze naar je zouden moeten luisteren!
Een specifieke invulling van die ultrakorte uitleg is als volgt: 1. Stel drie vragen (bijvoorbeeld: “Heb jij last van onleesbare tests? Ben je langer bezig met het fixen van gebroken tests dan dat je er de voordelen van plukt? Of verdrinken je tests in ondoordringbare plumbing code?"); 2. Noem een tijdsbepaling (“Aan het eind van deze sessie…"); 3. Noem drie “-erren” (”…weet jij hoe je leesbaarder, robuuster en beter ontworpen tests schrijft!"). Het is een wat goedkope truc, maar: als het werkt, dan werkt het.
Begin het liefst elk hoofdstuk met een aansprekende anekdote die het probleem schetst. Het probleem uitleggen is prima, maar een verhaal is beter. Mensen zijn verhalende dieren, en je boodschap zal zo meer aansluiting vinden.
Het is bij hybride presentaties nagenoeg onmogelijk om beide soorten publiek - in de zaal en via de webcam - tegelijkertijd te bedienen. Probeer dit dan ook niet. Behandel de camera in de zaal eenvoudigweg als één van de aanwezigen. Spreek desnoods van tevoren af: neem alleen deel via de webcam als de presentatie minder relevant voor je is. (Dit was een tip van één van de andere deelnemers aan de masterclass.)
Las na elk hoofdstukje een vragenronde in. Check of mensen de boel begrepen hebben, dat houdt hen bij de les. Zeker bij online presentaties is dit een goed middel om ervoor te zorgen dat mensen niet afdwalen richting hun telefoon of e-mail.
Noem drie argumenten voor een stelling - en niet meer. Na meer dan drie argumenten beginnen mensen argwanend te worden. Als je meer argumenten paraat hebt, kies dan de beste drie voor je doelpubliek.
Sluit niet af met een vragenronde. Een vragenronde is prima, maar wanneer je deze als afsluiting inbouwt, dan geef je de controle uit handen over het gevoel waarmee je publiek de zaal verlaat. Bouw na de vragenronde nog een korte samenvatting in - noem niet meer dan drie punten! Dit zijn de hoofdzaken waarvan je wil dat je publiek ze onthoudt.
Optioneel: sluit af met een call to action. Daarin vraag je je publiek (of reik je hen aan) wat de kleinst mogelijke stap is die zij morgen kunnen ondernemen om hun nieuw opgedane kennis in de praktijk te brengen. Hoe kleiner, hoe beter, want des te groter is de kans dat ze het daadwerkelijk gaan doen!
Wat ik anders zou doen
Ik heb het geluk aan mijn kont hangen, want bij gebrek aan andere aanwezigen met een uitgewerkte presentatie, had ik de gelegenheid mijn Developer Meet-uppraatje voor van Rooij te houden. Hij gaf me enkele heel waardevolle tips, zoals: leg meer nadruk op het probleem, in plaats van direct naar de oplossing te gaan. Dit was een steeds terugkerend fenomeen in mijn presentatie, viel mij nu ook op. Een goede tip, vlak voor de daadwerkelijke presentatie!
Met het goed over kunnen brengen van de boodschap bleek het gelukkig wel redelijk goed te zitten. Toch had van Rooij ook hier nog een paar uitstekende tips in het verschiet. Zoals: koppel nieuwe kennis aan de al bestaande kennis van je publiek. In het geval van mijn presentatie betekende dat bijvoorbeeld: noem eerst het Arrange, Act, Assert-patroon van unittests, voordat het Given When Then-patroon van diens naamgeving uitlegt. Het is een simpele truc om ervoor te zorgen dat de informatie beter opgenomen wordt.
Zijn suggestie om mijn presentatie met een anekdote te beginnen heb ik ter harte genomen. Maar tijdens het presenteren werd het me op nogal ongemakkelijke wijze duidelijk dat ik wel iets meer tijd had mogen uittrekken om na te denken over hoe ik die anekdote zou vertellen. Als je het doet, doe het dan ook goed!
De belangrijkste les die ik leerde was echter: maak de boodschap veel, véél kleiner. Mijn presentatie zat zo erg tot de nok toe vol met informatie, dat ik er zelf op een gegeven moment ook moe van begon te worden. Tijdens het presenteren werd me duidelijk dat ik eigenlijk twee presentaties aan het geven was: één over tests als documentatie, en één over de wisselwerking tussen tests en het ontwerp van software. De tijd die ik zou winnen met het schrappen van de boodschap, zou ik steken in het beter uitwerken van het probleem.
Niet voor niets zegt men: de beste manier om iets te leren is om het andere mensen te leren. De afgelopen Developer Meet-up heb ik enorm veel geleerd over unittests én het geven van presentaties. - En eerlijk? Ik heb nu al zin in mijn volgende presentatie!