Как придумать тему технического доклада
Когда я был молодым, ещё школьником, мне крупно повезло — я нашёл в нашем городе то, что сейчас называют профессиональным сообществом. Мы называли себя клубом программистов. Школьники и студенты, мы обретали профессионализм под присмотром старших товарищей. Программисты делились опытом, информацией, литературой. Мой друг показывал мне, как писать на языке ассемблера, а я ему — как писать на C.
Через много лет, уехав в Москву, я попытался найти похожее сообщество здесь, но не нашёл. Сообщество пришлось создать самому.
Мы всё так же клуб программистов, но уже московский. Очень часто на наших встречах мы делаем доклады. У нас несколько организаторов, каждый из которых занимается чем то своим; я отвечаю за подготовку и репетицию докладов. Я не знаю, сколько всего их было, но, кажется, что не меньше ста.
Доклады были разными. Я хотел, чтобы они были захватывающими и полезными, так что мне пришлось разобраться в том, как сделать доклад интересным. Оказалось, что эти знания востребованы и среди начинающих докладчиков, и среди деврелов, так что в конце концов я решился написать статью на эту тему.
Но материала оказалось много и статьи получилось две. Сейчас вы читаете первую — о том, как придумать тему доклада. Вторая — как сделать доклад интересным — будет готова через неделю.
Хочу поблагодарить коллег из сообщества деврелов, которых я попросил поделиться мыслями. Отдельное спасибо — Григорию Петрову, Василике Климовой и Олегу Бунину за скрупулёзную вычитку и рекомендации.
Эта статья не появилась бы без Антона Полякова и организованного им обсуждения. Именно тогда я впервые задумался о том, чтобы подытожить и доступно изложить свой опыт.
Собирая материал, я понял, что все советы хорошо ложатся не только на подготовку докладов, но и написание статей. Есть небольшие отличия — назовём их «спецификой» —, но есть и много общего. Именно поэтому в качестве иллюстраций я ссылаюсь не только на доклады, но и на статьи.
Найти тему
Поиск темы — первый камень преткновения для начинающего докладчика. Он либо вообще не знает, о чём рассказывать; либо не может остановиться на единственной идее из тех, что кружат в его голове. Организаторы конференций знают об этой проблеме. Там, в программном комитете, есть опытные разработчики, которые помогают нащупать возможные темы. Обычно всё стартует с обсуждения недавних проектов, рабочих ситуаций, прослушанных докладов и прочитанных книг. Скажем, Григорий Петров — деврел из Evrone — начинает интервью команды со слов «давайте вспомним, что ярче всего подгорело за последние полгода». Этот способ подходит, если у вас под рукой есть опытный разработчик с широким кругозором, но, как правило, его нет, и вам предстоит выкручиваться самому.
Ильф и Петров утверждали, что спасение утопающих — дело рук самих утопающих. Попробуем разобраться сами, откуда вообще появляются темы для докладов.
То, что нас не убивает
Доклады бывают разными — серьёзными и весёлыми, трудными и простыми, скучными и захватывающими. Бывают доклады, которые заставляют слушателей сопереживать рассказчику, что кажется невозможным для технического повествования.
Как можно сопереживать нулям и единицам?
Похоже, здесь есть какой-то секрет и он, правда, существует.
Мы сопереживаем живой эмоции, и это значит, что в основе таких — драматических — докладов, тоже лежит эмоция.
Изредка эта эмоция положительная, например, человек рассказывает, как устроился в Google. Но гораздо чаще в основе переживательных докладов лежит какая-нибудь жизненная неприятность.
Долгие поиски работы, выгорание, рабочий конфликт — всё это служит прекрасной темой для доклада. Живая эмоция, если её не потерять, вызывает отклик у аудитории.
Правда, у этого мотива есть и проблемы. Одна из них — эмоция почти всегда негативна, а это значит, что мы выплёскиваем злость или обиду. Широко известен пример со статьёй «Меня перевезли в другую страну, а через две недели выставили на мороз». Она собрала большой отклик на Хабре и много плюсов.
В то же время часть комментаторов негативно оценивали именно автора статьи. Масло в огонь подливали и его коллеги, которые не остались в стороне. Сейчас статья автором закрыта, но, если вы её читали, думаю, вы её помните. С точки зрения привлечение внимания и заработка кармы на Хабре — автор, несомненно, в плюсе. С точки зрения долговременного построения карьеры — кажется, что нет.
Чтобы не было негативного бумеранга, эмоцию надо выводить на конструктив. Да, вы столкнулись с неприятной ситуацией, и вам действительно досталось. Что в результате? Вы стали сильнее, умнее, добрее? Вы осознали важную жизненную истину, которой готовы поделиться? Возможно, у вас есть пара полезных советов?
В качестве хороших конструктивных примеров рекомендую доклад Ильи Якямсева «Эффективность не работает» и доклады Максима Дорофеева о прокрастинации. Ещё один позитивный пример — очень комментируемая статья про то, как Лена в 29 лет решила вкатиться в IT.
То, что мы научились делать
Ошибаются те, кто считает, что эмоции и интеллект далеки друг от друга, Мы — программисты — знаем, как мучительны порой бывают нерешённые задачи. Неудачные попытки решения — одна за одной — вызывают приступы раздражения, а то и отчаяния.
А решённая задача способна погрузить нас в эйфорию.
Поэтому для программистов решённая задача может послужить прекрасной основой для захватывающего эмоционального доклада.
Впрочем, даже у лучших кандидатов есть тёмные стороны. Первая — очевидная для докладчика — заключается в том, что решённая задача кажется несущественной. Докладчик думает, что подобные задачи слушатели решают по тридцать раз на дню, так что конкретно его достижение никакого интереса для них не представляет.
Это может оказаться правдой. Чтобы понять потенциальный интерес к задаче, поговорите с коллегами или тимлидом, они дадут вам взгляд со стороны. Оцените собственные усилия по решению. Хороший кандидат для доклада — задача, которая не далась вам с первого раза, а потребовала пары недель работы.
Вторая тёмная сторона — решённая задача кажется слишком существенной. Такая ситуация бывает у программистов-новичков, которые любую взятую вершину воспринимают, как высокую. В результате появляются статьи «Сейчас я вам расскажу, как делать запросы в SQL. Надо писать SELECT».
Запросы в SQL тоже могут стать хорошей затравкой для доклада, но эту затравку нужно расширить до полноценного введения в тему.
Третья тёмная сторона таких докладов связана с личным восприятием самого докладчика. Для него проблема возникла две недели назад, в известном ему контексте. Если он пытается пересказать её «как есть», он рассказывает решение самому себе двухнедельной давности, а это непонятно никому, кроме пары его коллег.
Надо погрузить слушателей в свой контекст. Часто это оказывается проблемой, потому что докладчик думает, что слушатели и так всё знают.
Чем больше контекста вы даёте, тем больше ваша потенциальная аудитория. В книгах авторы знакомят читателя с миром и персонажами, точно также спикеры могут знакомить слушателя с предысторией и сложностями. Здесь важно не перестараться, иначе введение может затянуться. Если вы рассказываете о задаче, которую решили на языке PHP и фреймворке Laravel, вам достаточно погрузить Laravel-программистов в контекст своей задачи. Вы можете расширить аудиторию на всех PHP-программистов и даже на всех веб-программистов, которые пишут на Python, Node.js или C#, и это может быть оправдано. Но расширять контекст бесконечно не получится — в какой-то момент введение станет больше доклада.
Аналогом решённой задачи может быть сложная тема, с которой вы разобрались. Я помню, что освоение OAuth заняло у меня приблизительно две недели штудирования RFC, потому что стандарты должен быть точными, а не понятными. Чтобы быстро въехать в тему, нужна разъясняющая статья или доклад, но никак не стандарт. Разобравшись с тем, как устроен OAuth, можно и самому сделать доклад на эту тему.
Такой подход иногда называют методом Фейнмана, в честь известного физика и популяризатора науки. Он утверждал: «если хочешь в чём то хорошо разобраться, попробуй рассказать об этом кому-нибудь другому». Правда, хорошо рассказать о сложной теме бывает непросто, этот навык надо осваивать. Притчей во языцех являются статьи-озарения «так вот что такое монада». Виталий Брагилевский — преподаватель и один из разработчиков компилятора Haskell, утверждает, что после таких объяснений сам перестаёт понимать, что это такое.
В качестве иллюстрации метода Фейнмана рекомендую статью о фильтре Калмана.
То, что мы знаем
Когда вы решаете задачу в третий раз, вы можете рассказать о её решении. Когда вы решаете задачу в тридцатый раз, вы можете рассказать про большой круг похожих задач. Мы, программисты, очень любим такие абстракции.
Обычные знания нас уже не устраивают — нам подавай мета-знания. Повседневное мышление перестаёт казаться нам удивительным — по настоящему счастливыми нас делает рефлексия на тему мышления.
Поэтому экспертные знания так востребованы.
Экспертом стать не очень сложно. Практически любой сеньор обладает нужным кругозором, и даже миддл-программисты на хорошем уровне разбираются в нескольких темах.
Проблемы у экспертов две. Первая заключается в том, что эксперт не считает свои знания экспертными. Ну, подумаешь, — говорит он, — принципы SOLID. Все знают принципы SOLID! Это неправда. Все читали о принципах SOLID. Подавляющее большинство помнит расшифровку 2–3 букв аббревиатуры. Так что если вы сумеете доходчиво рассказать об этих принципах, у вас будет хороший экспертный доклад для программистской конференции.
Вторая проблема экспертных докладов заключается в том, что экспертизой трудно делится. Если вы набираете её месяцами, практикуя кодирование, как вы можете уложить все полученные откровения в тридцать минут доклада? Никак, даже и не пытайтесь.
Часто экспертные доклады — это доклады о какой-то яркой детали, которая застревает в голове у слушателя. Как только он столкнётся с похожей проблемой, он вспомнит о детали и, по крайней мере, будет знать, куда копать дальше.
В идеальном случае такие доклады не несут новые знания, они несут новую структуру. Слушатель знает решения десятков задач, но не видит общей картины. Вы показываете ему картину, и он понимает, как эти задачи связаны между собой и, главное — как они решаются.
Пример хорошей рефлексии — доклад Виталия Шароватова о том, как он был тим-лидом. Статья «всех времён и народов» конца 90-х — Александр Каталов рассказал о том, как заработать на shareware-программах. После этой статьи в России появилось целое сообщество shareware-программистов, в котором было нескольких сотен человек.
Другие варианты
Иногда хорошая статья — это перевод хорошей статьи на русский язык. Я не большой специалист по переводам, но кажется, что здесь не всё просто. Обычно надо связаться с автором и попросить разрешение на перевод и публикацию. С докладами этот способ вообще не работает — его называют плагиатом.
Впрочем, если чужая статья или чужой доклад рождают у вас самобытные мысли, они могут послужить основой для вашего доклада. А некоторые спикеры во время подготовки смотрят видеозаписи лучших выступлений по своей теме.
Есть также способ, к которому прибегают научные журналисты и популяризаторы. Мы назовём его «докладом на злобу дня». Вы берёте тему, которая интересна людям, погружаетесь в неё, собираете материал и, обладая опытом и кругозором, делаете востребованный доклад. Скажем, про copilot — кажется, он ещё не успел устареть.
Это работающий способ, но у него есть ограничения. Он действительно требует много времени и подходит больше для журналиста-популяризатора, чем для разговаривающего программиста.
В качестве иллюстрации посоветую вам перевод статьи, написанной после прочтения книги Чистый код. Будь вы автором, вы могли бы сделать доклад на тему «Кто переоценил Чистый код» или что-нибудь в этом роде.
Статьи на злобу дня практически самые популярные, что подтверждает перечень десяти самых просматриваемых статей на Хабре.
Кстати, раз уж речь зашла о Хабре. Там есть такой проект — контент-студия, где Хабр сводит корпорации, нуждающиеся в технических авторах и самих авторов. Антон Поляков, долгое время руководивший этой студией, буквально пару месяце назад выпустил книгу Хит на Хабр, где изложил свой опыт написания хороших статей.
В книге Антон подробно исследует в том числе и выбор темы, и даёт рекомендации, многие из которых подходят не только для статей, но и для докладов.
Чек-лист
Результат наших поисков удобно представить в виде чек-листа. Чтобы составить список подходящих тем, возьмите листок бумаги, ручку и напишите:
Что у вас болело
Какие задачи вы решали
Что вас вдохновляло
Темы, в которых вы разобрались
Книги, статьи, доклады, подкасты, которые вызвали у вас живой отклик
Темы, в которых вам хотелось бы разобраться
Перед вами ваши потенциальные доклады. Конечно, не каждый пункт этого списка можно превратить в выступление. Список нужно отфильтровать.
Фильтры
Маленькая тема
Вы решили задачу на работе. Сколько времени она заняла? Если несколько дней, то о решение вы расскажете за несколько минут. Для доклада этого мало. На больших конференциях доклады длятся в среднем полчаса. Опытные спикеры могут сделать доклад на сорок–шестьдесят минут. Организаторы принимают и двадцатиминутные выступления, но двадцать минут — это минимум.
Чтобы сделать доклад, вам нужно расширить тему, например, добавить похожие задачи или выйти на качественно новый уровень — рассказать о решение класса задач. Подумайте, можно ли расширить не очень большую тему, и — если нет — смело её вычёркивайте.
Маленькая аудитория
У вас может быть специфический контекст, который понимают далеко не все. Вы можете взять среднего специалиста и дать ему необходимые вводные, но сколько времени это займёт?
Для большинства докладов можно без труда увеличить аудиторию на два порядка, сделав небольшое введение. Оцените, насколько большим будет введение в вашу тему. Пять или десять минут — хорошо, двадцать минут — очень плохо.
Большая тема
Вернёмся к нашим монадам. В интернете есть десятки статей про монады и ещё столько же докладов. Проблема в том, что монадам посвящён университетский семестр, или вся вторая половина книги Липовача. Чтобы в них разобраться, надо прочитать книгу и прорешать хотя бы часть задач.
Большую тему не рассказать за сорок минут, так что режьте нещадно. Возможно, вам удастся нащупать тему обычного размера. Или вы сможете сделать цикл докладов. Цикл — не то, с чем можно идти на конференцию, но для внутренних митапов он прекрасно подходит. Для начинающего докладчика цикл — всегда плохо, потому что долго. Начинайте с небольших тем, чтобы обрести опыт подготовки, затем переходите к большим.
Приоритизация
Маленькие темы нужно расширить, большие — урезать. Всё это требует времени. В вашем списке будет несколько неподъёмных тем и несколько подъёмных. Если у вашего доклада есть заказчик, обсудите темы с ним — он подскажет, какие из них приоритетнее.
В конечном итоге, из всех записанных тем у вас останется несколько самых подходящих. Это и есть ваш задел на будущее — каждая из этих тем может стать хорошим техническим докладом.
Выход за границы
Бросим взгляд за горизонт. Сейчас вам удалось найти тему для доклада. Трюк с поиском темы сработает ещё несколько раз.
Если вы планируете регулярно выступать с докладами, темы из личного опыта быстро кончатся. И это проблема. Чтобы делиться знаниями, нужно много знаний. Чтобы развивать личный бренд, нужно много докладов.
Где найти бесконечный источник тем, если обнаруженные нами способы конечны? Мы не властны над тем, сколько неприятных ситуаций случится с нами с ближайшее время. Мы не способны решать трудные задачи одну за одной. Тем более, мы не можем быть экспертами сразу по многим вопросам. Делая доклады в одной области, мы неизбежно будем повторяться.
К счастью, мы знаем, к кому обратиться за помощью. Сходные проблемы возникают и у писателей, которым постоянно нужны темы для новых рассказов, повестей и романов. И мы знаем, что профессиональные писатели недостатка в темах не испытывают. Как они это делают?
Подход писателя
У писателей есть два основных способа. Во-первых, они расширяют собственный кругозор. Они хорошо эрудированны, много читают и многое могут рассказать. Они могут создавать новые мысли, просто сопоставляя информацию из разных источников.
Во-вторых, писатели перестают опираться на личный опыт при поиске тем. Человеческая жизнь ограничена — невозможно самому пережить все те истории, о которых пишут плодовитые авторы.
У каждого писателя есть секретный блокнот, куда он записывает интересные случаи из жизни. Заметки в газетах, рассказы друзей, собственные идеи.
Всё то же самое нужно делать и нам, если мы хотим стать профессиональными техническими докладчиками.
Больше читаем
Делаем пет-проекты
Подсматриваем, что есть у соседей
Забегаем на неисследованные территории
Заводим секретный блокнот
Через год, два или три у вас появится пул вопросов, которые вам интересны и про которые вы могли бы рассказать. Это не значит, что вам не придётся готовиться. Но, по крайней мере, на запрос организатора конференции вы всегда сможете достать из рукава две-три подходящие темы.
А секретный блокнот можно завести прямо сейчас.
Заключение
Как говорится, не боги горшки обжигают, и путь в тысячу миль начинается с первого шага. Самое время, чтобы сесть с ручкой и блокнотом, выбрать тему и начать подготовку доклада. Впереди осенние конференции. И ещё немного конференций.
