#плохиетексты Яркий пример того, что на Хабре нужно очень осторожно писать простые руководства
https://habr.com/ru/company/otus/blog/582862/
Этот текст сам по себе не плохой — он просто раскрывает тему очень и очень поверхностно. В результате читатели не находят нужной для себя информации, ставят минусы и пишут негативные комменты. Дополнительным минусом такой поверхностности стала ссылка на курс «C# Developer». Что же там будут преподавать, если публикуются такие переводы.
Как не допускать таких ошибок:
1. Писать «сериалы». Если читатель понимает, что конкретная статья — это только кусочек информации по теме, а все остальные аспекты вы раскроете в следующих публикациях, то негатива не будет. Можно даже наводящими вопросами по тексту собирать обратную связь, таким образом формируя новую статью.
2. Раскрывать в статье только одну тему. Например, в данном случае статья бы называлась не «String.Format в C# — все, что вам нужно знать», а «Как использовать String.Format в C# для преобразований даты и времени». И в ней раскрывались всевозможные примеры таких преобразований, разбирались ошибки и т.д.
https://habr.com/ru/company/otus/blog/582862/
Этот текст сам по себе не плохой — он просто раскрывает тему очень и очень поверхностно. В результате читатели не находят нужной для себя информации, ставят минусы и пишут негативные комменты. Дополнительным минусом такой поверхностности стала ссылка на курс «C# Developer». Что же там будут преподавать, если публикуются такие переводы.
Как не допускать таких ошибок:
1. Писать «сериалы». Если читатель понимает, что конкретная статья — это только кусочек информации по теме, а все остальные аспекты вы раскроете в следующих публикациях, то негатива не будет. Можно даже наводящими вопросами по тексту собирать обратную связь, таким образом формируя новую статью.
2. Раскрывать в статье только одну тему. Например, в данном случае статья бы называлась не «String.Format в C# — все, что вам нужно знать», а «Как использовать String.Format в C# для преобразований даты и времени». И в ней раскрывались всевозможные примеры таких преобразований, разбирались ошибки и т.д.
Про истории в ИТ-текстах
Я, конечно, очень сильно загружен в Yandex.Cloud, но периодически беру сторонние проекты. Чаще всего это некоторый контент-консалтинг или редактура текстов для Хабра и VC. Такие задачи помогают переключиться, да и просто наработать новый опыт, который может помочь в Яндексе.
Большинство текстов, с которыми приходит ИТ-компании, — это мануалы, написанные разработчиками, или кейсы, которые собрали в PR. Кажется, что это разные направления, но проблема у них обычно одна — отсутствует история. В мануалах рассказывается, как с помощью некоторых инструментов и команд что-то реализовать, но совершенно не даётся информация о том, как пришли к этому решению. В кейсах очень много данных про сам «продукт» и чем он может быть полезен, но очень поверхностно про его разработку, проблемы, муки выбора и всё остальное.
Это, конечно, моё личное мнение и личный опыт, но я уверен, что любой ИТ-текст лучше всего рассказывать в формате истории. Даже релиз продукта или продающую презентацию лучше всего строить таким образом, чтобы читатель мог выстроить у себя в голове определённую логику повествования. Вступление, проблема, выбор правильного решения, реализация, развитие, заключение. Правильно написанная история, даже если она на 70% состоит из строчек кода, даст возможность читателю соотнести свой собственный опыт с написанным рассказом.
Конечно, и тут стоит повториться, это моё мнение и всего лишь один способ написать хороший текст. На Хабре периодически отлично заходят, например, простые инструкции, а на VC — реклама, но если вы хотите рассказать не про что-то очень редкое и крутое, то добавить в статью хорошую историю будет очень правильно.
Я, конечно, очень сильно загружен в Yandex.Cloud, но периодически беру сторонние проекты. Чаще всего это некоторый контент-консалтинг или редактура текстов для Хабра и VC. Такие задачи помогают переключиться, да и просто наработать новый опыт, который может помочь в Яндексе.
Большинство текстов, с которыми приходит ИТ-компании, — это мануалы, написанные разработчиками, или кейсы, которые собрали в PR. Кажется, что это разные направления, но проблема у них обычно одна — отсутствует история. В мануалах рассказывается, как с помощью некоторых инструментов и команд что-то реализовать, но совершенно не даётся информация о том, как пришли к этому решению. В кейсах очень много данных про сам «продукт» и чем он может быть полезен, но очень поверхностно про его разработку, проблемы, муки выбора и всё остальное.
Это, конечно, моё личное мнение и личный опыт, но я уверен, что любой ИТ-текст лучше всего рассказывать в формате истории. Даже релиз продукта или продающую презентацию лучше всего строить таким образом, чтобы читатель мог выстроить у себя в голове определённую логику повествования. Вступление, проблема, выбор правильного решения, реализация, развитие, заключение. Правильно написанная история, даже если она на 70% состоит из строчек кода, даст возможность читателю соотнести свой собственный опыт с написанным рассказом.
Конечно, и тут стоит повториться, это моё мнение и всего лишь один способ написать хороший текст. На Хабре периодически отлично заходят, например, простые инструкции, а на VC — реклама, но если вы хотите рассказать не про что-то очень редкое и крутое, то добавить в статью хорошую историю будет очень правильно.
Книги, которые нужно прочитать начинающему ИТ-редактору. Часть 1
1. «Совершенный код. Мастер-класс» Стив Макконнелл
Общий взгляд на конструирование и разработку ПО. Очень много полезной информации о методиках, тестировании, отладке, рефакторинге и многом другом.
2. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему.» Джин Ким
Просто, доступно и в лёгкой художественной форме про методологию DevOps. Вы же точно не будете читать манифест по девопсу?
3. Microsoft Russian Style Guide — руководство по стилю от Microsoft: как правильно называть элементы, какие формулировки лучше использовать и т.д.
1. «Совершенный код. Мастер-класс» Стив Макконнелл
Общий взгляд на конструирование и разработку ПО. Очень много полезной информации о методиках, тестировании, отладке, рефакторинге и многом другом.
2. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему.» Джин Ким
Просто, доступно и в лёгкой художественной форме про методологию DevOps. Вы же точно не будете читать манифест по девопсу?
3. Microsoft Russian Style Guide — руководство по стилю от Microsoft: как правильно называть элементы, какие формулировки лучше использовать и т.д.
Как копирайтеру прийти в ИТ
Я не берусь, конечно, говорить за весь рынок копирайтеров, исследований не делал, но по собственному ощущению и количеству поступающих сообщений могу констатировать следующее:
1. Большое количество копирайтеров сейчас остались без работы. Люди активно пишут, интересуются вакансиями, берут тестовые задания.
2. В ИТ и околоИТ дефицит хороших авторов. В лучшем случае 25% выданных тестовых возвращаются, из них единицы можно нанимать сразу. Но скорее всего нужно быть готовым, что человека придётся ещё обучать. Параллельно очень много сообщений от ИТ-компаний, которые ищут авторов.
Как же перейти на работу с ИТ-компаниями? Тут можно выделить несколько проблем, которые я отмечаю у авторов:
1. Отсутствие написанных текстов по определённым тематикам, реализованных проектов и т.д. Понятно, что любой компании или агентству нужен более менее готовый человек с каким-то портфолио. Но где их взять, если на работу никто не берёт?
2. Отсутствие желания учиться и собирать информацию. Например, я часто даю тестовое задание написать кейс по видео. И самая распространённая ошибка в таком случае — это сделать траскрибацию. Я, конечно, оцениваю, что человек правильно перевёл аудио в текст и не ошибся в терминах (и даже порекомендую такого человека коллегам), но задача всё равно не выполнена.
Что делать:
1. Начинайте вести блог на Хабре, VC и любой другой площадке. Пишите обзоры, разбирайте новости, работайте с комментами. Во-первых, это позволит вам понять специфики площадок и научиться писать тексты, которые понравятся конкретной аудитории. Во-вторых, вас могут заметить представители компаний и пригласить писать тексты для них.
2. Привыкайте, что классический вариант «насобирал текстов из интернета и скомпоновал свою версию» может не работать. Скорее всего вам придётся попробовать что-то сделать своими руками, разобраться в технологии хотя бы на минимальном уровне.
3. Найдите своего редактора. Человека, который прочитает ваш текст и не только скажет, что он отвратительный, но и расскажет почему. Частично такого фидбека можно добиться комментами, но всё-таки желательно, чтобы иногда ваш текст разбирали от начала и до конца, правили логику, объясняли ошибки.
Удачи. Я снова начинаю вести этот канал и развивать тему «обучения редакторов». Да, обещал давно, но я не инфоцыган, чтобы надёргать банальностей из интернета и «прогревать курс», так что хочется сделать классный и полезный продукт.
Я не берусь, конечно, говорить за весь рынок копирайтеров, исследований не делал, но по собственному ощущению и количеству поступающих сообщений могу констатировать следующее:
1. Большое количество копирайтеров сейчас остались без работы. Люди активно пишут, интересуются вакансиями, берут тестовые задания.
2. В ИТ и околоИТ дефицит хороших авторов. В лучшем случае 25% выданных тестовых возвращаются, из них единицы можно нанимать сразу. Но скорее всего нужно быть готовым, что человека придётся ещё обучать. Параллельно очень много сообщений от ИТ-компаний, которые ищут авторов.
Как же перейти на работу с ИТ-компаниями? Тут можно выделить несколько проблем, которые я отмечаю у авторов:
1. Отсутствие написанных текстов по определённым тематикам, реализованных проектов и т.д. Понятно, что любой компании или агентству нужен более менее готовый человек с каким-то портфолио. Но где их взять, если на работу никто не берёт?
2. Отсутствие желания учиться и собирать информацию. Например, я часто даю тестовое задание написать кейс по видео. И самая распространённая ошибка в таком случае — это сделать траскрибацию. Я, конечно, оцениваю, что человек правильно перевёл аудио в текст и не ошибся в терминах (и даже порекомендую такого человека коллегам), но задача всё равно не выполнена.
Что делать:
1. Начинайте вести блог на Хабре, VC и любой другой площадке. Пишите обзоры, разбирайте новости, работайте с комментами. Во-первых, это позволит вам понять специфики площадок и научиться писать тексты, которые понравятся конкретной аудитории. Во-вторых, вас могут заметить представители компаний и пригласить писать тексты для них.
2. Привыкайте, что классический вариант «насобирал текстов из интернета и скомпоновал свою версию» может не работать. Скорее всего вам придётся попробовать что-то сделать своими руками, разобраться в технологии хотя бы на минимальном уровне.
3. Найдите своего редактора. Человека, который прочитает ваш текст и не только скажет, что он отвратительный, но и расскажет почему. Частично такого фидбека можно добиться комментами, но всё-таки желательно, чтобы иногда ваш текст разбирали от начала и до конца, правили логику, объясняли ошибки.
Удачи. Я снова начинаю вести этот канал и развивать тему «обучения редакторов». Да, обещал давно, но я не инфоцыган, чтобы надёргать банальностей из интернета и «прогревать курс», так что хочется сделать классный и полезный продукт.
Попросили дать комментарий про то, какие направления сейчас будут востребованы в ИТ-копирайтинге. Нафантазировал следующее, публикую без сокращений:
1. HR-бренд. Развитие и продвижение HR-бренда через публикации на Хабре, VC, RB и подобных сайтах и раньше было важным направлением, а сейчас станет чуть ли не самым приоритетным. Айтишники продолжат эмигрировать. Часть народа, конечно, вернётся со временем, но это не решение кадровых проблем в ИТ-компаниях. Следовательно, нужны будут авторы, которые смогут самостоятельно проводить интервью с тимлидами, разбираться в технологиях и писать качественные тексты. Не рекламные, конечно, но очень нативно и через пользу для читателей заманивающие в штат.
2. Инструкции. Точнее «продвижение софта и сервисов через инструкции». Уход многих иностранных сервисов из России заставляет наши компании менять свои бизнес и рабочие процессы. А разработчики, которые предлагают аналогичный софт и сервисы, сейчас стараются любым способом обратить на себя внимание. Следовательно, нужны будут авторы, которые смогут самостоятельно писать полезные инструкции.
3. Презентации, лендинги, SEO. Эти направления и раньше были востребованы, а сейчас я бы ожидал «большого взрыва». Заблокированы многие соцсети, прекращают работу СМИ, а значит надо вкладываться в собственные площадки, развивать и продвигать их в поиске. Следовательно, нужны будут авторы, которые не только умеют кратко и по делу описывать сложные технологии, но и разбираться в бизнес-процессах, а также самостоятельно верстать лендинги.
Напоследок спросили, что сейчас делать копирайтерам. Ответил одним словом: «Учиться!».
1. HR-бренд. Развитие и продвижение HR-бренда через публикации на Хабре, VC, RB и подобных сайтах и раньше было важным направлением, а сейчас станет чуть ли не самым приоритетным. Айтишники продолжат эмигрировать. Часть народа, конечно, вернётся со временем, но это не решение кадровых проблем в ИТ-компаниях. Следовательно, нужны будут авторы, которые смогут самостоятельно проводить интервью с тимлидами, разбираться в технологиях и писать качественные тексты. Не рекламные, конечно, но очень нативно и через пользу для читателей заманивающие в штат.
2. Инструкции. Точнее «продвижение софта и сервисов через инструкции». Уход многих иностранных сервисов из России заставляет наши компании менять свои бизнес и рабочие процессы. А разработчики, которые предлагают аналогичный софт и сервисы, сейчас стараются любым способом обратить на себя внимание. Следовательно, нужны будут авторы, которые смогут самостоятельно писать полезные инструкции.
3. Презентации, лендинги, SEO. Эти направления и раньше были востребованы, а сейчас я бы ожидал «большого взрыва». Заблокированы многие соцсети, прекращают работу СМИ, а значит надо вкладываться в собственные площадки, развивать и продвигать их в поиске. Следовательно, нужны будут авторы, которые не только умеют кратко и по делу описывать сложные технологии, но и разбираться в бизнес-процессах, а также самостоятельно верстать лендинги.
Напоследок спросили, что сейчас делать копирайтерам. Ответил одним словом: «Учиться!».
КАК НАЧАТЬ, ЧТОБЫ ДЕСЯТЬ РАЗ НЕ ПЕРЕПИСЫВАТЬ
«Напишите план и тезисы.» Так нас учили в школе и на таком же начале настаивают большинство редакторов. Отчасти, конечно, это правильный подход, который помогает на раннем этапе структурировать текст и задать правильные векторы для автора. Но почему тогда так много итераций правок и комментариев? Автор плохой?
Может быть. Но скорее всего проблема в том, что на самом раннем этапе точно никто не сказал, о чём будет этот текст и на какую аудиторию он рассчитан. Расскажу на примере бизнес-кейсов облачного сервиса Yandex SpeechKit.
Речевые технологии используются огромным количеством компаний для создания собственных голосовых помощников, колл-центров, контроля продажников и много чего ещё. При этом SpeechKit находиться обычно «под капотом» этих сервисов. И вот есть реализованный кейс, собрана фактура, автор пишет текст для сайта, и я понимаю — всё хорошо, но совершенно нет логики, не понятно для кого всё это написано. А ведь был план, чёткая структура… Дело всего лишь в том, что в данной статье есть очень много информации про реализованному кейсу, но очень мало про речевые технологии. Есть цифры, есть факты, но ведь это статья на сайт облачной платформы. Да, нам важно подсветить успехи клиента №1, но также нужно, чтобы другой перспективный клиент №2 захотел себе речевые технологии, а не команду разработчиков клиента №1. 😈 Обратная ситуация — статья о том же кейсе на VC или RB. Там акцент как раз должен быть на бизнесе и достижениях клиента, и только вскользь про технологии.
Нулевой этап подготовки текста — это понимание его ценности для бизнеса, выбор фокуса в зависимости от площадки для публикации и аудитории, построение логики. А уже только потом пишем план и тезисы.
Но для начала расскажу про то, как определить ценность, фокус и логику…
P.S.: Решил публиковать части большого материала, который по идее воплотиться в методичку и курс.
«Напишите план и тезисы.» Так нас учили в школе и на таком же начале настаивают большинство редакторов. Отчасти, конечно, это правильный подход, который помогает на раннем этапе структурировать текст и задать правильные векторы для автора. Но почему тогда так много итераций правок и комментариев? Автор плохой?
Может быть. Но скорее всего проблема в том, что на самом раннем этапе точно никто не сказал, о чём будет этот текст и на какую аудиторию он рассчитан. Расскажу на примере бизнес-кейсов облачного сервиса Yandex SpeechKit.
Речевые технологии используются огромным количеством компаний для создания собственных голосовых помощников, колл-центров, контроля продажников и много чего ещё. При этом SpeechKit находиться обычно «под капотом» этих сервисов. И вот есть реализованный кейс, собрана фактура, автор пишет текст для сайта, и я понимаю — всё хорошо, но совершенно нет логики, не понятно для кого всё это написано. А ведь был план, чёткая структура… Дело всего лишь в том, что в данной статье есть очень много информации про реализованному кейсу, но очень мало про речевые технологии. Есть цифры, есть факты, но ведь это статья на сайт облачной платформы. Да, нам важно подсветить успехи клиента №1, но также нужно, чтобы другой перспективный клиент №2 захотел себе речевые технологии, а не команду разработчиков клиента №1. 😈 Обратная ситуация — статья о том же кейсе на VC или RB. Там акцент как раз должен быть на бизнесе и достижениях клиента, и только вскользь про технологии.
Нулевой этап подготовки текста — это понимание его ценности для бизнеса, выбор фокуса в зависимости от площадки для публикации и аудитории, построение логики. А уже только потом пишем план и тезисы.
Но для начала расскажу про то, как определить ценность, фокус и логику…
P.S.: Решил публиковать части большого материала, который по идее воплотиться в методичку и курс.
Про пресс-релизы
Пожалуйста, не пишите такие конструкции, как «мы объединили свою экспертизу, чтобы создать гаджет-сервис, который добавляет новую функциональность в пользовательский опыт»? Это прям маркетинговый буллшит бинго. Если руки чешутся использовать эти фразы, то вынесите их в цитату от спикера, а в самом тексте только тот самый пресловутый инфостиль и цифры, которые можно использовать в публикациях.
Про видео
Пожалуйста, проверяйте тексты к роликам про ИТ у грамотного редактора и (или) технаря. Понимаю, что такие конструкции, как «вы научитесь программировать на html и css» выглядят осмысленно и, наверное, привлекут внимание простого пользователя. Но, чёрт побери, любой мало-мальски понимающий человек после этой фразы не сможет относиться серьёзно как к самому ролику, так и компании, которая его выпустила.
#душнилаonoff
Пожалуйста, не пишите такие конструкции, как «мы объединили свою экспертизу, чтобы создать гаджет-сервис, который добавляет новую функциональность в пользовательский опыт»? Это прям маркетинговый буллшит бинго. Если руки чешутся использовать эти фразы, то вынесите их в цитату от спикера, а в самом тексте только тот самый пресловутый инфостиль и цифры, которые можно использовать в публикациях.
Про видео
Пожалуйста, проверяйте тексты к роликам про ИТ у грамотного редактора и (или) технаря. Понимаю, что такие конструкции, как «вы научитесь программировать на html и css» выглядят осмысленно и, наверное, привлекут внимание простого пользователя. Но, чёрт побери, любой мало-мальски понимающий человек после этой фразы не сможет относиться серьёзно как к самому ролику, так и компании, которая его выпустила.
#душнилаonoff
Ещё до Яндекса на различных проектах я часто сталкивался с таким требованием к тексту, как «высокая уникальность». Руководствуясь каким-то стандартами, меня просили довести статью до такого состояния, чтобы различные сервисы антиплагиата показывали максимум 5-7% заимствования. Доходило до маразма, когда мне пришлось несколько раз переписывать записанное мной интервью. Человек рассказывал про одну технологию, и его прямая речь оказалось очень похожей на уже опубликованную статью из интернета. Допускаю, что он что-то цитировал по памяти, но всё же. В другой ситуации рерайт написанного текста из-за проверки на плагиат очень сильно потерял как в красоте, так и в смысле.
Я, конечно, против прямого воровства контента. Но стоит иметь в виду, что в ИТ многие технологии описаны множество раз. Сколько статей вы найдёте по запросу «postgresql»? Сотни? Тысячи? Но мы всё равно продолжаем писать про эту СУБД в контексте собственных проектов и продуктов. И неизменно затрагиваем описание самой технологии, чтобы читателю не приходилось отвлекаться на поиск в интернете того, что ему может быть непонятно. Реально ли написать 1001 раз про PostgreSQL так, чтобы нигде не повториться? Конечно, нет.
Используйте все доступные материалы, компонуйте их между собой, переписывайте, но не старайтесь добиться каких-то процентов уникальности. Более того, если вы не очень хорошо разбираетесь в конкретной технологии, то в процессе доведения до мифического совершенства очень легко допустить такие ошибки, за которые вас комьюнити, например, Хабра очень быстро распнёт. А с таким трудом написанная статья получит столько минусов, что вы эту карму очень долго будете отрабатывать.
Я, конечно, против прямого воровства контента. Но стоит иметь в виду, что в ИТ многие технологии описаны множество раз. Сколько статей вы найдёте по запросу «postgresql»? Сотни? Тысячи? Но мы всё равно продолжаем писать про эту СУБД в контексте собственных проектов и продуктов. И неизменно затрагиваем описание самой технологии, чтобы читателю не приходилось отвлекаться на поиск в интернете того, что ему может быть непонятно. Реально ли написать 1001 раз про PostgreSQL так, чтобы нигде не повториться? Конечно, нет.
Используйте все доступные материалы, компонуйте их между собой, переписывайте, но не старайтесь добиться каких-то процентов уникальности. Более того, если вы не очень хорошо разбираетесь в конкретной технологии, то в процессе доведения до мифического совершенства очень легко допустить такие ошибки, за которые вас комьюнити, например, Хабра очень быстро распнёт. А с таким трудом написанная статья получит столько минусов, что вы эту карму очень долго будете отрабатывать.
Половина всех запросов от ИТ-компаний лично ко мне сейчас — это Хабр. Публикации на этой площадке очень важны как для продаж, так и для формирования бренда и найма новых сотрудников. Однако у большинства совершенно нет контента для Хабра и, как правило, происходит следующий диалог:
— Мы сейчас покупаем блог на Хабре и хотим публиковать посты.
— Хорошо. Какие? Есть темы? Есть материал?
— Ну, у маркетинга есть идеи, видео с презентаций...
— Так не пойдёт. Нужны технические темы, давайте поговорим с вашим CTO, лидами.
— У них нет времени.
На этом разговор заканчивается. И я бы не стал тратить время на написание этого текста, но листал утром ленту Хабра и нашёл яркий пример «публикации ради публикации». Называется пост «Видео о процессе производства спутниковых терминалов» и... это правда видео и транскрибация с этого видео. Не особо заморачиваясь, они просто вставили видеоролик и скопировали текст его озвучки. Вышло как вышло — эффект даже не нулевой, отрицательный. Хотя саму тему можно было развернуть так, что эта публикация легко бы вошла в топ, особенно в нынешних условиях.
Мораль: ищите авторов не в маркетинге, а среди собственных технарей. И привлекайте грамотных редакторов, чтобы довести полученный текст до ума.
— Мы сейчас покупаем блог на Хабре и хотим публиковать посты.
— Хорошо. Какие? Есть темы? Есть материал?
— Ну, у маркетинга есть идеи, видео с презентаций...
— Так не пойдёт. Нужны технические темы, давайте поговорим с вашим CTO, лидами.
— У них нет времени.
На этом разговор заканчивается. И я бы не стал тратить время на написание этого текста, но листал утром ленту Хабра и нашёл яркий пример «публикации ради публикации». Называется пост «Видео о процессе производства спутниковых терминалов» и... это правда видео и транскрибация с этого видео. Не особо заморачиваясь, они просто вставили видеоролик и скопировали текст его озвучки. Вышло как вышло — эффект даже не нулевой, отрицательный. Хотя саму тему можно было развернуть так, что эта публикация легко бы вошла в топ, особенно в нынешних условиях.
Мораль: ищите авторов не в маркетинге, а среди собственных технарей. И привлекайте грамотных редакторов, чтобы довести полученный текст до ума.
Редакторское про будущее
Заменит ли копирайтеров AI? Да, безусловно. Дело в том, что уже сейчас есть модели, которые позволяют делать прекрасный рерайтинг текстов. Пройдёт совсем немного времени и копирайтеры с журналистами (тут я подразумеваю переписывателей новостей и пресс-релизов) станут куда менее востребованными.
Что делать? Уходить в очень узкопрофильные темы. Модель не напишет сложный технический или медицинский текст. И даже рерайт сделает с большими ошибками по смыслу. Второй вариант развития — редактура. Один коллега недавно, представляя меня клиентам, назвал «входной и выходной точкой в создании текстов». Можно стремиться к этому, потому что любому AI понадобиться контроль на входе и выходе.
В общем, профессия «писателя» никуда не уйдёт. Да, в неё безусловно увеличится порог вхождения и к этому надо начинать готовиться уже сейчас.
Заменит ли копирайтеров AI? Да, безусловно. Дело в том, что уже сейчас есть модели, которые позволяют делать прекрасный рерайтинг текстов. Пройдёт совсем немного времени и копирайтеры с журналистами (тут я подразумеваю переписывателей новостей и пресс-релизов) станут куда менее востребованными.
Что делать? Уходить в очень узкопрофильные темы. Модель не напишет сложный технический или медицинский текст. И даже рерайт сделает с большими ошибками по смыслу. Второй вариант развития — редактура. Один коллега недавно, представляя меня клиентам, назвал «входной и выходной точкой в создании текстов». Можно стремиться к этому, потому что любому AI понадобиться контроль на входе и выходе.
В общем, профессия «писателя» никуда не уйдёт. Да, в неё безусловно увеличится порог вхождения и к этому надо начинать готовиться уже сейчас.
Несколько раз прочитав короткую лекцию «как начать писать про ИТ и для ИТ», я всё-таки додумался записать её и перевести в текст.
Во-первых, без хотя бы какого-то погружения у вас ничего не получится. Как нельзя начать говорить и писать на другом языке без просмотра фильмов, общения и всего остального, так и не получится начать писать технические тексты, если вы не интересуетесь темой. Классический вариант копирайтера «насобирал текстов из поиска, всё срерайтил, ничего не понял, но технари разберутся» совершенно не работает. Я раньше ещё думал, что это рабочая схема для всех, но опыт показал, что нет. Просто так не работает. Вам придётся попробовать что-то сделать своими руками, разобраться в технологии хотя бы на минимальном уровне. Если вы уже в ИТ-компании, замечательно. Общайтесь, просите разъяснить простым языком, как работает какая-либо технология, библиотека, сервис, методология что угодно. Если такой идеальной ситуации не произошло, то, и я сейчас скажу слова, которые не произносил с универа, читайте методички. Удивительно, но факт: аспирантами и профессорами написано очень много методических материалов для студентов по информатике, программированию, системному администрированию и т.д. Как правило, это гора копипасты и воды, но в них есть некоторая структура и подача материала. Плюс часто какие-то проверочные задания. И, если вы только начинаете писать технотексты, для вас такие методички — золото. Ищете на разные темы, читаете, делайте домашки, сдавайте экзамены друзьям. Учитесь!
Во-вторых, хотя всё можно делать одновременно, вам нужна практика. Как я стал редактором. Да просто вёл блог в ЖЖ, потом начал писать для Хабра, попробовал себя в техписательстве, а затем всё закрутилось. Какой из этого можно сделать вывод. Да просто надо начинать писать. В отличие от того времени, сейчас гораздо больше каналов распространения контента. Переписывайте новости для канала в Tg, делайте переводы на Хабр, ведите свой блог на VC, да где угодно. Через некоторое время вас обязательно заметят, предложат написать статью, релиз или пост для соцсеток. Почему так. Да просто вариант «я буду пробоваться на все вакансии и может кто-то возьмёт» не работает. Например, не хватит опыта на тестовое задание или завалитесь на собеседовании. Но если у вас уже есть много материала, который вы написали просто так, то и отношение к вам будет совсем другое. И, конечно, когда вы начнёте пробовать писать для различных площадок, то поймёте их специфику, огребёте много хейта в комментариях, на вас будут ругаться редакторы...
В-третьих, найдите своего редактора. Не самый очевидный совет, так как сразу возникают замечания «надо кого-то искать, как это сделать, кому-то придётся платить и т.д.». Всё понимаю, но, как в любой профессии, на старте всегда нужен человек, который скажет, что вы делаете хорошо, а что говно нет. Вашими редакторами могут стать комментаторы на Хабре или VC, знакомые айтишники или даже специально нанятый для этого человек. Я всегда рассказываю, что очень много почерпнул у своего редактора на Хабре, когда начал писать для их контентной студии. Меня не учили, конечно, но мелкие правки и замечания по логике текста помогли мне понять, что я делаю не так. Ну и, конечно, были моменты, когда я хотел ещё докручивать текст, а редактор останавливал. Это тоже правильно, так как перфекционизм нужно сдерживать.
В заключение хочется сказать, что я всегда рассматривал «копирайтера в ИТ» как отдельную профессию. Вы можете писать смешные, ироничные, захватывающие и даже идеальные рассказы на любую другую тему, но в технотексте это будет «бред же, вода, удали на хрен». Просто потому, что вы не раскрыли тему или наделали множество ошибок по сути. Поэтому, как и в любой другой профессии, начинайте сначала, а потом уже будете объединять скилы.
Во-первых, без хотя бы какого-то погружения у вас ничего не получится. Как нельзя начать говорить и писать на другом языке без просмотра фильмов, общения и всего остального, так и не получится начать писать технические тексты, если вы не интересуетесь темой. Классический вариант копирайтера «насобирал текстов из поиска, всё срерайтил, ничего не понял, но технари разберутся» совершенно не работает. Я раньше ещё думал, что это рабочая схема для всех, но опыт показал, что нет. Просто так не работает. Вам придётся попробовать что-то сделать своими руками, разобраться в технологии хотя бы на минимальном уровне. Если вы уже в ИТ-компании, замечательно. Общайтесь, просите разъяснить простым языком, как работает какая-либо технология, библиотека, сервис, методология что угодно. Если такой идеальной ситуации не произошло, то, и я сейчас скажу слова, которые не произносил с универа, читайте методички. Удивительно, но факт: аспирантами и профессорами написано очень много методических материалов для студентов по информатике, программированию, системному администрированию и т.д. Как правило, это гора копипасты и воды, но в них есть некоторая структура и подача материала. Плюс часто какие-то проверочные задания. И, если вы только начинаете писать технотексты, для вас такие методички — золото. Ищете на разные темы, читаете, делайте домашки, сдавайте экзамены друзьям. Учитесь!
Во-вторых, хотя всё можно делать одновременно, вам нужна практика. Как я стал редактором. Да просто вёл блог в ЖЖ, потом начал писать для Хабра, попробовал себя в техписательстве, а затем всё закрутилось. Какой из этого можно сделать вывод. Да просто надо начинать писать. В отличие от того времени, сейчас гораздо больше каналов распространения контента. Переписывайте новости для канала в Tg, делайте переводы на Хабр, ведите свой блог на VC, да где угодно. Через некоторое время вас обязательно заметят, предложат написать статью, релиз или пост для соцсеток. Почему так. Да просто вариант «я буду пробоваться на все вакансии и может кто-то возьмёт» не работает. Например, не хватит опыта на тестовое задание или завалитесь на собеседовании. Но если у вас уже есть много материала, который вы написали просто так, то и отношение к вам будет совсем другое. И, конечно, когда вы начнёте пробовать писать для различных площадок, то поймёте их специфику, огребёте много хейта в комментариях, на вас будут ругаться редакторы...
В-третьих, найдите своего редактора. Не самый очевидный совет, так как сразу возникают замечания «надо кого-то искать, как это сделать, кому-то придётся платить и т.д.». Всё понимаю, но, как в любой профессии, на старте всегда нужен человек, который скажет, что вы делаете хорошо, а что говно нет. Вашими редакторами могут стать комментаторы на Хабре или VC, знакомые айтишники или даже специально нанятый для этого человек. Я всегда рассказываю, что очень много почерпнул у своего редактора на Хабре, когда начал писать для их контентной студии. Меня не учили, конечно, но мелкие правки и замечания по логике текста помогли мне понять, что я делаю не так. Ну и, конечно, были моменты, когда я хотел ещё докручивать текст, а редактор останавливал. Это тоже правильно, так как перфекционизм нужно сдерживать.
В заключение хочется сказать, что я всегда рассматривал «копирайтера в ИТ» как отдельную профессию. Вы можете писать смешные, ироничные, захватывающие и даже идеальные рассказы на любую другую тему, но в технотексте это будет «бред же, вода, удали на хрен». Просто потому, что вы не раскрыли тему или наделали множество ошибок по сути. Поэтому, как и в любой другой профессии, начинайте сначала, а потом уже будете объединять скилы.
Типографские раскладки. Установите и используйте, чтобы не бесить редактора.
Типографская раскладка Ильи Биртмана. Windows и macOS. Адаптация для Ubuntu.
Лично я раскладкой Бирмана не пользуюсь, у меня собственная раскладка для Windows, собранная когда-то давно с помощью программы Microsoft Keyboard Layout Creator.
Типографская раскладка Ильи Биртмана. Windows и macOS. Адаптация для Ubuntu.
Лично я раскладкой Бирмана не пользуюсь, у меня собственная раскладка для Windows, собранная когда-то давно с помощью программы Microsoft Keyboard Layout Creator.
Как собирать информацию для статьи. Несколько советов
Про различные технологии написано сотни и тысячи статей. Так в чём проблема собрать информацию на определённую тему и переписать её в свой текст? Так думают очень многие копирайтеры, но вот только результат такого рерайтинга очень часто не радует. Как собирать информацию:
1. Проверяйте актуальность информации. Технологии развиваются очень быстро и, например, некоторые недостатки или проблемы какой-либо СУБД, описанные в десятке статей даже за последний год, в момент написания вашей статьи могут быть уже исправлены.
2. Проверяйте термины, особенно если вы их не понимаете. Я встречал ошибку в описании одной технологии в трёх статьях подряд. «Нулевым пациентом» оказалась статья-перевод на английском языке со слишком буквальным переводом термина. Так что проверяйте всё и используйте различные источники, в том числе иностранные.
3. Обязательно читайте комментарии к статьям, которые вы хотите использовать. На том же Хабре из комментов можно порой вынести больше информации, чем из самой публикации.
Соберите и проверьте информацию, напишите план, начинайте писать.
P. S. Все советы не помогут, если вы хотя бы немного сами не разобрались в теме. Концепция «я соберу текст, сам не понимаю, но технари-то разберутся» не работает.
Про различные технологии написано сотни и тысячи статей. Так в чём проблема собрать информацию на определённую тему и переписать её в свой текст? Так думают очень многие копирайтеры, но вот только результат такого рерайтинга очень часто не радует. Как собирать информацию:
1. Проверяйте актуальность информации. Технологии развиваются очень быстро и, например, некоторые недостатки или проблемы какой-либо СУБД, описанные в десятке статей даже за последний год, в момент написания вашей статьи могут быть уже исправлены.
2. Проверяйте термины, особенно если вы их не понимаете. Я встречал ошибку в описании одной технологии в трёх статьях подряд. «Нулевым пациентом» оказалась статья-перевод на английском языке со слишком буквальным переводом термина. Так что проверяйте всё и используйте различные источники, в том числе иностранные.
3. Обязательно читайте комментарии к статьям, которые вы хотите использовать. На том же Хабре из комментов можно порой вынести больше информации, чем из самой публикации.
Соберите и проверьте информацию, напишите план, начинайте писать.
P. S. Все советы не помогут, если вы хотя бы немного сами не разобрались в теме. Концепция «я соберу текст, сам не понимаю, но технари-то разберутся» не работает.
Довольно интересное исследование про рынок копирайтинга с 24 февраля.
Про копирайтинг в ИТ могу сказать, что рынок начал оживать. Я это всегда проверял по количеству запросов от HR. Весной они упали практически до нуля, сейчас — минимум раз в неделю приходят с запросами на тексты и редактуру. Особенно актуальны стали две темы:
— HR-бренд — айтишников на рынке и так не хватало, а в связи с последними событиями и совсем обострилась. И лучше ситуация в ближайшие пару лет точно не будет. Поэтому HR нужно больше статей на Хабре и других ресурсах с рассказами о том, как круто пилить продукты у них в компании.
— SEO-тексты — ИТ-компании очень быстро поняли, что нужно работать над своими сайтами. Больше статей, больше выдачи. Тут, правда, выяснилось, что штатные копирайтеры, хорошо пишущие для SMM и презентаций, часто не могут даже сделать рерайты статей про технологии.
Подытожим: если вы копирайтер, то самое время пойти учиться ИТ. Заказов тут будет всё больше.
Про копирайтинг в ИТ могу сказать, что рынок начал оживать. Я это всегда проверял по количеству запросов от HR. Весной они упали практически до нуля, сейчас — минимум раз в неделю приходят с запросами на тексты и редактуру. Особенно актуальны стали две темы:
— HR-бренд — айтишников на рынке и так не хватало, а в связи с последними событиями и совсем обострилась. И лучше ситуация в ближайшие пару лет точно не будет. Поэтому HR нужно больше статей на Хабре и других ресурсах с рассказами о том, как круто пилить продукты у них в компании.
— SEO-тексты — ИТ-компании очень быстро поняли, что нужно работать над своими сайтами. Больше статей, больше выдачи. Тут, правда, выяснилось, что штатные копирайтеры, хорошо пишущие для SMM и презентаций, часто не могут даже сделать рерайты статей про технологии.
Подытожим: если вы копирайтер, то самое время пойти учиться ИТ. Заказов тут будет всё больше.
Что делать, если автору не хватает информации
В работе с авторами довольно часто возникает момент, когда присылают очень короткий и несодержательный текст. Классическое объяснение — клиент/спикер не дал больше информации. Что делать?
Простое решение: написать дополнительные вопросы, отправить клиенту/спикеру с написанным черновиком, ожидать ответа. Работает не всегда, так как ответить могут классическими «да/нет» или какими-либо цифрами. Как задавать вопросы я ещё напишу, но вышеописанные ответы расширить текст могут и не помочь.
Сложное решение: цепляться за фактуру. Например, клиент использует Kubernetes и в интервью рассказывает, что они используют эту систему оркестрации для сборки релизов и т.д. Автор так и пишет в тексте. Но если контента не хватает, то эту информацию можно использовать значительно шире — зацепиться за CI/CD и развернуть мысль в том направлении, что эта DevOps-практика помогает клиенту контролировать выход новых версий своего продукта, уменьшить time-to-market и многое другое. Очень часто в процессе можно написать нечто совсем несоответствующее действительности, НО это даже лучше. При проверке вашего текста клиент отметит эту информацию как неверную, и, как показывает практика, даст очень развёрнутый комментарий на этот счёт. Который, в свою очередь, вы сможете использовать в работе над новой версией статьи.
Можно решения комбинировать, конечно, но если вы хотите писать для ИТ, то не стоит писать свои тексты только на основании полученных данных или интервью. Только глубокое изучение вопроса, только хардкор.
В работе с авторами довольно часто возникает момент, когда присылают очень короткий и несодержательный текст. Классическое объяснение — клиент/спикер не дал больше информации. Что делать?
Простое решение: написать дополнительные вопросы, отправить клиенту/спикеру с написанным черновиком, ожидать ответа. Работает не всегда, так как ответить могут классическими «да/нет» или какими-либо цифрами. Как задавать вопросы я ещё напишу, но вышеописанные ответы расширить текст могут и не помочь.
Сложное решение: цепляться за фактуру. Например, клиент использует Kubernetes и в интервью рассказывает, что они используют эту систему оркестрации для сборки релизов и т.д. Автор так и пишет в тексте. Но если контента не хватает, то эту информацию можно использовать значительно шире — зацепиться за CI/CD и развернуть мысль в том направлении, что эта DevOps-практика помогает клиенту контролировать выход новых версий своего продукта, уменьшить time-to-market и многое другое. Очень часто в процессе можно написать нечто совсем несоответствующее действительности, НО это даже лучше. При проверке вашего текста клиент отметит эту информацию как неверную, и, как показывает практика, даст очень развёрнутый комментарий на этот счёт. Который, в свою очередь, вы сможете использовать в работе над новой версией статьи.
Можно решения комбинировать, конечно, но если вы хотите писать для ИТ, то не стоит писать свои тексты только на основании полученных данных или интервью. Только глубокое изучение вопроса, только хардкор.
Отличный пример, как не нужно писать статьи на Хабр.
https://habr.com/ru/post/682838/
Хотя идея была хорошая.
#плохиетексты
https://habr.com/ru/post/682838/
Хотя идея была хорошая.
#плохиетексты