"El informe no tiene derecho a ser aburrido": una entrevista con Baruch Sadogursky sobre hablar en conferencias

Baruch Sadogursky - Defensor del desarrollador en JFrog, coautor de Liquid Software, un conocido orador de TI.

En una entrevista, Baruch contó cómo se está preparando para los informes, cómo las conferencias extranjeras difieren de las rusas, por qué los participantes deberían asistir a ellas y por qué hablar con un disfraz de rana.



Comencemos con lo más simple. ¿Qué opinas, por qué incluso hablar en conferencias?

En realidad, para mí, hablar en conferencias es trabajo. Si responde de manera más global a la pregunta “¿Por qué mi trabajo?”, Entonces esto es para eso (al menos para JFrog) para lograr dos objetivos. En primer lugar, establecer contacto con nuestros usuarios y clientes. Es decir, cuando hablo en conferencias, estoy disponible para que todos los que tengan alguna pregunta, algún comentario sobre nuestros productos y empresas, puedan hablar conmigo, de alguna manera puedo ayudarlos y mejorar su experiencia. en trabajar con nuestros productos.

En segundo lugar, es necesario aumentar el conocimiento de la marca. Es decir, si le cuento algunas cosas interesantes, la gente está interesada en qué tipo de JFrog es, y como resultado, entra en nuestro embudo de relaciones con los desarrolladores, que finalmente va al embudo de nuestros usuarios, que finalmente va al embudo de nuestros clientes.

Dime, por favor, ¿cómo te estás preparando para tus actuaciones? ¿Hay algún algoritmo de preparación?

Hay cuatro pasos de preparación más o menos estándar. El primero es el inicio, como en una película. Alguna idea debería surgir. Aparece una idea, y luego madura por un tiempo bastante largo. Está madurando, piensas cómo es mejor presentar esta idea, en qué sentido, en qué formato, qué se puede decir al respecto. Esta es la primera etapa.

La segunda etapa es escribir un plan específico. Tienes una idea, y comienza a crecer en detalles sobre cómo la presentarás. Por lo general, esto se realiza en el formato de algún tipo de mapa mental, cuando todo lo relacionado con el informe aparece en torno a la idea: argumentos de apoyo, introducción, algunas historias que desea contar al respecto. Esta es la segunda etapa: el plan.

La tercera etapa es escribir diapositivas para este plan. Utiliza algunas ideas abstractas que aparecen en las diapositivas y respaldan su historia.

La cuarta etapa es carreras, ensayos. En esta etapa, es importante asegurarse de que el arco de la historia haya resultado, que la historia esté conectada, para asegurarse de que todo sea normal a tiempo. Después de eso, el informe puede declararse listo.

¿Cómo entiendes que "este tema" necesita ser abordado? ¿Y cómo se escribe material para informes?

No sé cómo responder, de alguna manera viene. O es "Oh, qué bueno resultó aquí", o es "Oh, nadie realmente lo sabe y entiende" y hay una oportunidad para contar, explicar y ayudar. Una de estas dos opciones.

La recopilación de material depende mucho del informe. Si este es un informe sobre algún tema abstracto, entonces esto es más literatura, artículos. Si esto es algo práctico, será escribir código, algunas demostraciones, encontrar las piezas de código correctas en los productos, etc.

Actuación de Baruch en la reciente Cumbre DevOps Amsterdam 2019

El miedo a las actuaciones y la emoción son algunas de las razones más comunes por las que la gente no sube al escenario. ¿Puedes dar algún consejo a aquellos que están preocupados durante las actuaciones? ¿Estás preocupado y cómo lidias?

Sí, lo tengo, debería ser, y, probablemente, en el momento en que dejo de preocuparme, esta es una ocasión para arreglar este asunto.

Me parece que esto es absolutamente normal cuando subes al escenario y hay mucha gente frente a ti. Te preocupas porque es una gran responsabilidad, es natural.

¿Cómo lidiar con eso? Hay diferentes formas Nunca lo he tenido a un nivel tal que necesite pelear directamente, así que es difícil para mí decirlo.

Lo más importante que me ayuda también es la cara amigable, una cara familiar en la audiencia. Si le pide a alguien que conozca que venga a su informe, que se siente en la primera fila en el medio para que siempre pueda mirarlo, y la persona será positiva, sonreirá, asentirá, apoyará, creo que esta es una gran ayuda. . No le pregunto específicamente a nadie sobre esto, pero si sucede que hay una cara familiar en la audiencia, ayuda mucho y alivia el estrés. Este es el consejo más importante.

Hablas mucho en conferencias rusas e internacionales. ¿Ves la diferencia entre los informes en conferencias rusas y extranjeras? ¿Hay alguna diferencia en la audiencia? En la organización?

Veo dos grandes diferencias. Está claro que las conferencias son diferentes tanto en Rusia como en el extranjero, pero si tomamos el promedio para el hospital, entonces en Rusia las conferencias son más técnicas en términos de la profundidad de los informes, en términos de hardcore. Esto es a lo que la gente está acostumbrada, posiblemente gracias a conferencias tan importantes como Joker, JPoint, Highload, que siempre se basaron en presentaciones hardcore. Y la gente espera de las conferencias exactamente esto. Y para muchos, este es un indicador de si es una buena conferencia o una mala: hay mucha carne y mucho hardcore o hay mucha agua.

Para ser honesto, tal vez porque hablo mucho en conferencias extranjeras, no estoy de acuerdo con este enfoque. Creo que los informes sobre habilidades blandas, "informes semi-humanitarios" no son menos, y tal vez incluso más importantes para las conferencias. Debido a que puede leer algunas cosas técnicas en los libros, puede descubrir el manual del usuario, pero con respecto a las habilidades blandas, con respecto a la psicología, con respecto a la comunicación, no hay ningún lugar para tomarlo todo, al menos Fácil, accesible y comprensible. Me parece que esto no es menos importante que el componente técnico.

Esto es especialmente importante para conferencias sobre DevOps, como DevOpsDays, porque DevOps no se trata de tecnología en absoluto. DevOps se trata solo de comunicación, se trata de formas de trabajar juntos para personas que antes no trabajaban juntas. Sí, hay un componente técnico allí, porque la automatización es crítica para DevOps, pero este es solo uno de ellos. Y cuando la conferencia DevOps, en lugar de hablar sobre DevOps, habla sobre la confiabilidad o automatización del sitio, o sobre las tuberías, entonces esta conferencia, a pesar del hecho de que es muy difícil, en mi opinión, simplemente pierde la esencia de DevOps y se convierte en conferencias sobre administración de sistemas, no sobre DevOps.

La segunda diferencia está en la preparación. Nuevamente, tomo el promedio para el hospital y los casos generales, no los privados. En el extranjero, se supone que la mayoría de las personas han recibido capacitación para hablar en público en sus vidas. Al menos en Estados Unidos, es parte de la educación superior. Si una persona se graduó de la universidad, ya tiene una experiencia considerable en hablar en público. Por lo tanto, después de que el comité del programa examinó el plan y se dio cuenta de qué se trataría el informe, no hay más entrenamientos sobre discursos para el orador, porque se cree que lo más probable es que sepa cómo.

En Rusia, tales suposiciones no se hacen porque pocas personas tienen experiencia en hablar en público y, por lo tanto, los oradores están mucho más capacitados. Nuevamente, en el caso general, hay carreras, hay clases con oradores, hay cursos en oratoria para ayudar a los oradores.

Como resultado, los hablantes débiles que hablan mal, son excluidos o se les ayuda a convertirse en hablantes más fuertes. El hecho de que en Occidente hablar en público se considere una habilidad que muchos tienen como resultado tiene el efecto contrario, porque esta suposición a menudo resulta ser falsa, errónea, y las personas que no saben hablar en público abiertamente se equivocan en el escenario y reciben informes desagradables. Y en Rusia, donde se cree que no hay experiencia en hablar en público, el resultado es mucho mejor, porque fueron entrenados, probados, elegidos bien, etc.

Estas son las dos diferencias.

¿Has estado en DevOpsDays en otros países? ¿Cómo crees que difieren de otras conferencias? ¿Hay alguna característica?

Probablemente estuve en varias docenas de conferencias DevOpsDays en todo el mundo: en Estados Unidos, en Europa y en Asia. Esta franquicia de conferencias es bastante única, ya que tiene un formato más o menos establecido que puede esperar en cualquier lugar de cualquiera de estas conferencias. El formato es el siguiente: hay relativamente pocas presentaciones de conferencias de front-end y se dedica mucho tiempo al formato de espacios abiertos.

Los espacios abiertos son un formato en el que el tema por el cual votó la mayoría de las personas se discute con otros participantes. El que propuso este tema: él es el anfitrión, hace que comience la discusión. Este es un formato excelente, porque, como sabemos, la comunicación y la creación de redes no son una parte menos importante de una conferencia que los informes. Y cuando la conferencia pasa la mitad de su tiempo bajo el formato de red, esto es muy bueno.

Además, DevOpsDays suele organizar Lightning Talks: estos son informes breves de cinco minutos que le permiten aprender mucho sobre las cosas y abrir los ojos a algunas cosas nuevas en un formato aburrido. Y si en medio de un informe regular te das cuenta de que no es tuyo, entonces se pierde tiempo, se pierden 30-40 minutos de tu vida, entonces aquí estamos hablando de informes durante cinco minutos. Y si no está interesado, entonces terminará pronto. "Cuéntanos, pero rápido", también es un muy buen formato.

Hay DevOpsDays más técnicos, hay aquellos que están diseñados específicamente para lo que es DevOps: procesos, colaboración, estas son las cosas. Es interesante tanto eso como otro, y es interesante cuando hay tanto eso como otro. Me parece que hoy es una de las mejores franquicias de conferencias sobre DevOps.

Muchas de sus presentaciones son similares a las presentaciones o presentaciones: luego cuenta un informe en forma de tragedia griega, luego interpreta el papel de Sherlock, luego actúa con un disfraz de rana. ¿Cómo se te ocurren? ¿Hay objetivos adicionales además de hacer que el informe sea aburrido?

Me parece que el informe no tiene derecho a ser aburrido, porque, en primer lugar, paso el tiempo de la audiencia, están menos involucrados en el informe aburrido, aprendieron menos, aprendieron menos, y esta no es la mejor pérdida de tiempo. En segundo lugar, mis objetivos tampoco se han logrado: no piensan nada bueno de mí, no piensan nada bueno de JFrog, y para mí es una especie de fracaso.

Por lo tanto, los informes aburridos no tienen derecho a existir, al menos para mí. Trato de hacerlos interesantes, atractivos y memorables. Las actuaciones son unidireccionales. Y, de hecho, el método es bastante fácil. Todo lo que se necesita es encontrar un formato interesante, y luego los mismos pensamientos que se presentan en forma de un informe regular, establecidos en un formato inusual.

¿Cómo se me ocurre esto? Sucede de diferentes maneras. A veces son algunas ideas las que me vienen a la mente, a veces son ideas que me dan cuando corro o comparto mis pensamientos sobre el informe y me dicen: "¡Oh, esto se puede hacer así!" Sucede de manera diferente. Cuando aparece una idea, siempre es muy alegre y genial, lo que significa que se puede hacer un informe más interesante e involucrado.



¿Qué aspectos de la esfera de TI le gustan personalmente? ¿Hay tales oradores? Y por que

Hay dos tipos de oradores cuyas apariencias me gustan. El primero son los altavoces que trato de ser. Cuentan interesantes e involucrados, intentan que todos estén interesados ​​y escuchen.

El segundo tipo de oradores son aquellos que pueden decir de manera muy interesante y emocionante sobre cualquier hardcore generalmente aburrido.

De los nombres en la segunda categoría, este es Aleksey Shepelev, quien habla sobre la recolección de basura de alto rendimiento y el interior de la máquina virtual de Java, que es interesante y humorístico. Otra apertura de los últimos DevOops es Sergey Fedorov de Netflix. Él contó algo puramente técnico sobre cómo optimizaron su red de entrega de contenido, y lo contó de manera muy interesante.

De la primera categoría están Jessica Deen, Anton Weiss, Roman Shaposhnik. Estos son los oradores que cuentan de manera interesante, con humor, y que reciben merecidamente altas calificaciones.

Seguramente tienes más invitaciones para hablar en conferencias que tiempo para esto. ¿Cómo eliges dónde vas y dónde no?

Las conferencias y los oradores, como casi todo lo demás, se rigen por las relaciones de mercado de oferta y demanda y el valor mutuo. Hay conferencias que, por así decirlo, me quieren más de lo que las necesito. En términos de la audiencia que espero encontrar allí, y el impacto que espero traer allí. Hay conferencias que, por el contrario, quiero obtener mucho más de lo que me necesitan. En términos de valor para mí, decido a dónde ir.

Es decir, si esto, por ejemplo, es algún tipo de geografía, en la que estratégicamente necesito entrar, esta es una conferencia grande y bien conocida, que tiene una buena reputación y a la que la gente asistirá, entonces obviamente realmente la necesito. Y lo preferiría a otras conferencias.

Si se trata de algún tipo de pequeña conferencia regional, y tal vez donde no estamos muy interesados, puede ser que un viaje allí no justifique los costos de tiempo que se impondrán a este negocio. Relaciones normales de mercado de demanda, oferta y valor.

Buena geografía, buena demografía, contactos potencialmente buenos, comunicación: la clave del hecho de que la conferencia será interesante para mí.

En una de sus entrevistas, mencionó que durante el año habla en unas cuarenta conferencias. ¿Cómo te las arreglas para trabajar y prepararte para las actuaciones? ¿Y te las arreglas para mantener el equilibrio trabajo / vida con ese horario? ¿Compartir secretos?

Viajar a conferencias es la parte más importante de mi trabajo. Por supuesto, hay todo lo demás: hay preparación para informes, mantenerse en forma técnica, escribir código, aprender cosas nuevas. Todo esto se hace en paralelo con las conferencias: por las tardes, en el avión, el día anterior, cuando ya llegué a la conferencia, y será mañana. Algo asi.

Es difícil, por supuesto, mantener el equilibrio trabajo / vida cuando hay tanto tiempo en viajes de negocios. Pero trato de compensar esto por el hecho de que, al menos cuando no estoy en un viaje de negocios, estoy 100% con mi familia, no respondo correos electrónicos por las noches, trato de no participar en ninguna llamada telefónica por las tardes y los fines de semana. Cuando no estoy en un viaje de negocios y esto es tiempo familiar, entonces esto es realmente 100% tiempo familiar. ¿Funciona esto y resuelve el problema? No Pero espero que esto de alguna manera compense a mi familia por todo el tiempo que estoy ausente.

Uno de los informes de Baruch es "Tenemos DevOps. Vamos a despedir a todos los probadores "

Con un horario tan apretado, ¿logras mantener un nivel técnico o ya te has alejado de la programación?

Intento hacer algunas cosas técnicas mientras me preparo para mis informes y otras actividades en la conferencia. Estos son todo tipo de demostraciones técnicas, algunos mini informes que tenemos en los stands. Esto no es programación, es más integración, pero esto es al menos un trabajo técnico que intento hacer. De esta manera, mantengo el conocimiento de nuestros productos, nuevas características, etc.

Por supuesto, decir que ahora soy el mismo codificador hardcore que tenía hace 7 años, probablemente ya sea imposible. No estoy seguro si esto es malo. Esto es probablemente algún tipo de evolución natural. Esto es menos interesante para mí y hay menos tiempo, así que, probablemente, que Dios esté con él.

Todavía me considero un fuerte especialista técnico, todavía estoy consciente de lo que está sucediendo, me mantengo en buena forma. Aquí está mi situación híbrida hoy.

Por favor, cuénteme un par de historias graciosas o situaciones extremas que le hayan sucedido: llegó tarde al avión / borró la presentación / apagó la electricidad durante el informe / ¿no llegó el equipaje?

De las situaciones divertidas, recuerdo la mayoría de los fracasos de pesadillas que ocurrieron en los informes. Naturalmente, porque esta es la situación más estresante, porque es el público, el tiempo, y debe asegurarse de que no lo desperdicien en vano.

Tuve una "pantalla azul de la muerte" en Windows y Mac durante la charla. En Windows fue una vez, en Mac un par de veces. Esto, por supuesto, es estresante, pero de alguna manera resolvemos este problema, la computadora se reinicia, sigo contando algo en este momento, pero el estrés es enorme.

Probablemente la situación más divertida que tuve en la conferencia de Groovy. No recuerdo exactamente dónde se celebró la conferencia, al parecer, en un hotel, y frente a este hotel hubo algún tipo de construcción o reparación. Y entonces estaba hablando de algún tipo de código que escribí, era una demostración. Esta fue la primera iteración de la demostración, que era comprensible, pero tal vez no estaba escrita de la mejor manera. Iba a refactorizarlo y mejorarlo, y mencioné algún tipo de frase como "autocrítico" sobre el hecho de que se trata de "código de mierda". Estaba en el segundo piso, y en este momento la grúa en el sitio de construcción enfrente solo estaba levantando el inodoro portátil. Y la escena estaba enfrente de la ventana. Es decir, miro por esta ventana, digo "código de mierda", y un inodoro flota fuera de la ventana. Y les digo a todos: "Date la vuelta, tenemos una ilustración aquí". Probablemente fue la mejor diapositiva de mis pensamientos: el inodoro volador en mi charla cuando hablaba de código de mierda.

El equipaje no provenía de historias como esta: en principio, es una historia normal, no hay nada de qué hablar. Podemos organizar una entrevista por separado sobre todo tipo de consejos de viaje, donde puede hablar sobre el equipaje que no llegó, pero no hubo nada crítico.

Me esfuerzo mucho a toda costa para volar siempre, entrar y asistir a todas las conferencias que prometí, porque, una vez más, es hora de que la gente. El tiempo de las personas no tiene precio porque es el tipo de crédito de confianza que le dan. Y si este préstamo se engaña, entonces no podrá recuperarlo.

Si una persona se tomó el tiempo, vino a la conferencia para escuchar mi informe, pero lo tomé y no asistí, esto es malo, porque no hay forma de devolverle el tiempo a esta persona. , .

: « ? , ». , ?

! . - . , soft skills. , , soft skills. .

, , , . , , , — . , , , - . .

: — .

DevOpsCon

, , - , ?

. — . -, . , , - , , , , . , - , .

, . 10-15-30 — , 150-200-300 , .

, : , , . , , -, . , , +1, , . , , -- , .

— . , , 60 , , . — , , , , .

, . -, . . . , , , , , .

, — .

El 7 de diciembre, Baruch hablará en la conferencia DevOpsDays Moscú . En el informe, Baruch analizará las fallas reales que ocurren diariamente y en todas partes al actualizar el software. Mostrará cómo todo tipo de patrones de DevOps se ajustan a diferentes escenarios y cómo su aplicación adecuada podría salvarte.

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

Ven a conocer!