{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Как писать и редактировать тексты о том, чего не понимаешь и при чем тут китайская комната

Я пишу и редачу тексты для IT уже 3 года. В последнее время много приходится работать с текстами от айтишников и для айтишников — хардкорными статьями и переводами на Хабр про машинное обучение, ИИ, Kubernetes и прочие сложные штуки. Хочу поделиться своим опытом и рассказать, как справляться с такими текстами. Тут будет больше про IT, но подход применим к любым сложным темам и текстам для профессионалов.

Зачем вообще нужен тот, кто не понимает

Казалось бы: не понимаешь — вали писать про то, что понимаешь. Пусть пишут сами специалисты или те, кто решил уйти в редактуру. Но есть несколько нюансов:

  • Специалисты писать не хотят. Их время очень дорого, и они могут ответить на пару вопросов или потом проглядеть готовый текст. Но тратить часы на его написание — нет. Разве что компания заплатит, но это часто будет сильно дорого.
  • Специалисты писать не умеют. Можно быть крутым программистом или девопсом, но не очень внятно складывать слова в предложения. Я замечала, как в статьях от классных инженеров скачет мысль, пропадают логические связи, какие-то моменты остаются откровенно непонятными вообще никому, появляется какой-то страшный канцелярит, через который не продраться.. Причем устно они часто изъясняются прекрасно, но когда дело доходит до текста — что-то ломается. Писать — тоже навык, и он есть не у всех.
  • Уходить в редактуру им нет смысла. Это особенно касается IT — если ты уже крутой программист, смысл тебе становиться редактором. Программистом заработаешь наверняка больше.

Те, кто хотят и умеют — пишут сами, и у них получается круто. Гораздо лучше, чем у меня. Но компаниям нужны большие объемы текстов, поэтому и требуются авторы и редакторы, которые возьмут интервью и упакуют все в нормальный текст.

Мне часто говорят «Я бы хотел писать тексты, но совершенно нет времени». Или «Спасибо, я бы так связно точно не написал». То есть потребность в том, кто не понимает в теме, но понимает в текстах — есть.

В чем проблема: полноценно понять невозможно

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

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

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

Когда я редактировала эту расшифровку, я вообще ничего не понимала в теме. Но получилось вроде ОК =)

Что делать: стать «китайской комнатой»

Существует мысленный философский эксперимент, названный китайской комнатой. Представим комнату, в которой сидит человек, не знающий китайского. У него в комнате есть инструкция — при получении таких-то иероглифов набери такие-то и такие-то. Он получает что-то, не понимает этого, набирает ответ по инструкции и выдает его. А снаружи сидит человек, знающий китайский. Он отправляет в комнату вопрос и получает из нее ответ. И если инструкция внутри достаточно подробная, то ответ получится осмысленный, хотя отвечающий понятия не имеет ни о вопросе, ни об ответе.
Сам эксперимент относится к вопросам искусственного интеллекта и всего такого, почитайте подробнее в википедии, если хотите, штука интересная. Но я хочу порассуждать о ней в рамках редактуры.

Редактируя текст по не совсем понятной тебе теме, ты становишься той самой «китайской комнатой» — последовательно применяешь знакомые тебе паттерны редактуры к тому, что не совсем понимаешь. На выходе должно получаться осмысленно и лучше, чем было «до». Тогда ты хорошая «китайская комната».

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

Я выделила для себя несколько правил, которые помогают мне быть хорошей «китайской комнатой».

Набить руку в написании и редактуре текстов

Важно базово быть хорошим специалистом: уметь писать емко, четко, без воды, полезно и интересно для читателя. Насмотренность на большое количество текстов поможет правильно составлять предложения даже из слов, которые вы не полностью понимаете — просто на основе их окончаний и понимания общей структуры текста.

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

Если вы не разбираетесь в Kubernetes, то многие слова тут, очевидно, вам непонятны. Но видно, что текст после редактуры структурирован лучше и читается легче

Разобраться в самых основах темы

Работать, вообще не понимая терминов, все-таки очень тяжело. Чтобы выстраивать схемы и не нарушить логику повествования, нужно хотя бы на уровне дилетанта понимать:

  • как устроена система, которую вы описываете;
  • какие в ней есть компоненты, что они примерно делают;
  • как компоненты взаимодействуют друг с другом.

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

Мне на старте работы помогала неоконченная вышка в IT — я хоть знала, как в интернете ходят пакеты (и что это не пакеты из пятерочки), как выглядит интерфейс IDE для программирования и чем реально занимается программист. Но сейчас про это все есть миллион статей в интернете от тех, кто делает курсы для айтишников, так что разобраться не проблема. В других сферах, наверное, посложнее, но тоже можно.

У себя в телеграм-канале про редактуру в IT я начала вести IT-словарь, где публикую самые важные основные термины, стараясь описать их простым языком. Если планируете писать для IT, заглядывайте, с основами точно разобраться будет проще.

Спрашивать экспертов, но не перебарщивать

Любой текст для экспертов вы будете писать с другим экспертом — иначе никак. Вы не сможете сами рассказать хардкорным программистам о новой технологии хардкорного программирования — нужен будет другой хардкорный программист.

Обычно эксперт дает интервью, набрасывает что-то текстом сам, либо проводит вебинар, а вы потом на его основе что-то пишете. В таком случае при особых непонятках эксперту можно задать вопрос. Но тут важно не переборщить — мы помним, что эксперт занятой, а его время дорого.

Я задаю вопросы, если:

  • Какой-то термин или слово сказаны неразборчиво, и не очень понятно, о чем речь.
  • Предложение или абзац никак не выстраиваются логически, получается какая-то ерунда.
  • Нужно нарисовать какую-то объясняющую схему.

В остальных случаях обычно спускаю на тормозах — если что, эксперт поправит потом. Он все равно будет смотреть статью после написания и потратит на это время.

Не упрощать

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

В сложной теме нормально, если вы не поняли, о чем текст. И даже если главный редактор не понял. Главное, чтобы поняли эксперты.

Тут мне даже со схемой не стало сильно понятнее. Но пояснять все процессы и каждый элемент не нужно — аудитория читателей и так знает, что тут происходит

Дать эксперту проверить текст после вас

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

0
104 комментария
Написать комментарий...
Куляшова Наталья

А еще бывает, что попадаются супер-классные эксперты, которые умеют понятно объяснять. И ты вроде бы в сложной теме, но ПОНИМАЕШЬ, потому что тебе по полочкам разложили и подвели к этому пониманию. Но это особенный дар, конечно, и не нужно надеяться, что все эксперты будут такими.

Статья огонь, спасибо!

Ответить
Развернуть ветку
Denis Zotov

Как сказал один мой коллега, чем "старше" (по уровню) инженер, тем больше ему приходится писать текстов и тем меньше - кода. "Младшие" разработчики пишут код для систем, а "старшие" - "код" для людей.

Ответить
Развернуть ветку
101 комментарий
Раскрывать всегда