Конференции — памятка докладчику
«Who are you to fucking lecture me?» © Lavrov
Написано по опыту:
- выступления на конференциях
- SECR-2007/2008/2009/2010
- SEF-2009
- ReqLabs-2009
- AgileDays-2009/2011/2013
- Application Developer Days-2010/2011
- РИТ-2010
- Software People-2010/2012
- SQADays-6/7/8/10
- Knowledge Management Forum-2010
- DevConf-2011
- WhaleRider-2011/2012
- Open-Source в высшей школе-2012/2013/2014/2015
- ProfsoUX-2013
- организации
- конференций:
- AgileDays 2009-2015 — Организатор, член ПК, публикация материалов.
- Application Developer Days-2010/2011/2012 — Организатор, председатель программного комитета, публикация материалов.
- SECR-2011-2015 — член ПК, видеосьемка и публикация.
- SPM-2011 — член ПК, видеосьемка и публикация.
- SQADays-10/11 — орг, видеосьемка и публикация.
- WUD-2011/2012 — видеосьемка и публикация.
- OSND UA-2012/2013 — видеосьемка и публикация.
- PingWinFest-2012 — видеосьемка и публикация.
- Open-Source в высшей школе 2013-2015 — видеосьемка и публикация
- OSSDEVConf 2013-2015 — видеосьемка и публикация
- Russian Open Source Summit 2013-2014 — видеосьемка и публикация
- ProfsoUX 2013-2015 — видеосьемка и публикация
- UXPeople 2013-2015 — видеосьемка и публикация
- ProductCamp 2012-2015 — видеосьемка и публикация
- LeanKanbanRussia-2014
- конференций:
- встреч профессиональных software-сообществ — AgileRussia.ru, ALT.NET, MSTC, Stratoplan.ru, UML2.ru.
- посещения и около-ПКшной активности в десятке различных software-конференций.
Contents
Вы решили выступить на конференции?
Не делайте этого.
Зачем это вам? Рассказать о вашем новом изобретении? Алгоритме? Фреймворке? Подходе? Это в прошлом тысячелетии, веке устных коммуникаций, когда цикл бумажной публикации с редакторами-рецензентами-корректорами-типографией занимал кварталы и годы, выступление было самым быстрым способом озвучить «first draft» и получить быстрый feedback.
Это время, с счастью ушло.
First draft, первый feedback, заявка на приоритет — все это делается по-другому.
- Новый алгоритм? Доказательство сложности задачи? — Пишите статью на arxiv.org.
- Новый фреймворк? Утилита? — «Show me your code!», публикуйте ее в open-source, github и googlecode ждут ее.
- Идеи-мысли-нужен feedback? — Напишите пост или серию постов в блог.
- У вас нет блога или малочитаемый, а вы хотите большую аудиторию? — Напишите в крупный коллективный блог, типа habra.
- Дислексия, с трудом формулируете мысли, лень много печатать? — Запишите подкаст, вебкаст, скринкаст, 100500 вариантов сделать это самостоятельно.
- Нужны «очки» для защиты курсовой, диплома, диссера? — Это не повод мучать скукой участников, многие из которых заплатили денег, потратили время, возможно приехали издалека. Сначала выступайте на своих внутриинститутских семинарах и конференциях, выполните вышеозвученные пункты (публикация статей-блогпостов-кода), и, только если этого недостаточно — см. далее.
А когда же надо выступать? Только тогда, когда вы очень хотите именно выступить, выложится полностью, чтобы использовать все возможности личного контакта для донесения своей мысли, и вы четко понимаете какие.
Возможно у вас есть скрытые цели — реклама продукта, себя самого, продвижение своего образа мысли или приобретение полезных знакомств. Осознайте эти цели. Бесцельность убивает мотивацию, уверенность и смысл.
Вы должны быть уверены, что сможете
- Отлично визуализировать доносимые идеи
- Уверенно и четко говорить
- Поддерживать внимание аудитории (многодневная конференция — дикий стресс не только для докладчиков, для участников тоже — это какой-то митинг и мозговой штурм, растянувшийся на несколько дней).
- Развлечь слушателей.
Если вы на это не готовы, а идете за очками в духе «сорок минут унылого позора, и вопрос с диссером закрыт» — завязывайте и не ухудшайте свою карму. Если вы смущаетесь/стесняетесь → решайте эту проблему. Или не идите выступать.
Вы еще с нами?
Хорошая конференция, это:
- Театр (standup comedy) — вы должны развлечь зрителей. Со сцены. Голосом, жестами, мимикой.
- Это кино или анимация, которое вы сделаете принесете с собой. Видеочасть весьма важна!
- Это Колизей — вы рискуете, что умные вопросы от ваших оппонентов порвут вам репутацию, на глазах довольной аудитории с попкорном.
Вы готовы потратить время, силы, нервы, креатифф, голосовые связки, рискнуть репутацией? ОК, продолжаем.
Все это конечно, не относится к вам, если вы достигли статуса «живого бога» — гуру software architecture, CEO многотысячной компании, супертренер эффективной методологии, супер-шоумен-бизнес-тренер собирающий стадионы, или очень красивый и харизматичный человек (обоих полов) → тогда конечно, народ будет счастлив вас видеть, и будет слушать вас, какую бы ерунду вы не придумали за пять минут до выступления.
Не передумали? Тогда переходим к следующей части.
Подготовка к выступлению
Если вы не считаете себя звездой сцены, осмелимся дать несколько общекультурных советов успешных выступлений.
Самый распространенный жанр, которому уже исполнилось несколько десятков лет — это выступление «под слайды». Обязательно ознакомьтесь с «Смертью от Powerpointа», если вы вдруг еще ее не видели, это займет у вас пару минут.
Ну, а если вы готовы потратить чуть больше времени ради отличного результата, то здесь([1]) вы совершенно случайно можете скачать подборку книг и аудиокниг, покрывающие и искусство правильных слайдов, и основные понятия дизайна и грамотной визуализации информации, и даже аудиокнигу об искусстве публичных выступлений -- ее можно ненапряжно прослушать в «транспортное время». Кстати, все это полезно не только для выступлений на конференциях, все это очень правильная инвестиция в communication skills, существенно повышающая вашу рыночную ценность...
С другой стороны, 90%[1], что вы поленитесь, и скачивать и читать/книги вы не будете.
Да и «Смерть от PowerPointа», хотя и четко показывает бессмысленность «слайдоментов», сделана в основном для продавцов-маркетологов, чтобы им было эффективней делать презентации для хомячков в стиле «гипножаба». Когда дословно, по этим правилам «Слайд=Фотография+лозунг≈[Де]мотиватор» делают слайды к техническому выступлению, получается странно (вот кстати, свежий пример с одной из наших конференций, когда докладчик дословно послушался этих советов. Вроде картинки яркие, и метафоры визуализированы, но по сути — потрачено место на совсем очевидное, а на нетривиальное и содержательное не осталось места и нормальной визуализации — схем, диаграмм и т.п.).
Поэтому простые советы из своего опыта.
Визуальная часть важна. Нетривиальные вещи из программирования нельзя эффективно изложить, не задействуя зрение. Но, нельзя скатываться в слайдоменты и субтитры.
А при рассказе, помните об основном принципе программирования — DRY=Dont Repeat Yourself. Если вы почти дословно пересказываете содержимое слайда — у воспринимающего возникает эффект «глючной копипасты» — через визуальный и звуковой канал к нему приходят почти одинаковые куски, и это мало того,
- что скучно — когнитивная интерференция, аудио- и видео- волны гасят друг друга,
- так это еще и нецелостно (если софтверный человек видит два почти одинаковых куска кода — почти наверняка, по крайней мере в одном из них ошибка).
Поэтому — если у вас на слайдах текст — минимизируйте его. Выкините все, что лишнее. Найдите более лаконичные формулировки, более удачные слова, метафоры и культурные коды. Минимум. Рефакторинг, пауза — посмотрите свежим взором, нет ли чего лишнего? Повторите.
Русский письменный язык красив, но чудовищно избыточен, провоцирует писать длинные предложения, изобилующие прилагательными, причастными и деепричастными оборотами, утомляющими всех перечислениями, отвлеченными описаниями, псевдоостроумными метафорами, и просто тянет вместо простой мысли написать очередной Великий Русский Роман, чтобы осчастливить всех... СТОП! Не тащите вот такое на слайд!
Только самое необходимое, все остальное вы скажете словами! Берите пример с редактора Ольминского.
Потом можно будет чуть-чуть поиграть с шрифтами и цветом. Например, жирным выделите самое важное, красным — плохое и опасное, синим — приятное и вкусное. Ну или придумайте свою надежную семантическую палитру, основанную хоть на цветах китайских пуховиков 90-х годов.
Можно набросать Software Speaker Manifesto:
- Лаконичный текст лучше литературного.
- Лучше, чем просто текст — текст структурированный. Да, на худой конец — списки с буллеты. Осточертело, но лучше чем абзацы прозы.
- Лучше, чем текст — схемы. Простые. Не надо UML и иже с ним (если, конечно, у вас доклад — не про UML). Не надо кучу клипарта из микрософтовского офиса (серверов в виде minitower, теток с дисками в руках, десктопов с флопповодами).
- Простые графы — круги, прямоугольники, стрелки, текст. Визуализируют зависимости, потоки.
- Вложенность понятий — пересекающиеся круги, и иные фигуры с полупрозрачными простыми цветами.
- Простые графики, лучше двухмерные.
- Код бывает полезен. Но и как с текстом — минимум, только самое важное, обязательно Syntax Highlighing.
- Общий принцип — если содержимое слайда можно разделить на несколько — сделайте это! Всем будет лучше видно! Не надо будет вчитыватся, инфа будет просто падать в мозг слушателя параллельно с вашей речью! Это бесплатно!
- Тема о чем-то видимом? Софт с GUI, работа с IDE, и т.п. — просто покажите это! Даже если это слепая и зарытая в землю, как крот серверная софтина, попробуйте визуализировать потоки данных, графики мониторинга метрик, на самый худой конец можно показать логи. А вообще:
- Скриншот лучше ста слов.
- Живьем — лучше, чем скриншот.
- Но, если вы не супермастер демонстраций — заготовьте заранее скринкаст (лайвкодинга, лайвдемо, или презентации по майндмапу). Это будет быстрее и надежней, чем живьем. Впрочем, заготовьте в любом случае, кроме импровизации по заказам аудитории.
- Цвета. Шрифты. Размеры — относится и к слайдам, и к коду, и к скринкастам. Максимально простые и надежные.
- Фон — только светлый. Выступать с черным фоном можно только, либо если кинозал с полным затемнением (так делает Стив Джобс), либо перед каждым зрителем — личный монитор. В остальных случаях — все засветится, код не будет виден, все будет уродливо.
- Цвета — контрастные с фоном. Красный-Синий-Зеленый, ну и легкие вариации. Светложелтого на белом запросто не увидят!
- Размеры шрифтов — максимум возможного.
- Шрифты без засечек и прочих украшательств («Courier New» для кода — это Адѣ!). Если вы не специалист по шрифтам, рекомендуем использовать прекрасную новую семейку Windows-шрифтов, за которую Микрософту можно простить многое: Calibri, Candara, Cambria, Consolas. Начиная с виндовс-висты, они идут в стандартном комплекте, если вы линуксоид — то их можно нарыть. Если вы маковод, то наверно вы все равно не будете слушать чужие советы по шрифтам.
- Если у вас совсем нет опыта, и вы делаете слайды в PowerPointе, попробуйте погуглить оценивающий плагин «Текстозавр».
- Техническая анимация — переходы между слайдами, спецэффекты в духе prezi.com — нафиг не нужны. Они подспорье для «HypnoToad», для гипнотизирования аудитории, это не наш метод. Я наблюдал несколько околотехнических презентаций, сделанных в Prezi, кроме головокружения у аудитории, положительных эффектов не замечено.
- Хитрые бекграунды — нафиг. Логотипы вашей компании или еще чего-нибудь (включая конференцию) — уберите куда-нибудь в угол, и минимизируйте их, они просто жрут ценное пространство.
Обкатка
Предпусковая подготовка
Вопрос с оборудованием очень важен. Принцип Питерса, по отношению к конференции — то, что может сломаться, и даже не может, обязательно сломается в самый важный момент, за минуту до конференции!
Я бы сам не поверил, в такое, но у меня личный опыт — когда надежно работающий ноутбук, на трех конференциях гарантированно падал в BSOD именно в момент начала выступления (и оживить его можно было только откатом к контрольной точке!). Часть этой мистики я расшифровал — глюки аппаратного ускорения видеовоспроизведение XVID-lossless видеороликов 1280x720, возникающие только при подключении этого лептопа к сети, а RGB-выхода — к проектору.
В результате 100500 тестовых прогонов эту проблему не обнаруживали, а когда ноутбук подключался к проектору и сети (чтобы не дай бог, не разрядился в процессе), и запускалась моя видеопрезентация в том кодеке и с максимальным разрешением, случалась та фигня.
Поэтому — либо
- Выступайте со своего ноутбука, но
- 100500 раз проверьте, что все ОК.
- Найдите время в перерыве или до начала конференции, проверить, нет ли проблем с подключением именно в том зале, именно к тем проекторам или телевизорам. Продолжает ли все работать после этого?
- Если собираетесь лезть в интернет, и что-то показывать, возьмите свой личный канал (йота, 3G), не надейтесь на общий Wi-Fi, который организаторы дают всем — он будет гарантированно забит под завязку. И проверьте, что сотовый или WiMax-интернет ловится в той комнате. Лучше заранее узнать план здания у организаторов, и если комната без окон, в глубине помещения, отказаться от интернет демонстраций, либо готовится к этому (личный WiMax-роутер, добрасывающий интернет от окон вглубь помещения, например).
- Если вы выступаете с компьютера организаторов, то урежьте аппетиты, делайте простые артефакты выступающего — слайды в PDF, со встроенными шрифтами, и то, также, в перерыве, проверьте, нормально ли показывается это все у организаторов.
Выступление
Довольно о видеочасти. Теперь о вас. Собственно вы, а не слайды-видео-скринкасты, являетесь центром доклада (а не только телесуфлером/бэк-вокалистом/говорящим динамиком).
Держите внимание на себе, контролируйте и поддерживайте восприятие аудитории («Не спать!»), задавайте вопросы на понимание, проверяйте, что вы ее еще не потеряли, уйдя в какие-то узкие дебри (даже если какой-то мудак или спец в теме загнал вас туда своими вопросами).
В некотором смысле, профессиональные конференции — это любительский театр по извращенным темам для узкого круга ценителей. Не стесняйтесь жестикулировать — человеческие руки очень мощный инструмент визуализации, используется с доисторических времен, и восприятие жестов очень надежно — оно сидит в генетической прошивке. Хорошая тема — показать что-то не только на экране, но и в виде интересных предметов. Например, Елена «АленаCPP» Сагалаева, на своем докладе «Искусственный интеллект в играх» показывала деревянные модельки машинок, связанных резинками, для иллюстрации грязных трюков игроделов.
Говорите всегда в микрофон. Даже если вам кажется, что вас слышат — в задних рядах точно все плохо. И очень плохо на видео/аудиозаписи — техника не настолько чувствительна, как человеческое ухо, и даже если постфактум делать усиление, нормализацию, динамическую компрессию — будет не очень, ибо с вашим бормотанием усилятся и все шорохи, и прочие фоновые звуки, которых мы обычно не замечаем (мозг — самый лучший фильтр).
Старайтесь, чтобы и вопросы к вам задавали в микрофон, ну а если это не так — просто повторяйте вопрос в своей формулировке перед началом ответа. Заодно это прояснит, правильно ли вы этот вопрос поняли.
Помните об аудитории! Ваша задача донести до нее нетривиальные вещи, даже если они вам кажутся тривиальными.
Хотя для людей вне индустрии, все software люди выглядят «компьютерщиками», от эникейщика до архитектора высоконагруженных сервисов, даже внутри отдельных профессий надеятся на надежное понимание «вы должны понять меня как программист программиста», бессмысленно.
«Программист» — это такое обобщенное понятие, как «собака» — в этой профессии так много ответвлений, не только со своими языками/фреймворками, но даже языками и ценностями. Бухгалтерскому программисту неведом хайлоад, но целостность, точность, надежность вшита в подкорку, а веселому вебстартаперу пофиг на проблемы «пользователей-хомячков», ведь их миллионы, лишь бы сервис не лежал целиком (да и то, сейчас можно «свалить на DDOS»). И т.п. Куча профессиональных сект «Свидетели Монад», «Возлюбившие GIT», «Уверовавшие в приход шестого перла» — с одной стороны, могут очень хорошо «рубить» в тех концепциях, которые вы рассказываете, с другой — дать вам «прикурить», если вы подставитесь, но в любом случае, надо ориентироваться на самого простого, «сферического программиста в вакууме», проще представлять его простым студентом, недавно научившимся кодить в процедурном и объектном стилях, на чем-то распространенном, а об остальном не имеющем ни понятия.
Если же вы вообще, полезли в дебри Computer Science, то не надейтесь, что ваши загибы о тонкостях гомоморфного шифрования кольцах полиномов, или эффективном построении AST-деревьев поймут все присутствующие, хотя возможно все из них проходили и алгебру, и криптографию, и «теорию реализации языков программирования».
Поэтому, постарайтесь «раскрыть тему»:
- Начните с элементарных вещей, не бойтесь показаться Капитаном Очевидность в начале.
- Говорите максимально просто. Плюсы выступления на конференции — не надо изображать письменный язык, или академический канцелярит. Можно и нужно говорить просто, повторятся и повторять важные вещи, вставлять паузы... УСИЛЕНИЕ ВАЖНЫХ МОМЕНТОВ ГОЛОСОМ, кстати, использовать, например, всякие вспомогательные слова, соответственно. Вот. Кстати говоря, например. Именно так.
- Потом постепенно переходите к более нетривиальным частям. Даже если неподготовленная аудитория, по мере «повышения уровня» под конец отвалится — она сможет таки получить хотя бы 50% информации, и хотя бы понять, интересно ли ей это в перспективе, имеет ли смысл самостоятельно догуглить тему, ну и вообще, «какой у темы вкус». Если они отвалятся в самом начале, КПД будет 0%, это пичаль.
- Концентрируйтесь на своем опыте. Не надо тупо пересказывать Википедию или прочитанную вами книжку — это банально и не возбуждает. Расскажите реальные «истории из окопов» — это отлично воспринимается и запоминается (люди вообще лучше воспринимают истории, чем сухие схемы и таблицы). Не скрывайте существующих проблем — это и честно, и добавляет доверия.
- Не ленитесь несколько раз пояснить основным моменты — чем может быть полезна описываемая вами технология для аудитории (ибо почти всегда вопросы начинаются из серии «А нафиг или где это применять?»), и какие там риски и опасности. Возможно единственным плюсом вашей технологии — это извращенное интеллектуальное удовольствие. Честно скажите об этом — ОК!:
- «Программирование на Brainfuck — возбуждает. К тому же я один такой в городе N, уволить, или даже проревьювить меня не могут»
- «Алгоритмы гомоморфного шифрования пока слишком трудоемки, для того, чтобы реализовать хоть какую-то полезную функциональность»
- «Технически, я не знаю, куда можно было бы применить этот фреймворк, но он иллюстрирует интересную парадигму функциональной разработки...»
- «Система управления версиями YYY отстойна, но зато на ее примере мы видим концепт-реализацию алгебры патчей».
Примечания
- ↑ Реальный опыт предложения этой ссылки авторам.
[ List view ]Comments
Хорошая статья, но граммарнаци бы ей не повредил.
Если видите ошибки - поправьте. Это вики.
Please login to comment.