Z racji tego, że niedawno zakończyłem tournée po konferencjach IT Academic Days na Pomorzu oraz aktualnie mam wiele okazji, by prowadzić prezentacje związane z AppCampem i Oculus Riftem, opiszę poniżej jak moim zdaniem nie powinna wyglądać prezentacja techniczna.

Na wstępie pozwolę sobie rozróżnić prezentację techniczną od warsztatów czy szkoleń. Celem dwóch ostatnich jest przekazanie jak największej ilości informacji uczestnikom wsparte materiałami czy ćwiczeniami praktycznymi – wszystko w myśl zasady: usłyszysz – zapomnisz, zobaczysz – zapamiętasz, zrobisz – zrozumiesz.

„O tym więcej mowy nie będzie” – chciałbym tak powiedzieć. Niestety podstawowy problem prezentacji jaki zauważam jest ich zbyt duży odchył w kierunku formy warsztatowej. Jak się to objawia? Prezenterzy umieszczają w swoich prezentacjach duże ilości rozwiązań konkretnych problemów. Fakt, fajnie jest zobaczyć jeden, dwa przykłady zastosowania, w których dodatkowo ujawnia się dodatkowe zalety prezentowanej technologii. Ale iterowanie po dużej ilości przykładów zawierających pełne rozwiązanie uważam za zbędne.

Na przykład – jeśli zainteresuje mnie na prezentacji nowa technologia przetwarzania wideo sam sprawdzę, jak zmienić za jej pomocą mp4 na avi. Wystarczy informacja na prezentacji, że mogę oraz jeden przykład, który pokaże że jest to łatwe.

Kolejnym problemem jest live coding. Można do niego podejść na dwa sposoby – pisanie od zera albo prawie od zera oraz korzystanie ze snippetów/gotowego kodu. Pierwsze podejście jest fajne w przypadku bardzo małych fragmentów kodu, które nie zdążą zanudzić słuchaczy. Nudne mogą być z dwóch powodów – odbiorca rozumie za mało albo za dużo.

Pierwszego przypadku wyjaśniać pewnie nie trzeba – na pierwszym roku studiów zdarzyło mi się pójść na prezentację o Silverlight mimo iż nie znałem C#. Sama technologia mnie zaciekawiła, ale prawie żadnego przykładu nie rozumiałem i nudziłem się podczas nich strasznie. Z kolei obecnie widząc live coding w C# nudzę się również, ponieważ zanim osoba skończy pisać już wiem do czego dąży. Człowiek z reguły szybciej myśli niż pisze :D.

Kończąc wątek kodzenia na żywo zarzucę moją teorią. Prezenterzy piszą kod na prezentacja bo nie mają wystarczająco dużo materiału na samą prezentację. Wszak programiście łatwiej jest napisać kod niż przygotować slajdy.

Zarówno dużo konkretnych przykładów, jak i pisanie na żywo (szczególnie z uczestnikami!), są jak najbardziej potrzebne podczas warsztatów – uczestnicy mogą się dopytać, spróbować samemu to napisać itp. Na prezentacjach ich wrogiem stał się Google i internet – nie trzeba silić się na zapamiętanie konkretnej treści 1h prezentacji – wystarczy wiedzieć, co wpisać w wyszukiwarce podczas nauki tego na własną rękę.

Co zatem moim zdaniem powinno znaleźć się na prezentacji technicznej? Według mnie są trzy elementy dla każdej prezentowanej technologii/rozwiązania:

  1. Podstawowe informacje, dzięki którym będę wiedział do czego mogę tego użyć.
  2. Dlaczego mogę zechcieć tego użyć.
  3. Gdzie w razie potrzeby mogę znaleźć więcej informacji.

Jeśli prezentacja odpowiada na te 3 pytania (lub prelegent odpowie podczas Q&A) zapewne w razie potrzeby zagłębie się bardziej w temat – najważniejsze, że będę wiedział czego szukać :-).