Lev Goncharov

Infrastructure simplifying engineer

View My GitHub Profile

Как подготовиться к выступлению на технической коференции и не слететь с катушек?

Date: 2024-08-09

У меня в копилке сотня технических выступлений на английском и русском разной степени публичности. Вещал на международных конференциях, подкастах, делал с нуля курс по Infrastructure as Code, занимался DevOps школой, подготовил несколько туторов. И знаете что? Я заметил некий паттерн в подготовке к техническим выступлениям. Вот, кстати, он:

roadmap

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

Why?

why?

Прежде чем готовиться, вам надо ответить для себя на простой вопрос: зачем оно мне? Ответы могут быть разные, и они похожи на пирамиду Маслоу (холиварно, но всё же):

Test

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

Which topic should I choose?

Порой сложно выбрать готовую тему. У меня примерно такое деление:

Хорошие темы

Это беспроигрышные варианты:

Спорные темы

Тут очень сильно зависит от автора и качества материала. Надо быть очень аккуратным. По первой, в эти темы лучше не лезть.

Плохие темы

Materials

Materials

Что видите на фото? Это куча несортированного непонятно чего. Это сырые заметки по теме, которую подумываете рассказать. Они могут быть совершенно разными:

Их задача — копиться, и когда вам надо будет пример: выдернуть, причесать и презентовать.

Trello

Где и как хранить, каждый решает сам. Нет готовых стандартов:

У меня изначально была связка Trello + Google Docs. В итоге пришёл к Obsidian + Git.

Abstracts

Abstracts

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

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

Scenario

Scenario

Готовим историю. Тут всё просто, так как основная работа была ранее сделана, и нам остается пройти по алгоритму:

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

Requisites

Requisites

Готовим слайды на раз-два:

Create content

Extend the speech via slides

Так что же должно быть на слайдах? Есть прекрасная презентация Death by PowerPoint — рекомендую к изучению.

Text on slides

Bad

Слайды с кучей мелкого текста смотрятся ужасно по многим причинам:

Такое решение работает только как раздатка, но вы же не будете делать два варианта слайдов, правда?

Good

Основные задачи слайда:

Я обычно делаю так:

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

Screenshots

Фото и скриншоты желательно подрезать/растягивать на весь слайд и не оставлять белых полей, так смотрится целостней.

Screenshots 1

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

Screenshots 2

А вот скриншоты неизвестных программ плохо — человек теряется. Вот многие из вас работали с galaxy.ansible.com?

Text on screenshots

Screenshots 3

Текст без подложки трудно читаем.

Screenshots 4

Если же её подкрасить, то сразу более читаемо.

Code

Code

Много кода не читаемо, так как человеку надо загрузить его в голову. Поэтому убираем всё лишнее:

Как надо:

Roadmap

roadmap

Хорошо себя показывают дорожные карты, они выступают напоминалкой, где мы, как долго ещё и склеивают части рассказа между собой.

5±2

Есть Магическое число семь плюс-минус два — человек не может удержать в голове слишком много, поэтому:

  1. Списки — наш друг.
  2. На каждый слайд добавляем по 1, максимум 2 новых элемента. Их можно подсветить.
  3. В целом не надо стараться больше 7 идей донести, а лучше 4.

Presentation as Code

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

Изначально я делал всё в PowerPoint и страдал:

В данный момент перехожу на подход Presentation as Code.

  1. Создаю презентацию в синтаксисе Markdown: marpit.marp.app.
  2. Рисую изображения через приложение draw.io в формате SVG.
  3. Храню всё в Git.
  4. Экспортирую презентацию в PDF.

Интеграция с VS Code:

У решения есть минусы:

Пример куска презентации:

---
marp: true
theme: default
paginate: true
style: |
    section {
        justify-content: flex-start
    }
    h1,
    strong {
        color: #E20074;
    }
---
<style scoped>
    section {
        background-color: #E20074;
        justify-content: center;
    }
    h1,
    h3 {
        color: white;
    }
</style>
<!-- _paginate: skip !-->

## Terraform 4 VmWare in XXX

lev@xxxx
xx.xx.2023

---
<!-- _paginate: hide !-->
## IaC: use cases

![bg contain](./assets/IaC_usecases.svg)

Show

Есть разные форматы мероприятий, но в общих чертах это:

Interaction with organizers

0. Apply

Ищем площадку, готовим тезисы и подаемся. Иногда есть готовые порталы, иногда нужно писать на почту. Стандартного нет. Полезно приложить ссылки на другие выступления, если есть, чтобы организаторы могли оценить уровень.

1. Initial call

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

2. Demo

Это редкий зверь, у меня ни разу не было, но люди говорят, встречается в природе.

3. Accept

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

4. Dry-run

Dry-run

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

5. Show

Есть небольшая разница между офлайн и онлайн выступлениями, но есть общие советы:

  1. Сконвертировать презентацию в PDF.
  2. Разослать всем причастным:
    • Организаторам.
    • Положить на флэшку.
    • Выложить в публичный доступ.
  3. Взять стакан воды или бутылку с водой.

Как-то был прекрасный опыт:

Offline

Offline

Кстати, про экран презентера, на больших эвентах у вас может быть такое:

  1. Беспроводной микрофон, возможно петличка.
  2. Почти всегда есть кликер.
  3. В ногах часы с таймером обратного отсчета.
  4. В ногах или перед глазами дублирующий монитор с тем, что видят зрители.

А может этого всего и не быть, если мероприятие попроще. Обычно я с собой вожу:

Но это всё баловство. Из лайфхаков:

Online

Online

Основная проблема online — это беспроводные технологии и канал. Поэтому:

  1. Подключаем интернет проводом и держим запасной вариант связи.
  2. Используем проводную гарнитуру.
  3. Заранее проверяем задний фон.
  4. Искусственное освещение лучше дневного, так как зашло солнце — освещение поехало.

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

Results

Results

Как ни странно, но выступление не заканчивается после выступления. Подумайте сами: вы уже структурировали материал, наклепали мемасиков — остается только написать текст, который и так знаете наизусть.

Landing

Landing

Последний слайд выступления обычно самый фотографируемый. Поэтому на него выношу:

  1. Основную идею / roadmap выступления.
  2. Контакты, ссылку на лэндинг.

Где хостить лэндинг?

Основная проблема здесь в том, что ссылка на лэндинг нужна в момент выступления, а расшифровка будет когда-то потом (про образ этого выступления я делал почти 5 лет назад, и вот только дошли руки напечатать…).

Поэтому у меня такая связка:

  1. GitHub Pages — там в Markdown пишу посты всякие.
  2. Купил домен за 2€.
  3. Взял публичный бесплатный почтовый сервис.
  4. Прикрутил Google Analytics.

То есть www.goncharov.xyz хостится на github.com/ultral/ultral.github.io . Его также можно посмотреть через github.com/ultral/ultral.github.io/blob/master/README.md, и оно автоматически публикуется. Сплошные плюсы:

  1. Есть прикольная почта.
  2. Когда делаю презентацию, сразу делаю лэндинг на последней странице (последний слайд самый фотографируемый, не считая мемов) и перевожу аудиторию в онлайн. А так как есть Google Analytics, видно, сколько народу пришло.
  3. После спича выкладываю расшифровку на лэндинг.

Получается win-win:

Writing

Writing

Есть неплохой гайд от Хабра, как писать, но если кратко:

Writing

В целом все как со слайдами:

Вначале пишем драфт, он может быть кривым. Это нормально.

Writing

На следующий день/неделю/месяц его перечитываем, причесываем и публикуем.

PR

Если хочется заморочиться, то можно постить на разные площадки:

Но по моим наблюдениям, оно в итоге будет проиндексировано и люди будут приходить читать, говорить спасибо.

Вместо заключения

roadmap

Не надо стесняться выступать, не надо накручивать себя и придумывать синдром самозванца. Горшки не боги обжигают, и выступления/писанина такой же скилл. Он помогает привести мысли в порядок и яснее доносить свои идеи.