«Доклад не имеет права быть скучным»: интервью с Барухом Садогурским о выступлениях на конференциях

Барух Садогурский — Developer Advocate в компании JFrog, соавтор книги «Liquid Software», известный IT-спикер.

В интервью Барух рассказал, как он готовится к докладам, чем зарубежные конференции отличаются от российских, зачем участникам ходить на них и зачем выступать в костюме лягушки.

Начнем с самого простого. Как тебе кажется, зачем вообще выступать на конференциях?

На самом деле, для меня выступать на конференциях — это работа. Если отвечать более глобально на вопрос «Зачем моя работа?», то это для того (по крайней мере для компании JFrog), чтобы достичь двух целей. Во-первых, чтобы установить контакт с нашими пользователями и клиентами. То есть когда я выступаю на конференциях, я доступен для того, чтобы все, у кого есть какие-то вопросы, какой-то фидбек по нашим продуктам и компании, могли со мной поговорить, я мог им как-то помочь и улучшить их экспириенс в работе с нашими продуктами.

Во-вторых, это нужно для повышения узнаваемости бренда. То есть если я рассказываю какие-то интересные вещи, то народ интересуется, что это за JFrog такой, и в итоге попадает в нашу воронку developer relations, которая в итоге переходит в воронку наших пользователей, которая в итоге переходит в воронку наших покупателей.

Расскажи, пожалуйста, как ты готовишься к выступлениям? Есть какой-то алгоритм подготовки?

Есть четыре более-менее стандартных этапа подготовки. Первый — это inception, как в кино. Должна появиться какая-то идея. Появляется идея, и дальше она довольно долго зреет. Она зреет, ты думаешь, как эту идею лучше подать, в каком ключе, в каком формате, что по этому поводу можно сказать. Это первый этап.

Второй этап — это написание конкретного плана. У тебя есть идея, и она начинает обрастать деталями о том, как ты ее будешь преподносить. Обычно это делается в формате какого-нибудь mind-map, когда вокруг идеи появляется все, что связано с докладом: поддерживающие аргументы, вступление, какие-то истории, которые ты хочешь про это рассказать. Это второй этап — план.

Третий этап — это написание слайдов по этому плану. Ты используешь какие-то абстрактные идеи, которые появляются на слайдах и поддерживают твою историю.

Четвертый этап — это прогоны, репетиции. На этом этапе важно убедиться, что сюжетная арка получилась, что рассказ связный, убедиться, что по времени все нормально. После этого доклад можно объявлять готовым.

Как ты понимаешь, что «вот с этой темой» нужно выступить? И как набираешь материал для докладов?

Я не знаю, как ответить, оно само как-то приходит. Или это «Ой, как круто у нас тут получилось», или это «Ой, вокруг про это толком никто не знает и не понимает» и есть возможность рассказать, объяснить и помочь. Один из этих двух вариантов.

Сбор материала очень зависит от доклада. Если это доклад по какой-то абстрактной теме, то это больше литература, статьи. Если это что-то практическое, то это будет написание кода, какие-то демки, поиск правильных кусков кода в продуктах и так далее.

Выступление Баруха на прошедшем недавно DevOps Summit Amsterdam 2019

Страх выступлений и волнение — одни из самых частых причин, почему люди не выходят на сцену. Можешь дать какие-то советы тем, кто волнуется во время выступлений? Волнуешься ли ты сам и как справляешься?

Да, у меня это есть, это должно быть, и, наверно, в тот момент, когда я вообще перестану волноваться, это повод с этим делом завязывать.

Мне кажется, это совершенно нормальное явление, когда ты выходишь на сцену и перед тобой много народу. Ты волнуешься, потому что это большая ответственность, это естественно.

Как с этим бороться? Существуют разные способы. У меня это никогда не было на таком уровне, что нужно прямо бороться, поэтому мне сложно сказать.

Самое главное, что и мне тоже помогает, это friendly face — какое-то знакомое лицо в аудитории. Если попросить кого-то, кого ты знаешь, прийти на твой доклад, сесть в первых рядах посередине, чтобы всегда можно было на него смотреть, и человек будет позитивно настроен, будет улыбаться, кивать, поддерживать, мне кажется, это огромная-огромная помощь. Специально я об этом никого не прошу, но если так бывает, что есть знакомое лицо в аудитории, это очень здорово помогает, снимает стресс. Это самый главный совет.

Ты много выступаешь на российских и международных конференциях. Видишь ли ты разницу между докладами на российских и зарубежных конференциях? Есть ли разница в аудитории? В организации?

Я вижу две большие разницы. Понятно, что конференции разные и в России, и за рубежом, но если брать среднее по больнице, то в России конференции более технические в плане глубины докладов, в плане хардкора. Это то, к чему люди привыкли, возможно, благодаря таким крупнейшим конференциям как Joker, JPoint, Highload, в основе которых всегда лежали хардкорные доклады. И народ ожидает от конференций именно этого. И для очень многих это является показателем того, хорошая это конференция или плохая: много там мяса и хардкора или там много воды.

Я, честно говоря, может быть из-за того, что много выступаю на зарубежных конференциях, не согласен с этим подходом. Я считаю, что доклады про soft skills, «полугуманитарные доклады», не менее, а, может, даже более важны для конференций. Потому что какие-то технические вещи можно в итоге прочитать в книжках, можно разобраться по user manual, а вот то, что касается soft skills, то, что касается психологии, то, что касается общения, этого всего взять негде, по крайней мере, легко, доступно и понятно. Мне кажется, что это не менее важно, чем техническая составляющая.

Это особенно важно для конференций по DevOps, такой, как DevOpsDays, потому что DevOps — он же вообще не про технологии. DevOps как раз про коммуникации, он как раз про способы работать вместе людям, которые раньше вместе не работали. Да, там есть техническая составляющая, потому что автоматизация критична для DevOps, но это всего лишь одна из. И когда конференция по DevOps вместо того, чтобы рассказывать про DevOps, рассказывает про site reliability или про автоматизацию, или про пайплайны, то эта конференция, несмотря на то, что она очень хардкорная, на мой взгляд, как раз упускает саму суть DevOps и становится конференций про системное администрирование, а не про DevOps.

Вторая разница — в подготовке. Опять же, я беру среднее по больнице и общие случаи, а не частные. За рубежом исходят из того, что большинство людей прошли определенный тренинг публичных выступлений в своей жизни. По крайней мере в Америке — это часть высшего образования. Если человек закончил колледж, то у него уже есть немаленький опыт публичных выступлений. Поэтому после того, как программный комитет посмотрел на план и понял, о чем будет доклад, то больше никаких тренингов по выступлениям для спикера не делается, потому что считается, что он, скорее всего, и так это умеет.

В России таких предположений не делают, потому что опыт публичных выступлений мало у кого есть, и поэтому спикеров намного больше тренируют. Опять же, в общем случае, есть прогоны, есть занятия со спикерами, есть курсы публичных выступлений для помощи спикерам.

В итоге слабые докладчики, которые плохо рассказывают, отсеиваются, или им помогают стать более сильными докладчиками. То, что на Западе public speaking считается скиллом, который у многих есть, в итоге получает обратный эффект, потому что это предположение часто оказывается ложным, ошибочным, и люди, которые не умеют говорить на публике, откровенно лажают на сцене и получаются отвратительные доклады. А в России, где считается, что опыта публичных выступлений нет, в итоге получается намного лучше, потому что их тренировали, их проверили, выбрали хорошее и так далее.

Вот такие две разницы.

Ты бывал на DevOpsDays в других странах? Как тебе кажется, чем они отличаются от других конференций? Есть какие-то особенности?

Я был, наверно, на нескольких десятках конференций DevOpsDays по всему миру: и в Америке, и в Европе, и в Азии. Эта франшиза конференции довольно уникальна тем, что у нее существует более-менее сложившийся формат, который ты можешь ожидать в любом месте, от любой из этих конференций. Формат такой: есть относительно немного фронтальных конференционных докладов, и много времени уделяется формату open spaces.

Open spaces — это такой формат, в котором тема, за которую больше всего человек проголосовали, обсуждается вместе с другими участниками. Тот, кто эту тему предложил — он ведущий, он делает так, чтобы дискуссия началась. Это прекрасный формат, потому что, как мы знаем, общение и нетворкинг — это не менее важная часть любой конференции, чем доклады. И когда конференция закладывает половину своего времени под нетворкинг-формат — это очень круто.

Плюс на DevOpsDays часто проводят Lightning Talks — это короткие доклады по пять минут, которые позволяют про многое узнать и открыть глаза на какие-то новые вещи в нескучном формате. И если в середине обычного доклада ты понял, что это не твое, то время потеряно, 30-40 минут твоей жизни пропало, то тут речь идет про доклады на пять минут. И если вам неинтересно, то это скоро закончится. «Расскажи нам, но быстренько» — это тоже очень хороший формат.

Есть более технические DevOpsDays, есть те, которые заточены специально под то, чем является DevOps: процессы, коллаборация, вот такие штуки. Интересно и то, и другое, и интересно, когда есть и то, и другое. Мне кажется, на сегодняшний день, это одна из лучших франшиз конференций про DevOps.

Многие твои выступления похожи на перформансы или спектакли: то ты рассказываешь доклад в форме греческой трагедии, то ты в роли Шерлока, то выступаешь в костюме лягушки. Как ты их придумываешь? Есть ли какие-то дополнительные цели, кроме того, чтобы доклад не был скучным?

Мне кажется, что доклад не имеет права быть скучным, потому что, во-первых, я трачу время слушателей, на скучном докладе они меньше вовлечены, они меньше выучили, они меньше нового узнали, и это не лучшая трата их времени. Во-вторых, мои цели тоже не достигнуты: они ничего хорошего не думают обо мне, ничего хорошего не думают о JFrog, и для меня это какой-то фейл.

Поэтому скучные доклады не имеют права на существование, по крайней мере, у меня. Я стараюсь сделать их интересными, привлекательными и запоминающимися. Перформансы — это один из способов. И, на самом деле, способ достаточно легкий. Все, что нужно, это придумать какой-то интересный формат, и дальше те же мысли, которые излагаются в виде обычного доклада, изложить в необычном формате.

Как я это придумываю? Бывает по-разному. Иногда это какие-то идеи, которые мне приходят в голову, иногда это какие-то идеи, которые мне подают, когда я устраиваю прогоны или делюсь мыслями про доклад и мне говорят: «О, это же можно сделать вот так!» По-разному бывает. Когда идея появляется, то это всегда очень радостно и клево, это значит, что можно сделать более интересный и вовлеченный доклад.

Чьи выступления из IT-сферы нравятся лично тебе? Есть такие спикеры? И почему?

Есть два вида докладчиков, чьи выступления мне нравятся. Первый — это докладчики, на которых я стараюсь быть похожим. Они рассказывают интересно и вовлеченно, стараются сделать так, чтобы всем было интересно и все слушали.

Второй вид докладчиков — это те, кто умеют очень интересно и захватывающе рассказать про всякий обычно скучный хардкор.

Из имен во второй категории — это Алексей Шепелев, который рассказывает про какой-то глубокий performance garbage collection и внутренности java virtual machine интересно и с юмором. Еще открытие последнего DevOops — Сергей Федоров из компании Netflix. Он рассказывал чисто техническую вещь, как они оптимизировали свой content delivery network, и рассказывал он это очень интересно.

Из первой категории — это Jessica Deen, Антон Вайс, Роман Шапошник. Это те спикеры, которые рассказывают интересно, с юмором, и заслуженно получают высокие рейтинги.

Наверняка приглашений выступить на конференциях у тебя больше, чем времени на это. Как ты выбираешь, куда поедешь, а куда нет?

Конференции и спикеры, как и почти все остальное, регулируются рыночными отношениями спроса и предложения и ценности одного от другого. Есть конференции, которые, ну так скажем, хотят меня больше, чем они мне нужны. В плане аудитории, которую я ожидаю там встретить, и влияния, которое я ожидаю там нанести. Есть конференции, на которые, наоборот, я хочу попасть гораздо больше, чем я им нужен. По размеру ценности для меня я решаю, куда ехать.

То есть если это, например, какая-то география, куда мне стратегически нужно попасть, это большая известная конференция, у которой хорошая репутация, и на которую пойдут люди, то, очевидно, она мне сильно нужна. И я предпочту ее другим конференциям.

Если это какая-то маленькая региональная конференция, и, может быть, там, где нам не очень интересно, то может быть, что поездка туда и не оправдывает затраты на время, которые будут заложены на это дело. Нормальные рыночные отношения спроса, предложения и ценности.

Хорошая география, хорошая демография, потенциально хорошие контакты, общение — залог того, что конференция будет мне интересна.

В одном из своих интервью ты упомянул, что за год выступаешь примерно на сорока конференциях. Как ты успеваешь работать и готовиться к выступлениям? И удается ли тебе при таком графике соблюдать work/life balance? Поделись секретами?

Ездить по конференциям — это львиная часть моей работы. Безусловно, есть все остальное: есть подготовка к докладам, поддержание себя в технической форме, написание кода, изучение новых вещей. Это все делается параллельно с конференциями: вечерами, в самолете, за день до, когда уже прилетел на конференцию, и она завтра. Как-то так.

Тяжело, конечно, соблюдать work/life balance, когда столько времени в командировках. Но я стараюсь это компенсировать тем, что, по крайней мере, когда я не в командировке, я на 100% с семьей, я не отвечаю на емейлы по вечерам, стараюсь не участвовать ни в каких созвонах по вечерам и по выходным. Когда я не в командировке и это семейное время, то это действительно семейное время на 100%. Работает ли это и решает ли это проблему? Нет. Но я надеюсь, что это каким-то образом компенсирует моей семье все то время, которое я отсутствую.

Один из докладов Баруха — «У нас DevOps. Давайте уволим всех тестировщиков»

При таком жестком графике ты успеваешь поддерживать технический уровень или уже отошёл от программирования?

Я стараюсь делать какие-то технические вещи во время подготовки к моим докладам и другим активностям на конференции. Это всякие технические демки, какие-то мини-доклады, которые мы проводим на стендах. Это не программирование-программирование, это больше интеграция, но это хоть какая-то техническая работа, которую я стараюсь делать. Таким образом я поддерживаю знания о наших продуктах, новых фичах и так далее.

Безусловно, сказать, что я сейчас такой же хардкор-кодер, какой был 7 лет назад, уже, наверно, нельзя. Не уверен, что это плохо. Наверно, это какая-то естественная эволюция. Это и мне менее интересно, и времени меньше есть, так что, наверно, и бог с ним.

Я все еще считаю себя сильным техническим специалистом, я все еще в курсе того, что происходит, держу себя в тонусе. Вот такая у меня гибридная ситуация на сегодняшний день.

Расскажи, пожалуйста, парочку смешных историй или экстремальных ситуаций, которые случались с тобой: опоздал на самолет/удалил презентацию/отключили электричество во время доклада/не прилетел багаж?

Из смешных ситуаций больше всего мне запоминаются всякие кошмарные фейлы, которые случались на докладах. Естественно, потому что это самая стрессовая ситуация, потому что это публика, время, и нужно сделать так, чтобы они не зря его потратили.

У меня был «blue screen of death» и на Windows, и на Mac во время доклада. На Windows было один раз, на Mac пару раз. Это, конечно, стрессово, но мы этот вопрос как-то решаем, компьютер перезагружается, я продолжаю в это время что-то рассказывать, но стресс это огромный.

Наверно, самая смешная ситуация была у меня на конференции по Groovy. Я не помню, где точно проходила конференция, кажется, в гостинице, и напротив этой гостиницы шла какая-то стройка или ремонт. И вот я рассказывал про какой-то код, который я написал, это была демка. Это была первая итерация демки, которая была понятна, но, может, не лучшим образом написана. И я собирался как раз ее рефакторить и улучшать, и упомянул какую-то фразу типа «self deprecating» про то, что это «shitty code». Дело было на втором этаже, и в это время кран на стройке напротив как раз поднимал переносной туалет. А сцена была напротив окна. То есть я смотрю в это окно, говорю «shitty code», а за окном проплывает туалет. И я говорю всем: «Развернитесь, у нас тут иллюстрация». Наверно, это был самый лучший слайд моих мыслей — летающий туалет в моем докладе, когда я рассказывал про shitty code.

Из историй типа не пришел багаж — это, в принципе, нормальная история, об этом нечего даже говорить. Можем устроить отдельное интервью про всякие travel tips, где можно поговорить про не пришедший багаж, но ничего критичного не было.

Я очень стараюсь во что бы то ни стало всегда прилетать, приходить и присутствовать на всех конференциях, на которых я обещал, поскольку, опять же, время людей. Время людей бесценно, потому что это такой кредит доверия, который они тебе дают. И если этот кредит профукать, то его потом обратно никак не получить.

Если человек потратил время, пришел на конференцию, чтобы послушать мой доклад, а я взял и не пришел, это плохо, потому что время этому человеку никак не вернуть. Поэтому для меня супер важно все мои обещания в этом плане сдерживать, и пока что все получается.

Многие думают так: «Зачем вообще ходить на конференции? Видео можно посмотреть на ютубе, а пообщаться всегда можно онлайн». Как считаешь, зачем нужно ходить на конференции участникам?

Прекрасный вопрос! На конференции нужно ходить ради нетворкинга. Это бесценно и по-другому не получить никак. Я уже упоминал важность общения, коммуникаций и soft skills. Просмотр видосика на ютубе, к сожалению, не дает опыта в soft skills. Поэтому на конференции надо ходить ради общения.

Кроме того, по крайней мере у меня, при просмотре роликов на ютубе вовлеченность совершенно другая, и материал заходит и запоминается намного хуже. Может быть, это чисто у меня, но я подозреваю, что быть в зале на докладе и смотреть ролик на ютубе — это совершенно разные вещи. Особенно, если доклад хороший, мне кажется, намного-намного лучше услышать его живьем. Это как послушать живой концерт и пластинку.

И еще раз повторю: нетворкинг и общение — это не взять из ютуба.

Совместный доклад с Леонидом Игольником на DevOpsCon

Дай, пожалуйста, какое-то напутствие тем, кто только собирается стать спикером или только начал выступать?

Поищите локальные митапы. Локальные митапы — это отличная штука для начала спикерской карьеры по нескольким причинам. Во-первых, локальные митапы всегда ищут докладчиков. Может быть, что без опыта и не будучи именитым спикером, вам будет тяжело податься на какую-то известную конференцию, или программный комитет после общения с вами поймет, что, может быть, вам еще немножко рановато. В отличие от этого, локальные митапы всегда ищут спикеров и планка вхождения туда намного-намного ниже, поэтому туда намного легче попасть.

Кроме того, уровень стресса совершенно другой. Когда приходят 10-15-30 человек — это совсем не то, чем когда в зале 150-200-300 человек, поэтому намного легче.

Опять же, на локальный митап затраты намного меньше: не надо никуда лететь, не надо тратить дни, можно просто прийти вечером. Вспоминая мой совет о том, что важно иметь дружественное лицо среди публики, на локальный митап гораздо легче прийти с кем-то, потому что это не стоит денег. Если вы выступаете на конференции, вы как спикер приходите бесплатно, но вот этому вашему +1, который будет дружественное лицо в публике, надо покупать билет. Если вы выступаете на митапе, такой проблемы нет, вы можете привезти с собой одного-двух-трех друзей, которые будут дружественным лицом в зале.

И дополнительный плюс — у организаторов митапов намного больше возможностей вам помочь. Потому что у организаторов конференций будет, например, 60 докладов, которые нужно просмотреть, оттренировать и подготовить. А у организаторов митапов — один, два или три, поэтому вам, естественно, будет уделяться намного больше внимания.

Кроме того, с локальных митапов гораздо легче получить фидбэк. Вы закончили ваш доклад и вот вы и публика уже общаетесь и обсуждаете что-то, что связано с вашим докладом. Для больших конференций это часто не так. Вы сделали доклад и все. Публика, которая у вас была серой массой во время доклада, ушла, и вы больше ничего о них не знаете, не слышите, никакого фидбэка не получите.

Как ни крути, локальные митапы — это отличная тема вообще и для начинающих в частности.

7 декабря Барух выступит на конференции DevOpsDays Moscow. В докладе Барух проанализирует реальные фейлы, которые ежедневно и повсеместно происходят при обновлении софта. Он покажет, как всевозможные DevOps-паттерны ложатся на различные сценарии и как правильное их применение смогло бы, возможно, вас спасти.

Еще в программе: Александр Чистяков (vdsina.ru), Михаил Чинков (AMBOSS), Роман Бойко (AWS), Павел Селиванов (Southbridge), Родион Нагорнов (Лаборатория Касперского), Андрей Шорин (консультант по DevOps).

Приходите знакомиться!

Источник: habr.com