“O relatório não tem o direito de ser chato”: uma entrevista com Baruch Sadogursky sobre falar em conferências

Baruch Sadogursky - Desenvolvedor Advogado na JFrog, co-autor de Liquid Software, um conhecido palestrante de TI.

Em uma entrevista, Baruch contou como está se preparando para os relatórios, como as conferências estrangeiras diferem das russas, por que os participantes deveriam comparecer e por que falar fantasiando de sapo.



Vamos começar com o mais simples. O que você acha, por que falar em conferências?

Na verdade, para mim, falar em conferências é trabalho. Se você responder de maneira mais global à pergunta "Por que meu trabalho?", Então é para isso (pelo menos para o JFrog), a fim de alcançar dois objetivos. Em primeiro lugar, estabelecer contato com nossos usuários e clientes. Ou seja, quando falo em conferências, estou disponível para que todos que tiverem alguma dúvida, algum feedback sobre nossos produtos e empresas possam falar comigo, de alguma forma eu possa ajudá-los e melhorar sua experiência. no trabalho com nossos produtos.

Em segundo lugar, é necessário aumentar o reconhecimento da marca. Ou seja, se eu lhe contar algumas coisas interessantes, as pessoas estão interessadas em que tipo de JFrog é e, como resultado, ele entra no nosso funil de relações com desenvolvedores, que acaba indo para o funil de usuários, que acaba indo para o funil de nossos clientes.

Diga-me, por favor, como você está se preparando para suas apresentações? Existe algum algoritmo de preparação?

Existem quatro etapas de preparação mais ou menos padrão. O primeiro é o início, como em um filme. Alguma idéia deve surgir. Uma idéia aparece e depois amadurece por um longo tempo. Está amadurecendo, você pensa em como é melhor apresentar essa idéia, em que sentido, em que formato, o que pode ser dito sobre isso. Esta é a primeira etapa.

A segunda etapa é escrever um plano específico. Você tem uma ideia e ela começa a crescer em detalhes sobre como você a apresentará. Normalmente, isso é feito no formato de algum tipo de mapa mental, quando tudo relacionado ao relatório aparece em torno da ideia: argumentos de apoio, introdução, algumas histórias que você deseja contar. Esta é a segunda etapa - o plano.

A terceira etapa é escrever slides para este plano. Você usa algumas idéias abstratas que aparecem nos slides e apóiam sua história.

O quarto estágio é executado, ensaios. Nesse estágio, é importante garantir que o arco da história tenha saído, que a história esteja conectada, para garantir que tudo esteja normal a tempo. Depois disso, o relatório pode ser declarado pronto.

Como você entende que "esse tópico" precisa ser abordado? E como você digita material para relatórios?

Eu não sei como responder, ele próprio vem de alguma forma. Ou é "Ah, como ficou legal aqui" ou "Ah, ninguém realmente sabe e entende sobre isso" e há uma oportunidade de contar, explicar e ajudar. Uma dessas duas opções.

A coleta de material depende muito do relatório. Se este é um relatório sobre algum tópico abstrato, então há mais literatura, artigos. Se isso for algo prático, ele estará escrevendo código, algumas demos, encontrando os trechos de código certos nos produtos e assim por diante.

Desempenho de Baruch na recente DevOps Summit Amsterdam 2019

O medo de apresentações e o entusiasmo são alguns dos motivos mais comuns pelos quais as pessoas não sobem ao palco. Você pode dar alguns conselhos para aqueles que estão preocupados durante as apresentações? Você está preocupado e como lida?

Sim, eu tenho, deve ser, e, provavelmente, no momento em que paro de me preocupar, é uma ocasião para me relacionar com esse assunto.

Parece-me que isso é absolutamente normal quando você sobe no palco e há muitas pessoas na sua frente. Você se preocupa porque é uma grande responsabilidade, é natural.

Como lidar com isso? Existem maneiras diferentes. Eu nunca tive um nível tão alto que preciso lutar diretamente, então é difícil para mim dizer.

A coisa mais importante que também me ajuda é o rosto amigável - um rosto familiar na platéia. Se você perguntar a alguém que você conhece para ir ao seu relatório, sentar na primeira fila no meio para que você possa sempre olhar para ele, e a pessoa será positiva, sorrirá, acenará com apoio, acho que essa é uma ajuda enorme e enorme . Eu não pergunto especificamente a ninguém sobre isso, mas se acontecer que haja um rosto familiar na platéia, isso ajudará bastante e aliviará o estresse. Este é o conselho mais importante.

Você fala muito em conferências russas e internacionais. Você vê a diferença entre os relatórios nas conferências russas e estrangeiras? Existe alguma diferença na audiência? Na organização?

Eu vejo duas grandes diferenças. É claro que as conferências são diferentes na Rússia e no exterior, mas se considerarmos a média do hospital, na Rússia as conferências são mais técnicas em termos de profundidade dos relatórios, em termos de hardcore. É a isso que as pessoas estão acostumadas, possivelmente graças a grandes conferências como Joker, JPoint, Highload, que sempre foram baseadas em apresentações hardcore. E as pessoas esperam das conferências exatamente isso. E para muitos, esse é um indicador de se é uma conferência boa ou ruim: há muita carne e hardcore lá ou muita água.

Para ser sincero, talvez porque falo muito em conferências estrangeiras, não concordo com essa abordagem. Acredito que relatórios sobre habilidades sociais, “relatórios semi-humanitários” não são menos, e talvez ainda mais importantes para conferências. Como você pode ler algumas coisas técnicas nos livros, pode descobrir o manual do usuário, mas com relação às habilidades pessoais, com relação à psicologia, com relação à comunicação, não há para onde levar tudo, pelo menos fácil, acessível e compreensível. Parece-me que isso não é menos importante que o componente técnico.

Isso é especialmente importante para conferências no DevOps, como o DevOpsDays, porque o DevOps não é sobre tecnologia. O DevOps se refere apenas à comunicação, trata-se de maneiras de trabalhar em conjunto para pessoas que não trabalharam juntas antes. Sim, há um componente técnico lá, porque a automação é essencial para o DevOps, mas este é apenas um deles. E quando a conferência do DevOps, em vez de falar sobre o DevOps, fala sobre confiabilidade ou automação do site, ou sobre pipelines, essa conferência, apesar do fato de ser muito hardcore, na minha opinião, perde a essência do DevOps e se torna conferências sobre administração do sistema, não sobre DevOps.

A segunda diferença está em preparação. Mais uma vez, tomo a média dos casos hospitalares e gerais, e não particulares. No exterior, supõe-se que a maioria das pessoas tenha passado por algum treinamento de falar em público em suas vidas. Pelo menos na América, faz parte do ensino superior. Se uma pessoa se formou na faculdade, então ele já tem uma experiência considerável em falar em público. Portanto, depois que o comitê do programa examinou o plano e percebeu o que seria o relatório, não há mais treinamentos sobre discursos para o orador, pois acredita-se que ele provavelmente saiba como.

Na Rússia, essas suposições não são feitas, porque poucas pessoas têm experiência em falar em público e, portanto, os palestrantes são muito mais treinados. Novamente, no caso geral, há corridas, há aulas com palestrantes, existem cursos de oratória para ajudar os palestrantes.

Como resultado, os falantes fracos que falam mal, são excluídos ou são ajudados a se tornarem falantes mais fortes. O fato de falar em público no Ocidente ser considerado uma habilidade que muitos têm como resultado obtém o efeito oposto, porque essa suposição é frequentemente falsa, errônea e as pessoas que não sabem falar em público confundem abertamente no palco e recebem relatórios repugnantes. E na Rússia, onde acredita-se que não há experiência em falar em público, o resultado é muito melhor, porque eles foram treinados, testados, escolhidos como bons e assim por diante.

Essas são as duas diferenças.

Você já esteve no DevOpsDays em outros países? Como você acha que eles diferem de outras conferências? Existem recursos?

Eu provavelmente participei de várias dezenas de conferências do DevOpsDays em todo o mundo: na América, na Europa e na Ásia. Essa franquia de conferência é bastante única, pois possui um formato mais ou menos estabelecido que você pode esperar em qualquer lugar de qualquer uma dessas conferências. O formato é o seguinte: há relativamente poucas apresentações de conferências front-end e muito tempo é dedicado ao formato de espaços abertos.

Espaços abertos é um formato no qual o tópico para o qual a maioria das pessoas votou é discutido com outros participantes. Quem propôs este tópico - ele é o anfitrião, ele inicia a discussão. Este é um excelente formato, porque, como sabemos, a comunicação e a rede não são parte menos importante de qualquer conferência do que os relatórios. E quando a conferência fica metade do tempo no formato de rede - isso é muito legal.

Além disso, o DevOpsDays costuma hospedar relâmpagos - esses são relatórios breves de cinco minutos que permitem aprender muito sobre as coisas e abrir seus olhos para algumas coisas novas em um formato chato. E se, no meio de um relatório regular, você perceber que não é seu, então o tempo será perdido, 30 a 40 minutos de sua vida serão perdidos. Então, aqui estamos falando de relatórios por cinco minutos. E se você não estiver interessado, isso terminará em breve. "Diga-nos, mas rapidamente" também é um formato muito bom.

Existem DevOpsDays mais técnicos, existem aqueles que são personalizados especificamente para o que é DevOps: processos, colaboração, essas são as coisas. É interessante isso e outro, e é interessante quando existe isso e outro. Parece-me hoje que esta é uma das melhores franquias de conferências sobre DevOps.

Muitas de suas performances são semelhantes a performances ou performances: então você conta um relatório na forma de uma tragédia grega, depois interpreta o papel de Sherlock, depois age com uma fantasia de sapo. Como você os cria? Existem metas adicionais além de tornar o relatório chato?

Parece-me que o relatório não tem o direito de ser chato, porque, em primeiro lugar, passo o tempo da audiência, eles estão menos envolvidos no relatório chato, aprendem menos, aprendem menos, e isso não é o melhor desperdício de tempo. Em segundo lugar, meus objetivos também não foram alcançados: eles não pensam nada de bom em mim, não pensam nada de bom no JFrog e, para mim, é algum tipo de falha.

Portanto, relatórios chatos não têm o direito de existir, pelo menos para mim. Eu tento torná-los interessantes, atraentes e memoráveis. As apresentações são de sentido único. E, de fato, o método é bastante fácil. Tudo o que é necessário é apresentar um formato interessante e, em seguida, os mesmos pensamentos que são apresentados na forma de um relatório regular, apresentados em um formato incomum.

Como eu faço isso? Isso acontece de maneiras diferentes. Às vezes, algumas idéias vêm à minha mente, às vezes, algumas que elas me dão quando corro ou compartilho meus pensamentos sobre o relatório e elas me dizem: "Oh, isso pode ser feito assim!" isso acontece de maneira diferente. Quando uma ideia aparece, é sempre muito alegre e legal, o que significa que um relatório mais interessante e envolvido pode ser feito.



De quais aparências da esfera de TI você gosta pessoalmente? Existem tais alto-falantes? E porque

Existem dois tipos de falantes cujas aparências eu gosto. O primeiro são os alto-falantes que tento ser. Eles falam interessante e envolvido, tentam fazer com que todos se interessem e ouçam.

O segundo tipo de alto-falantes são aqueles que sabem falar de maneira muito interessante e empolgante sobre qualquer hardcore geralmente chato.

Dos nomes da segunda categoria, esse é Aleksey Shepelev, que fala sobre uma coleta de lixo de alto desempenho e o interior da máquina virtual java, que é interessante e bem-humorada. Outra abertura do DevOops mais recente é Sergey Fedorov, da Netflix. Ele contou uma coisa puramente técnica sobre como eles otimizaram sua rede de entrega de conteúdo, e contou isso de maneira muito interessante.

Da primeira categoria estão Jessica Deen, Anton Weiss, Roman Shaposhnik. Esses são os palestrantes que contam de maneira interessante, com humor, e merecidamente recebem classificações altas.

Certamente você tem mais convites para falar em conferências do que tempo para isso. Como você escolhe para onde vai e para onde não?

Conferências e palestrantes, como quase todo o resto, são governados por relações de oferta e demanda e valor de mercado entre si. Há conferências que, por assim dizer, me querem mais do que eu preciso. Em termos do público que espero encontrar lá e do impacto que espero trazer para lá. Há conferências que, pelo contrário, quero obter muito mais do que precisam de mim. Em termos de valor para mim, eu decido para onde ir.

Ou seja, se isso, por exemplo, é algum tipo de geografia, onde estrategicamente preciso entrar, esta é uma grande conferência bem conhecida, que tem uma boa reputação e que as pessoas vão participar, então obviamente eu realmente preciso disso. E eu preferiria a outras conferências.

Se este é algum tipo de pequena conferência regional, e talvez onde não estamos muito interessados, pode ser que uma viagem por lá não justifique os custos de tempo que serão estabelecidos para esse negócio. Relações normais de mercado de demanda, oferta e valor.

Boa geografia, boa demografia, contatos potencialmente bons, comunicação - a chave para o fato de que a conferência será interessante para mim.

Em uma de suas entrevistas, você mencionou que durante o ano fala em cerca de quarenta conferências. Como você consegue trabalhar e se preparar para as apresentações? E você consegue manter o equilíbrio entre trabalho e vida pessoal com esse cronograma? Compartilhar segredos?

Viajar para conferências é a parte principal do meu trabalho. Claro, há tudo o mais: há preparação para relatórios, mantendo-se em forma técnica, escrevendo código, aprendendo coisas novas. Tudo isso é feito em paralelo com as conferências: à noite, no avião, no dia anterior, quando eu já cheguei à conferência, e será amanhã. Algo assim.

É difícil, é claro, manter o equilíbrio entre trabalho / vida pessoal quando há tanto tempo em viagens de negócios. Mas tento compensar isso pelo fato de que, pelo menos quando não estou em viagem de negócios, estou 100% com minha família, não respondo e-mails à noite, tento não participar de chamadas telefônicas à noite e nos fins de semana. Quando não estou em viagem de negócios e é hora da família, é realmente 100% tempo para a família. Isso funciona e resolve o problema? Não. Mas espero que isso de alguma forma compense minha família por todo o tempo em que estou ausente.

Um dos relatórios de Baruch é "Temos DevOps. Vamos demitir todos os testadores ”

Com um cronograma tão apertado, você consegue manter um nível técnico ou já se afastou da programação?

Tento fazer algumas coisas técnicas enquanto me preparo para meus relatórios e outras atividades na conferência. São todos os tipos de demonstrações técnicas, alguns mini-relatórios que realizamos nas bancas. Isso não é programação, é mais integração, mas isso é pelo menos algum trabalho técnico que tento fazer. Dessa maneira, mantenho o conhecimento de nossos produtos, novos recursos etc.

É claro que dizer que agora sou o mesmo codificador de hardcore que eu tinha 7 anos atrás, provavelmente já é impossível. Não tenho certeza se isso é ruim. Provavelmente é algum tipo de evolução natural. Isso é menos interessante para mim e há menos tempo, então, provavelmente, Deus esteja com ele.

Ainda me considero um forte especialista técnico, ainda estou ciente do que está acontecendo, me mantenho em boa forma. Aqui está minha situação híbrida hoje.

Conte-me algumas histórias engraçadas ou situações extremas que aconteceram com você: você estava atrasado para o avião / excluiu a apresentação / desligou a eletricidade durante o relatório / não chegou bagagem?

Das situações engraçadas, lembro-me de todos os tipos de pesadelos que aconteciam nos relatórios. Naturalmente, porque esta é a situação mais estressante, porque é o público, o tempo e você precisa garantir que eles não o desperdiçam em vão.

Eu tive uma “tela azul da morte” no Windows e no Mac durante a conversa. No Windows, era uma vez, no Mac algumas vezes. Isso, é claro, é estressante, mas, de alguma forma, resolvemos esse problema, o computador reinicia, continuo dizendo algo no momento, mas o estresse é enorme.

Provavelmente a situação mais engraçada que tive na conferência Groovy. Parece que não me lembro exatamente onde a conferência foi realizada, e em frente a esse hotel havia algum tipo de construção ou reparo. E então eu estava falando sobre algum tipo de código que escrevi, era uma demonstração. Esta foi a primeira iteração da demo, que foi compreensível, mas talvez não tenha sido escrita da melhor maneira. E eu ia refatorá-lo e melhorá-lo, e mencionei algum tipo de frase como "auto-depreciativo" sobre o fato de ser um "código de merda". Era no segundo andar e, naquele momento, o guindaste no canteiro de obras do lado oposto estava apenas levantando o banheiro portátil. E a cena estava do outro lado da janela. Ou seja, olho através desta janela, digo "código de merda" e um banheiro flutua do lado de fora da janela. E digo a todos: "Vire-se, temos uma ilustração aqui". Provavelmente foi o melhor slide dos meus pensamentos - o banheiro voador na minha conversa quando falei sobre código de merda.

A bagagem não veio de histórias como essa - em princípio, é uma história normal, não há nada para falar. Podemos organizar uma entrevista em separado sobre todos os tipos de dicas de viagem, nas quais é possível conversar sobre a bagagem que não chegou, mas não houve nada crítico.

Esforço-me a todo custo para sempre voar, entrar e participar de todas as conferências que prometi, porque, novamente, é hora das pessoas. O tempo das pessoas não tem preço, porque é o tipo de crédito que elas dão a você. E se esse empréstimo for enganado, você não poderá recuperá-lo.

Se uma pessoa tirou um tempo, veio à conferência para ouvir meu relatório, mas eu aceitei e não vim, isso é ruim, porque não há como retornar o tempo para essa pessoa. , .

: « ? , ». , ?

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

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

: — .

DevOpsCon

, , - , ?

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

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

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

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

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

, — .

Em 7 de dezembro, Baruch falará na conferência do DevOpsDays em Moscou . No relatório, Baruch analisará as falhas reais que ocorrem diariamente e em qualquer lugar ao atualizar o software. Ele mostrará como todos os tipos de padrões do DevOps se encaixam em diferentes cenários e como o aplicativo adequado pode salvá-lo.

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

Venha se familiarizar!