Каждый год тысячи разработчиков отправляют заявки на конференции. Кто-то получает приглашение с первой попытки, кто-то несколько лет подряд видит письмо с отказом и решает, что выступления — «не его».
За последние годы наша команда организовала DUMP, PyCon Russia, RustCon, а в прошлом году — первую Let’s GoConf. За это время мы прочитали сотни заявок и заметили одну закономерность.
Очень сильные инженеры нередко присылают слабые заявки, что их хочется отклонить уже после первого прочтения.
И наоборот — иногда заявка выглядит довольно сырой, но после пары созвонов и нескольких итераций превращается в один из самых сильных докладов программы.
Почему так происходит?
Заблуждение №1. «Главное — быть экспертом»
Кажется очевидным: если человек много лет работает с Go, значит, у него автоматически получится хороший доклад.
На практике все немного не так.
Самый главный вопрос программного комитета звучит не «насколько человек крут», а что нового узнает слушатель за 40 минут.
Если после описания заявки этого не понятно, вероятность попасть в программу резко падает.
Заблуждение №2. «Тему нужно описать одной фразой»
Одна из самых распространённых ошибок — слишком краткое описание.
Например:
«Расскажу про сборщик мусора в Go.»
Или:
«Поговорим про микросервисы.»
Такие заявки почти невозможно оценить.
О чём именно будет доклад? Какой опыт у автора? Что нового услышит аудитория? Почему именно этот доклад стоит выбрать среди десятков других?
Этого в заявке просто нет.
Совсем иначе воспринимается описание вроде такого:
«Мы столкнулись с ростом потребления памяти после обновления Go. Разбирались, как работает GC, какие гипотезы оказались ложными, что происходило в production и какие изменения в итоге дали результат.»
Здесь уже появляется история.
А значит — появляется шанс представить, каким будет выступление.
Что программный комитет ищет на самом деле
Часто кажется, что организаторы ищут только самые сложные технические темы.
Это не совсем так. Гораздо важнее другое. Мы всегда обращаем внимание на несколько вещей.
Во-первых, практический опыт.
Если доклад вырос из реальной задачи, а не пересказывает документацию, его хочется слушать.
Во-вторых, честность.
Доклады про ошибки зачастую оказываются интереснее историй про идеальный проект. Что не получилось? Какие гипотезы оказались неверными? Где пришлось отказаться от первоначального решения? Именно это запоминается аудитории.
В-третьих, выводы.
После хорошего доклада слушатель должен уйти с ощущением: «Завтра попробую это у себя.»
«Но у меня нет готового доклада»
Это, наверное, самое частое опасение.
На самом деле на этапе CFP нам далеко не всегда нужен готовый доклад. Иногда достаточно хорошей идеи.
Если мы видим интересную тему и понимаем, что из неё может получиться сильное выступление, дальше начинается совместная работа.
Созвоны.
Обсуждение структуры.
Поиск главной мысли.
Прогоны.
Обратная связь.
Очень редко сильный доклад появляется сразу. Практически всегда это результат нескольких итераций.
Какие темы цепляют сильнее всего
Нет универсального списка.
Но почти всегда интересно читать заявки, в которых есть:
-
необычные инженерные задачи;
-
реальные цифры и результаты;
-
производительность;
-
эксплуатация;
-
миграции;
-
внутреннее устройство инструментов;
-
ошибки и неожиданные последствия принятых решений.
Гораздо слабее выглядят заявки уровня:
«Что такое горутины.»
Или:
«Знакомство с Go.»
Подобные темы уже много раз обсуждались.
Если вы всё же хотите говорить о чём-то хорошо известном, попробуйте найти собственный взгляд или необычный опыт.
Опыт выступлений почти ничего не решает
Есть миф, что конференции приглашают только известных спикеров. Это не так.
Каждый год мы видим людей, которые выходят на сцену впервые.
Если тема интересная, а человек готов работать над докладом, отсутствие опыта практически никогда не становится препятствием.
Более того, иногда именно новые спикеры делают самые запоминающиеся выступления.
Потому что рассказывают не абстрактную теорию, а историю, которую прожили сами.
Почему хорошие заявки иногда становятся плохими
Иногда автор настолько погружён в свою тему, что забывает объяснить очевидные для него вещи. Получается заявка, которую можно понять только после часового разговора.
К сожалению, программный комитет не может провести такой разговор с каждым кандидатом. Поэтому лучший совет очень простой.
Представьте, что заявку читает разработчик, который никогда не работал над вашим проектом.
Поймёт ли он:
-
какую проблему вы решали;
-
почему она была сложной;
-
что именно удалось сделать;
-
почему это будет полезно другим?
Если ответ «нет», скорее всего, заявку стоит доработать.
Вместо вывода
Самые интересные доклады редко начинаются со слов:
«Я хочу стать спикером.»
Чаще всё происходит наоборот.
Человек рассказывает коллегам историю из проекта. Замечает, что все начинают задавать вопросы. И только потом понимает: кажется, из этого может получиться хороший доклад.
Если у вас есть такая история — не откладывайте её «до следующего года».
Возможно, именно её не хватает в программе следующей конференции.
ссылка на оригинал статьи https://habr.com/ru/articles/1057348/