Лена из машины

✨Какими бывают клиенты в ИТ✨

В прошлом посте я рассказывала про три основные аудитории для ИТ-текстов → https://t.me/EditorExMachina/115. Пришло время поговорить про тексты для клиентов.

Клиенты в ИТ делятся на три категории:
👻Рядовые пользователи ИТ-продуктов, как правило разного ПО. Здесь в текстах очень мало от ИТ и много от обычной рекламы или информационных текстов. Эту аудиторию мало интересуют технические нюансы, им важна конкретная выгода. Такие тексты можно писать, даже не слишком глубоко разбираясь в ИТ. С них хорошо стартовать.

⚡️Крупные корпоративные пользователи ИТ-продуктов без особой экспертности. Похожи на первую аудиторию, только покупают не приложение для подсчета калорий за 100 рублей, а ИТ-инфраструктуру в свою компанию за миллионы. Их нюансы уже волнуют больше, и часто эти нюансы касаются именно технических деталей — какой SLA обеспечивает инфраструктура, как работает VPN и что там у вас по дата-центрам. Здесь нужно знать технические нюансы, чтобы перевести их на «продажный язык», но все еще важны быстрые и резкие преимущества, а не глубокие лонгриды с нюансами.

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

Действуем по старой схеме — ставьте реакцию по типу аудитории, с которой чаще сталкиваетесь, и поговорим про нее поподробнее.

Залезла в недра почты и нашла там свои старые-старые рабочие статьи за 2014 год =) Это не первые, работать я начала где-то в 2010, но все равно довольно показательно, как я писала раньше и как в целом раньше нужно было писать для всяческого SEO и прочего.

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

Странное утверждение о полезности:

Скандинавская ходьба сжигает в 1,5 раза больше калорий, чем обычная ходьба, поэтому она полезна для полных людей;

Тавтологии для объема (а еще неверные тире):

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

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

Вставать во время ходьбы нужно сначала на пятку, потом на носок. Движения должны быть плавными, без рывков. Сначала нужно шагнуть вперед, одну руку вытянув, согнув в локте и проследив, чтобы палка была под углом. Вторая рука, согнутая в локте на уровне таза, должна отойти назад.

А у вас остались примеры текстов со старта своей карьеры? Если да — поделитесь в комментариях, будет очень любопытно)

✨Для кого пишут ИТ-тексты✨

У всех ИТ-текстов — три основные аудитории. Тексты для них заметно различаются.

⚡️Клиенты. Это люди, которые покупают продукты ИТ-компаний: разработку сайта, программное обеспечение, построение ИТ-инфраструктуры. Для них важно, как именно продукт поможет облегчить жизнь, избежать расходов, оптимизировать бизнес, извлечь прибыль. Это классическая аудитория для рекламных статей, лендингов и статей про продукты и технологии.

👻Студенты. Это те, кому мы продаем всевозможные курсы — как для совсем новичков, так и уже для продолжающих, кто хочет углубиться в тему, повысить квалификацию или перейти из одной IT-сферы в другую. Это классическая аудитория для лендингов ИТ-курсов и общеобразовательных статей о разных сферах ИТ в разные блоги.

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

Для какой аудитории вы чаще всего пишете и редактируете тексты сейчас? Ставьте соответствующую реакцию — по самой популярной выберу, про какую первым делом рассказать побольше.

Еще напоминаю, что у меня есть курс про редактуру текстов в IT → https://tinyurl.com/28smysfs. Там есть про эти аудитории подробные уроки с примерами и практическими заданиями на самостоятельное выполнение.

✂Быстрый пример редактуры до/после✂

Пишите в комментарии, есть ли у вас идеи, как сделать этот кусочек ещё лучше.

💻Как я работаю на скорость💻

В прошлом посте был опрос — а теперь расскажу, как делаю я.

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

Я не считаю, что от этого страдает моя репутация. Да, я вряд ли положу этот текст в портфолио — но зато мои заказчики будут знать, что на меня можно положиться в такой сложной ситуации, и в ней я сделаю все, что могу.

При этом автора я принципиально не раскачиваю и новых экспертов не ищу — я считаю, что в такой ситуации мне важно сконцентрировать все свое время, внимание и силы на редактуре — так получится повысить качество работы, и при этом мне не переработать и не угореть (что тоже важно).

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

Опрос про работу на скорость

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

Вы открываете текст и видите, что он не очень — не хватает фактуры и местами непонятно, что хотел сказать автор. Вы знаете, что автор супер-медленный и какие-то ответы и правки будет давать очень долго — вы не успеете в срок.

Вы немного понимаете в теме и можете сами расширить и поправить какие-то тезисы. Текст останется слабым, но будет приемлемым.

Есть и другие редакторы — если откажетесь вы, текст возьмет другой.

Как вы поступите? Ставьте реакции:
👍Просто возьмусь и сделаю как получится
🤔Возьмусь, но попробую все-таки связываться с автором, как-то его качать, возможно попросить быстро ответить других экспертов или коллег.
👎Точно откажусь и не буду таким заниматься.

Напишите в комментарии, почему выбрали тот или иной вариант. А я потом напишу пост, как обычно поступаю я, потому что у меня такие ситуации не редкость)

#Объясняю_ITмемы

Иногда в собеседованиях айтишников (особенно часто так было раньше) задают один классический вопрос: «Что происходит, когда пользователь вводит URL в браузере?». Подразумевается, что человек кратко опишет процесс обмена информацией между браузером и «интернетом», то есть покажет свою компетентность в базовой работе интернета. Это важно знать программистам, чтобы правильно писать код для интернет-приложений.

Здесь же кандидат пошел слишком далеко и начал описывать то, что у него не просили — от него точно не ждали сигналов с клавиатуры или обжимки витой пары (это когда кабель интернета делают пригодным для собственно передачи интернета в компьютер).

В общем, на абстрактный вопрос был получен абстрактный ответ — не надо так.

А вы кстати знаете, что происходит, когда пользователь вводит url в браузере? Напишите в комментарии =)

Большой гайд про заключения в статьях

Начала писать пост про заключения: когда нужны, когда не нужны, как писать. Поняла, что в пост не влезает и нужно сделать много примеров, поэтому запилила статью на VC. Переходите, читайте, получилось довольно подробно → https://vc.ru/u/152954-lena-shpringer/1760640-gaid-po-zaklyucheniyam-k-statyam-zachem-kogda-i-kak-pisat-s-primerami-iz-realnyh-statei

⌨️Нейросети в России без бубна⌨️

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

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

✍Алиса.Про от Яндекса. Это YandexGPT 4, там есть работа с текстом и Шедеврум для картинок. Супер-дешево (я плачу 100р в месяц), без лимитов на генерации — видимо пока учится и растит популярность. Качество среднее, выдаёт много бреда, картинки генерит не очень точно, но для многих задачек реально хватает.

Очень рекомендую, если хотите пощупать нейросети или используете их редко и без особо сложных запросов.

🖋ChadGPT. Агрегатор, предоставляет доступ к целой группе нейросетей, в том числе ChatGPT4o и Миджорни. Оплата русской картой, тарифы гуманные — от 300 до 1700 в месяц. Но не безлимит — генерации в разных сетях стоят по-разному внутренних токенов-слов, и может понадобиться доплачивать. Все неиспользованные в месяце сгорают, то есть если купить тариф за 1700 и месяц не пользовать — всё пропадёт. Тут ссылка реферальная, дает бонус в 10000 слов при регистрации — и вам, и мне приятно.

Сюда я прихожу за более сложными объемными задачами, если понимаю, что и правда надо. Генерация картинок меня не очень устраивает скоростью и слишком большим обилием моделей, в которых я не разобралась, а вот работа с текстом на порядок лучше Алисы. Особенно радует возможность как в оригинальном ЧатГПТ прикреплять файлы для анализа.

Вот и всё) Расскажите, пользуете ли вы нейросети, и если да, то какие и как именно.

#Объясняю_ITмемы

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

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

Это как если бы вам как редактору в качестве тестового всегда давали похожий текст и задание «Придумайте к тексту 5 заголовков».

Так что котик грустит в бесконечном цикле одинаковости.

❤️Моя стратегия жизни в мире сбоев и блокировок❤️

Интернет вчера опять сбойнул и ВК был доступен, а Гуглдоки например нет. Что угодно в любой момент может надолго или навсегда отключиться — ничего с этим не поделаешь. Чтобы не пострадать от этого, я делаю следующее:

1. Раз в неделю делаю бэкап Гуглдиска — вручную качаю самые важные документы себе на компьютер. Наверное есть инструменты автоматизации, но мне проще вручную. Иногда если написала что-то очень важное — бэкаплю сразу.
2. Слежу за новостями о возможных блокировках. Если где-то что-то говорят — предпочитаю или вообще сразу перейти на альтернативу, или хотя бы поискать. Так я ушла из Трелло для ведения личных дел еще до того, как с ним возникли проблемы.
3. Не игнорирую нейросети, хотя многие доступны как-то мутно — пользуюсь российскими или способами обхода и доступа к зарубежным. Нейросети пока не супер-важны, но скоро станут базовым навыком, как компьютерная грамотность — не хочу его упустить из-за блокировок. (Ставьте реакцию глаз, если хотите, чтобы мы поговорили про то, как пользоваться нейросетями в редакторской работе в России без страшных танцев с бубном).
4. Не удаляю текстовые и табличные редакторы с компьютера, хотя почти ими не пользуюсь. Во время сбоя вот пригодились, чтобы срочно распечатать документ.
5. Все критически важное держу у себя на диске и в российских облаках типа Яндекса, но без фанатизма — есть риск потерять, но наверное как-то это переживу.

В итоге по мне все эти принципы помогают не нервничать, ничего не терять и нормально работать, даже когда что-то куда-то сыплется. Поделитесь в комментариях, что делаете вы.

🗒Заключения к статьям

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

По современному стандарту коммерческой редактуры каждой статье вроде как нужно заключение. По крайней мере, обычно в конце статьи обязательно что-то подытоживают. Здесь не будем говорить о том, стоит ли так делать, где и когда (может быть, поговорим про это позже) — хочется поговорить о самих заключениях.

Иногда их пишут в таком стиле:

В этой статье вы узнали:
1. Что такое сепульки.
2. Как производить сепуление.
3. Кто такой сепулятор.

Я считаю, что так делать нельзя, это никак не помогает читателю ничего подытожить. Вместо этого лучше делать так:

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

То есть заключение должно не просто напоминать читателю категории того, что он узнал — но и собственно рассказывать, что именно было рассказано. Это поможет освежить память, показать читателю самое главное и все-таки донести до него то, что он мог случайно пропустить, когда листал вашу статью по диагонали.

Минус метода в том, что так вы вроде бы растягиваете статью и повторяете уже сказанное дважды. Но я считаю, что люди, которые внимательно читали основной материал, заключение вполне могут просто пропустить, и от повторения не пострадают.

Я кстати сейчас работаю редактором в Практикуме, и для заключений в уроках тоже стараюсь придерживаться такого правила составления заключения — чтобы студент мог освежить в памяти то, что случайно забылось после большого объема новой информации или решения практических задач.

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

🖇Не нужно постоянно делать списки

В разных гайдах для авторов контента регулярно пишут, что списки хороши и облегчают восприятие. Это правда так, но на самом деле далеко не всегда.

Я в редактуре часто сталкиваюсь с ситуациями, которые выглядят примерно вот так:

«Далее необходимо разделить приложение на две части:
- клиентский код,
- серверный код.»

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

На мой взгляд, если в списке две–три сущности, и они однотипные и простые — их нужно просто оставить в предложении, вот так:

«Далее необходимо разделить приложение на две части: клиентский и серверный код».

Так гораздо легче и чище.

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

Схема может показаться слишком сложной, но на то есть своя причина. В этом поде у нас три контейнера:

1. В первом работает Vector. Его основная цель — сбор логов.
2. Второй контейнер — Reloader. У пользователей нашей платформы есть возможность описывать собственные пайплайны сборки логов. Специальный оператор берёт заданные пользователями данные и составляет configmap для Vector. Задача Reloader — проверить, что config правильный, и, если так, перезагрузить Vector.
3. Третий контейнер — Kube RBAC proxy. Он важен, поскольку Vector выводит различные метрики о собираемых логах. Эта информация может быть конфиденциальной, поэтому важно защитить её надлежащей авторизацией.

❔Как вы обозначаете свою профессию?❔

Каждый раз, когда меня спрашивают, кем я работаю — я теряюсь.

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

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

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

Остановилась пока коммерческом редакторе, но чувствую, что что-то не то. Так что расскажите, а как себя называете вы, опираясь на специфику вашей деятельности? Особенно вне диджитал и редакторской тусовки?

🎭«Пассивная агрессия» в статьях🎭

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

Суть в том, что в статье постоянно встречаются фразы вроде:
— «Ответ на этот вопрос очевиден, но давайте все-таки его рассмотрим»
— «Для понимания этого вам бы надо подтянуть свои знания в такой-то области».
— «Подробно мы на этом останавливаться не будем, про это уже написаны кучи статей, прочитайте их» (ссылок на статьи нет).
— «Если вы это подзабыли — это, конечно, плохо, но сейчас мы вам напомним».
— «Об этом мы писали выше, не будем тут повторяться, вы же читали внимательно и запомнили».

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

Но важно всегда понимать, что если вы считаете вещь всем известной — про нее просто не нужно говорить. А если считаете ее хоть немного неизвестной — не называйте вопрос очевидным и просто спокойно на него ответьте.

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

А вы бы кстати как назвали такое «поведение» в статьях? И как часто с ним сталкивались? И какие оно у вас ощущения вызывает?

🐾Почему аналогии плохи для споров, но хороши для текстов

Аналогия — это когда вы поясняете что-то сложное или неоднозначное через что-то более простое и понятное, но из другой области. Сравнивая языки программирования и HTML с хлебом и котиком например (это как в посте выше). В отличие от примера, тут мы не показываем применение сложного на практике, а берем объяснение из другой области, просто чтобы что-то сложное стало понятнее.

🐾Аналогии иногда любят использовать в спорах, приводя их как аргумент. Но это прям так себе идея, потому что внешнее сходство не означает сходства внутреннего. Слышали когда-нибудь фразу: «Хорош тот ключ, что открывает много замков — и плох тот замок, что открывается многими ключами»? Ее иногда используют для оправдания женской моногамии и мужской полигамии, если что =) Это как раз аналогия, вот только люди не ключи и не замки, и никаким вообще логическим доказательством чего-либо это не является. Поэтому использовать аналогию, чтобы доказать правдивость чего-то через якобы «подобное» — это ошибка.

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

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

🐾А вы часто используете аналогии в своих статьях? И что думаете об аргументацию через аналогии? Поделитесь в комментариях!

#Объясняю_ITмемы

Есть языки программирования: Python, PHP, Java, C#, C++ и всякие еще другие вроде Go. На них программисты пишут программы, которые умеют что-то делать — например, считать или анализировать данные.

А есть HTML — язык гипертекстовой разметки. На дилетантский взгляд он тоже может показаться языком программирования: куча английских слов, всякие скобочки и двоеточия. Но от языков программирования его отличает то, что этот язык не умеет ничего делать и вычислять. Он нужен для того, чтобы описать браузеру, как визуально должна выглядеть страница. Браузер считывает язык и отрисовывает все так, чтобы было красиво. Это если очень упрощенно.

Поэтому говорить, что HTML язык программирования — нельзя. Но так иногда говорят, потому что HTML «маскируется» и «тоже IT» — прямо как этот котик, притворяющийся хлебом.

🖥Как я пишу примеры кода для статей🖥

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

Решить проблему с кодом мне помог ChatGPT. Он прекрасно справляется с примерами кода разного уровня: может сравнить одну и ту же операцию в разных языках, продемонстрировать наглядно какую-нибудь библиотеку и даже написать с нуля несложную программу, например, игру.

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

Главное здесь помнить, что ChatGPT пока не идеален, и эксперт все равно должен будет проверить, что он там понаписал. Но проверить проще, чем написать — особенно учитывая, что ChatGPT прекрасно комментирует все, что накодил.