✅ наорала
Знаете мем про "оделся сам" и "наорала"? Он мне часто приходил в голову, когда помогала кому-то сформулировать описание доклада. Уж больно сильно отличались варианты "до" и "после" использования неких простых, но действенных рекомендаций.
Погнали, разберём их?
Самый универсальный шаблон хорошего описания давал Антон Черноусов, Developer Advocate:
Что важно в описании доклада для зрителя
1️⃣ В начале нужно показать проблему: что плохого происходит?
— В проблеме человек должен увидеть свою проблему. "Доклад - про меня".
— В начале желателен хук (создать любопытство).
2️⃣ Конец должен отвечать на поставленную в начале проблему. "Что я получу в результате, послушав доклад?" Человек читает начало и конец, если интересно - читает и середину.
Собственно, на этом можно было бы и закончить — посмотрите пример, как лаконично и понятно смотрится такое описание: 🔗 Infrastructure from Code. Следующий этап развития IaC / Антон Черноусов, DevOps Conf 2025.
Но давайте копнём ещё глубже.
Если потенциального слушателя заинтересовало название вашего доклада, то он идёт смотреть описание, и распространённая ошибка писать его в формате "что я сделал за последний год". Писать надо скорее в формате "вот почему ты должен потратить 30-50 минут своей жизни на мой доклад". Короче, говорим о слушателе, а не о себе.
Сложно найти статистические подтверждения, но практика показывает, что второй вариант работает сильно лучше. Посмотрите сами:
❌ «Расскажу, как мы за год перестроили процесс миграции и какие инструменты использовали».
✅ «Покажу, как сократить простой при миграции большой БД и не превратить переключение в ночной аврал».
Очень хорошо работает заход через конкретные боли, справиться с которыми вы поможете в своём докладе. Они же отлично ложатся в "хук", который нужен для привлечения внимания.
В общем, говорить с позиции слушателя — это главный лайфхак, рекомендую попробовать применить его, когда в следующий раз будете корпеть над тезисами :)