Идеальная профессия для душнил. Техписатель рассказывает про работу и зарплаты

Кто пишет: Вы находитесь в разделе «Блоги», а этот текст пишет Владислава Лагун, технический писатель Playrix с 4 годами опыта. 
Хотите написать что-то для блогов? Пишите на blog@dev.by или в телегу @blogs_devby. 

Кто такой технический писатель 

Самые распространённые задачи технического писателя: 

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

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

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

Путь входа в профессию можно посмотреть на RoadMap.sh. 

Какие навыки и инструменты нужны

Знания и навыки зависят от компании и конкретных требований: где-то могут понадобиться программирование, понимание API и скриптование. Где-то достаточно грамотности, программы для создания скриншотов и простого редактора текстов.

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

Для джунов важны:

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

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

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

Сколько зарабатывает технический писатель

Нет четкой вилки — профессия новая. На русскоязычном рынке, согласно исследованию Российской экономической школы рейты такие: от 800 $/ месяц (джун без опыта и технических навыков) до 5000 (senior Technical Writer с опытом от 3 лет и базовыми навыками программирования).

Американское бюро статистики дает цифру 50-100 тысяч (также до вычета налога) в год на май 2022 года. 

Куда расти?

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

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

Какое-то время техническими писателями становились уставшие от своих задач разработчики и тестировщики. Может быть и обратный переход. 

Как я стала техписателем

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

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

Также, ещё в университете я прошла курс по академическому письму (Academic Writing), который идеально подходит техническому писателю.

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

Я гуманитарий, в ИТ пришла после Факультета Международных отношений БГУ и магистратуры по истории. Первые несколько месяцев я ходила на все встречи с блокнотом, записывала в него непонятные термины (корутины, визуальный класс и многие другие), чтобы потом их загуглить или расспросить коллег.

Как проходит адаптация и обучение

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

Сейчас курсов по техническому писательству — очень много, на любой вкус и кошелек. На полноценные курсы у меня не нашлось времени ни до, ни после перехода. Целиком я проходила только Technical Writing Course от Google. 

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

Остальное обучение проходит под девизом «learn by doing». Я не ищу полноценные курсы, но часто просматриваю отдельные модули поинтересным темам на Coursera.

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

Вот мои любимые ресурсы:

• Зинсер, Уильям «Как писать хорошо». Книга легко читается, объясняет все самые необходимые моменты работы с текстом и универсальна: не имеет значения на каком языке вы пишете. Хотя в русском переводе она вышла в сокращении, поэтому я бы все же рекомендовала читать оригинал.
  Альтернативы: Нора Галь «Слово живое и мертвое», Корней Чуковский «Живой как жизнь. О русском языке».
• Krista van Laan, The Insider’s Guide to Technical Writing. Это одновременно вводно-ознакомительная и справочная книга. Моя копия утыкана закладками, как ёж иголками, чтобы можно было быстро найти нужную схему или подсказку для поискового запроса. Если вы писатель с опытом, книга не откроет вам новый мир, но будет отличным подспорьем для обучения молодых коллег. 
• Nick Milton, Patrick Lambe. The Knowledge Manager’s Handbook: A Step-by-Step Guide to Embedding Effective Knowledge Management in your Organization. Книга больше касается организации знаний и построения процесса работы с командой и экспертами, вариант для опытных или «на вырост».
• Write the Docs — сообщество работающих с документацией профессионалов. На их сайте можно найти книги, статьи, видео с конференций и даже контакты на случай острой необходимости нетворкинга.
• Блог технического писателя Тома Джонсона «I’d rather be writing» и особенно его курс по документации API. Последний сэкономил мне кучу времени на поиск информации и инструментов, когда мне нужно было быстро разобраться с темой.

А в чём подвох?

• Нет четких KPI — сложно просить повышения. Работу технического писателя сложно описать количественными показателями. Статьи бывают разного объема и сложности, на их написание может потребоваться разное количество времени и разная степень погружения в тему. Поэтому сложно проследить свой прогресс и презентовать его менеджменту. И тем самым добиться повышения. 
• Слишком много разных тем и задач. Нам постоянно приходится писать на незнакомые темы. Погружаться в новые области знания, снова и снова проходить стадию новичка некомфортно, но без этого этапа сложно сделать хорошую статью. 
• Ты всегда будешь задавать «глупые» вопросы. Открытые источники ошибаются и врут, люди забывают и путаются, поэтому важно перепроверять себя и других, не бояться задавать дилетантские вопросы специалистам. Если вопрос возник у писателя, он может возникнуть и у пользователя. 
• Повторные интервью, а ведь казалось, что всё поняла. Совершенно нормально, если во время разговора с разработчиком все было понятно, а после появилось много вопросов. Возможно, стоит созвониться ещё раз или подойти к коллеге с черновиком и задать появившиеся вопросы. 
• Постоянно приходится проявлять настойчивость. Не всем документация одинаково важна: разработчики заняты своим делом и могут откладывать задачи и переносить встречи. Напомнить о себе и добиться интервью или ревью это тоже задача технического писателя.  
• Вечные итерации и feedback. Каждый читатель видит текст со своей позиции, вопросы или сложности отличаются. Поэтому отзывов правок и комментариев может быть неожиданно много. 

Если у вас есть вопросы о профессии, оставляйте их в комментариях. Буду рада ответить. 

Мнение автора может не совпадать с позицией редакции. 

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

В 2023 году мы хотим собрать 1000 читателей-подписчиков.

Помочь нам можно через Patreon. 
Из Беларуси — через Donorbox.
И ещё криптой, тут кошельки.

Спасибо, что прочитали это сообщение.

Что ещё почитать про профессии у комьюнити:

• Как стать хорошим Java-разработчиком с нуля: максимально подробная инструкция для начинающих; 
• Як самастойна вывучыць аналіз даных? Парады ад Lead Data Scientist; 
• Как самостоятельно изучить Python для веб-разработки. Ловите подробный план обучения;