На каждой крупной регулярной конференции есть докладчики, которые приходят каждый год, рассказывают что-нибудь новое и всегда нравятся аудитории. Всегда быть в самом-самом топе для человека, который не занимается выступлениями профессионально, очень трудно (да и зачем), но всегда выдавать уверенно хороший материал — реально. Один из спикеров, сделавших несколько успешных докладов и на Highload++, и на РИТ++, — Иван Круглов из Booking.com.

Несколько дней назад в блоге Онтико уже была статья о подготовке докладчиков, посвящённая больше подаче материала, а сегодня хотелось бы рассказать о другом аспекте подготовки, которым на РИТ++ и Highload++ я в основном и занимаюсь. Давайте на примере последнего выступления Ивана рассмотрим, что важно и над чем мы при подготовке конференции работаем с докладчиками в области содержания.



Слайды тут.
Конечно, любой доклад про микросервисы или хотя бы про SOA автоматически получает +2 к харизме, но спикер ещё должен суметь этим воспользоваться.

Дисклеймер: про SOA только разбираемый доклад, а не сама статья.

Сюжет

Постановка проблемы

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

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

Мне кажется, когда все эти люди слышат «адище, монолит, PHP», когда видят попытку раскрасить всю архитектуру в два стека технологий («старый» и «новый»), и эта попытка сразу признаётся неудачной, — они на самом деле получают сигнал «мы с тобой одной крови», или, менее пафосно, «я такой же человек, как и вы, и у меня такие же трудности». Это важный сигнал, он даёт докладчику дополнительный кредит доверия от зрителей, и они сразу понимают, какого рода решений ждать от доклада.

Из возможных улучшений отмечу следующее: проблемы, на которые Иван ссылается в начале своего выступления, очень общие. Для лучшей фокусировки стоило их сузить. Например, секция о трудностях управления трафиком (минута начиная с 40:42), на мой взгляд, просится в постановку задачи, а не в выводы. Ведь именно про то, как управлять трафиком с помощью envoy и самописного control plane, речь в докладе и идёт.

Выводы

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

В выводах Ивана в данном выступлении меня смущает то, что из трёх пунктов напрямую из рассказа вытекают только полтора. Смотрите (начало на моменте 40:00):

1. Уделяйте особое внимание взаимодействию между сервисами, и все баззворды, которые вокруг этого придуманы, это не просто баззворды, а реально необходимые вещи. Это правда, но вытекает, скорее, из предыдущего доклада (на РИТ++, вот запись), чем из этого.
2. Плюсы и минусы подходов с библиотекой или с локальным прокси в выводах излагаются примерно так же подробно, чем в самом выступлении, и примерно в том же ключе. То есть этот вывод скорее повторяет ранее сказанное, чем резюмирует его, поэтому зачтём за половину.
3. Envoy и Istio — полезные, интересные инструменты, с помощью которых можно наладить взаимодействие между сервисами. Да, основная часть доклада именно про это.

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

Слайды

Схемы

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

Сложные схемы — один из самых энергоёмких видов контента. Посмотрите на слайд 36: правда же, нужно много сил, чтобы разобраться, что тут происходит?



А теперь посмотрите, если ещё не, как эта схема появляется в презентации. Рассказ о ней начинается на 24:20 и длится почти 4 минуты. При этом всегда понятно, о каком элементе схемы Иван в данный момент говорит, поскольку появляются элементы последовательно. Второй бонус последовательного появления таков, что возникает динамика. Когда на экране регулярно происходят какие-то события, это лучше статичной картинки, так как каждое новое движение привлекает взгляд зрителей.

У любой схемы (ок, почти у любой) есть точка входа, начиная с которой эту схему нужно рассматривать и рассказывать, и далее повествование по схеме как-то распространяется. Именно в таком порядке открываются схемы в рассказе Ивана, и при подготовке докладов мы рекомендуем всем делать именно так.

Слайды как дополнение спикера

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

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

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

Проектор и контраст

Лучше заранее проверить слайды в том зале, где предстоит выступать. К сожалению, это не всегда возможно, и в бизнес-школе Сколково, где проходят Highload++ и РИТ++, картинка в разных залах бывает разная. Если мы выступаем с проектором, то в общем случае лучше предполагать, что высокого контраста он не даёт.

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



Особенно страдают на проекторе скриншоты из мониторингов, которые почему-то у всех цветные на чёрном фоне (я уверен, что у большинства мониторингов есть в настройках и светлая гамма, но, видимо, злые сисадмины ею не пользуются). То есть у слайдов вроде номера 44 особенно велик риск превратиться в тыкву:



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

О репетициях

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

В этот раз на Highload++ 2017 мероприятия по подготовке у нас были не совсем такие, как обычно (эксперимент), и полного прогона этого доклада с записью, которую можно было бы просмотреть, не было, а это очень сильно помогло бы сделать логику рассказа более непрерывной.

Некоторые специалисты не рекомендуют смотреть запись своей репетиции накануне выступления, полагая, что это приносит больше вреда, чем пользы. Вред может случиться, если во время просмотра обращать основное внимание на то, что за день исправить всё равно нельзя. Я не раз видел, как докладчик, впервые увидев себя в записи, чуть ли не заламывает руки со стоном: «Это было ужасно… Сплошные э-э-э, там и как бы, что же делать?..» Если думать об этом вживую перед публикой, то, действительно, станет только хуже.

Избавиться от э-э-э за один день нельзя (точнее, я не знаю способа это сделать). Секрет тут в том, что в своей речи мы замечаем гораздо больше слов-паразитов, чем в чужой. И в обратную сторону это тоже работает: нам кажется, что всё ужасно, а сторонний наблюдатель воспринимает нас вполне нормально. Речь, засорённая настолько, чтобы это стало реальной проблемой, встречается довольно редко.

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

Приходите участвовать

В общем, если хотите не только выступить, но и прокачать свои навыки в процессе подготовки, то точно стоит подать заявку на доклад на фестиваль конференций РИТ++.