"Rapporten har ingen ret til at være kedelig": et interview med Baruch Sadogursky om taler på konferencer

Baruch Sadogursky - Developer Advocate hos JFrog, medforfatter til bogen "Liquid Software", berømt IT-taler.

I et interview forklarede Baruch, hvordan han forbereder sig til sine rapporter, hvordan udenlandske konferencer adskiller sig fra russiske, hvorfor deltagerne skulle deltage i dem, og hvorfor de skulle tale i et frøkostume.

"Rapporten har ingen ret til at være kedelig": et interview med Baruch Sadogursky om taler på konferencer

Lad os starte med det enkleste. Hvorfor tror du overhovedet at tale til konferencer?

Faktisk er det et job for mig at tale ved konferencer. Hvis vi svarer mere generelt på spørgsmålet "Hvorfor er mit arbejde?", så er dette i orden (i hvert fald for JFrog-virksomheden) at nå to mål. For det første at etablere kontakt til vores brugere og kunder. Det vil sige, at når jeg taler til konferencer, er jeg tilgængelig, så alle der har spørgsmål, lidt feedback på vores produkter og virksomhed, kan tale med mig, jeg kan på en eller anden måde hjælpe dem og forbedre deres oplevelse i arbejdet med vores produkter.

For det andet er dette nødvendigt for at øge brand awareness. Det vil sige, at hvis jeg fortæller nogle interessante ting, så er folk interesserede i, hvilken slags JFrog dette er, og som et resultat ender de i vores udviklerrelationstragt, som til sidst går ind i vores brugeres tragt, som til sidst går ind i vores kunders tragt.

Fortæl os venligst, hvordan du forbereder dig til forestillinger? Er der en form for forberedelsesalgoritme?

Der er fire mere eller mindre standardtrin i forberedelsen. Den første er begyndelsen, ligesom i filmene. En eller anden idé skal dukke op. En idé dukker op, og så modnes den ret længe. Det modnes, du tænker på, hvordan du bedst præsenterer denne idé, i hvilken nøgle, i hvilket format, hvad der kan siges om den. Dette er den første fase.

Den anden fase er at skrive en specifik plan. Du har en idé, og den begynder at få detaljer om, hvordan du vil præsentere den. Dette gøres normalt i en form for mindmap-format, når alt relateret til rapporten dukker op omkring ideen: understøttende argumenter, introduktion, nogle historier, som du gerne vil fortælle om den. Dette er anden fase - planen.

Den tredje fase er at skrive slides i henhold til denne plan. Du bruger nogle abstrakte ideer, som dukker op på slides og understøtter din historie.

Fjerde etape er gennemløb og øvelser. På dette stadie er det vigtigt at sikre sig, at historiebuen er slået ud, at historien er sammenhængende, og at alt er i orden med hensyn til timing. Herefter kan rapporten erklæres klar.

Hvordan forstår du, at "dette emne" skal behandles? Og hvordan indsamler man materiale til rapporter?

Jeg ved ikke, hvordan jeg skal svare, det kommer bare på en eller anden måde. Enten er det "Åh, hvor blev det fedt her," eller det er "Åh, ingen ved eller forstår rigtigt om det her," og der er mulighed for at fortælle, forklare og hjælpe. En af disse to muligheder.

Indsamlingen af ​​materiale er meget afhængig af rapporten. Hvis dette er en rapport om et eller andet abstrakt emne, så er det mere litteratur, artikler. Hvis dette er noget praktisk, så vil det være at skrive kode, nogle demoer, finde de rigtige stykker kode i produkter, og så videre.

Baruchs tale ved det nylige DevOps-topmøde i Amsterdam 2019

Frygt for præstationer og angst er nogle af de mest almindelige årsager til, at folk ikke går på scenen. Har du nogle råd til dem, der føler sig nervøse, når de optræder? Er du bekymret, og hvordan klarer du dig?

Ja, det har jeg, det burde være, og sandsynligvis, i det øjeblik, hvor jeg helt holder op med at bekymre mig, er det en grund til at stoppe med denne sag.

Det forekommer mig, at det er et helt normalt fænomen, når man går på scenen, og der er mange mennesker foran en. Du bekymrer dig, fordi det er et stort ansvar, det er naturligt.

Hvordan skal man håndtere dette? Der er forskellige måder. Jeg har aldrig haft det på et sådant niveau, at jeg har brug for at bekæmpe det direkte, så det er svært for mig at sige.

Det vigtigste, der også hjælper mig, er et venligt ansigt – et eller andet kendt ansigt blandt publikum. Hvis du beder en du kender om at komme til din tale, så sæt dig på forreste række i midten, så du altid kan se på ham, og personen vil være positiv, smile, nikke, støtte, jeg synes, det er en kæmpe kæmpe hjælp. Jeg beder ikke specifikt nogen om at gøre det her, men hvis det sker, at der er et kendt ansigt blandt publikum, hjælper det meget og lindrer stress. Dette er det vigtigste råd.

Du taler meget ved russiske og internationale konferencer. Kan du se forskel på rapporter på russiske og udenlandske konferencer? Er der forskel på publikum? I organisationen?

Jeg ser to store forskelle. Det er klart, at konferencer er forskellige både i Rusland og i udlandet, men hvis vi tager gennemsnittet for hospitalet, så er konferencerne i Rusland mere tekniske med hensyn til dybden af ​​rapporterne, hvad angår hardcore. Det er, hvad folk er vant til, måske takket være så store konferencer som Joker, JPoint, Highload, der altid har været baseret på hardcore-præsentationer. Og det er præcis, hvad folk forventer af konferencer. Og for mange mennesker er dette en indikator for, om denne konference er god eller dårlig: der er meget kød og hardcore, eller der er meget vand.

For at være ærlig, måske på grund af det faktum, at jeg taler meget på udenlandske konferencer, er jeg ikke enig i denne tilgang. Jeg mener, at rapporter om bløde færdigheder, "semi-humanitære rapporter", ikke er mindre og måske endda vigtigere for konferencer. Fordi nogle tekniske ting i sidste ende kan læses i bøger, kan du finde ud af dem ved hjælp af brugermanualen, men når det kommer til bløde færdigheder, når det kommer til psykologi, når det kommer til kommunikation, er der ingen steder at få alt dette, i det mindste let, tilgængeligt og forståeligt. Det forekommer mig, at dette ikke er mindre vigtigt end den tekniske komponent.

Dette er især vigtigt for DevOps-konferencer som DevOpsDays, fordi DevOps slet ikke handler om teknologi. DevOps handler kun om kommunikation, det handler kun om måder, hvorpå folk, der ikke har arbejdet sammen før, kan arbejde sammen. Ja, der er en teknisk komponent, fordi automatisering er afgørende for DevOps, men dette er kun en af ​​dem. Og når en DevOps-konference, i stedet for at tale om DevOps, taler om webstedets pålidelighed eller automatisering eller pipelines, så går denne konference, på trods af at den er meget hardcore efter min mening, glip af selve essensen af ​​DevOps og bliver til konferencer om systemadministration , ikke om DevOps.

Den anden forskel er i forberedelsen. Igen tager jeg hospitalsgennemsnittet og generelle tilfælde, ikke specifikke. I udlandet antager de, at de fleste mennesker har gennemgået en form for taletræning i deres liv. I det mindste i Amerika er det en del af videregående uddannelse. Hvis en person er uddannet fra college, har han allerede en betydelig erfaring med at tale offentligt. Efter at programudvalget har set på planen og forstået, hvad rapporten skal handle om, trænes der derfor ikke mere i at tale foredragsholderen, fordi man mener, at han højst sandsynligt ved, hvordan det skal gøres.

I Rusland er sådanne antagelser ikke lavet, fordi få mennesker har erfaring med at tale offentligt, og derfor er talere uddannet meget mere. Igen, generelt er der gennemgange, der er klasser med talere, der er talekurser for at hjælpe talere.

Som et resultat bliver svage talere, der kommunikerer dårligt, elimineret, eller de får hjælp til at blive stærkere oplægsholdere. Det faktum, at man i Vesten betragter offentlige taler som en færdighed, som mange mennesker har, får i sidste ende den modsatte effekt, fordi denne antagelse ofte viser sig at være falsk, fejlagtig, og folk, der ikke ved, hvordan man taler offentligt, skruer åbent op for scene og producere modbydelige rapporter. Og i Rusland, hvor det menes, at der ikke er nogen erfaring med at tale offentligt, viser det sig i sidste ende meget bedre, fordi de blev trænet, de blev testet, de valgte en god og så videre.

Det er de to forskelle.

Har du været til DevOpsDays i andre lande? Hvordan synes du, de adskiller sig fra andre konferencer? Er der nogle særlige funktioner?

Jeg har sikkert været til adskillige dusin DevOpsDays-konferencer rundt om i verden: i Amerika, Europa og Asien. Denne konferencefranchise er ret unik ved, at den har et mere eller mindre etableret format, som du kan forvente overalt fra enhver af disse konferencer. Formatet er som følger: Der er relativt få frontline-konferencepræsentationer, og der afsættes megen tid til open space-formatet.

Open spaces er et format, hvor det emne, som flest har stemt på, diskuteres sammen med andre deltagere. Den, der foreslog dette emne, er lederen, han sørger for, at diskussionen begynder. Dette er et fantastisk format, for som vi ved, er kommunikation og netværk ikke mindre vigtige dele af enhver konference end præsentationer. Og når en konference afsætter halvdelen af ​​sin tid til et netværksformat, er det meget fedt.

Derudover afholdes Lightning Talks ofte på DevOpsDays - det er korte fem minutters rapporter, der giver dig mulighed for at lære meget om meget og åbne dine øjne for nogle nye ting i et ikke-kedeligt format. Og hvis du midt i en almindelig rapport indså, at det her ikke er din, så er tiden spildt, 30-40 minutter af dit liv spildt, så er der her tale om rapporter i fem minutter. Og hvis du ikke er interesseret, slutter det snart. "Fortæl os, men hurtigt" er også et meget godt format.

Der er mere tekniske DevOpsDays, og der er dem, der er skræddersyet specifikt til, hvad DevOps er: processer, samarbejde, sådan noget. Det er interessant at have begge dele, og det er interessant at have begge dele. Jeg tror, ​​at dette er en af ​​de bedste DevOps-konferencefranchiser i dag.

Mange af dine forestillinger ligner forestillinger eller skuespil: Nogle gange holder du en tale i form af en græsk tragedie, nogle gange spiller du rollen som Sherlock, nogle gange optræder du i et frøkostume. Hvordan finder du på dem? Er der andre mål udover at gøre rapporten ikke kedelig?

Det forekommer mig, at en rapport ikke har ret til at være kedelig, for for det første spilder jeg lytternes tid, i en kedelig rapport er de mindre involverede, de har lært mindre, de har lært mindre nye ting, og det er ikke det bedste spild af deres tid. For det andet er mine mål heller ikke nået: de synes ikke noget godt om mig, de synes ikke noget godt om JFrog, og for mig er dette en form for fiasko.

Derfor har kedelige rapporter ingen ret til at eksistere, i hvert fald for mig. Jeg forsøger at gøre dem interessante, attraktive og mindeværdige. Forestillinger er én vej. Og faktisk er metoden ret nem. Alt du behøver er at komme med et interessant format og derefter præsentere de samme tanker, som præsenteres i form af en almindelig rapport i et usædvanligt format.

Hvordan finder jeg på dette? Det er ikke altid det samme. Nogle gange er det nogle ideer, der kommer til mig, nogle gange er det nogle idéer, som jeg får, når jeg gennemgår eller deler tanker om en rapport, og de fortæller mig: "Åh, det kan gøres sådan!" Det sker anderledes. Når en idé dukker op, er det altid meget glædeligt og fedt, det betyder, at du kan lave en mere interessant og involveret rapport.

"Rapporten har ingen ret til at være kedelig": et interview med Baruch Sadogursky om taler på konferencer

Hvis taler fra IT-området kan du personligt lide? Findes der sådanne højttalere? Og hvorfor?

Der er to typer højttalere, hvis præsentationer jeg nyder. Den første er de højttalere, jeg prøver at være som. De taler på en interessant og involveret måde og prøver at sikre, at alle er interesserede, og at alle lytter.

Den anden type højttalere er dem, der kan tale om enhver normalt kedelig hardcore på en meget interessant og spændende måde.

Blandt navnene i den anden kategori er dette Alexey Shepelev, der på en interessant og humoristisk måde fortæller om en eller anden form for dyb præstationsaffaldsindsamling og indersiden af ​​den virtuelle java-maskine. En anden opdagelse af de seneste DevOops er Sergey Fedorov fra Netflix. Han fortalte en rent teknisk ting om, hvordan de optimerede deres indholdsleveringsnetværk, og han fortalte det på en meget interessant måde.

Fra den første kategori - disse er Jessica Deen, Anton Weiss, Roman Shaposhnik. Det er talere, der taler interessant, med humor og fortjent får høje karakterer.

Du har sandsynligvis flere invitationer til at tale ved konferencer end tid til at gøre det. Hvordan vælger du, hvor du vil hen, og hvor ikke?

Konferencer og talere er ligesom næsten alt andet styret af markedsforhold mellem udbud og efterspørgsel og værdien af ​​den ene fra den anden. Der er konferencer, som, ja, lad os sige, vil have mig mere, end jeg har brug for dem. Med hensyn til det publikum, jeg forventer at møde der, og den indflydelse, jeg forventer at få der. Der er konferencer, som jeg tværtimod vil gå til meget mere, end de har brug for mig. Baseret på værdien for mig, beslutter jeg, hvor jeg skal hen.

Det vil sige, at hvis det her for eksempel er en form for geografi, hvor jeg strategisk skal hen, det er en stor velkendt konference, som har et godt ry, og som folk vil gå til, så har jeg åbenbart virkelig brug for det. Og jeg foretrækker det frem for andre konferencer.

Hvis det er en slags lille regional konference, og måske hvor vi ikke er særlig interesserede, så kan det være, at turen dertil ikke retfærdiggør den tid, der bruges på denne sag. Normale markedsforhold af efterspørgsel, udbud og værdi.

God geografi, god demografi, potentielt gode kontakter, kommunikation er garantien for, at konferencen bliver interessant for mig.

I et af dine interviews nævnte du, at du taler ved omkring fyrre konferencer om året. Hvordan formår du at arbejde og forberede dig til forestillinger? Og formår du at opretholde balancen mellem arbejde og privatliv med sådan en tidsplan? Vil du dele dine hemmeligheder?

At rejse til konferencer er brorparten af ​​mit arbejde. Selvfølgelig er der alt andet: Der er forberedelse til rapporter, holde sig i teknisk form, skrive kode, lære nye ting. Det hele foregår parallelt med konferencer: om aftenen, i flyet, dagen før, når du allerede er ankommet til konferencen, og det er i morgen. Sådan noget.

Det er selvfølgelig svært at opretholde balancen mellem arbejde og privatliv, når du bruger så meget tid på forretningsrejser. Men jeg forsøger at kompensere for dette ved, at jeg i hvert fald når jeg ikke er på forretningsrejse, er 100% sammen med min familie, jeg svarer ikke på mails om aftenen, jeg forsøger ikke at deltage i evt. opkald om aftenen og i weekenden. Når jeg ikke er på forretningsrejse, og det er familietid, er det virkelig 100 % familietid. Virker dette, og løser det problemet? Ingen. Men jeg håber, at dette på en eller anden måde vil kompensere min familie for al den tid, jeg er væk.

En af Baruchs rapporter er "Vi har DevOps. Lad os fyre alle testerne."

Med så stram en tidsplan, formår du at bevare dit tekniske niveau eller har du allerede bevæget dig væk fra programmering?

Jeg forsøger at lave nogle tekniske ting, mens jeg forbereder mig til mine foredrag og andre aktiviteter på konferencen. Det er alle mulige tekniske demoer, nogle mini-rapporter, som vi giver på stande. Dette er ikke programmering-programmering, det er mere integration, men dette er i det mindste noget teknisk arbejde, jeg prøver at udføre. På denne måde vedligeholder jeg viden om vores produkter, nye funktioner og så videre.

Selvfølgelig er det nok umuligt at sige, at jeg er den samme hardcore-koder nu, som jeg var for 7 år siden. Ikke sikker på, om det er en dårlig ting. Dette er sandsynligvis en form for naturlig udvikling. Dette er mindre interessant for mig, og jeg har mindre tid, så sandsynligvis, Gud velsigne ham.

Jeg betragter stadig mig selv som en stærk teknisk specialist, jeg holder mig stadig orienteret om, hvad der sker, jeg holder mig selv på tæerne. Dette er min hybride situation i dag.

Fortæl os venligst et par sjove historier eller ekstreme situationer, der skete for dig: Gik glip af flyet/slettede præsentationen/strømafbrydelsen under rapporten/bagagen ankom ikke?

Af de sjove situationer er det, jeg husker mest, alle mulige forfærdelige fejl, der skete under rapporterne. Naturligvis, fordi dette er den mest stressende situation, fordi det er publikum, tid, og du skal sørge for, at de ikke spilder den.

Jeg havde en "blue screen of death" på både Windows og Mac under snakken. På Windows skete det én gang, på Mac et par gange. Dette er selvfølgelig stressende, men vi løser på en eller anden måde dette problem, computeren genstarter, jeg fortsætter med at fortælle noget på dette tidspunkt, men stressen er enorm.

Den nok sjoveste situation, jeg havde, var på en Groovy-konference. Jeg kan ikke huske præcis, hvor konferencen blev holdt, ser det ud til, på et hotel, og overfor dette hotel var der en form for konstruktion eller renovering i gang. Og så talte jeg om noget kode, som jeg skrev, det var en demo. Dette var den første gentagelse af demoen, som var forståelig, men måske ikke velskrevet. Og jeg skulle lige omstrukturere og forbedre det, og jeg nævnte en sætning som "selvnedsættende" om det faktum, at dette er "lorte kode". Det var på anden sal, og på det tidspunkt var en kran på byggepladsen overfor lige ved at løfte et transportabelt toilet. Og scenen var overfor vinduet. Det vil sige, jeg kigger ud af dette vindue, siger "shitty code", og et toilet flyder forbi vinduet. Og jeg siger til alle: "Vend om, vi har en illustration her." Dette var nok den bedste rutsjebane af mine tanker - det flyvende toilet i min rapport, da jeg talte om lortekode.

Fra historier som bagagen ikke kom - dette er i princippet en normal historie, der er ikke noget at tale om. Vi kan arrangere et separat interview om alle mulige rejsetips, hvor vi kan tale om bagage, der ikke kom frem, men der var ikke noget kritisk.

Jeg prøver meget for enhver pris altid at flyve, komme og deltage i alle de konferencer, som jeg lovede, for igen, det er folks tid. Folks tid er uvurderlig, fordi det er sådan en tillidskredit, som de giver dig. Og hvis dette lån er spildt, så er der ingen måde at få det tilbage senere.

Hvis en person brugte tid, kom til konferencen for at lytte til min rapport, og jeg tog den og ikke kom, er det dårligt, for der er ingen måde at få denne persons tid tilbage. Derfor er det super vigtigt for mig at holde alle mine løfter i denne forbindelse, og indtil videre lykkes alt.

Mange tænker sådan her: ”Hvorfor overhovedet gå til konferencer? Du kan se videoen på YouTube, og du kan altid chatte online." Hvorfor tror du, at deltagerne skal til konferencer?

Godt spørgsmål! Du bør gå til konferencer for at netværke. Dette er uvurderligt, og der er ingen anden måde at få det på. Jeg har allerede nævnt vigtigheden af ​​kommunikation, kommunikation og bløde færdigheder. At se en video på YouTube giver desværre ikke erfaring med bløde færdigheder. Derfor skal du til konferencer for kommunikationens skyld.

Derudover er engagementet, i hvert fald for mig, helt anderledes, når man ser videoer på YouTube, og materialet huskes og huskes meget dårligere. Måske er det bare mig, men jeg formoder, at det at være i rummet til en snak og se en video på YouTube er helt andre ting. Især hvis rapporten er god, forekommer det mig, at det er meget, meget bedre at høre den live. Det er som at lytte til en livekoncert og en plade.

Og jeg gentager endnu en gang: netværk og kommunikation er ikke noget, man kan tage fra YouTube.

Fælles rapport med Leonid Igolnik på DevOpsCon

Giv venligst nogle afskedsord til dem, der lige planlægger at blive taler eller lige er begyndt at tale?

Se efter lokale møder. Lokale møder er en fantastisk måde at starte din talekarriere på af flere grunde. For det første er lokale møder altid på udkig efter talere. Det kan være, at uden erfaring og uden at være en berømt foredragsholder, vil det være svært for dig at søge ind på en eller anden kendt konference, eller programudvalget, efter at have kommunikeret med dig, vil forstå, at det måske stadig er lidt tidligt for dig. I modsætning hertil er lokale møder altid på udkig efter talere, og adgangsgrænsen er meget, meget lavere, så det er meget nemmere at komme dertil.

Desuden er stressniveauet helt anderledes. Når der kommer 10-15-30 mennesker, er det slet ikke det samme, som når der er 150-200-300 mennesker i hallen, så det er meget nemmere.

Igen er omkostningerne for et lokalt møde meget lavere: du behøver ikke at flyve nogen steder, du behøver ikke bruge dage, du kan bare komme om aftenen. Når jeg husker mit råd om vigtigheden af ​​at have et venligt ansigt blandt publikum, er det meget nemmere at komme til et lokalt møde med nogen, fordi det ikke koster penge. Taler du til en konference, kommer du som foredragsholder gratis, men denne +1 af dine, som vil være et venligt ansigt i offentligheden, skal købe en billet. Hvis du taler til et møde, er der ikke noget sådant problem, du kan tage en eller to eller tre venner med, som vil være et venligt ansigt i lokalet.

Og et ekstra plus er, at mødearrangører har meget flere muligheder for at hjælpe dig. For konferencearrangører vil for eksempel have 60 oplæg, der skal gennemgås, øves og forberedes. Og arrangørerne af meetups har en, to eller tre, så du får naturligvis meget mere opmærksomhed.

Derudover er det meget nemmere at få feedback fra lokale møder. Du er færdig med din rapport, og nu kommunikerer og diskuterer du og publikum allerede noget relateret til din rapport. For store konferencer er dette ofte ikke tilfældet. Du lavede en rapport, og det var det. Publikum, som var en grå masse under din rapport, er gået, og du ved ikke længere noget om dem, du hører ikke, du vil ikke modtage nogen feedback.

Uanset hvad man kan sige, er lokale møder et godt emne generelt og for begyndere i særdeleshed.

Baruch taler ved konferencen den 7. december DevOpsDays Moskva. I sin rapport vil Baruch analysere reelle fejl, der opstår hver dag og overalt, når softwaren opdateres. Det vil vise, hvordan alle mulige DevOps-mønstre passer ind i forskellige scenarier, og hvordan anvendelse af dem korrekt kan muligvis redde dig.

Også i programmet: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (DevOps-konsulent).

Kom og bliv bekendt!

Kilde: www.habr.com

Tilføj en kommentar