Как писать и редактировать тексты о том, чего не понимаешь и при чем тут китайская комната — Офтоп на vc.ru
→ Оригинал (без защиты от корпорастов) | Изображения из статьи: [1]
Я пишу и редачу тексты для IT уже 3 года. В последнее время много приходится работать с текстами от айтишников и для айтишников — хардкорными статьями и переводами на Хабр про машинное обучение, ИИ, Kubernetes и прочие сложные штуки. Хочу поделиться своим опытом и рассказать, как справляться с такими текстами. Тут будет больше про IT, но подход применим к любым сложным темам и текстам для профессионалов.
Зачем вообще нужен тот, кто не понимает Казалось бы: не понимаешь — вали писать про то, что понимаешь. Пусть пишут сами специалисты или те, кто решил уйти в редактуру. Но есть несколько нюансов: Те, кто хотят и умеют — пишут сами, и у них получается круто. Гораздо лучше, чем у меня. Но компаниям нужны большие объемы текстов, поэтому и требуются авторы и редакторы, которые возьмут интервью и упакуют все в нормальный текст. Мне часто говорят «Я бы хотел писать тексты, но совершенно нет времени». Или «Спасибо, я бы так связно точно не написал». То есть потребность в том, кто не понимает в теме, но понимает в текстах — есть.
В чем проблема: полноценно понять невозможно Чаще всего копирайтеры пишут тексты о чем-то для клиентов, которые не разбираются в теме. В таком случае разобраться можно, если поболтать со специалистами и покопаться в источниках. Например, если ваша компания продает клиентам VPN, можно понять в общих чертах, как он работает, куда отправлять трафик, что и как шифрует. Для уровня дилетанта вашего понимания хватит. Другое дело, если вам нужно писать тексты для технически подкованной аудитории. Они знают, что такое VPN и как он работает — их интересуют нюансы, используемые технологии, какие-то практические фишки и тому подобная глубина. Чтобы разобраться в этом на их уровне, вам понадобятся месяцы и годы реальной практики, что для автора и редактора технически невозможно. Предположим, вы все-таки разобрались в теме VPN. Но вот вам уже надо написать статью про Kubernetes. Или про специфическую библиотеку для Python. Или про подход MLOps в машинном обучении. Разобраться в каждом — не хватит жизни. Надо действовать по-другому.
Когда я редактировала эту расшифровку, я вообще ничего не понимала в теме. Но получилось вроде ОК =)
Что делать: стать «китайской комнатой» Существует мысленный философский эксперимент, названный китайской комнатой. Представим комнату, в которой сидит человек, не знающий китайского. У него в комнате есть инструкция — при получении таких-то иероглифов набери такие-то и такие-то. Он получает что-то, не понимает этого, набирает ответ по инструкции и выдает его. А снаружи сидит человек, знающий китайский. Он отправляет в комнату вопрос и получает из нее ответ. И если инструкция внутри достаточно подробная, то ответ получится осмысленный, хотя отвечающий понятия не имеет ни о вопросе, ни об ответе. Редактируя текст по не совсем понятной тебе теме, ты становишься той самой «китайской комнатой» — последовательно применяешь знакомые тебе паттерны редактуры к тому, что не совсем понимаешь. На выходе должно получаться осмысленно и лучше, чем было «до». Тогда ты хорошая «китайская комната». Конечно, отличий от китайской комнаты полно. Нужно многое понимать, правила выработал ты сам, а твою работу потом проверят. Но общие принципы довольно близки, и мне просто нравится думать о своей работе как о чем-то, похожем на прикольный философский эксперимент. Я выделила для себя несколько правил, которые помогают мне быть хорошей «китайской комнатой».
Набить руку в написании и редактуре текстов Важно базово быть хорошим специалистом: уметь писать емко, четко, без воды, полезно и интересно для читателя. Насмотренность на большое количество текстов поможет правильно составлять предложения даже из слов, которые вы не полностью понимаете — просто на основе их окончаний и понимания общей структуры текста. Это как в лингвистической сказке: «Сяпала Калуша с Калушатами по напушке, и увазила бутявку». Или у Кэррола «Варкалось. Хливкие шорьки пырялись по наве, и хрюкотали зелюки, как мюмзики в мове». Непонятно, но вы понимаете, что грамматически полностью верно. В нехудожественном тексте это чуть сложнее, но опыт в редактуре поможет правильно сокращать и структурировать неструктурированное.
Если вы не разбираетесь в Kubernetes, то многие слова тут, очевидно, вам непонятны. Но видно, что текст после редактуры структурирован лучше и читается легче
Разобраться в самых основах темы Работать, вообще не понимая терминов, все-таки очень тяжело. Чтобы выстраивать схемы и не нарушить логику повествования, нужно хотя бы на уровне дилетанта понимать: Чтобы разобраться, стоит почитать статьи в интернете или немного позадавать эксперту банальных вопросов. Вообще без понимания вы, вероятнее всего, облажаетесь. Мне на старте работы помогала неоконченная вышка в IT — я хоть знала, как в интернете ходят пакеты (и что это не пакеты из пятерочки), как выглядит интерфейс IDE для программирования и чем реально занимается программист. Но сейчас про это все есть миллион статей в интернете от тех, кто делает курсы для айтишников, так что разобраться не проблема. В других сферах, наверное, посложнее, но тоже можно. У себя в телеграм-канале про редактуру в IT я начала вести IT-словарь, где публикую самые важные основные термины, стараясь описать их простым языком. Если планируете писать для IT, заглядывайте, с основами точно разобраться будет проще.
Спрашивать экспертов, но не перебарщивать Любой текст для экспертов вы будете писать с другим экспертом — иначе никак. Вы не сможете сами рассказать хардкорным программистам о новой технологии хардкорного программирования — нужен будет другой хардкорный программист. Обычно эксперт дает интервью, набрасывает что-то текстом сам, либо проводит вебинар, а вы потом на его основе что-то пишете. В таком случае при особых непонятках эксперту можно задать вопрос. Но тут важно не переборщить — мы помним, что эксперт занятой, а его время дорого. Я задаю вопросы, если: В остальных случаях обычно спускаю на тормозах — если что, эксперт поправит потом. Он все равно будет смотреть статью после написания и потратит на это время.
Не упрощать Когда пишешь для нетехнической аудитории, нужно стараться описать все так, чтобы и ребенку было понятно. В текстах для профессионалов этот подход категорически не подходит. Если вы пишете статью о том, как внедрили Kubernetes в технически сложных условиях, ни дай бог вам рассказывать, что Kubernetes вообще такое, и разжевывать каждый шаг — вас никто не станет читать. В сложной теме нормально, если вы не поняли, о чем текст. И даже если главный редактор не понял. Главное, чтобы поняли эксперты.
Тут мне даже со схемой не стало сильно понятнее. Но пояснять все процессы и каждый элемент не нужно — аудитория читателей и так знает, что тут происходит
Дать эксперту проверить текст после вас Это ключевой и самый важный момент. Без него, скорее всего, получится какая-то фигня, не имеющая отношения к реальности, с фактическими ошибками или серьезными ляпами. Эксперт прочитает текст, выделит ошибочные моменты, и потом уже скажет «Да, теперь все верно, так и есть. Это то, что я хотел сказать». То есть вы сможете однозначно быть уверены, что не написали фигню, и это текст от эксперта для экспертов. Вы — просто «китайская комната», которая помогла донести текст от первого ко вторым.
Сам эксперимент относится к вопросам искусственного интеллекта и всего такого, почитайте подробнее в википедии, если хотите, штука интересная. Но я хочу порассуждать о ней в рамках редактуры.