Как (не) нужно писать синопсисы/заявки/презенташки

Наболело не скажу откуда, напишу лучше конструктивное. И полезное для многих людей творческих профессий, а такможе разработчиков и иногда даже предпринимателей. Ибо, как практика показывает, люди массово не понимают, шо такое заявка/синопсис/презентация, даже когда формальные требования к их составлению где-нибудь прописаны буквами по белому.

Суть в чём. У каждого вида контента/продукта есть своя задача. Задача книжки/постановки/игры – развлечь, увлечь, обучить, поделиться какими-то мировоззренческими максимами. Задача сервиса/софта/приложения – решить какую-то задачу, опять же помочь, развлечь, научить…

НО задача синопсиса/заявки/презы о продукте – НЕ та же самая, что задача самого продукта.

Продукт/контент предназначен конечному пользователю: зрителю, читателю, геймерю, юзеру.

А вот заявка/синопсис/преза предназначены не конечным пользователям, а людям, которые могут помочь проекту/продукту состояться. Этих людей не нужно убеждать почитать-поиграть-посмотреть. Их нужно убедить поспособствовать реализации проекта. Им нужно объяснить, почему и нафига этот проект нужен миру, чё нового-интересного-важного он принесёт (а мб даже окупится).

Для аргументации такого уровня требуется не завлекательная, а сугубо техническая информация. Объёмная, внятая, без ужимок, соплей и недосказанностей.

Категорически нихть совершенно фу брось каку не нужно и очень вредно составлять синопсисы/заявки так, как составляют аннотации.

По заявке/презе должно быть ясно, кто аудитория проекта, и чем чётче она определена, тем лучше. Т.е. «Все, кто интересуется рыбалкой» – плохо. «Круглогодичные рыбаки выходного дня 40+ из Мурманска и области» – хорошо. «Посетители Литсайта» – плохо. «Читатели 16-25 полу женского с достатком средним и низким» – ок.

Если это заявка на софт, то должно быть ясно, какие конкретно задачи он закрывает и почему он это делает быстрее/удобнее/ёмче, чем аналогичные софты. С цифрами, фактами, графиками, а не «Клянусь мамой Гиппократа» и обилием лозунгов.

Если это заявка на сюжетный контент (книга, фильм, игра, постановка) – должно быть понятно: в каком мире приключается история, по каким законам действует мир. С кем случается история, чего и почему хотят герои, кто и что им мешает. Что будет, если герои проиграют, какими путями они пойдут к цели, какие инструменты/механики могут использовать, чем дело закончится (в случае ветвистых концовок – какие есть варианты финала).

В заявке/синопсисе нет понятия «спойлер» – все вопросы, включая сюжетные, должны быть закрыты.

Оценочные суждения («загадочные и странные события») нужно выкинуть в мусор, а вместо этого пояснить буквами: чо конкретно происходит в истории.

Прилагательные в превосходной степени можно засунуть в шредер – совершенно ни к чему писать в заявке/презе «Это любопытнейшая история / суперполезный софт», нужно составить заявку/презу так, чтобы отборщик сказал: «Воу, это любопытнейшая история» / «Это суперполезный софт» и захотел помочь реализовать проект.

Интересничания, выпукливания глаз и недомаркетологические приёмы («Сможет ли Петрович одолеть Томного Формалина?») нужно сварить и просочить в канализацию – такие вещи даже в аннотациях лишние, а в заявках/синопсисах/презах не нужны никогда и нипочему, там нужен чёткий ответ: сможет Петрович или увы.

При этом крайне желательно прокачать в себя навык отделять критично важные факторы от второстепенных. Если какое-то уточнение, деталь, эпизод, параметр можно выдернуть из общей конструкции и она не рассыпется — значит, этот параметр второстепенный. Значит, он не нужен в заявке. А очень важно, чтобы смыслы в заявке/синопсисе/презентации были подсвечены достаточно, но не избыточно.

Ибо вам же нужно, чтобы вашу заявку изучили, а не чтобы в ней утонули, последним бульком повесив воронку инферно у вас над башкой. Потому решительно оставляйте за скобками абсолютно все второстепенные уточнялки, детали, штрихи, философствования. В крайнем случае затолкайте их куда-нибудь дополнительно, в отдельный файл/папку/пакет с пакетами.

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

Надеюсь, этот крик души кому-нибудь поможет переосмыслить неочевидности, не сейчас, так в будущем :)