Мой обычный день в роли технического писателя

Обычно я начинаю день как и все люди: подъем, умывание, кофе и… путь до моего рабочего места — мой верный ноутбук! 💻 Путь не долгий, но требует силы воли! 😄

Сначала прохожу двухфакторную аутентификацию, а потом залезаю в Slack, посмотреть, что нового. Тут же проверяю и почту — вдруг меня уже засыпали запросами по текстам и документации? (впрочем, обычно так и есть)

Первый час утра обычно уходит на ответы QA команд. Как правило они просят помочь с текстами для новых фич, или проверяют, правильно ли мы описали какой-нибудь UI элемент. 🧐

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

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

Ну еще, неотъемлемая часть каждого рабочего дня — дэйлики в Zoom. Как правило, это короткие созвоны, но за неделю набегает около 10 часов. На некоторых таких встречах непосредственно обсуждаем какие-либо сложные моменты, а на некоторых просто необходимо присутствовать.

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

А у вас как проходит рабочий день?

Резюме

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

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

В процессе вы сами лучше поймете, насколько готовы к новой профессии и насколько вам это интересно.

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

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

Что важно для хорошего резюме?

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

Активные глаголы для описания ваших функций.
Например, вместо «Работа переводчиком в Cringe agency в части перевода технических текстов», лучше написать: «оформлял техническую документацию по требованиям заказчика», «участвовал в создании внутреннего глоссария и базы знаний» и тд.

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

Вход в профессию технического писателя

~~Меня часто спрашивают:~~ А что нужно знать, чтобы стать техническим писателем?

Смотря каким.

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

А есть, например, техрайтеры в сфере IT, где в зависимости от компании будут свои стандарты ведения и создания документации.

Например, у нас в компании, стандарты мы создавали сами (очень удобно😂)

Вот чтобы устроиться работать таким техническим писателем, достаточно на старте иметь следующее:

- лингвистический/филологический бэкграунд

- общее представление о том, как писать стройный текст (хоть на русском, хоть на английском)

- желание овладеть новыми программами и знаниями.

Например, я ничего не знал про API, про среду Atlassian, и много чего еще. Но глаза горели желанием все постичь и начать применять (ну и необходимость соответствовать коллективу тоже подталкивала😼).

Поэтому за сравнительно небольшое время в боевом режиме у меня все получилось. Получится и у вас!

В следующем посте расскажу про ещё одну важную вещь для старта в техрайтинге - важность резюме и отраженного там опыта🤓

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

И возможно, кто-то из вас задумывался о релокации в другие страны, например, в Испанию или Аргентину.

А для этого конечно было бы круто выучить или подтянуть свой испанский)

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

Ну и ещё, она классный преподаватель, и помимо прочего готовит к международному экзамену DELE?

Вэлком!

Тут ребята из quizzes4fun подготовили недельный курс по Git для начинающих, чтобы въехать в тему)

Кому интересно - ознакомьтесь, думаю, будет полезно)

Варианты роста для технического писателя

Когда вы приходите в ту или иную профессию, то первая мысль, которая обычно посещает голову “вау, это сложно, но интересно” или “Оу, ну, не шибко интересно, но пойдет”.

Ну а если вы только получили первую работу после универа или после долгого периода сидения без работы, то наверное что-то вроде “О, здесь есть зарплата, круто!” ?

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

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

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

Горизонтальный рост. Например, вы работали на гос предприятии и писали инструкции по ГОСТам, а потом решили расширить сферу своих компетенций, прокачали английский, изучили новые программы, и зашли в сферу IT в какой-нибудь медицинский стартап, или в геймдев и тд.

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

Наверное, самое идеальное — это пройти путь техрайтера от джуна до сеньора/лида, попутно изучая воркфлоу смежных профессий (а это изучение неизбежно, так как вы плотно взаимодействуете, например, с проджект менеджерами, разработчиками, и, особенно, с бизнес аналитиками), чтобы потом через 3-5 лет уже попробовать себя в том, что для вас ближе из этих профессий помимо техписательства.

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

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

Всем привет, со мной тут вышел подкаст на тему техписательства?

Рассказываю как я пришёл в эту сферу, чем занимаюсь на работе и много чего ещё?

Релиз ноутс

Функциональность сервисов и продуктов всегда меняется и развивается. Иногда это просто мелкие баги, а порой - полное изменение функционала, удаление целых разделов UI и добавление новых.

Чтобы ваши пользователи знали об исправленных ошибках и изменениях в функционале, необходимо составлять так называемые релиз ноутс (Release Notes) ?

Если кратко, то это описание произошедших изменений.

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

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

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

Бывает, что нужна консультация с бизнес аналитиком или разработчиком, если описание изменения в тикете не очень понятно.

Мы выделили для себя следующую структуру для доки:

- Стори (большие/ключевые изменения);

- Изменения по запросу бизнеса;

- Мелкие исправления UI и бэка;

- API (изменение эндпоинтов);

- Баги.

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

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

А вы создаете релиз ноутс? Если да, расскажите как у вас устроен этот процесс ?

Для тех, кто пишет или только начинает писать на английском - три полезных и интересных статьи на хабре?