"L'informe no té dret a ser avorrit": una entrevista a Baruch Sadogursky sobre discursos en conferències

Baruch Sadogursky és un defensor de desenvolupadors a JFrog, coautor del llibre "Liquid Software", un conegut ponent de TI.

En una entrevista, Baruch va explicar com es prepara per als informes, com es diferencien les conferències estrangeres de les russes, per què els participants van a ells i per què haurien de parlar amb un vestit de granota.

"L'informe no té dret a ser avorrit": una entrevista a Baruch Sadogursky sobre discursos en conferències

Comencem pel més senzill. Què en penseu, per què parlar a les conferències?

De fet, parlar a les conferències és una feina per a mi. Si responeu de manera més global a la pregunta "Per què el meu treball?", això és per tal (almenys per a JFrog) assolir dos objectius. En primer lloc, establir contacte amb els nostres usuaris i clients. És a dir, quan parlo a les conferències, estic disponible perquè tothom que tingui alguna pregunta, algun tipus de feedback sobre els nostres productes i empreses pugui parlar amb mi, els pugui ajudar d'alguna manera i millorar la seva experiència de treball amb els nostres productes.

En segon lloc, cal augmentar la notorietat de marca. És a dir, si explico coses interessants, aleshores la gent està interessada en quin tipus de JFrog és aquest i, com a resultat, cau en el nostre embut de relacions amb els desenvolupadors, que finalment va a l'embut de conversió dels nostres usuaris, que finalment va a l'embut de conversió. dels nostres clients.

Digueu-nos, si us plau, com us prepareu per a les actuacions? Hi ha algun algorisme d'entrenament?

Hi ha quatre etapes més o menys estàndard de preparació. El primer és el començament, com a les pel·lícules. Hi ha d'haver alguna idea. Apareix una idea, i després madura durant força temps. Madura, penses com presentar millor aquesta idea, en quina clau, en quin format, què es pot dir d'això. Aquesta és la primera etapa.

La segona etapa és la redacció d'un pla específic. Tens una idea i comença a créixer en detalls sobre com la presentaràs. Normalment això es fa en el format d'algun tipus de mapa mental, quan tot el relacionat amb l'informe apareix al voltant de la idea: arguments de suport, una introducció, algunes històries que es vol explicar al respecte. Aquesta és la segona etapa: el pla.

La tercera etapa és escriure diapositives segons aquest pla. Feu servir algunes idees abstractes que apareixen a les diapositives i doneu suport a la vostra història.

La quarta etapa són les proves, els assajos. En aquesta etapa, és important assegurar-se que l'arc de la història ha resultat, que la història és coherent, per assegurar-se que tot va bé a temps. Després d'això, l'informe es pot declarar preparat.

Com entens que s'ha de tractar "aquest tema"? I com es recull el material per als informes?

No sé com respondre, d'alguna manera ve per si sol. O és "Oh, que bé ho hem fet aquí", o bé és "Oh, ningú al voltant ho sap ni entén realment" i hi ha l'oportunitat d'explicar, explicar i ajudar. Una d'aquestes dues opcions.

La recollida de material depèn molt de l'informe. Si aquest és un informe sobre algun tema abstracte, és més literatura, articles. Si això és pràctic, serà escriure codi, algunes demostracions, trobar les peces de codi adequades als productes, etc.

Discurs de Baruch a la recent DevOps Summit Amsterdam 2019

La por a les actuacions i l'ansietat és un dels motius més habituals pels quals la gent no puja a l'escenari. Tens algun consell per a aquells que es posen nerviosos mentre actuen? Estàs preocupat i com ho portes?

Sí, ho tinc, hauria de ser, i, probablement, en el moment en què deixo de preocupar-me gens, aquest és un motiu per lligar amb aquest assumpte.

Em sembla que això és un fenomen completament normal quan vas a l'escenari i hi ha molta gent davant teu. Estàs preocupat perquè és una gran responsabilitat, és natural.

Com fer-hi front? Hi ha diferents maneres. Mai ho he tingut a tal nivell que hagis de lluitar directament, així que em costa dir-ho.

El més important, que també m'ajuda, és una cara amable, una mena de cara coneguda entre el públic. Si demanes a algú que coneixes que vingui a la teva presentació, asseu-te a les primeres files al mig perquè sempre el puguis mirar, i la persona serà positiva, somriurà, assentirà, donarà suport, crec que això és un gran, gran ajuda.. No pregunto específicament a ningú sobre això, però si passa que hi ha una cara coneguda entre el públic, ajuda molt, alleuja l'estrès. Aquest és el consell més important.

Parles molt a congressos russos i internacionals. Veus la diferència entre els informes a les conferències russes i les estrangeres? Hi ha diferència en l'audiència? A l'organització?

Veig dues grans diferències. Està clar que les conferències són diferents tant a Rússia com a l'estranger, però si prenem la mitjana d'un hospital, a Rússia les conferències són més tècniques pel que fa a la profunditat dels informes, pel que fa al hardcore. Això és al que la gent està acostumada, potser gràcies a conferències tan importants com Joker, JPoint, Highload, que sempre s'han basat en xerrades hardcore. I això és el que la gent espera de les conferències. I per a molta gent això és un indicador de si es tracta d'una conferència bona o dolenta: hi ha molta carn i hardcore o hi ha molta aigua.

Per ser sincer, potser perquè parlo molt a congressos estrangers, no estic d'acord amb aquest plantejament. Crec que els informes sobre habilitats blanques, “informes semihumanitaris”, no són menys, i potser encara més importants per a conferències. Com que algunes coses tècniques es poden llegir eventualment als llibres, es pot entendre el manual d'usuari, però pel que fa a les habilitats suaus, com a la psicologia, com a la comunicació, no hi ha cap lloc on portar-ho tot, almenys fàcil, accessible i entenedor. Em sembla que això no és menys important que el component tècnic.

Això és especialment important per a conferències de DevOps com DevOpsDays perquè DevOps no tracta gens de tecnologia. DevOps només es tracta de comunicació, només de maneres de treballar junts amb persones que no han treballat junts abans. Sí, hi ha un component tècnic, perquè l'automatització és fonamental per a DevOps, però aquest és només un d'ells. I quan una conferència sobre DevOps, en comptes de parlar de DevOps, parla sobre la fiabilitat del lloc o sobre l'automatització, o sobre pipelines, aleshores aquesta conferència, malgrat que és molt hardcore, al meu entendre, només troba a faltar l'essència mateixa de DevOps i es converteix en conferències sobre l'administració del sistema, no sobre DevOps.

La segona diferència està en la preparació. De nou, estic prenent mitjanes hospitalàries i casos generals, no casos individuals. A l'estranger, parteixen del fet que la majoria de la gent s'ha format per parlar en públic al llarg de les seves vides. Almenys a Amèrica, forma part de l'educació superior. Si una persona es va graduar a la universitat, ja té molta experiència en parlar en públic. Per tant, després que la comissió de programa hagi examinat el pla i hagi entès de què tractarà l'informe, aleshores no es fa més formació per parlar per al ponent, perquè es creu que ell, molt probablement, ja sap com fer-ho.

A Rússia, aquestes suposicions no es fan, perquè poca gent té experiència en parlar en públic i, per tant, els parlants estan molt més entrenats. De nou, en general, hi ha run-throughs, hi ha classes amb ponents, hi ha cursos de parla en públic per ajudar els ponents.

Com a resultat, s'eliminen els parlants febles que no parlen bé o se'ls ajuda a convertir-se en parlants més forts. El fet que a Occident parlar en públic es consideri una habilitat que tenen molts, al final té l'efecte contrari, perquè aquesta suposició sovint resulta falsa, errònia i gent que no sap parlar en públic amb franquesa. arruïnar-se a l'escenari i rebre informes repugnants. I a Rússia, on es creu que no hi ha experiència en parlar en públic, al final resulta molt millor, perquè es van formar, es van provar, van triar-ne de bons, etc.

Aquí hi ha les dues diferències.

Has estat a DevOpsDays en altres països? En què creus que es diferencien d'altres conferències? Hi ha alguna característica?

Probablement he assistit a diverses desenes de conferències DevOpsDays arreu del món: a Amèrica, a Europa i a Àsia. Aquesta franquícia de conferències és força única perquè té un format més o menys establert que podeu esperar a qualsevol lloc de qualsevol d'aquestes conferències. El format és aquest: hi ha relativament pocs informes de conferències frontals i es dedica molt de temps al format d'espais oberts.

Els espais oberts és un format en què es parla amb la resta de participants del tema que més ha votat la gent. Qui ha proposat aquest tema és el líder, s'assegura que comenci la discussió. Aquest és un format fantàstic, perquè, com sabem, la comunicació i el treball en xarxa no són una part menys important de qualsevol conferència que els informes. I quan una conferència dedica la meitat del seu temps a un format de xarxa, és molt divertit.

A més, les xerrades Lightning se celebren sovint als DevOpsDays: es tracta d'informes breus de cinc minuts que us permeten aprendre molt i obrir els ulls a algunes coses noves en un format no avorrit. I si enmig d'un informe regular us heu adonat que no era per a vosaltres, aleshores es perd el temps, s'han perdut 30-40 minuts de la vostra vida, aquí estem parlant d'informes durant cinc minuts. I si no us interessa, aviat s'acabarà. "Digues-nos, però ràpid" també és un format molt bo.

Hi ha DevOpsDays més tècnics, n'hi ha que s'adapten específicament al que és DevOps: processos, col·laboració, coses com aquestes. Tots dos són interessants, i és interessant quan hi ha tots dos. Crec que aquesta és una de les millors franquícies de conferències DevOps actuals.

Moltes de les teves actuacions són com actuacions o actuacions: ara expliques un reportatge en forma de tragèdia grega, després estàs en el paper de Sherlock, després actues amb un vestit de granota. Com se'ls acudeix? Hi ha cap objectiu addicional a més de no avorrir l'informe?

Em sembla que el reportatge no té dret a ser avorrit, perquè, en primer lloc, perdo el temps dels oients, estan menys implicats en un reportatge avorrit, han après menys, han après menys coses noves, i això no és el millor. perdre el seu temps. En segon lloc, els meus objectius tampoc s'assoleixen: no pensen res de bo de mi, no pensen res de bo sobre JFrog, i per a mi això és una mena de fracàs.

Per tant, els informes avorrits no tenen dret a existir, almenys per a mi. Intento que siguin interessants, atractives i memorables. Les actuacions són unidireccionals. I, de fet, el mètode és bastant fàcil. Tot el que cal és crear un format interessant i, després, posar les mateixes reflexions que es presenten en forma d'informe habitual en un format inusual.

Com se m'aconsegueix això? No sempre és el mateix. De vegades aquestes són algunes idees que em vénen al cap, de vegades aquestes són algunes idees que se'm donen quan organitze sortides o comparteixo idees sobre l'informe i em diuen: "Oh, pots fer-ho així!" Succeeix de manera diferent. Quan sorgeix una idea, sempre és molt alegre i fresca, la qual cosa vol dir que pots fer un reportatge més interessant i implicat.

"L'informe no té dret a ser avorrit": una entrevista a Baruch Sadogursky sobre discursos en conferències

Quines actuacions de l'àmbit informàtic t'agraden personalment? Hi ha aquests altaveus? I per què?

Hi ha dos tipus de parlants els discursos dels quals m'agraden. El primer són els altaveus, que intento ser com. Expliquen històries d'una manera interessant i atractiva, intentant que tothom estigui interessat i que tothom escolti.

El segon tipus d'altaveus són aquells que són capaços d'explicar d'una manera molt interessant i emocionant sobre qualsevol hardcore habitualment avorrit.

Dels noms de la segona categoria, aquest és Alexey Shepelev, que parla d'alguna mena de recollida d'escombraries de rendiment profund i l'interior d'una màquina virtual java d'una manera interessant i còmica. Un altre descobriment de l'últim DevOops és Sergey Fedorov de Netflix. Va explicar una cosa purament tècnica, com van optimitzar la seva xarxa de distribució de continguts, i ho va explicar d'una manera molt interessant.

De la primera categoria - aquesta és Jessica Deen, Anton Weiss, Roman Shaposhnik. Aquests són els ponents que expliquen històries interessants, amb humor, i reben merescudament valoracions altes.

Probablement tingueu més invitacions per parlar a conferències que temps per fer-ho. Com esculls on vas i on no?

Les conferències i els ponents, com gairebé tota la resta, es regeixen per les relacions de mercat d'oferta i demanda i el valor de l'una de l'altra. Hi ha conferències que, diguem-ne, em volen més del que les necessito. Pel que fa al públic que espero trobar-hi allà i l'impacte que espero tenir-hi. Hi ha conferències a les quals, per contra, vull assistir molt més del que em necessiten. Segons el valor per a mi, decideixo on anar.

És a dir, si es tracta, per exemple, d'algun tipus de geografia on estratègicament necessito anar, aquesta és una gran conferència coneguda que té una bona reputació i a la qual anirà la gent, llavors, evidentment, ho necessito molt. I ho preferiré a altres conferències.

Si es tracta d'una mena de petit congrés regional, i, potser, on no ens interessa gaire, pot ser que un viatge allà no justifiqui el temps dedicat a aquest tema. Relacions normals de mercat de demanda, oferta i valor.

Bona geografia, bona demografia, potencialment bons contactes, comunicació són la garantia que la conferència serà del meu interès.

En una de les teves entrevistes, vas esmentar que parles en una quarantena de conferències a l'any. Com ho fas per treballar i preparar-te per a les actuacions? I aconsegueixes mantenir la conciliació laboral/vida familiar amb aquest horari? Comparteix els teus secrets?

Viatjar a conferències és la part del lleó de la meva feina. Per descomptat, hi ha tota la resta: hi ha preparació per als informes, mantenir-se en forma tècnica, escriure codi, aprendre coses noves. Tot això es fa paral·lelament a les conferències: al vespre, a l'avió, el dia abans, quan ja has arribat a la conferència, i és demà. Alguna cosa com això.

És difícil, per descomptat, mantenir un equilibri entre la vida laboral i la vida familiar quan tens tant de temps en viatges de negocis. Però intento compensar amb el fet que, almenys quan no estic de viatge de negocis, estic 100% amb la meva família, no responc correus electrònics a la nit, intento no participar en cap trucada telefònica. a les nits i els caps de setmana. Quan no estic de viatge de negocis i és temps familiar, realment és temps 100% familiar. Funciona i resol el problema? No. Però espero que d'alguna manera compensi la meva família per tot el temps que estic fora.

Un dels informes de Baruch és "Tenim DevOps. Acomiadarem tots els provadors"

Amb un horari tan dur, aconsegueixes mantenir un nivell tècnic o ja t'has allunyat de la programació?

Intento fer algunes coses tècniques mentre preparo les meves xerrades i altres activitats a la conferència. Són tota mena de demostracions tècniques, una mena de mini-informes que fem a les grades. No és programació-programació, és més integració, però almenys és una feina tècnica que intento fer. D'aquesta manera, mantinc el coneixement dels nostres productes, noves característiques, etc.

Per descomptat, dir que ara sóc el mateix programador hardcore que fa 7 anys és probablement impossible. No estic segur de si això és dolent. Probablement algun tipus d'evolució natural. Això és menys interessant per a mi, i hi ha menys temps, així que, probablement, Déu el beneeixi.

Encara em considero un gran especialista tècnic, encara sóc conscient del que passa, em mantinc en bona forma. Aquesta és la meva situació híbrida actual.

Si us plau, explica'ns un parell d'històries divertides o situacions extremes que t'han passat: has perdut l'avió / has esborrat la presentació / has tallat l'electricitat durant el reportatge / no has arribat equipatge?

De les situacions divertides, recordo sobretot tota mena de fracassos de malson que van passar als informes. Naturalment, perquè aquesta és la situació més estressant, perquè aquest és el públic, el temps, i cal assegurar-se que no el malgasten en va.

Vaig tenir una "pantalla blava de la mort" tant a Windows com a Mac durant la xerrada. A Windows va passar una vegada, a Mac un parell de vegades. Això, per descomptat, és estressant, però d'alguna manera solucionem aquest problema, l'ordinador es reinicia, segueixo explicant alguna cosa en aquest moment, però l'estrès és enorme.

Probablement la situació més divertida que he tingut mai va ser en una conferència de Groovy. No recordo exactament on es va fer la conferència, crec que va ser en un hotel, i hi havia algun tipus de construcció o renovació davant d'aquest hotel. I així estava parlant d'algun codi que vaig escriure, era una demostració. Aquesta va ser la primera iteració d'una demostració que era comprensible però potser no ben escrita. I només anava a refactoritzar i millorar-lo, i vaig esmentar alguna frase com "autodespreciar" sobre el fet que això és "codi de merda". Era al segon pis, i en aquell moment la grua de l'obra d'enfront només estava aixecant un vàter portàtil. I l'escenari era davant de la finestra. És a dir, miro per aquesta finestra, dic "codi de merda", i un vàter flota fora de la finestra. I dic a tothom: "Gira't, aquí tenim una il·lustració". Aquesta va ser probablement la millor diapositiva dels meus pensaments: un vàter volador del meu informe, quan vaig parlar d'un codi de merda.

L'equipatge no va sorgir d'històries com aquesta: aquesta és, en principi, una història normal, no hi ha res de què parlar. Podem organitzar una entrevista per separat sobre tot tipus de consells de viatge, on es pot parlar de l'equipatge que no va arribar, però no hi havia res crític.

M'esforço molt per volar sempre, venir i ser present a totes les conferències que vaig prometre, perquè, de nou, és l'hora de la gent. El temps de la gent no té preu, perquè és un crèdit de confiança que et donen. I si aquest préstec es malgasta, no hi ha manera de recuperar-lo més tard.

Si una persona va passar temps, va venir a la conferència per escoltar el meu informe, i jo el vaig agafar i no vaig venir, això és dolent, perquè no hi ha manera de tornar el temps d'aquesta persona. Per tant, és molt important per a mi complir totes les meves promeses en aquest sentit, i fins ara tot està funcionant.

Molta gent pensa així: “Per què anar a conferències? Pots veure el vídeo a YouTube i sempre pots xatejar en línia". Per què creus que els participants han d'assistir a les conferències?

Gran pregunta! Cal anar a conferències per fer xarxa. No té preu i no hi ha cap altra manera d'aconseguir-ho. Ja he esmentat la importància de la comunicació, la comunicació i les soft skills. Mirar un vídeo a YouTube, malauradament, no dóna experiència en habilitats suaus. Per tant, s'ha d'anar a conferències per tal de comunicar-se.

A més, almenys per a mi, quan miro vídeos a YouTube, la implicació és completament diferent, i el material entra i es recorda molt pitjor. Potser és només per a mi, però sospito que estar a la sala en un reportatge i veure un vídeo a YouTube són coses completament diferents. Sobretot si el reportatge és bo, crec que és molt, molt millor escoltar-lo en directe. És com escoltar un concert en directe i un disc.

I repeteixo una vegada més: el networking i la comunicació no estan trets de YouTube.

Xerrada conjunta amb Leonid Igolnik a DevOpsCon

Si us plau, pots donar algunes paraules de comiat a aquells que acaben de ser parlants o que acaben de començar a parlar?

Busqueu trobades locals. Les trobades locals són un lloc fantàstic per començar la vostra carrera d'orador per diversos motius. En primer lloc, les trobades locals sempre busquen ponents. Pot ser que sense experiència i sense ser un ponent eminent, us sigui difícil presentar-vos a alguna conferència coneguda, o la comissió del programa, després de parlar amb vosaltres, entengui que potser és una mica aviat per a vosaltres. En canvi, les trobades locals sempre busquen parlants i la barra d'entrada és molt, molt més baixa, de manera que és molt més fàcil arribar-hi.

A més, el nivell d'estrès és completament diferent. Quan vénen 10-15-30 persones, no és gens el mateix que quan hi ha 150-200-300 persones a la sala, així que és molt més fàcil.

De nou, els costos d'una trobada local són molt més baixos: no cal volar enlloc, no cal passar dies, només podeu venir al vespre. Recordant el meu consell sobre la importància de tenir una cara amistosa entre la multitud, és molt més fàcil venir a una reunió local amb algú perquè no costa diners. Si parles en una conferència, tu com a ponent vens gratis, però aquest +1 teu, que serà una cara amiga del públic, necessita comprar una entrada. Si esteu actuant en una trobada, no hi ha cap problema, podeu portar un o dos o tres amics amb vosaltres que seran una cara amistosa a la sala.

I un avantatge addicional és que els organitzadors de trobades tenen moltes més oportunitats per ajudar-vos. Perquè els organitzadors de les jornades tindran, per exemple, 60 informes que caldrà revisar, practicar i elaborar. I els organitzadors de les trobades en tenen una, dues o tres, així que, naturalment, us prestarà molta més atenció.

A més, és molt més fàcil obtenir comentaris de les trobades locals. Heu acabat el vostre informe i ara vosaltres i el públic ja esteu comunicant i discutint alguna cosa relacionada amb el vostre informe. Per a conferències grans, sovint no és així. Has fet un informe i ja està. El públic que vas tenir com a massa gris durant el reportatge ha marxat, i no en saps res més, no ho sents, no rebràs cap comentari.

Sigui el que es digui, les trobades locals són un gran tema en general i per als principiants en particular.

7 de desembre Baruch parlarà a la conferència DevOpsDays Moscou. En l'informe, Baruch analitzarà els errors reals que es produeixen diàriament i arreu quan s'actualitza el programari. Us mostrarà com els diferents patrons de DevOps encaixen en diferents escenaris i com aplicar-los correctament us podria salvar.

També al programa: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (consultor DevOps).

Vine a conèixer-te!

Font: www.habr.com

Afegeix comentari