Почему сильные доклады не проходят CFP, а слабые заявки иногда становятся лучшими выступлениями
Каждый год разработчики отправляют заявки на конференции по CFP. Одни попадают в программу с первого раза, другие получают отказы несколько лет подряд и начинают думать, что публичные выступления - "не про них". Парадокс в том, что отказ часто не связан с уровнем инженера: сильные специалисты регулярно присылают неубедительные заявки, а темы, которые на старте выглядят средне, в итоге превращаются в мощные и запоминающиеся доклады.
Мы видим это изнутри больше 15 лет, организуя крупные ИТ‑конференции DUMP, PYCON и RUSTCON. В прошлом году к ним добавилась новая площадка для Go‑разработчиков - Let's GoConf. За это время через программный отбор прошли сотни заявок, и закономерность повторяется из сезона в сезон: качество будущего выступления и качество текста заявки - не одно и то же.
Заблуждение №1: "Если я эксперт, заявка и так сильная"
Самая распространённая ошибка - считать, что экспертность автоматически "продаёт" тему. На практике опыт - это фундамент, но не гарантия. Программный комитет в первую очередь оценивает не регалии автора и не громкость имени, а простую вещь: что нового и полезного узнает слушатель за 40 минут.
Если из заявки непонятно, какой именно результат получит аудитория, шанс попасть в программу резко падает - даже при сильном бэкграунде спикера. Комитету важно увидеть ценность доклада, а не только подтверждение того, что автор "разбирается".
Заблуждение №2: "Достаточно одной фразы"
Ещё одна типичная проблема - сверхкороткое описание в стиле: "Расскажу про сборщик мусора в Go" или "Поговорим про микросервисы". Такие заявки почти невозможно оценивать. Неясно:
- о чём именно будет доклад (уровень, угол, границы темы);
- какой опыт у автора и на каких кейсах он строит рассказ;
- зачем это слушателю, кроме общих слов.
Совсем иначе звучит заявка, в которой есть контекст и история: например, вы обновили версию Go, получили рост потребления памяти, пошли разбираться с GC, выдвигали гипотезы, часть из них оказалась ложной, в production всплыли неожиданные детали, а в итоге вы нашли изменения, которые стабилизировали систему. Здесь уже появляется сценарий доклада - и у программного комитета появляется шанс представить, "как это будет на сцене".
Что на самом деле ищет программный комитет
Хорошие темы не обязательно должны быть максимально сложными. "Глубина" важна, но чаще побеждает сочетание трёх параметров:
1) Практика. Сильнее всего работают доклады, которые выросли из реальной инженерной задачи, а не из пересказа документации и общеизвестных статей.
2) Честность. Ошибки, неожиданные эффекты и провалы нередко интереснее успехов. Что не сработало? Почему? Какие допущения оказались неверными? Что пришлось переделывать на ходу?
3) Выводы. Доклад ценен, когда слушатель уходит с ощущением: "я понимаю, что попробовать у себя". Не абстрактное "мы сделали микросервисы", а конкретика - какие решения оказались удачными, какие - нет, и в каких условиях.
"У меня нет готового доклада" - и это нормально
На этапе CFP готовое выступление обычно не требуется. Более того, отсутствие "отполированного" доклада - нормальное состояние для большинства заявок. Часто достаточно идеи и понятного каркаса: проблема → контекст → действия → результат → выводы.
Если тема цепляет, дальше начинается совместная работа: обсуждение фокуса, уточнение тезисов, сбор структуры, прогоны, правки. Почти ни один сильный доклад не появляется "сразу идеальным" - это всегда несколько итераций, где первоначальная мысль превращается в ясный рассказ.
Какие темы чаще проходят отбор
Универсального рецепта нет, но статистически чаще выигрывают заявки, в которых есть:
- реальные инженерные задачи и ограничения (сроки, нагрузка, бюджет, легаси);
- цифры и измеримый эффект (время ответа, стоимость, память, стабильность);
- производительность и эксплуатация (observability, инциденты, SLO, on-call);
- миграции и архитектурные изменения (как переходили и что сломали по пути);
- внутреннее устройство инструментов (как работает "под капотом");
- ошибки и неожиданные последствия принятых решений.
Хуже смотрятся слишком общие темы вроде "Что такое горутины" или "Введение в Go". Но даже базовую тему можно усилить - добавив собственный опыт, нестандартный кейс, сравнение подходов или разбор заблуждений, которые вы встречали в реальной работе.
Опыт выступлений не решает всё
Существует миф, что на конференциях берут только известных спикеров. На деле каждый год на сцену выходят люди, выступающие впервые. И нередко именно их доклады оказываются самыми запоминающимися - потому что там меньше "теоретического шоу" и больше честной инженерной истории: что болело, что попробовали, что сломали, что поняли.
Программный комитет чаще настораживает не отсутствие сценического опыта, а отсутствие ясности: если заявка выглядит как набор общих фраз, непонятно, сможет ли спикер удержать внимание и довести слушателя до выводов.
Почему хорошие идеи "не заходят" именно в заявке
Иногда идея сильная, но автор слишком "внутри" темы. Для него многое очевидно, и поэтому он пропускает базовый контекст - тот самый мостик, по которому аудитория должна перейти от "ничего не понял" к "теперь ясно". В результате текст заявки начинает быть понятен только после длинного разговора.
Но программный комитет не может устраивать такие разговоры со всеми. Поэтому действует простое правило: заявку должен понять человек вне вашего контекста - быстро и без расшифровки намёков. Минимальный набор, который стоит проговаривать прямо в тексте:
- какую проблему вы решали;
- почему она была нетривиальной;
- что именно вы сделали (и почему так);
- какой результат получили;
- зачем это слушателю и что он сможет применить.
Как превратить "размыто" в "берём"
Ниже - практичные приёмы, которые часто резко усиливают заявку без изменения самой темы.
Сузьте фокус до одного конфликта. Не "всё про микросервисы", а "как мы разрезали монолит и упёрлись в наблюдаемость и транзакционность".
Добавьте признаки реальности. Временные рамки, ограничения, нагрузка, характер инцидентов, что было в production - это делает заявку "живой" и проверяемой.
Опишите, что будет внутри 40 минут. 3-5 пунктов плана помогают комитету увидеть структуру, а вам - не расплыться.
Покажите, что вы не продаёте идеологию. "Мы выбрали X, потому что..." звучит сильнее, чем "X - лучший подход". А если вы ещё и перечисляете, где X не подходит, доверия становится больше.
Новые параграфы: как повысить шансы на прохождение CFP
1) Сформулируйте "обещание слушателю" одной строкой. Это не тема, а результат: "После доклада вы сможете диагностировать рост памяти после обновления Go и понять, какие метрики смотреть в первую очередь".
2) Укажите целевую аудиторию и уровень. "Для тех, кто уже пишет сервисы на Go и сталкивается с нагрузкой/инцидентами" - лучше, чем попытка понравиться всем сразу.
3) Добавьте измеримость, даже если цифры приблизительные. Комитету важно видеть, что вы не пересказываете теорию. Формулировки уровня "получили снижение p95", "сократили время восстановления", "уменьшили потребление памяти" делают заявку весомее.
4) Не бойтесь рассказывать про неудачи. Доклады "как мы ошиблись" часто полезнее, потому что экономят чужое время и бюджет. Главное - довести историю до выводов: какие признаки указывали на проблему, что вы бы сделали иначе, какие проверки добавили.
5) Проверьте заявку на понятность "человеку рядом". Дайте текст коллеге из другой команды. Если он не может за минуту пересказать, о чём доклад и в чём польза - заявка, скорее всего, слишком внутренняя.
6) Заложите место для обсуждения, но не оставляйте пустоты. Фраза "подробности расскажу в докладе" не помогает. Лучше кратко обозначить поворотные моменты: какие гипотезы вы проверяли, где ошиблись, что оказалось ключевым сигналом.
7) Не превращайте заявку в резюме. Перечень ваших достижений важен, но вторичен. Комитету нужен не список технологий, а ясный ответ: что вы принесёте аудитории и почему именно ваш опыт делает рассказ ценным.
8) Подумайте о названии как о навигации. Сильный заголовок не обязан быть остроумным, но он должен задавать рамки: "Рост памяти после обновления Go: разбор GC‑гипотез, которые не сработали, и изменений, которые помогли".
Вместо вывода
Сильные доклады редко рождаются из мысли "я хочу выступить". Чаще всё начинается с короткого рассказа коллегам: вы делитесь историей, видите живой интерес, слышите вопросы - и внезапно понимаете, что это уже почти готовый материал. Если у вас есть такая история, не откладывайте её. Возможно, именно её и не хватает программе следующей конференции.
Главное - помнить: CFP оценивает не вашу самооценку и не масштаб вашей должности. Оно оценивает ясность, пользу и конкретику. И часто достаточно слегка переформулировать и структурировать мысль, чтобы сильная инженерная работа наконец стала сильной заявкой.
