Каждый год разработчики отправляют заявки на конференции. Кто-то проходит с первого раза, кто-то несколько лет подряд получает отказы и начинает думать, что выступления — это «не его».

МЫ уже 15+ лет организуем масштабные ит-конференции – DUMP, PYCON, RUSTCON. А в прошлом году дебютировала наша новая конференция для разработчиков golang –  Let's GoConf. За это время через нас прошли сотни заявок, и одна вещь повторяется из года в год: сильные инженеры часто присылают слабые заявки, а средние на первый взгляд идеи иногда превращаются в отличные доклады.

Почему так происходит?

«Главное — быть экспертом»

Самое распространённое заблуждение — что экспертность автоматически делает заявку сильной. На практике это не так. Экспертность — это база, но не гарантия.

Программный комитет в первую очередь смотрит не на опыт автора, а на другое: что нового узнает слушатель за 40 минут. Если из заявки это не понятно, шансы попасть в программу резко падают.

Слишком короткое описание — частая проблема

Одна из типичных ошибок — попытка описать доклад одной фразой: «Расскажу про сборщик мусора в Go» или «Поговорим про микросервисы».

Такие заявки невозможно оценить. Неясно, о чём именно будет речь, какой у автора опыт и зачем это слушать. Совсем другое дело, когда есть контекст: «Мы столкнулись с ростом потребления памяти после обновления Go. Разбирались, как работает GC, какие гипотезы оказались неверными, что происходило в production и какие изменения помогли.»

Здесь уже видна история. А значит — можно представить доклад.

Что на самом деле ищет программный комитет

Часто кажется, что нужны только сложные и «глубокие» темы. Но это не совсем так.Мы смотрим на три вещи:

Практика.
Лучше всего работают доклады, выросшие из реальных задач, а не пересказ документации.

Честность.
Ошибки и неудачи часто интереснее успехов. Что не сработало? Почему? Что пришлось переделать?

Выводы.
Хороший доклад оставляет ощущение: «это можно попробовать у себя».

«У меня нет готового доклада»

Это нормальное состояние для большинства заявок. На этапе CFP готовый доклад вообще не обязателен. Часто достаточно идеи. Если тема интересная, дальше начинается совместная работа: обсуждения, структура, прогоны, правки. Почти ни один сильный доклад не появляется сразу — это всегда несколько итераций.

Какие темы обычно проходят лучше

Универсального рецепта нет, но чаще всего выигрывают заявки, где есть:

  • реальные инженерные задачи;

  • цифры и измеримый результат;

  • производительность и эксплуатация;

  • миграции и изменения архитектуры;

  • внутреннее устройство инструментов;

  • ошибки и неожиданные эффекты решений.

Слабее выглядят слишком общие темы вроде: «Что такое горутины» или «Введение в Go». Если тема базовая, важно добавить свой опыт или нестандартный взгляд.

Опыт выступлений не решает всё

Есть миф, что на конференции берут только известных спикеров. Это не так. Каждый год на сцену выходят люди, которые выступают впервые. И часто именно они делают самые запоминающиеся доклады — потому что рассказывают не теорию, а свой реальный опыт.

Почему хорошие идеи иногда «не заходят» в заявке

Частая проблема — автор слишком глубоко внутри темы. Для него всё очевидно, и он не объясняет базовый контекст. В итоге заявка понятна только после долгого разговора.

Но программный комитет не может проводить такие разговоры со всеми, поэтому работает простое правило: если заявку читает человек вне контекста, он должен понять суть.

  • какую проблему решали;

  • почему она была сложной;

  • что сделали;

  • зачем это слушателю.

Если этого нет — заявку почти всегда приходится дорабатывать.

Вместо вывода

Сильные доклады редко начинаются с мысли «я хочу выступить».

Чаще всё происходит иначе: человек рассказывает коллегам историю, видит интерес, получает вопросы — и только потом понимает, что из этого может получиться доклад.

Если у вас есть такая история — не откладывайте её на потом. Возможно, именно её не хватает в программе следующей конференции.