"O informe non ten dereito a ser aburrido": unha entrevista con Baruch Sadogursky sobre discursos en conferencias

Baruch Sadogursky - Developer Advocate en JFrog, coautor do libro "Liquid Software", famoso orador de TI.

Nunha entrevista, Baruch explicou como se prepara para os seus informes, como se diferencian as conferencias estranxeiras das rusas, por que os participantes deberían asistir a elas e por que deberían falar cun traxe de sapo.

"O informe non ten dereito a ser aburrido": unha entrevista con Baruch Sadogursky sobre discursos en conferencias

Comecemos polo máis sinxelo. Por que cres que falar en conferencias?

De feito, falar en congresos é un traballo para min. Se respondemos de forma máis xeral á pregunta "Por que é o meu traballo?", entón isto é para (polo menos para a empresa JFrog) acadar dous obxectivos. En primeiro lugar, establecer contacto cos nosos usuarios e clientes. É dicir, cando falo nas conferencias, estou dispoñible para que todos os que teñan dúbidas, algún comentario sobre os nosos produtos e empresa, poidan falar comigo, poder axudalos dalgún xeito e mellorar a súa experiencia no traballo cos nosos produtos.

En segundo lugar, isto é necesario para aumentar a notoriedade da marca. É dicir, se conto algunhas cousas interesantes, entón a xente está interesada en que tipo de JFrog é este e, como resultado, acaban no noso funil de relacións con desenvolvedores, que finalmente pasa ao funil dos nosos usuarios, que finalmente pasa ao funil dos nosos clientes.

Cóntanos como te preparas para as actuacións? Existe algún tipo de algoritmo de preparación?

Hai catro etapas máis ou menos estándar de preparación. O primeiro é o inicio, como nas películas. Debe aparecer algunha idea. Aparece unha idea, e despois madura durante bastante tempo. Vai madurando, estás a pensar como presentar mellor esta idea, en que clave, en que formato, que se pode dicir sobre ela. Esta é a primeira etapa.

A segunda etapa é escribir un plan específico. Tes unha idea, e comeza a adquirir detalles sobre como a presentarás. Isto adoita facerse nalgún formato de mapa mental, cando todo o relacionado co informe aparece arredor da idea: argumentos de apoio, introdución, algunhas historias que se quere contar sobre el. Esta é a segunda etapa - o plan.

A terceira etapa é escribir diapositivas segundo este plan. Usas algunhas ideas abstractas que aparecen nas diapositivas e apoias a túa historia.

A cuarta etapa son as probas e os ensaios. Nesta fase, é importante asegurarse de que o arco da historia resultou, de que a historia é coherente e de que todo estea ben en termos de tempo. Despois diso, o informe pódese declarar listo.

Como entendes que hai que abordar "este tema"? E como recolle o material para os informes?

Non sei como responder, só chega dalgún xeito. Ou é "Oh, que xenial quedou aquí", ou é "Oh, ninguén realmente sabe ou entende sobre isto", e hai unha oportunidade de contar, explicar e axudar. Unha destas dúas opcións.

A recollida de material depende moito do informe. Se este é un informe sobre algún tema abstracto, entón é máis literatura, artigos. Se isto é algo práctico, entón será escribir código, algunhas demostracións, atopar as pezas correctas de código nos produtos, etc.

Discurso de Baruch no recente DevOps Summit Amsterdam 2019

O medo ao rendemento e a ansiedade son algunhas das razóns máis comúns polas que a xente non sube ao escenario. Tes algún consello para aqueles que se senten nerviosos ao actuar? Estás preocupado e como te enfrontas?

Si, téñoo, debería ser, e, probablemente, no momento no que deixo de preocuparme por completo, este é un motivo para deixar este asunto.

Paréceme que este é un fenómeno completamente normal cando vas ao escenario e hai moita xente diante de ti. Preocúpate porque é unha gran responsabilidade, é natural.

Como tratar con isto? Hai diferentes formas. Nunca o tiven a tal nivel que necesite loitar contra el directamente, polo que cústame dicir.

O máis importante que tamén me axuda é unha cara amiga, algunha cara coñecida entre o público. Se lle pides a alguén que coñeces que veña á túa charla, séntese na primeira fila do medio para poder mirar sempre para el, e a persoa será positiva, sorrirá, asentirá, apoiará, creo que isto é enorme, axuda enorme. Non lle pido a ninguén que faga isto, pero se ocorre que hai unha cara coñecida no público, axuda moito e alivia o estrés. Este é o consello máis importante.

Falas moito en conferencias rusas e internacionais. Ves a diferenza entre os informes en conferencias rusas e estranxeiras? Hai diferenza na audiencia? Na organización?

Vexo dúas grandes diferenzas. Está claro que as conferencias son diferentes tanto en Rusia como no estranxeiro, pero se tomamos a media do hospital, entón en Rusia as conferencias son máis técnicas en canto á profundidade dos informes, en termos de hardcore. Isto é ao que a xente está afeita, quizais grazas a conferencias tan importantes como Joker, JPoint, Highload, que sempre se basearon en presentacións hardcore. E isto é exactamente o que a xente espera das conferencias. E para moita xente isto é un indicador de se esta conferencia é boa ou mala: hai moita carne e hardcore ou hai moita auga.

Sinceramente, quizais polo feito de falar moito en congresos estranxeiros, non estou de acordo con este enfoque. Creo que os informes sobre habilidades blandas, “informes semi-humanitarios”, non son menos, e quizais aínda máis importantes para as conferencias. Debido a que algunhas cousas técnicas pódense ler finalmente nos libros, podes descubrilas usando o manual de usuario, pero cando se trata de habilidades blandas, cando se trata de psicoloxía, cando se trata de comunicación, non hai onde conseguir todo isto, polo menos. fácil, accesible e comprensible. Paréceme que isto non é menos importante que o compoñente técnico.

Isto é especialmente importante para conferencias de DevOps como DevOpsDays, porque DevOps non trata en absoluto de tecnoloxía. DevOps só se trata de comunicacións, trátase só de formas de traballar xuntos para persoas que non traballaron antes. Si, hai un compoñente técnico, porque a automatización é fundamental para DevOps, pero este é só un deles. E cando unha conferencia DevOps, en lugar de falar de DevOps, fala de fiabilidade do sitio ou de automatización ou canalizacións, entón esta conferencia, a pesar de que é moi hardcore, na miña opinión, perde a esencia mesma de DevOps e convértese en conferencias sobre administración de sistemas. , non sobre DevOps.

A segunda diferenza está na preparación. De novo, tomo a media hospitalaria e os casos xerais, non os específicos. No estranxeiro, asumen que a maioría da xente se someteu a algún tipo de formación para falar en público nas súas vidas. Polo menos en América, é parte da educación superior. Se unha persoa se formou na universidade, entón xa ten unha experiencia considerable en falar en público. Por iso, despois de que a comisión do programa estudie o plan e entenda de que vai o informe, non se fai máis formación para falar por quen fala, porque se cre que, moi probablemente, sabe como facelo.

En Rusia, tales suposicións non se fan, porque poucas persoas teñen experiencia en falar en público e, polo tanto, os falantes están formados moito máis. De novo, en xeral, hai paseos, hai clases con relatores, hai cursos de fala en público para axudar aos falantes.

Como resultado, elimínanse os falantes débiles que se comunican mal, ou se lles axuda a converterse en presentadores máis fortes. O feito de que en Occidente falar en público se considere unha habilidade que teñen moitas persoas, ten ao final o efecto contrario, porque esta suposición adoita resultar falsa, errónea e as persoas que non saben falar en público enganan abertamente. escenificar e producir informes noxentos. E en Rusia, onde se cre que non hai experiencia en falar en público, ao final resulta moito mellor, porque foron adestrados, foron probados, escolleron un bo, etc.

Estas son as dúas diferenzas.

Estiveches en DevOpsDays noutros países? En que cres que se diferencian doutras conferencias? Hai algunha característica especial?

Probablemente estiven en varias ducias de conferencias DevOpsDays en todo o mundo: en América, Europa e Asia. Esta franquía de conferencias é bastante única xa que ten un formato máis ou menos establecido que podes esperar en calquera lugar de calquera destas conferencias. O formato é o seguinte: hai relativamente poucas presentacións de conferencias de primeira liña e dedícase moito tempo ao formato de espazos abertos.

Os espazos abertos é un formato no que se discute o tema polo que máis persoas votou xunto con outros participantes. Quen propuxo este tema é o líder, vela por que comece a discusión. Este é un gran formato porque, como sabemos, a comunicación e o traballo en rede non son partes menos importantes de calquera conferencia que as presentacións. E cando unha conferencia dedica a metade do seu tempo a un formato de rede, é moi xenial.

Ademais, os Lightning Talks adoitan celebrarse nos DevOpsDays: son informes breves de cinco minutos que che permiten aprender moito sobre moitas cousas e abrir os ollos a algunhas cousas novas nun formato non aburrido. E se no medio dun informe regular te decataches de que isto non é o teu, entón pérdese o tempo, 30-40 minutos da túa vida son desperdiciados, entón aquí estamos falando de informes durante cinco minutos. E se non che interesa, rematará pronto. "Cóntanos, pero rápido" tamén é un formato moi bo.

Hai DevOpsDays máis técnicos, e hai outros que se adaptan especificamente ao que é DevOps: procesos, colaboración, cousas así. É interesante ter os dous, e é interesante ter os dous. Creo que esta é unha das mellores franquías de conferencias DevOps hoxe.

Moitas das túas actuacións son similares a representacións ou obras de teatro: ás veces dás unha charla en forma de traxedia grega, ás veces interpretas o papel de Sherlock, ás veces actúas cun traxe de sapo. Como se lles ocorre? Hai algún obxectivo adicional ademais de que o informe non sexa aburrido?

A min paréceme que unha reportaxe non ten dereito a ser aburrida, porque, en primeiro lugar, perdo o tempo dos oíntes, nunha reportaxe aburrida están menos implicados, aprenden menos, aprenden menos cousas novas, e isto non é. a mellor perda do seu tempo. En segundo lugar, tampouco se acadaron os meus obxectivos: non pensan nada bo sobre min, non pensan nada bo sobre JFrog, e para min isto é unha especie de fracaso.

Polo tanto, os informes aburridos non teñen dereito a existir, polo menos para min. Intento facelos interesantes, atractivos e memorables. As actuacións son dun xeito. E, de feito, o método é bastante sinxelo. Todo o que precisa é crear algún formato interesante e, a continuación, presentar os mesmos pensamentos que se presentan en forma de informe regular nun formato inusual.

Como se me ocorre isto? Non sempre é o mesmo. Ás veces, estas son algunhas ideas que se me ocorren, outras son algunhas ideas que se me dan cando fago repasos ou comparto ideas sobre un informe e dinme: "Oh, pódese facer así!" Ocorre doutro xeito. Cando aparece unha idea, sempre é moi alegre e xenial, o que significa que podes facer unha reportaxe máis interesante e implicada.

"O informe non ten dereito a ser aburrido": unha entrevista con Baruch Sadogursky sobre discursos en conferencias

De quen lle gustan persoalmente os discursos do ámbito informático? Existen este tipo de altofalantes? E por que?

Hai dous tipos de relatores cuxas presentacións me gustan. O primeiro son os altofalantes que intento ser. Falan dun xeito interesante e implicado, procurando que todos estean interesados ​​e que todos escoiten.

O segundo tipo de altofalantes son aqueles que poden falar de calquera hardcore habitualmente aburrido dun xeito moi interesante e emocionante.

Dos nomes da segunda categoría, este é Alexey Shepelev, quen fala de algún tipo de recollida de lixo de rendemento profundo e do interior da máquina virtual java dun xeito interesante e humorístico. Outro descubrimento do último DevOops é Sergey Fedorov de Netflix. Contou unha cousa puramente técnica sobre como optimizaron a súa rede de distribución de contidos, e contouno dun xeito moi interesante.

Da primeira categoría - estes son Jessica Deen, Anton Weiss, Roman Shaposhnik. Estes son os relatores que falan de xeito interesante, con humor, e reciben merecidamente altas valoracións.

Probablemente teñas máis invitacións para falar nas conferencias que tempo para facelo. Como elixes onde irás e onde non?

As conferencias e os relatores, como case todo o resto, réxense polas relacións de mercado de oferta e demanda e o valor dunhas a outras. Hai conferencias que, pois, digamos, querenme máis do que as necesito. En canto ao público que espero atopar alí e ao impacto que espero ter alí. Hai conferencias ás que, pola contra, quero ir moito máis do que me precisan. En función do valor para min, decido onde ir.

É dicir, se este é, por exemplo, algún tipo de xeografía onde teño que ir estratexicamente, esta é unha conferencia grande e coñecida que ten boa reputación e á que a xente vai ir, obviamente o necesito moito. E prefiro a outras conferencias.

Se se trata dunha pequena conferencia autonómica, e, quizais, na que non nos interesa moito, pode ser que a viaxe alí non xustifique o tempo dedicado a este asunto. Relacións normais de mercado de demanda, oferta e valor.

Boa xeografía, boa demografía, potencialmente bos contactos, comunicación son a garantía de que a conferencia será interesante para min.

Nunha das túas entrevistas mencionaches que falas nunhas corenta conferencias ao ano. Como consegues traballar e preparar as actuacións? E consegues manter a conciliación laboral/vida familiar con tal horario? Compartir os teus segredos?

Viaxar a conferencias é a parte do león do meu traballo. Por suposto, hai todo o demais: hai preparación para informes, manterse en forma técnica, escribir código, aprender cousas novas. Todo isto faise paralelamente ás conferencias: polas noites, no avión, o día anterior, cando xa chegaches á conferencia, e é mañá. Algo coma isto.

É difícil, por suposto, manter a conciliación da vida laboral e familiar cando pasas tanto tempo en viaxes de negocios. Pero intento compensalo co feito de que, polo menos cando non estou de viaxe de negocios, estou 100% coa miña familia, non respondo correos electrónicos polas noites, procuro non participar en ningún. chamadas polas noites e os fins de semana. Cando non estou nunha viaxe de negocios e é tempo familiar, realmente é tempo 100% familiar. Funciona isto e resolve o problema? Non. Pero espero que isto compensará dalgún xeito á miña familia durante todo o tempo que estou fóra.

Un dos informes de Baruch é "Temos DevOps. Imos despedir a todos os probadores".

Cun calendario tan apretado, logras manter o teu nivel técnico ou xa te afastaches da programación?

Intento facer algunhas cousas técnicas mentres me preparo para as miñas charlas e outras actividades na conferencia. Son todo tipo de demostracións técnicas, uns minirreportaxes que damos nos stands. Isto non é programación-programación, isto é máis integración, pero isto é polo menos un traballo técnico que intento facer. Deste xeito manteño o coñecemento dos nosos produtos, novas funcións, etc.

Por suposto, probablemente sexa imposible dicir que agora son o mesmo programador hardcore que hai 7 anos. Non estou seguro se iso é algo malo. Esta é probablemente unha especie de evolución natural. Isto é menos interesante para min, e teño menos tempo, entón, probablemente, Deus o bendiga.

Sigo considerándome un gran especialista técnico, sigo ao tanto do que está a suceder, sigo atento. Esta é a miña situación híbrida hoxe.

Cóntanos un par de historias divertidas ou situacións extremas que che pasaron: perdeches o avión/eliminou a presentación/corteu a luz durante a reportaxe/non chegou a equipaxe?

Das situacións divertidas, o que máis recordo son todo tipo de terribles fracasos que ocorreron durante as reportaxes. Por suposto, porque esta é a situación máis estresante, porque é o público, o tempo e hai que asegurarse de que non o desperdicien.

Tiven unha "pantalla azul da morte" tanto en Windows como en Mac durante a charla. En Windows pasou unha vez, en Mac un par de veces. Isto é, por suposto, estresante, pero dalgunha maneira resolvemos este problema, o ordenador reinicia, sigo contando algo neste momento, pero o estrés é enorme.

Probablemente a situación máis divertida que tiven foi nunha conferencia de Groovy. Non lembro exactamente onde se celebrou a conferencia, ao parecer, nun hotel, e fronte a este hotel houbo algún tipo de construción ou reforma. E entón falei sobre algún código que escribín, era unha demostración. Esta foi a primeira iteración da demo, que era comprensible, pero quizais non estaba ben escrita. E só ía refactorizar e melloralo, e mencionei algunha frase como "autodespreciar" sobre o feito de que isto é "código de merda". Estaba no segundo andar, e nese momento un guindastre da obra de enfrente estaba só levantando un inodoro portátil. E o escenario estaba fronte á fiestra. É dicir, miro por esta fiestra, digo "código de merda" e un inodoro flota á beira da fiestra. E dígolles a todos: "Dá a volta, aquí temos unha ilustración". Esta foi probablemente a mellor diapositiva dos meus pensamentos: o baño voador do meu informe cando falaba de código de merda.

De historias como a equipaxe non veu - esta é, en principio, unha historia normal, non hai nada que falar. Podemos organizar unha entrevista separada sobre todo tipo de consellos de viaxe, onde podemos falar da equipaxe que non chegou, pero non houbo nada crítico.

Esforzo a toda costa voar sempre, vir asistir a todas as conferencias nas que prometín, porque, de novo, é o momento da xente. O tempo da xente non ten prezo porque é un crédito de confianza que che dan. E se se desperdicia este préstamo, non hai forma de recuperalo máis tarde.

Se unha persoa pasou tempo, veu á conferencia para escoitar o meu informe, e eu o tomei e non vin, isto é malo, porque non hai forma de recuperar o tempo desta persoa. Polo tanto, é súper importante para min cumprir todas as miñas promesas neste sentido, e ata agora todo está funcionando.

Moita xente pensa así: “Por que ir a conferencias? Podes ver o vídeo en YouTube e sempre podes falar en liña". Por que cres que os participantes teñen que ir a conferencias?

Gran pregunta! Deberías ir a conferencias para facer redes. Isto non ten prezo e non hai outro xeito de conseguilo. Xa mencionei a importancia da comunicación, a comunicación e as habilidades blandas. Ver un vídeo en YouTube, por desgraza, non proporciona experiencia en habilidades sociais. Polo tanto, cómpre ir a conferencias por mor da comunicación.

Ademais, polo menos para min, cando vexo vídeos en YouTube, o compromiso é completamente diferente, e o material lémbrase e lémbrase moito menos ben. Quizais só sexa eu, pero sospeito que estar na sala nunha charla e ver un vídeo en YouTube son cousas completamente diferentes. Sobre todo se a reportaxe é boa, paréceme que é moito, moito mellor escoitala en directo. É como escoitar un concerto en directo e un disco.

E repito unha vez máis: o traballo en rede e a comunicación non son algo que poidas sacar de YouTube.

Informe conxunto con Leonid Igolnik na DevOpsCon

Por favor, dálle algunhas palabras de despedida a aqueles que só están planeando converterse en orador ou que acaban de comezar a falar?

Busca encontros locais. As reunións locais son unha boa forma de comezar a túa carreira de orador por varios motivos. En primeiro lugar, as reunións locais sempre buscan oradores. Pode ser que, sen experiencia e sen ser un orador famoso, che resulte difícil presentarte a algunha conferencia famosa, ou a comisión do programa, despois de comunicarse contigo, entenda que quizais aínda sexa un pouco cedo para ti. Pola contra, as reunións locais sempre buscan oradores e a barra de entrada é moito, moito máis baixa, polo que é moito máis fácil chegar.

Ademais, o nivel de estrés é completamente diferente. Cando veñen 10-15-30 persoas, non é para nada o mesmo que cando hai 150-200-300 persoas no salón, polo que é moito máis sinxelo.

De novo, os custos dunha reunión local son moito máis baixos: non tes que voar a ningún lado, non tes que pasar días, só podes vir pola noite. Lembrando os meus consellos sobre a importancia de ter unha cara amable entre o público, é moito máis doado acudir a unha reunión local con alguén porque non custa diñeiro. Se falas nunha conferencia, ti como orador ven de balde, pero este +1 teu, que será unha cara amiga do público, ten que mercar unha entrada. Se estás a falar nunha reunión, non hai tal problema, podes traer contigo un ou dous ou tres amigos que serán unha cara amiga na sala.

E unha vantaxe adicional é que os organizadores de encontros teñen moitas máis oportunidades de axudarche. Porque os organizadores do congreso terán, por exemplo, 60 presentacións que deben ser revisadas, practicadas e preparadas. E os organizadores dos encontros teñen un, dous ou tres, polo que, naturalmente, recibirás moita máis atención.

Ademais, é moito máis doado obter comentarios das reunións locais. Remataches o teu informe e agora ti e a audiencia xa estás comunicando e discutindo algo relacionado co teu informe. Para conferencias grandes moitas veces non é o caso. Fixeches un informe e xa está. O público, que foi unha masa gris durante a túa reportaxe, marchou, e xa non sabes nada deles, non escoitas, non recibirás ningún comentario.

Diga o que se diga, as reunións locais son un gran tema en xeral e para os principiantes en particular.

Baruch falará na conferencia do 7 de decembro DevOpsDays Moscova. No seu informe, Baruch analizará os fallos reais que se producen todos os días e en todas partes á hora de actualizar o software. Mostrará como todo tipo de patróns DevOps encaixan en diferentes escenarios e como aplicalos correctamente pode salvarte.

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

Ven a coñecer!

Fonte: www.habr.com

Engadir un comentario