Тексты

Моим любимым русским техническим писателям посвящается

Работа технического писателя создавать документы на программные продукты, в основном всевозможные руководства пользователя. Разработка документа дело непростое. Есть очень много подходов и практик. Например, технические писатели в научно-производственных предприятиях часто пишут по ГОСТам или другим отечественным стандартам. Их цель точно и верно описать продукт. А technical writers в международных компаниях пишут по style guides (Microsoft Manual of Style, например). В этом случае цель, скорее, донести до пользователя, как продукт работает. Здесь фокус смещен с продукта на читателя.

Мне довелось побыть техническим писателем в разных местах, с разными правилами и политиками. Оглядываясь назад, могу сказать, что даже в НИИ тексты можно переориентировать на конечного пользователя, и документы от этого выиграют. Но в ГОСТах про это не пишут. А style guides, во-первых, на английском, а во-вторых, не афишируются в отечественных конторах типа НПП, КБ, и пр. Поэтому есть явная нехватка информации. Я попробую ее восполнить.

Чем отличаются доки для продуктов Yandex, Google, Microsoft, Apple, от old-school документации, созданной инженерами-конструкторами?

Классический инженер пишет так, чтобы продукт был описан максимально полно и правильно + в соответствии с ГОСТами и принятой терминологией. Причем многие термины и определения в ГОСТах устарели и совсем не красят документы. Но это не проблема для конструкторов никто и не думает, легко ли пользователю понять текст. А вот доки, сделанные для людей, отличаются: они написаны понятным языком и учитывают интересы пользователя. Вопрос приоритетов.

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


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

Я работаю в коммерческой разработке с 2011 года. С конца 2012 занимаюсь разработкой под iOS. Свою первую техническую статью я написал на Хабре в начале 2017 года про подход к локализации мобильных приложений. Потом выпустил ещё несколько статей по iOS-разработке на Хабре и в конце 2017 года я перешёл в новую компанию и решил вести блог про solution architecture https://medium.com/@nvashanin, где начал описывать общие концепты, обязанности архитектора, его скилл-сет и т.д. К лету 2020 года количество просмотров моих статей перевалило за 800 тысяч, а количество времени, которое люди потратили на прочтение больше 6 млн минут, или около 12 лет чистого времени. Флагманская статья была переведена другими людьми на разные языки: например, польский или испанский.

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

Предыстория

Мне стало интересно развиваться в сторону архитектора программного обеспечения ещё в 2016 году. В начале 2017 года я побывал на первом в своей жизни трёхдневном интенсиве, где матёрый архитектор рассказывал про основные концепции. К концу интенсива мы объединялись в команды, которые должны были взять предложенную проблему, придумать под неё архитектурное решение и защитить перед другими командами. Честно признаться, тогда это вышло у меня плохо.

Я уже был тимлидом несколько лет, затем перешёл в другую компанию и узнал, что есть отдельная ветка развития в архитекторы. Для этого мне пришлось поработать на своём проекте архитектором и пройти ассессмент через комитет зрелых архитекторов. Я прошел этот комитет только со второго раза, через полгода после первой попытки. Общий процент прохождения в компании на эту позицию был около 25%.

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

Зачем вести технический блог

Я часто слышу вопрос: Зачем мне блог?. Вот лишь несколько причин и они актуальны не только для IT-сферы.

Прокачивать знания. Если вам интересна какая-то тема и вы хотите в ней лучше разобраться пишите статью. Так вы сможете улучшить собственные знания и разложить их по полочкам. Я завёл блог, потому что хотел структурировать свои знания в области работы архитектора ПО.

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

А ещё, грамотно развивая личный бренд, вы можете стать инфлюенсером то есть специалистом, к чьему мнению прислушиваются другие участники сообщества. Один из ярких примеров кейс ребят из Rambler. В 2016 году у них получилось зарекомендовать VIPER как лучшую архитектуру слоя презентации на iOS и альтернативу более классическим MVC и MVVM среди русского iOS-сообщества. И всё благодаря толковым выступлениям и полезным статьям. Очень много компаний и разработчиков перетащили VIPER себе, некоторые до сих пор её используют.

Продвигать компанию. Создание личного бренда всегда тесно переплетается с укреплением бренда компании. Это взаимовыгодная ситуация: вы помогаете привлекать лучшие кадры, подаёте хороший пример своим коллегам, рассказываете о продукте и полезных инсайдах рынку, и компания так или иначе вас поощряет.

Конечно, важно, чтобы руководство компании также осознавало ценность этой истории и поддерживало активность сотрудников. Мы в Cardsmobile сейчас активно работаем над укреплением HR-бренда на рынке, и, возможно, мои статьи помогут мотивировать ребят из команды делиться знаниями, писать статьи и выступать.

Заработать деньги. Большинство заводит блог, чтобы заработать. Это частая причина для трэвел или бьюти сферы, но, что парадоксально, в IT-блогинг редко идут за деньгами. Хотя возможности всё же есть: я купил себе часы на деньги, которые принёс мне блог хотя и не ставил перед собой цели заработать.

О чём писать в блоге

Вопрос, с которым сталкивается каждый, кто решил завести блог: О чём писать?. Чаще всего темы для статей подсказывает сама причина, по которой вы решили завести блог. Если вы решили прокачаться пишите статьи о том, в чём хотите разобраться. Если же укрепить бренд компании и свой собственный рассказывайте о своей работе, проектах, применяемых технологиях.

Для себя я выделил следующие направления или рубрики:

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

Кейсы. Сделали что-то интересное расскажите об этом. Частая ошибка ощущение, что вы не делаете ничего интересного. Зачастую всё наоборот. Смотрите на свою работу не изнутри, а со стороны, и боритесь с синдромом самозванца.

Работаете с высоконагруженным back-endом расскажите, как делаете хайлоад и почему именно так. Верстаете UI расскажите про интересную анимацию, которую сделали. Использовали в проекте новую технологию расскажите о своём опыте работы с ней. Ваши подводные камни и инсайды помогут другим не сидеть над проблемой часами.

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

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

Статьи с юмором. Возьмите серьёзную тему и расскажите о ней в легком ключе. Аудитории такое заходит.

Пара советов по поиску тем

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

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

Читайте комментарии к чужим статьям. Это кладезь информации о том, что интересует и беспокоит других людей.

Помните, что уникальных и гениальных идей, как правило, мало. Всё так или иначе уже было кем-то придумано. Тем не менее это не повод не писать, ведь хороших описательных текстов мало. Мой совет: просто пишите, и со временем вы научитесь быстро находить интересные темы для блога.

Как написать хорошую статью

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

Составляйте план. Интересная и понятная статья начинается с плана и структурирования основных мыслей. Набросать хороший скелет статьи мне помогают mind maps. Для этой статьи получился небольшой mind map, но иногда выходят и солидные. Ниже mind map, который я собрал, чтобы рассказать в Твиттере о своём опыте жизни в Нидерландах.



Сделайте план настолько подробным, насколько сможете. Постарайтесь выделить все основные идеи, которые хотите раскрыть в статье.

Придерживайтесь структуры. Чтобы читателю было проще ориентироваться в статье, используйте традиционную структуру, состоящую из введения, основной части и заключения.

• Введение.

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

• Основная часть.

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

• Выводы или заключение.

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

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

Придумайте ёмкое название. Нет секретов, которые помогут вам подобрать идеальную формулировку или длину заголовка. Формулируйте заголовок так, чтобы он раскрывал содержание статьи и помогал читателю сделать выбор: читать или не читать. Иногда срабатывают броские и компрометирующие заголовки они цепляют внимание, но важно, чтобы содержание статьи оправдало ожидания читателя. Также есть смысл изучить выдачу поисковиков, чтобы понять, какие темы чаще всего ищут. Всегда подбирайте название после того, как закончили писать содержание статьи так оно получится максимально релевантным.

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

Отдельного внимания заслуживает заглавная картинка к статье тизер (от англ. tease дразнить). Из названия понятен механизм, по которому её следует выбирать: она должна вызывать желание открыть ссылку. Это важно, ведь человек первым делом обращает внимание именно на картинку. Симпатичный вижуал соберёт больше внимания и переходов.

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





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

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

Проверка орфографии, пунктуации и стилистики текста. Советую пользоваться специальными автоматизированными сервисами: Орфограммка для орфографии, пунктуации и стилистики; Advego для стилистической проверки текста; Главредом царём сервисов, который очищает текст от словесного мусора. Для текстов на английском языке я использую платную версию сервиса Grammarly.

Проверка ревьюерами. В тех областях, о которых я пишу от iOS разработки до архитектуры у меня есть несколько хороших ревьюеров специалистов, чьему мнению я доверяю. Они хорошо разбираются в теме и могут дать комментарии по содержанию: в iOS разработчик из VK, мой хороший друг из Санкт-Петербурга, а в архитектуре архитектор из Google в Кремниевой долине. Если у вас на примете нет таких экспертов, покажите статью руководителю или коллегам. Большие компании, в которых процесс производства контента поставлен на поток, сотрудничают с внешними рецензентами.

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

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

Где публиковать статью: выбор площадки

Если у компании есть собственный блог, начать можно с него. Если же нет варианта два: уже существующие площадки или блог на своём домене.

Блог-платформ много: у русскоязычной аудитории популярен Хабр, у англоязычной Medium. Платформ для создания собственного блога также немало. У каждого из подходов есть свои плюсы и минусы.

Популярная платформа

+ Развитый SEO, благодаря чему вашу статью будут находить читатели. Это уменьшает затраты как времени, так и денег на раскрутку блога. При этом платформы генерируют трафик не только на новые статьи: я не пишу с августа прошлого года, но каждый месяц мои статьи получают порядка 25 тысяч просмотров.

+ Готовый UI, который упрощает вёрстку статей. Платформы предлагают удобные редакторы, в которые встроены разнообразные шаблоны и механики. В Medium, к примеру, есть блок с автоматическим расчётом времени, которое потребуется для прочтения статьи. Статьи также удобно читать: в редакторах по умолчанию предусмотрены воздух в тексте, вариации шрифтов, заголовки, удобная работа с картинками и многое другое.

+ Простой запуск. Работа над статьей идёт по простому сценарию: написание > публикация.

Базовая кастомизация стилистики. Если хочется сложной вёрстки или нестандартных фишек, такой вариант не подойдёт.

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

Зависимость от востребованности площадки. Если сервис теряет популярность, то и ваш блог теряет популярность.

Блог на собственном домене

Плюсы популярных платформ это минусы блогов на своём домене. А минусы платформ плюсы собственных площадок.

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

Если вам всё же хочется иметь собственный домен, некоторые площадки разрешают настроить собственное доменное имя и публиковать статьи под ним такая опция доступна, к примеру, на Medium. Оценив все плюсы и минусы обоих вариантов, я завёл блоги на двух платформах: на Хабре и Medium.

Как продвигать статью

Если вы решили запустить блог на платформе, вам по умолчанию будет доступен трафик, который генерирует сама платформа. К продвижению блога на собственном домене есть смысл подключить SEO-специалиста.

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

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

Опубликуйте ссылку во всех социальных сетях. Даже если у вас не раскручены соцсети, посты всё равно сгенерируют некоторое количество просмотров на старте это уже хорошо. В моём случае лучше всего работает Linkedin, где у меня более 3 тысяч контактов, преимущественно англоязычное сообщество. А вот Instagram, по моим ощущениям, для IT-блогов не работает совсем.

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

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

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








Скрины сообщений в Linkedin

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

Как монетизировать блог

Перейдём к самой провокационной теме можно ли монетизировать блог, и как это сделать.

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

Виды монетизации

Есть два направления монетизации.

Прямая. Вы получаете деньги непосредственно за написание статьи.

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

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

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

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

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

Механизмы монетизации

Я протестировал несколько механизмов монетизации. Делюсь их результатами.

Нативная монетизация блог-платформы. Делюсь опытом с Medium. Каждый читатель или автор может купить платный аккаунт за $ 5 и читать все статьи на платформе. Статьям, которые ему нравятся, читатель ставит лайк на Medium это называется хлопок. Деньги, которые читатель заплатил за подписку, распределяются между авторами понравившихся ему статей. Лучшие авторы могут получать неплохие деньги. В конце месяца Medium отправляет всем авторам рассылку, в которой раскрывает топовые цифры по доходам. В мае 2020 года цифры выглядели так: лучший автор получил $ 25000 за месяц со всех своих статей, а за лучшую статью выплатили больше $ 10000. Я получил за одну из статей $ 50 за месяц она была опубликована за 8 месяцев до того, как я протестировал инструмент.


Скрин экрана с информацией о том, сколько я заработал на одной из своих статей


Минус такого формата в том, что статья доступна только тем, у кого есть подписка. Меня это не устраивало, поэтому я изучил и другие варианты.

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

Аффилированные программы есть у многих программных продуктов и магазинов на HubSpot опубликован список доступных программ: от Coursera до Amazon. Я выбрал последний: в каждой моей статье есть пара ссылок на книги по архитектуре. Если кто-то покупает их по моей рекомендации, Amazon перечисляет мне определенный процент. Механика проста: если вы пишете полезный контент для своей аудитории, правильно подобранная аффилированная программа может вас озолотить. Ссылки в моих статьях до сих пор генерируют в среднем от $100 до $150 каждый месяц даже с учётом того, что последнюю статью я написал почти год назад (но я обещаю исправиться и снова начать писать!).


Мой доход в аффилированной программе Amazon за октябрь 2019 года

Недостаток такого подхода в том, что вывести деньги с Amazon на карточки российских банков невозможно. Я жил в Нидерландах, поэтому проблем с банковским счётом и выводом денег у меня не было. Вы же можете сделать счёт на PayPal и выводить деньги через него.

Аффилированные программы самый прибыльный и проверенный способ монетизации. Они могут приносить тысячи долларов ежемесячно при условии, что вы пишете постоянно. Кейсы подтверждают: один автор сделал линк-приглашение в водители Uber, когда агрегатор только начинал свою экспансию, и заработал $ 50000, а другой написал статью об Instagram-ботах на Medium и заработал $2000.

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

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

Маркетинговые посты. Если вы ведёте популярный блог на определённую тематику, компании захотят за деньги публиковать у вас маркетинговые посты или делать внутренние интеграции так как в вашем блоге сосредоточена их целевая аудитория.

К примеру, вы пишете про всё, что связано с Devops, а у компании открываются новые платные курсы по этому направлению. Вполне возможно, они захотят купить интегрированную нативную рекламу в вашем блоге. Лично я такую монетизацию не пробовал, но мне поступали предложения.

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

Возможно, если бы я писал больше статей, я бы зарабатывал на блоге пару тысяч долларов в месяц. Пока за всё время существования с 2017 года блог принёс мне около $ 5000 через разные форматы монетизации. На эти деньги я купил себе часы, о чём уже упоминал в начале статьи. Приятный бонус особенно учитывая то, что я всерьез не занимался блогом и продвижением, а лишь хотел изучить это направление.

Длина статьи, тэги и ещё три лайфхака

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

Лучше доработать статью, чем выпустить сырую. Звучит по-капитански, но иногда мне приходилось дорабатывать уже опубликованную статью. Такой подход рушит ваш авторитет в глазах читателей и приводит к уменьшению трафика. Солженицын в Круге первом описывает правило последних вершков: когда 95% работы закончено, остаётся всего ничего, но эти 5% работы самые сложные с точки зрения мотивации и самые важные с точки зрения удобства читателя. Всегда доделывайте статью до конца, даже если вам и кажется, что и так сойдет иначе зачем это всё?

Оптимальная длина одной статьи 7 минут. Такова статистика Medium. Прочтение статей с самым высоким рейтингом на платформе занимает 7 минут. Конечно, это не универсальное число. На мой взгляд, наилучший тайминг от 6 до 10 минут. В такой статье достаточно контента, чтобы полноценно раскрыть тему, но её не сложно прочитать за один раз. Многое также зависит от площадки: где-то оптимальная длина поста 3 минуты, а где-то возможно, все 30 минут.

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

Публикуйте статью в четверг или в субботу утром. По статистике в эти дни количество просмотров на 33% больше, чем в другие. Худший день для публикации понедельник.

Используйте ключевые слова для оптимизации в поиске. Ключевые слова помогут вывести статью и блог в топ, если вы публикуете текст на своей площадке.

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

Вместо выводов, или что дальше

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

Попробуйте опубликовать хотя бы пять статей, а после оцените первые промежуточные результаты: стали ли вы лучше формулировать мысли, растёт ли количество читателей, стало ли у вас больше читателей, появились ли постоянные читатели.

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

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

Получилась самая большая статья, которую я когда-либо писал. Я очень надеюсь, что раскрыл тему и замотивировал вас начать писать. Это долгий путь, но он того стоит. Write it right now!

Полезные ссылки

Grammarly сервис для проверки текстов на английском языке.
Главред сервис для проверки текста на русском языке.
Орфограммка сервис для проверки орфографии, пунктуации и стилистики.
Advego сервис для проверки стилистики.
Пиши, сокращай Максима Ильяхова и Людмилы Сарачевой лучшая книга на русском языке для тех, кто хочет писать понятные и ёмкие тексты.
Текст, который продает товар услугу или бренд Анны Шуст ещё одна книжная находка, которая поможет прокачать навык писательства.
Блог на миллион долларов книга известного эксперта по диджитал-маркетингу Наташи Кортни-Смит.

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

Конкретнее

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

Целевая аудитория кажется каким-то внешним фактором, не влияющим на документы, но это не так. Очень много проблем в доках решается именно отсылкой к ЦА. Например, насколько понятен этот текст? За всех мы сказать не можем: мне, например, понятен, а вот ему не очень. Так мы далеко не уедем, нужно какое-то решение. А именно: понятно ли это для целевой аудитории? Рассмотрим пример.

Я писала документы для Acronis Cyber Infrastructure, это когда из серверов делают кластер, а его используют для storage и virtual machines. Упрощенно, этот продукт рассчитан на enterprises, в частности, на сервис-провайдеров. ЦА документов системные администраторы, и не самые простые. Обыкновенному человеку они будут непонятны. Но это не bug, это by design. Если бы мы писали эти доки для обычных пользователей, то:

1. Нужно было бы объяснять все концепты storage и HCI очень подробно и понятно. Такой dummy guide, для чайников.
2. Нельзя было бы использовать общепринятые термины сферы, нужно было бы упрощать и описывать. Например, вместо node, возможно, был бы server, потому что это слово более употребимо и понятнее всем, хотя оно не передает роли сервера в кластере.

Короче говоря, это были бы совсем другие документы.

Плохо, когда для доков не определена ЦА. Начинаются метания: а это достаточно понятно? А это не слишком элементарно? К вопросу о ГОСТах и ЕСПД. Там как раз часто целевая аудитория люди, которые почти не умеют пользоваться компьютером. Сейчас таких мало. Поэтому документ на обычного современного юзера, написанный по ЕСПД, может получиться очень тяжелым, перегруженным ненужными деталями. Зато, вероятно, в момент написания ГОСТов он четко попадал бы в ЦА.

Заметки на полях

• В начале документа неплохо иметь раздел Target audience, чтобы было сразу понятно, для кого написан документ. К сожалению, часто там написано: Для всех, кто читает этот документ или использует наш продукт. Если вам попадется нормальный раздел, где четко описана целевая аудитория, скиньте, пожалуйста, в комменты, с удовольствием почитаю.
• Иногда документ рассчитан на более-менее общую аудиторию, но есть пара сложных моментов для знатоков, например, какие-то хитрые настройки. Такие вещи можно убирать в knowledge base.
• Даже если вы пишите доку для админов и сразу это обозначаете в разделе Target audience, все равно придут люди, которые вообще не шарят. И они станут писать вам: А что это? А это? А почему так сложно? Будьте готовы.

Проще

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

Было

Для установки программы необходимо запустить исполняемый файл wizard.exe и следовать указаниям мастера установки.

Стало

Чтобы запустить мастер установки, дважды нажмите на файл wizard.exe.

Было

В этом окне можно установить флаг для создания значка (ярлыка) на рабочем столе, который может быть использован для запуска ПО на выполнение. После задания значения флага следует нажать кнопку Далее.

Стало

При необходимости, установите флажок Создать значок на рабочем столе. Нажмите Далее.

Заметки на полях

• Совершенно спокойно можно убирать из доков описание общих свойств элементов GUI. То есть если вы описываете таблицу, а в ней (ничего себе!) можно поменять ширину столбцов перетаскиванием границы, это писать необязательно. Реальный пример: Размеры частей окна и ширина колонок могут быть изменены путем перемещения разделительных полос левой кнопкой мыши. Положение окна можно изменить перемещением строки заголовка с помощью левой кнопки мыши (ЛКМ).
• Иногда исходный текст настолько запутанный, что даже не знаешь, с какой стороны подступиться. Самое сложное здесь понять, что же имеется в виду, а уже с пониманием будет легче подобрать простые слова. Обычно такие тексты просто нужно переписать начисто. Вот, поломайте голову над таким примером: Пользователь имеет возможность изменить положение объекта вручную, перетащив его с помощью ЛКМ в удобное положение. Существует два способа изменения положения объекта. 1-ый способ заключается в свободном перемещении, когда можно выбрать любую позицию для установки объекта. 2-й способ, когда позиция имеет фиксированное место с дискретным углом 45 и фиксированным удалением от точки пересечения графика с визиром.

Короче

Недавно на одном из вебинаров услышала очень точную фразу: Каждое слово, которое вы пишите, пользователь читать не хочет. Согласна на 100%. Но при этом, признаюсь, мне знакомо чувство, когда хочется еще дописать, и еще немного объяснить, и повторить то же другими словами, ну, чтобы точно дошло! Борюсь с этим чувством, и вам советую.

Сделать текст короче это не совсем то же самое, что сделать его проще. Когда мы упрощаем текст, мы убираем лишние технические детали. А когда мы сокращаем его, мы убираем фигуры речи и лишние обычные слова. Например, если пункт 2 идет после пункта 1, не нужно писать После выполнения пункта 1. Или вместо следует нажать лучше писать нажмите.

Было

После выполнения указанных действий в режиме Р для печати билета с одним из запрограммированных тарифов от 1 до 9 достаточно нажать соответствующую цифровую клавишу. Билет будет автоматически отпечатан.

Стало

Чтобы напечатать билет с запрограммированным тарифом от 1 до 9, нажмите на соответствующую цифру.

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

Было

Для обновления, нужно временно скопировать файл Ф на компьютер с ПО, обновить программой П (указать путь к файлу Ф), затем скопировать файл обратно на сетевой ресурс. Перед началом обновления, необходимо убедиться в достаточном количестве свободного места на диске, где расположен файл Ф, это необходимо для создания резервной копии. Объём свободного места должен быть не менее размера обновляемого файла. Если свободного места недостаточно, программа выведет соответствующее сообщение.

Стало

Обновление

1. Убедитесь, что на диске, где расположен файл Ф, достаточно места для создания резервной копии.
2. Скопируйте файл Ф из сетевого хранилища на компьютер с программой П
3. В программе П укажите путь к файлу Ф и обновите его.
4. Скопируйте обновленный файл Ф обратно в сетевое хранилище.

Заметки на полях

• Когда мы работаем с большими абзацами сплошного текста, нужно помнить про visual effectiveness. Слишком много букв подряд и читать уже сложно. Иногда достаточно разбить на шаги или абзацы, а иногда можно подумать про схему. Толковая схема решает. Но чтобы сделать толковую схему, нужно понимать суть процедуры от и до. Здесь может пригодиться помощь разработчика или program manager.

Последовательнее

Технический писатель человек творческий, поэтому названий для одной и той же операции может быть много: нажать, щелкнуть, кликнуть, и все в одном документе. И помножим это на количество творческих людей, работающих над одним документом. Я за консистентность. Одна и та же операция должна называться одинаково. Если вам нравится Щелкнуть, то так и пишите везде. Если Нажать аналогично. Выберите подходящий термин и последовательно применяйте его везде. А еще лучше, заведите корпоративный глоссарий, хотя бы на русском, и там пропишите нужные фразы. +500 к консистентности, и еще помогает новичкам быстрее освоиться.

Заметки на полях

• Иногда непонятно правильное название чего-то на русском, но известно его английское название. Например, у нас есть нода, от английского node. Как найти верное русское слово? Можно зайти на глоссарий Microsoft. Там выбираем английский исходный язык и русский язык перевода, вводим слово на английском, и смотрим предложенные варианты на русском. Получаем узел.
• Если уж решились сделать документы последовательнее, эти правки должны быть применены повсеместно. Иначе какой смысл? Обычно такие изменения затрагивают больше всего текстов. Поэтому здесь нужно правильно рассчитать сроки и затраты. И особенно важно не забыть про локализацию, ведь для них это означает очень масштабное изменение в нескольких языках сразу.
• Когда в документах то disk, то drive, это не очень хорошо. Но когда то же самое в GUI, это совсем плохо. Поэтому на GUI смотрим особенно внимательно и запоминаем все варианты, которые потом нужно будет править.

Ресурсы

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

• Слово живое и мертвое Норы Галь. Классика.
• Живой как жизнь Корнея Чуковского, глава Канцелярит. Классика.
• Пиши, сокращай Максима Ильяхова. Свежий взгляд на старые проблемы +очень практичный подход. Здесь подробно описано, как именно можно сократить тексты.
• Developing Quality Technical Information: A Handbook for Writers and Editors от Gretchen Hargis и др. Здесь много про цели, задачи, ЦА документов. А еще хорошие примеры и практичные советы.

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