Nikola Buhiniček iz Productivea na ovogodišnjem je izdanju .debuga održao predavanje “Kako razvijati feature 2 godine i ne dobiti otkaz?“. Posjetitelji su to predavanje ocijenili vrlo visokom prosječnom ocjenom od 4,55, a tri od četiri ocjene bile su čista petica. Stoga smo dogovorili s Nikolom da za naš portal napiše savjete o tome kako, kao developer koji nema iskustva s predavanjem, svoje znanje i iskustvo pretočiti u dobro predavanje za konferenciju poput naše. Njegov tekst donosimo u nastavku.

Kako se pripremiti za vaše prvo javno predavanje?

Ove godine sam dobio priliku da prezentiram na .debug konferenciji. To mi je bio big deal – moje prvo javno predavanje. Htio sam to napraviti “kak spada” pa sam se primio posla. Pošto sam developer, pristupio sam tome developerski i kroz ovaj post ću vam opisati taj proces. Važno za napomenuti je da je prezentiranje vještina kao i svaka druga – s praksom i s vremenom ćete to raditi sve bolje i bolje.

Za temu sam odabrao feature koji je mene kao developera i leada, kao i moj cijeli tim, jako challengeao. Kako sada sve što smo naučili u dvije godine razvoja plus uvod i zaključak stavit na prezentaciju koja traje 30 minuta? Kako dati najveći mogući value ljudima koji će doći slušati moje predavanje?

Kao i početak svakog featurea na kome radimo, treba početi pisati specifikaciju. Tako sam i ja ovdje krenuo s outlineom predavanja.

No, razmišljao sam onda, kako znam da to što ja mislim da je bitno i to što želim prenijet publici i njima bitno? Okej, trebam feedback, kako doći do njega?

Za predavanje na .debugu treba napisati kratki opis teme koji se može naći na rasporedu predavanja. To je jedini sadržaj na temelju koga možete zainteresirati ljude da dođu na vaše predavanje.

Upravo taj opis sam odlučio poslati par frendova na različitim pozicijama u developmentu. Uz to, poslao sam im: “meni bi puno značilo kada bi mi rekao što bi ti očekivao od takve prezentacije? Koji bi bio value kom bi se nadao?” Isto to sam pitao i par kolega na poslu koji nisu bili toliko upoznati s ovom tematikom da mi ne bi dali biased komentare. Kolege s više iskustva oko prezentiranja sam pitao za općenite smjernice.

Iz toga sam izvukao dosta informacija o tome na koja pitanja bi trebao dati odgovor. To mi je pomoglo da popravim outline, da ga učinim konkretnijim i da po tome napravim prvu verziju prezentacije. To je bio moj “PoC” i sad je uslijedila faza prvog testiranja.

Prilikom traženja inicijalnog feedbacka mi je jedan od prijatelja rekao da mu se javim kada ću imati spremnu prezentaciju, da se nađemo i prođemo sto sam smislio. Tako je i bilo – javio sam mu se i evo nas na kavi u Atriumu jedan ponedjeljak nakon posla. Nisam mu isprezentirao predavanje kako bi na .debugu već smo prolazili po slajdovima kako bi probao shvatiti moju priču, njene glavne i ne toliko glavne dijelove.

To je potrajalo više od pola sata i tu mi je već ukazao da sam previše toga stavio na slajdove. Zatim smo opet prolazili deck i micali sadržaj koji nije bio toliko bitan za samu poantu predavanja. Također kao i u developmentu – imaš puno ideja za feature no vrijeme je najčešće ograničeno, moraš vidjet što je must-have, a što nice-to-have. Najbolji savjet koji mi je dao je bio: “ljudi su došli slušati tebe i tvoju priču. Nitko iz publike neće znati više o toj temi od tebe, nema razloga za brigu i stres. To je tvoja tema, ti si to prošao, znaš sve o njoj.” Bilo je tu još savjeta:

• nemoj se oslanjati na presenter notes jer u trenu predavanja nećeš stići pratiti publiku, slajdove i te bilješke
• presenter notes neka budu natuknice, ne rečenice
• što manje teksta na slajdovima da fokus publike bude na tebi i tvom pričanju
• ako je slot 30 minuta, ciljaj na 20-25 minuta
• ostani na razini detalja koja je dovoljna slušateljima da shvate poantu, a da s druge strane ne ulaziš u detalje koji nisu toliko bitni
• dobro je svesti predavanje na relatable razinu s publikom
• ne koristiti interne pojmove
• jako je bitna intonacija i stil pričanja – ne smiješ pričati monotono
• snimi se kako prolaziš prezentaciju i poslušaj da vidiš što je višak, a što ne
• …

Kao što vidite ima tu dosta savjeta, puno toga što bi trebali imati u glavi. Zvučalo je overwhellming u tom trenu. Idućih dana sam razmišljao o tome i doradio prezentaciju. Tada sam organizirao još jedno probno predavanje. Ovaj puta pred većom publikom – petero kolega iz firme. Do tog trena sam prošao prezentaciju 10ak puta, ali ovo je prvi put da ću je for real prezentirati pred drugim ljudima.

Proba je prošla solidno no vremenski gledano je opet bilo na knap. Što je bio i jedan od komentara kolega: “jako brzo pričaš pa te je u trenucima teško pratiti. Uspori malo kako bi sve skupa lakše leglo ljudima.” Znači i dalje je previše sadržaja. Rekli su da ima višaka, a da ima i pojmova koje bi bilo dobro proširiti ili ubaciti. Npr. u uvodnom djelu prezentacije sam mislio da moram objasniti prijašnje ponašanje sustava.

Na tom djelu sam trošio oko 3 minute predavanja dok je to zapravo bilo nešto što bi se moglo svesti na 30ak sekundi. Također, previše sam otišao u product-related rasprave, manje u tehničke. Trebao bi više prilagoditi sadržaj za publiku koju očekujem. Kako je ovo developerska konferencija, trebalo bi podebljati tehničke detalje i odluke. Komentirali smo također memove koje sam ubacio – zanimalo me kuži li se poanta, jesu li smiješni, je li to too much za predavanje. Uglavnom, dobio sam dosta kvalitetan feedback s kojim sam još jednom došao do nove verzije decka.

Taj deck sam prošao još 5-10 puta i usput napravio par sitnih tweakova – najviše u pogledu daljnjeg rezanja sadržaja.

And that’s a wrap.

Predavanje je prošlo odlično! Bio sam jako sretan količinom ljudi koja je došla čuti što im imam za reći, s raspravama nakon predavanja i sa svojom izvedbom. Sve skupa sam uložio nekih 50-60 sati pripreme i drago mi je da se je taj trud prepoznao od strane publike – što kroz pohvale narednih dana, što kroz rezultate ankete za .debug predavače.