Ich bin aktuell am Reflektieren. Der Auslöser ist meine erstmalige Teilnahme bei der #NRWConf im September. Seit mindestens 15 Jahren spreche ich auf Entwicklerkonferenzen.
TechEd, Basta, Synopsis, Microsoft Days, TechDays, Winsummit, TechTalk, VSone, ADC, GUI&DESIGN, ICE Lingen, Developer Conference Hamburg, SDN Netherlands ...
Dazu veranstalten wir auch eigene Formate mit teilweise über 500 Teilnehmer wie SharePoint Conference, ADC++, ADC X, VSOne, SQL Days und GUI&DESIGN.
Ich habe also hunderte Auftritte verfolgt. Viele waren gut, einige bodenlos, manche aber auch sensationell.
Es ist relativ einfach für die “Geht gar nicht”-Sprecher und Vorträge Ursachen zu nennen:
- Samples gehen nicht
- Vortrag endet viel zu früh
- Spricht undeutlich
- monoton
- Inhaltlich völlig daneben
- wirkt unvorbereitet
Die üblichen Rhetorik-Tipps tauchen da nicht auf, wie
- schaut zur Wand
- Körperhaltung
- Füllwörter wie Äh..
Das mag in mittelmäßigen Sessions nicht stören.
Schwierig wird es herauszufinden, was einen Top-Vortrag ausmacht. In unserem Team haben wir zwei Kollegen, Martin und Andreas, die in den Teilnehmerfeedbacks über mir liegen können. Martin hatte auf dem letzen Microsoft Server Summit den Top-Vortrag im Teilnehmerranking. Ich war leider nicht dabei, um zu analysieren warum. Aber andere #1 Sprecher und das passende Thema kenne ich.
- Clemens Vasters zu .Net-Zeiten
- Christian Weyer über WCF
- Neno Loje speziell zu ALM
- Ingo Rammer: Debugging
- Michael Willlers mit dem Finger in der Wunde
- Rainer Stropek: Live Coding
- Don Box über SOAP
- Scott Hanselman zu allem
- Anders Hejlsberg zu C#
Dies nur als Auszug. Ich hoffe, damit niemanden vor den Kopf zu stoßen, weil er in dieser subjektiven Hannes-Hit-List nicht auftaucht. Ich frage mich jedes Mal: was haben diese Sprecher gemein? Es sind alles Männer. Sonst eint sie jedoch wenig. Einzig die Begeisterung für ihr Thema. Wobei bei Mr C# sich diese durchaus verbergen kann, das ist eher ein religiöser Akt.
Ein durchaus häufiger Diskussionspunkt ist PowerPoint. Ich halte wenig von Zero Slides - Just Code Vorträgen. Manches muss einfach skizziert werden. Didaktisch ist das natürlich super, wenn man das live per Pen-Eingabe tun kann, weil dann der Teilnehmer die Entstehung lernt. Das kostet aber viel Zeit. Meine Regeln dazu:
- Gut lesbar bis zum letzten Platz
- nichts wichtiges im unteren Bereich
- weniger Text ist mehr
- mindestens 2 Minuten pro Slide einkalkulieren
Konferenzslides haben das Ziel, den Vortrag zu stützen und nicht als Lernunterlage zu dienen!
Softwareentwickler machen interessanterweise bessere Vorträge als IT Pros, wobei letztere durchaus aufgeholt haben. Es muss wohl am Code liegen. Da gibt es einige Fraktionen: die, die runterkodiert als wär's ein Maschinenschreibwettbewerb, diejenigen, die aus der Toolbar dragen und droppen, die mit Code in PowerPoint und die mit einem fertigen Sample.
Demo-Code sollte nie wesentlich länger als eine Bildschirmseite sein. Wenn möglich sollte man diesen tippen, um dem Zuseher mehr Einblick in die Entstehung zu gewähren. Variablen nenne ich immer möglichst sinnfrei. Ich bin als Teilnehmer oft verwirrt, ob das nun eine Framework-Funktion ist oder per Nuget-Wunder erschienen ist. Das stört das Lernen.
Und Code muss funktionieren. Also vorher ausprobieren. Live-Bugfixing kommt nur selten gut an. Man merkt das sofort am steigenden Geräuschpegel im Auditorium. Plötzlich verspürt jeder Hustenreiz.
Vorträge müssen eine Geschichte erzählen. Sie sollen einen Anfang und ein Ende haben, mit Höhepunkten in der Mitte. Wie prüfe ich vorher, ob die Geschichte wirkt? Bei sehr großen Events wie der TechEd gibt es sogenannte Rehearsals. Also eine Probe vor kleinem Fachpublikum. Ich hasse das. Ich brauche das echte Publikum, um mich entfalten zu können. Persönlich bin ich dazu übergegangen, die Session per Camtasia einmal oder auch mehrmals aufzuzeichnen. Mein persönlicher Review. Ich lade auch gerne Kollegen ein, sich die Videos anzusehen. Dabei lernt man natürlich auch die Samples fehlerfrei runterzutippen bzw. die Stolpersteine kennen.
Hab ich das schon erwähnt? Die Samples müssen laufen!
Dazu bedarf es natürlich einwandfreier Technik. Immer die Adapter dabei haben, einen Presenter und eine externe Maus. Seit vielen Jahren nutze ich einen zweiten Monitor, der per USB angeschlossen wird. Ich verwende ein älteres Modell von MiMo. Die Kollegen setzen auf was größeres von Lenovo. Beide per USB ohne zusätzliche Stromversorgung nutzbar. PowerPoint 2013 zeigt dann die Notizen im zweiten Monitor an. In die Notes schreibe ich mir dann Zahlen oder Namen rein, die nicht unmittelbar geläufig sind und auf den Slides aus didaktischen Gründen keinen Sinn machen.
Früher hatte ich auch die Code-Samples auf dem zweiten Screen per Notepad geöffnet. Heute nutze ich dafür wieder Papier. Für jede Demo ein Blatt in großer Schrift mit Textmarker-Highlight auf Stellen, in denen ich gerne Fehler mache, z.B. typische Buchstabendreher oder fehlende Imports.
All das macht mich zu einem guten Sprecher. Wenn die Tagesform stimmt, es mein Thema ist und das Publikum mitzieht, werde ich sehr gut. Aber noch nicht der Beste.
Auf meiner TechEd-Teilnahme hatte ich eine lange Diskussion zum Thema. Spannend ist, dass Sessions am ersten Tag schlechter bewertet werden. Am besten läuft's ab Tag 3, ab dem späten Vormittag. Themen, in denen neue Produkte und Features gezeigt werden haben #1 Potential. Oder Themen, die so in die Tiefe gehen, dass kaum mehr wer im Saal mitkommt.
Entertainment kommt immer gut an, will aber geübt sein. Ich hatte drei Mal in meinem Leben die Chance ein Thema in einer Tour zu präsentieren. Bis zu 20 Mal dasselbe. Da kannst du an jedem Wort feilen. Ist echt eine super Erfahrung. Witz und Ironie sind aber auch ein gefährliche Sache. Ich hatte in einem User Group-Vortrag eine sehr dicke Frau in Leggings in meinen Slides. So etwas geht in Österreich und vielleicht in Bayern. Woanders hatte ich im Anschluß eine Beschwerde im Postfach. Für die ich übrigens sehr dankbar bin. Fettnäpfchen müssen raus. Eine 6 im Feedback reicht, um dich von deinem #1 Ziel zu entfernen.
Und nicht vergessen: die Beispiele müssen 100 % funktionieren.