Na Javarsovii 2009 miałem okazję przyjrzeć się dwóm prezentacjom, które stanowiły swoje całkowite przeciwieństwo. Pierwsza z nich to genialna prezentacja Pawła Szulca o Apache Wicket. Druga to bardzo słaba prezentacja Jacka Zadrąga o Androidzie.
Zarówno Paweł jak i Jacek mieli wyrównane szanse. Mało czasu na przygotowanie (pierwszy dostał temat na dzień przed prezentacją, a drugi wrócił po urlopie) i temat na którym się znają. Nie będę analizował dokładnie co kto i jak zrobił, ale ci co widzieli obie te prezentacje wiedzą w czym bój.

Przygotowania

Mamy temat prezentacji. Musimy więc usiąść na dupie i przez 3 minuty pomyśleć co chcemy pokazać. Czasu mamy za mało, a materiał jest zbyt obszerny. Tak jest zawsze. Kto miał okazję być na prezentacjach Waldiego, ten wie, że dyskusję można ciągnąć do momentu, w którym wszyscy padną ze zmęczenia.
Takie przygotowania polegają na napisaniu na kartce tematyki, którą chcemy poruszyć. Nie jest na razie istotna kolejność. Ważne jest tylko to co chcemy przekazać publice. Kolejny krok to porządkowanie tej listy. Każdy element wynika z poprzedniego. Ciężko mówić o widgetach GWT, bez omówienia jak działa kompilator GWT. Jeżeli jakiś temat wymaga poruszenia dwóch innych to warto zacząć budować drzewo zależności. Na koniec porządkujemy to drzewo tak, że otrzymujemy plan prezentacji.

Szablon

Prezentacje zawsze będą szablonowe. Chodzi mi o pewne stałe elementy, a nie sposób ich realizacji. Zazwyczaj zaczynamy od przedstawienia się i kilku słów o sobie. Naprawdę kilku. Później zazwyczaj jest plan prezentacji, prezentacja właściwa, Q&A i zakończenie.

Plan prezentacji należy wytłumaczyć

Zawsze jak pojawia się slajd numer 2, czyli agenda rodzi się pytanie dlaczego prelegent przyjął taką, a nie inną kolejność. Zazwyczaj intuicja podpowiada, że ma to ręce i nogi. Warto jednak stojąc przed ludźmi, krótko powiedzieć dlaczego wybraliśmy taką, a nie inną kolejność. Warto to też zrobić z innego powodu. Jak przygotowujemy prezentację to agenda i jej przetrenowanie pozwalają przemyśleć kolejność.

Nie nudź

Prezentacje techniczne mają to do siebie, że obowiązują w nich pewne zasady. Wspomniałem o szablonach. Niezależnie jak będziesz się starać to poza te szablony nie nie wyrwiesz. Skoro nie można się wyrwać to należy je wykorzystać. Niech każdy krok prezentacji będzie nawiązywał do jakiegoś kulturowego elementu. Pawłowy Ali G był fajny. Paintball Jakuba Dziwisza też nieźle wyglądał. Pomimo braku merytorycznej wartości takie wstawki pozwalają na zainteresowanie ludzi tematem.

Przygotuj się na pytania

Przejrzyj FAQ technologii. Przeczytaj kilka tutoriali. Pytania są zazwyczaj standardowe, ale może się pojawić coś ciekawszego. Najważniejsza zasada nie wprowadzaj w błąd jeżeli nie jesteś czegoś pewien to powiedz, że nie jesteś pewien i odeślij do źródeł.

Zakończenie

Zazwyczaj ludzie po prezentacji chcą porozmawiać i dopytać o jakieś sprawy. Bądź do dyspozycji. Oczywiście jeżeli goni cię czas to poproś o kontakt mailowy.

Kodowanie na żywo

Zostawiłem to sobie na koniec, ponieważ jest to skomplikowana sprawa. Co do zasady kodowanie na żywo się nie sprawdza. zawsze popełnisz jakiś błąd i twoje ego oraz wizerunek eksperta stają się mocno zachwiane. Jest kilka sposobów na obejście tego problemu.
Pierwszy to przygotowanie screenshotów w ramach prezentacji. Jeżeli przy okazji wiesz o czym mówisz i kod jest przejrzysty to nie ma problemów.
Drugi to przygotowanie kilku wersji projektu. Kolejne stadia tworzenia aplikacji to kolejna wersja projektu. Wersja finalna musi działać i musi być przetestowana. Jest to może kapkę skomplikowane logistycznie, ale na prawdę się opłaca.
Generalnie kodowanie na żywo nie jest idealnym rozwiązaniem ponieważ wymaga rozdwojenia jaźni tak by kodować i jednocześnie opowiadać co się robi. Bez podzielności uwagi najprawdopodobniej się gdzieś walniemy. Dlatego kodowaniu na żywioł i na żywo mówimy zdecydowane nie.