- Необходимо сформулировать тему доклада и короткое описание
- Предпочтителен темный (черный) фон со светлыми (белыми) буквами (почитать)
Чтобы конструктивно проводить прогон доклада, нужно ответить на несколько вопросов, которые напрямую не превратятся в слайды презентации, но могут сильно повлиять на содержание доклада.
-
Аудитория, которой будет интересен доклад.
Например: Фронтендеры, использующие react или интересующиеся react-ом.
Зачем? Возможно, вы неправильно оцениваете фактическую аудиторию мероприятия, и ваша целевая аудитория пуста или почти пуста.
-
Что она по вашему мнению уже знает про тему доклада?
Например: Знают nodejs и умеют запускать тесты в mocha или аналоге.Не знают TypeScript и Flow, частично знакомы с ES6.Далеко не все пишут тесты. Некоторые, не очень верят в тесты, но пришли на доклад, чтобы эту веру получить.
Зачем? Возможно, вы переоцениваете слушателей, и многие вещи в вашем докладе нельзя будет давать без объяснения и ликбеза. Если вы не уверены в ответе, можно запланировать в начале доклада вопрос-голосвание с поднятием рук.
-
Ваша цель доклада? Как вы хотите повлиять на слушателей?
Например: Хочу, чтобы пользователи react начали писать эффективные тесты на свои react-компоненты. А остальные просто прониклись важностью тестов и задумались об этом.
Зачем? Чтобы выкидывать из доклада все части, которые не работают на ваши цели, и добавить что-то, что работает на них.
Если только вы не гуру докладов (в этом случае вы сами всё знаете лучше этой памятки), старайтесь сделать из своего доклада инструмент для принятия решений, который слушатели смогут применить позже в своей работе (Каптерев про это).
Первый прогон лучше сделать без слайдов и речи, только на основании плана основной части доклада. Это позволит скорректировать доклад на ранней стадии его подготовки. План может состоять из одного или нескольких блоков такого вида:
- Проблема и мотивация. Тут можно рассказать историю из жизни, привести эмоциональные аргументы и яркие примеры.
- Обзор возможных наивных решений с недостатками.
- Описание предлагаемого решения. Объяснение, почему описанных выше недостатков нет. Тут можно сравнить примеры кода, показать демо, использовать другую демонстрацию, которая вызывает вау-эффект.
- Анализ недостатков и работа с возражениями. В этой части нужно выключить режим “продавца” и честно рассказать обратную сторону выбора этого решения.
- Резюме применимости решения: Когда его стоит применять, а когда нет.
В конце доклада должен быть призыв к действию. Лучше предлагать сделать что-то конкретное. Предложите триггер для какого-нибудь конкретного первого шага.Например: Как только вам придется на работе создать или изменить React-компонент, напишите на него тест с помощью технологии XYZ. При проектировании нового контрола попробуйте playground для отладки.
Код должен быть контрастными крупными буквами. Скорее всего ваша IDE настроена на маленькие (чтобы на экране помещалось больше кода) не сильно контрастные шрифты (чтобы глаза не уставали). Скриншоты из вашей рабочей среды не подойдут!
Шрифт — не менее 16-18. Если делаете светлые буквы на темном фоне, то весь фон слайда должен быть тёмным. Белый слайд, на котором скриншот кода с темным фоном смотрится плохо и неконтрастно.
Уберите из кода всё лишнее. Типичный кусок кода из реального проекта плохо подходит для презентации as-is — там много лишнего. Всё, что не демонстрирует вашу мысль — отвлекает от неё. Подумайте, как можно сократить код, чтобы увеличить его понятность.
Если вы показываете слайд с кодом или сложной диаграммой, то уделите ему достаточно времени, прокомментируйте каждый элемент. Не нужно считать, что слушатели способны параллельно вашей речи прочитать и понять смысл кода или диаграммы. Скорее всего, наоборот, они и вас прослушают и код не успеют понять. Если вы не хотите комментировать некоторые элементы кода или диаграммы, то просто не показывайте их на слайде. Сложные слайды — неудачное место для острот и шуток, они только отвлекут и запутают слушателей.
Скриншоты. Перед тем как делать скриншоты рабочей системы, надо увеличить шрифты и уменьшить окно программы, которую вы скриншотите. Иначе на слайде будет всё слишком мелко.
Ссылки. Лучше указывать в таком виде, в котором их легко загуглить прямо в процессе доклада. Всем лень ждать, когда вы выложите слайды в общий доступ. Например, "Мой репозиторий на гитхаб" — плохой текст для ссылки, "Проект Grobuf на гитхабе" — норм, а github.com/skbkontur/grobuf — cовсем хорошо.
Живое демо. Доклад с хорошим живым демо всегда смотрится круче. Однако, опасайтесь демо, в которых вам что-то нужно будет активно делать на клавиатуре или мышке — в роли докладчика вам это будет делать неудобно. Сведите количество необходимых действий к минимуму и хорошо отрепетируйте демо. Опять же подумайте про контрастность и размер шрифтов. Подготовьте свою IDE и консоль заранее. Дополнительно подумайте, что может пойти не так. Боги демо всегда найдут способ всё вам испортить, вы даже не догадываетесь сколько у них для этого есть способов!
Если вы увидели на своём слайде ошибку, точнее укажите всем на неё и дайте чуть больше времени аудитории на восприятие этого слайда, ведь часть времени уйдет на осознание ошибки.
Если вам удобнее написать полностью текст доклада, имейте в виду, что устная и письменная речь сильно различаются. Когда человек повторяет заученный письменный текст — это заметно, выглядит искусственно и неприятно. Вместо того, чтобы записывать весь текст, лучше сконцентрироваться на основных опорных пунктах — проговорить их несколько раз разными способами, выбрать наиболее хорошую формулировку и записать и заучить точно в таком виде. Весь текст между опорными пунктами лучше оставить «живым».
Если вы боитесь забыть о чём-то сказать — оставьте себе подсказку на слайде. Старайтесь обойтись во время доклада без бумажки с подсказками. Во-первых, это выглядит не очень красиво, во вторых, в руках у вас уже будут — в одной кликер, а во второй микрофон.
Определите самые важные предложения в вашем докладе. Те, которые должны запомниться слушателям. Их нужно выделить интонационно в докладе. Часто это делают с помощью увеличенных пауз, более громкой и медленной речи. Про интонации и невербалику есть такое несерьёзное видеопособие с TEDx.
Доклад нужно репетировать и прогонять. Иначе велик риск выбиться из тайминга. Во время репетиции лучше держать что-то в руке под видом микрофона, чтобы привыкнуть к нему. Следите за тем, что вы не жестикулируете рукой с микрофоном — это будет влиять на звук. По этой же причине, при возможности, всегда выбирайте петличку или надеваемую на голову гарнитуру, а не микрофон в руке.
Старайтесь сделать прогон доклада до выступления, позовите на него опытных докладчиков. Даже бывалые спикеры на прогонах часто получают содержательную обратную связь.
Если вы просите людей проголосовать, подняв руки, то сделайте потом в докладе хоть что-то, что является реакцией на этот вопрос. Например, если на вопрос “кто знает, что такое XYZ” руки поднимает менее половины зала, то, стоит скорректировать свой доклад так, чтобы было понятно и тем, кто не поднял руку.
Открытый вопрос “Как вы думаете, почему это не сработает?” полезен тем, что все в этот момент попробуют задуматься над материалом вашего доклада. Поэтому даже несмотря на то, что вслух ответят всего один-два человека, польза будет для всех.
После подготовки доклада полезно проверить, не совершили ли вы какую-то типичную ошибку.
-
Подробно о простом, быстро о сложном. Уделить много внимания простым вещам, а потом быстро-быстро пробежаться по сложным. Проблема в том, что простые вещи люди часто знают и без вас, а сложные не успеют осознать.
-
Уделить мало внимания проблематике. Вы рассказываете про классный инструмент, но объяснение того, какую проблему он решает не убедительно. После такого доклада все подумают «Занятно, но бесполезно» и забудут его.
-
Доклад из hashtag-ов. Вы не погружаетесь в суть вещей, о которых рассказываете, а ограничиваетесь только перечислением технологий или подходов. Из вашего доклада слушатели извлекут только набор ключевых слов, каждое из которых им придётся дополнительно гуглить. Ценность такого доклада невелика, потому что гуглить, конечно, все поленятся.
-
Маркетинговый булшит. Вы только хвалите штуку про которую докладываете, но ничего не говорите про недостатки, ограничение применимости и риски. Такой доклад воспринимается с подозрением и недоверием. Технари лучше «покупают» идеи, если понимают их недостатки.