К основному контенту

Рекомендации начинающему докладчику

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

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

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

Итак, погнали.

Про что рассказывать и зачем оно вообще нужно?

В этом месте воспользуюсь помощью зала и просто отправлю вас к хорошим материалам других.

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

Рома Неволин "Как и зачем делать доклады?". Откровенно говоря, эта статья практически аналог того, что вы читаете здесь. Поэтому можно на ней и остановиться :)

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

Кому интересно дальше, поехали дальше.

Кажется вы нащупали возможную тему, что дальше?

Теперь ее нужно "повертеть" и ответить себе на следующие вопросы:
  • кого вы видите слушателями своего доклада, какими компетенциями они должны обладать?
  • для чего им ваш рассказ? Или для чего вам (это тоже важно)?
  • как поймете, что доклад получился?
  • что могут/должны будут сделать слушатели после доклада, когда вернутся к рабочим задачам?

Задача этого упражнения - помочь вам с контентом, структурой и выводами. 

Запускаем в работу

Я видел разные форматы подготовки и тут кажется, каждый делает так, как ему удобно. Для тех, кто делает первый доклад, я бы посоветовал следующие шаги:
  • подготовить скелет доклада (про что/зачем, основная часть/мясо тезисно, выводы).
    • зачем - тут про то, о чем будет доклад, фактически заготовка выводов, как ни странно :) 
    • план рассказа
    • "мясо" - содержательная часть, которая приведет нас к выводам
    • выводы - то, про что новички чаще всего забывают. Тут должна быть квинтэссенция доклада, могут быть рекомендации слушателям, ваши дальнейшие планы по этой теме (если они есть) и тп
    • все именно тезисно, без попыток оформления, расписывания пунктов и картинок
    • но картинки могут заменить собой часть тезисов (какие-то графики, диаграммы, скриншоты исходников и тп)
  • если есть возможность, обсудите результаты с кем-то. Это может быть коллега из вашей команды, ПК конференции, специально обученный человек у вас в компании. Да хоть я ;) (мы иногда ищем докладчиков снаружи на наши митапы) Основная цель - получить первую обратную связь и оценить интерес к теме доклада. Шаг необязательный, но полезный - тему можно довернуть в более интересную сторону на раннем этапе.
  • готовим презентацию, насыщая ее контентом (рекомендации по презам будут ниже).
  • прогоны, прогоны, прогоны (самостоятельно или с напарником). Важно наговорить текст, речь не про запомнить наизусть, а про "установить связи между слайдом и той информацией, которую хочется озвучить".

Рекомендации по слайдам

  1. Текст на слайдах должен максимально лаконично отражать то, что вы хотите сказать голосом. Если текста много и он занимает весь слайд - плохо (слушатели превратятся в читателей, а вас перестанут слушать). Понятно, что речь именно про "много читать", а не про "одно слово большим шрифтом на весь слайд".
  2. Иногда текст лучше заменить картинкой со схемой, они лучше воспринимаются с озвучкой.
  3. Про картинки - если на слайде только она, то самым правильным будет максимально занять весь слайд этой картинкой, без полей, хедеров и футеров. Следите за качеством картинки (иногда лучше словами без картинок рассказать, чем на "замылки" смотреть).
  4. Если у вас есть слайд с пунктами, например, последовательность шагов, которые нужно предпринять или перечисление плюсов/минусов, то воспользуйтесь или последовательным показом этих пунктов по ходу рассказа (анимация), или сделайте отдельные слайды для каждого рассказа по каждому из подпунктов. Почему? Потому что, снова, много текста - слушатели превращаются в читателей.
  5. Тут можно посмотреть рекомендации по показу исходников на слайдах
  6. Хорошо помогает и в структурировании, и в ориентации слушателей по ходу доклада привязка слайда к плану: например, в заголовке или в расставленных по презентации слайдах, возвращающих нас к плану и тому, где мы сейчас находимся. Хороший пример в презентации Вадим Пуштаева, правда сложно реализуемый без помощников. 
  7. Если по ходу рассказа вам хочется на что-то показать указкой, например, обратить внимание на код в исходниках, акцентировать какое-то место на схеме, воспользуйтесь "хардкод-ом": выделите нужное место или размером/цветом шрифта, или просто цветным прямоугольником. Это поможет слушателям сориентироваться на том, о чем вы сейчас рассказываете, а вам - не отвлекаться на показ.
Кажется пока все. Как обычно пункты неокончательные, буду стараться прикладывать хорошие примеры. Но потом...

Тут есть еще немного ссылок и про подготовку, и про само выступление.

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu