И технарь, и гуманитарий. Айтишники рассказали о работе технического писателя и посоветовали курсы
Technical Writing — сфера с широкими возможностями для роста, куда приходят специалисты и с гуманитарным, и с техническим бэкграундом. В отличие от популярных IT-профессий вроде фронтендера или тестировщика, о специфике работы технических писателей известно совсем мало. Решили разобраться вместе с экспертами.
Технический писатель отвечает за создание всей документации: это могут быть user guides, релиз-ноуты, API-документация и многое другое. Мы поговорили с техническими писателями о том, как они попали в профессию, какие трудности испытывали и как сейчас организована их работа.
Своими историями поделились:
- Светлана Лесюкова — Head of Technical Writers Department,
- Дмитрий — Technical Writer,
- Татьяна Шитик — Senior Technical Writer,
- Владислава Лагун — технический писатель,
- Сергей — технический писатель.
Содержание
Примечание Adviser
В этой статье ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Как становятся писателями в IT
Сейчас, заинтересовавшись профессией техписателя, можно пройти профильное обучение и целенаправленно искать работу. Но всего несколько лет назад эта специальность была довольно редкой. Те специалисты, у которых за плечами большой опыт, скорее всего попали на эту работу случайно из других сфер.
Свой путь я начинала 7 лет назад. Закочила курсы тестирования, но найти работу джуном было сложно, а деньги были нужны. Подвернулась вакансия технического писателя от немецкой компании. Там были довольно простые требования: знание двух языков, умение пользоваться компьютером.
Я согласилась, и следующий мой запрос в Google был: «Кто такой технический писатель?» — я начала узнавать о профессии за неделю до трудоустройства. Нашла неплохую статью со ссылками на документацию, почитала, и, придя на работу, уже примерно понимала, что от меня хотят. Тогда этого было достаточно: знание немецкого и английского; умение задавать вопросы; умение «щупать» продукт, которое я получила на курсах тестирования.
Сейчас требования усложнились, компании ожидают умение писать API-документацию, релиз-ноуты, интеграционные гайды. Нужно иметь какой-то технический бэкграунд, либо быть quick learner и уметь разбираться в незнакомых вещах в очень сжатые сроки. Человек может прийти из лингвистического университета и потом разобраться в технологиях, либо, наоборот, иметь бэкграунд в качестве разработчика, а в какой-то момент понять, что писать текст ему интереснее, чем код.
Технический бэкграунд или знания — большое подспорье в работе. Если вы начали изучать программирование или тестирование, но понимаете, что больше хочется работать не с ЯП, а с человеческим языком, возможно, вам понравится техрайтинг.
Мой карьерный путь начался в 2020 году. Это был последний год моего студенчества в МГЛУ. Помимо языков для людей, я немного интересовался языками для машин и искал стажировки в этом направлении. Компания Х (тогда штат был около 120 человек) приглашала к себе на обучение с возможностью трудоустройства. Было тестовое, связанное с программирование и затем интервью, которое я провалил. Со мной связался HR, чтобы донести эту чудесную новость и… предложить выполнить тестовое задание на должность технического писателя.
Я согласился. В тот вечер у меня было открыто две вкладки браузера: с тестовым заданием и с запросом в Google «Кто такой технический писатель?». Я не знал ничего об этом ремесле. Кое-как я написал тестовое, отправил, и стал читать статьи о профессии. Показалось интересно. Через день-два меня пригласили на собеседование, еще через день я получил оффер.
Как и в любой сфере, главное — уметь быстро учиться, спрашивать обо всем непонятном и вникать в новые задачи.
Я попал на продукт, целевой аудиторией которого были разработчики. Моей задачей было описание SDK: конфигурации объектов, сниппеты кода, пути кастомизации дефолтных методов, параметры, запросы и прочее. Не будь у меня основ программирования, возможно, я бы не вывез. Было сложно. Писать нужно просто, лаконнично, объективно, уметь иногда «выпытывать» информацию. Не бояться задать «глупый» вопрос. Все это — умения, которые ты приобретаешь c опытом.
Я был единственным техническим писателем, но у меня были отличные менторы. Они помогали во всем: структура документа, стиль, лексика, ревью. Делились статьями по темам, давали примеры того, как должен выглядеть хороший документ. Я очень благодарен Оле и Насте за помощь и передаю им большой-большой привет.
В профессию приходят из различных IT-профессий. Для технического писателя важно владение английским языком. Как минимум, потому что много материалов, статей и курсов не переведены — учиться на английском будет проще. Во-вторых, международный рынок открывает больше возможностей.
Я работала бизнес-аналитиком на банковских продуктах с 2014 по 2018 год. В банке эта позиция называлась просто «специалист» и обязанности были буквально неограниченные. Я занималась непосредственно бизнес-анализом, участвовала в тестировании, помогала саппорту и даже писала финансовую отчетность по своим продуктам. Постоянные переработки привели к жуткому выгоранию. Осознала, что моя любимая часть работы — написание требований. Вспомнила что еще в школе обожала писать, нашла профессию технического писателя. Но на тот момент это казалось чем-то очень нишевым, всю информацию я находила только в англоязычных источниках и даже не была уверена, что в Минске нужны такие специалисты.
У меня уже было два высших образования инженерное и экономическое. Уровень английского я постоянно поддерживала курсами и общением, но этого явно было недостаточно чтобы предъявить в резюме. Сперва думала получить сертификацию TOEFL или ELTIS, но у сертификатов есть срок действия, что не очень подходило для моих целей. Позже я узнала о программе «Современный иностранный язык» в Академии последипломного образования. Поступила на третье высшее. Это было двухлетнее очное обучение. Полтора года я училась на вечернем, совмещая с работой бизнес-аналитиком. Последние полгода обучения я уволилась с работы: училась, искала работу, подрабатывала на фрилансе.
При смене работы важно быть готовым к тому, что на первое время вы скорее всего потеряете в доходе, а работать придется больше обычного. Но со временем труд даст свои плоды.
Было сложно найти первую работу по специальности, глядя на мой опыт мне в основном предлагали бизнес-анализ или контет. Получив заветный офер, я очень обрадовалась, несмотря на то что начинаю джуном на зарплате значительно ниже чем я получала раньше. В мои обязанности входило написание документации для JavaScript-фреймворка. Мне пришлось сходу разобраться в Git, выучить Markdown, основы HTML, CSS, JavaScript и закончить внутренний курс компании для понимании работы их фреймворка. Этот старт сложно назвать мягким, но я очень благодарна за полученный опыт. Это задало определенный стандарт ниже которого уже стало неинтересно опускаться.
После этого работала техническим писателем еще в двух компаниях. В первый раз перешла, потому что предложили зарплату значительно выше. А второй раз преследовала профессиональные цели: заинтересовало что в компании работает целая команда технических писателей, в моем воображении это выглядело как чудесный лес с единорогами.
С должной подготовкой и стремлением, можно попасть в профессию как с техническим, так и с гуманитарным бэкграундом. Но независимо от имеющегося опыта, стоит быть готовым к тому что путь в профессию будет постепенным — нужно будет разбираться с технологиями.
Почти весь мой трудовой путь заключался в создании текстового контента: рекламные и информационные тексты, посты в соцсетях, художественные повествования — у меня и хобби было с этим связано. А со временем устроился писать техническую документацию: инструкции, описания, мануалы, рисую диаграммы и схемы. Иногда, очень редко, пишу маркетинговые статьи. Работаю и с требованиями, то есть иногда совмещаю свою работу с задачами бизнес-аналитика на проектах.
По-своему гуманитарный бэкграунд полезен: техническому писателю важно смотреть на текст с точки зрения пользователя, не обладающего специальными знаниями.
Программирование поможет понимать, как устроена система. Это очень ценно, особенно для роста. Но иногда нужно представить, как бы на текст взглянул человек, который технически совсем не подкован, и вот тогда разработческий взгляд может даже мешать.
Сам я пока не программирую, поэтому пользовательскую документацию писать проще. А вот за девелоперской постоянно приходится ходить к разработчикам, чтобы они объяснили, как что работает. Тут в любом случае, если учиться, то архитектуру более-менее начинаешь понимать.
Если стремиться попасть в профессию без знания технологий, важно иметь достаточное любопытство и упорство, чтобы разбираться во всем непонятном. Отчасти это напоминает журналистскую работу.
Сам по себе опыт в копирайтинге не сильно поможет. Уметь анализировать и писать текст — это только одна составляющая, нужно еще уметь задавать вопросы, погружаться в тему самостоятельно. Из не-айти профессий ближе всего к техписателю, как мне кажется, журналист-расследователь.
Среди технических писателей много бывших программистов. Это, наверное, самый стандартный трек перехода, особенно в США: выпускник Computer Science отучился, покодил пару лет, понял, что это не его и обучать, объяснять и вести документацию ему ближе. Мне кажется, с любым техническим бэкграундом вхождение в профессию будет более легким, чем с гуманитарным просто в силу специфики предмета.
Чем занимается технический писатель
Технический писатель создает всю документацию по продукту. Важно уметь составлять разные виды текстов и создавать понятную инфографику для любой аудитории — и для самих разработчиков, и для людей, которые с компьютером на «вы».
Писатели обычно относятся к продукту: выпускаемому движку, инструменту или сервису, и они пишут только или преимущественно для пользователей продукта. То есть занимаются продуктовой документацией. Само разделение «пользовательской» и «технической» документации условно. Любая документация, которая идет к пользователю — пользовательская. Это может быть описание кнопочек или описание API. Пользователь может быть художником, дизайнером интерьеров или игроком, а может быть программистом. Поэтому я бы скорее сказала, что продуктовая документация может быть разной степени технически сложной.
Менее сложная — это UI/UX документация: разъяснения, инструкции, ответы на вопросы, туториалы, инфографика, решение частых проблем, тексты для поддержки (иногда). Более сложная — документы о деталях разработки, документация API.
Если в компании один писатель, всю документацию по продукту пишет один человек. Если команда большая, может быть специализация по отдельным компонентам. В компаниях достаточно больших, чтобы иметь писателя, но недостаточно больших, чтобы иметь разные команды писателей, техписатель может писать UX-тексты и даже маркетинговые тексты.
У нас в отделе универсальные бойцы, все умеют все. Сейчас нас 10 человек, мы работаем на 4 разных продуктах: на 3, поменьше, по одному техническому писателю и на одном большом — 6 писателей. В рамках большого продукта каждый может отвечать за определенный набор фичей.
Когда мы нанимаем специалиста, он проходит онбординг, а затем мы выпускаем его на продукт или на компонент. Созваниваемся утром, обсуждаем задачи, и дальше писатели расходятся по своим командам. На всех продуктах в своем графике проходят спринты. Перед началом каждого спринта мы смотрим, какими задачами будет заниматься команда и требуют ли они обновления документации.
Обычно документацию пишем на этапе тестирования. Далее пишем релиз-ноуты: о тех обновлениях, которые произошли по итогу спринта. Согласовываем с Product Owner и отправляем клиентам. Я называю это «документация под ключ» — мы начинаем с анализа задач, которые требуют документирования, пишем, обновляем документацию и рассказываем об изменениях. Каждый писатель может справиться с любой задачей: писать user guides, API документацию, описывать конфиги, писать релиз-ноуты.
В работу технического писателя входит не только непосредственно создание текстов, но и много общения с разработчиками, бизнес-аналитиками, продакт оунерами, тестировщиками — нужно выяснить все нюансы, чтобы затем корректно их изложить. Это профессия для общительных людей.
В первую очередь технический писатель определяет цель документа и конечного пользователя, базово изучает технологию и интервьюирует всех причастных. Это могут быть разработчики, тестировщики, бизнес-аналитики и продукт-оунеры. Внутри компании мы руководствуемся унифицированными стайл-гайдами для каждого типа документации, будь то туториал, how-to, руководство пользователя, интеграционная документация или API.
Единые требования на должность технического писателя сформулировать трудно. В общих чертах: хорошее владение языком, умение быстро разбираться в новом, базовое понимание, как устроены информационные технологии. Но конкретный список навыков и инструментов в каждой вакансии будет свой.
Требования к писателю обычно прописаны в вакансии и зависят от типа документации — это может быть знание инструментов работы с текстом (платформы типа Confluence, publishing tools — MadCap, Adobe), систем версионирования или конкретные языки программирования. Если единственный тип документации, который нужно описывать — это API, конечно, в требованиях будет минимальное знание языка программирования.
Незнание ЯП может быть ограничением на любом уровне. Зависит от того, как хранит и организует свою работу с документацией компания. Где-то ограничением будет знание языка программирования, где-то опыт программирования\тестирования, а где-то знание ГОСТов. Обычно конкретные языки не принципиальны, скорее общее понимание и опыт.
Чтобы больше узнать о профессии и получить взгляд изнутри, полезно почитать блоги известных технических писателей. Светлана Лесюкова рекомендует:
Трудности в работе
Если вы рассматриваете для себя техрайтинг, важно знать и о сложностях — которые тут есть, как в любой другой профессии.
Команда должна понимать, что качество документации зависит от количества предоставленной писателю информации. Не во всех компаниях, где я работала, это понимали. Технический писатель может в сжатые сроки разобраться в теме, но он не успеет узнать все возможные корнер-кейсы и пути их обхода. А хорошая документация как раз и содержит в себе неочевидные вещи, которые пользователь не смог сам обнаружить и пришел искать в документацию.
Еще одна сложность — процессы. Многие команды хотят писателя, но когда получают, не представляют, как его интегрировать в процесс. Важна гибкость и открытость команды, но в первую очередь сам технический писатель должен четко понимать свои точки входа. В моем случае их три: я подключаюсь на этапе требований чтобы помочь бизнес-аналитикам с UX, в течении спринта я готовлю изменения в документацию и в день релиза я публикую релиз-ноутс. Параллельно у меня могут быть задачи на внеспринтовую документацию и ревью коллег.
Другая трудность — сравнительная молодость профессии и не всем ясное виденье роли технического писателя как единицы команды. Если вы будете единственным техническим писателем в компании, будте готовы самостоятельно выстраивать процессы с коллегами и определять скоуп задач.
Рынок не лучшем состоянии, а технический писатель, скажем честно, не самая приоритетная должность при найме. Но на удивление, я сам время от времени получаю сообщения с приглашениями хотя бы посмотреть вакансии. Так что спрос есть.
Как войти в профессию
Лучший способ освоить какую-то область — искреннее заинтересоваться: читать, слушать, смотреть, гуглить, общаться с людьми. Техрайтинг не является исключением.
Когда я начинала, полезной информации было крайне мало, а сейчас есть масса материалов. Можно просто ввести «technical writing» в поиске на Amazon, и он выдаст десятки книг. На Udemy и LinkedIn можно найти курсы, ориентируясь на рейтинг. Тем, кто хочет войти в профессию, важно уметь самостоятельно искать и фильтровать информацию, постоянно быть в инфополе. Подписаться на известных технических писателей в LinkedIn, читать статьи на Medium, слушать спикеров на онлайн-конференциях. Мне кажется, у меня ни дня не бывает, чтобы я что-то да не прочитала. И когда приходят устраиваться ребята, которые говорят, что за полгода не прочитали ни одной книги, не посетили ни одного вебинара, или не прослушали ни одного курса, я искренне не понимаю, чем они тогда занимались.
Мы попросили наших героев поделиться ссылками на ресурсы, которые помогут в обучении и в работе. Надеемся, они будут вам полезны.
Прежде всего стоит обратить внимание на стайл-гайды крупных компаний. Если вы пока не имеете представления о том, что должно быть в документации и каким языком ее писать, в них ответы на эти вопросы:
Не нужно учить, достаточно знать, что они есть, чем отличаются, и их главные принципы. Всякий раз, когда пишите — заглядывайте в гайдлайны.
Светлана Лесюкова порекомендовала книги, которые будут полезны начинающим писателям. Это необходимая база, которая поможет писать кратко, емко и понятно, и расскажет о современных подходах в тех. писательстве:
- Developing quality technical information, Michelle Carey;
- Product is docs, Christopher Gales;
- Docs like code, Anne Gentle;
- Пиши, сокращай, М.Ильяхов
- Ясно, Понятно, М.Ильяхов
- Modern Technical Writing: An Introduction to Software Documentation, Andrew Etter;
- Docs for Developers, Jared Bhatti.
Одно из самых непростых, но важных направлений в профессии — работа с API-документацией. Вот несколько ресурсов и образовательных программ, которые помогут разобраться в вопросе:
- Котроткий обзорный курс The Art of API Documentation, который поможет узнать основы работы с API-документацией и понять, насколько вам это интересно;
- Курс Learn API Technical Writing на Udemy — студенты учатся работать с данными, знакомятся с форматами JSON и XML;
- Learn API Technical Writing 2 — вторая часть курса, на которой учат работать с протоколом REST;
- An Introduction to APIs — базовый курс в текстовом формате на английском языке;
- Documenting APIs: A guide for technical writers and engineers — еще один курс в текстовом формате, длинный, подробный и максимально исчерпывающий.
Помимо совершенствования своего языка и приобретения технических знаний, стоит освоить полезные сервисы для работы. Современные онлайн-инструменты помогут писать грамотные легко читаемые тексты с понятной визуализацией.
Письмо — главный инструмент. Грамматика, пунктуация — с этим не должно быть проблем. Автоматизирует это дело сервис Grammarly, но он не панацея. Думать все равно придется.
Начинающим важно работать над читаемостью и простотой текста. Поначалу может появится соблазн писать красиво и вычурно. Боритесь с этим. Техническое письмо не для того, чтобы глаголом жечь сердца людей, а для того, чтобы помочь читателю решить задачу быстро и эффективно. Советую поиграть с Hemingway App и ознакомиться с понятием Plain language. Принципы универсальны для любого языка.
Технический писатель также работает с графикой. Иногда нужно делать красивые скриншоты. На первых порах будет достаточно представления об инструментах, например Snagit.
Если вы всерьез решили попробовать себя в профессии, одной лишь теории и пассивного знакомства с инструментами будет недостаточно. Важно пробовать свои силы, писать свои варианты документации для крупных или, наоборот, несуществующих продуктов — чтобы показать что-то в портфолио. Работодатели ценят реальные кейсы, с ними проще оценить уровень кандидата.
Сейчас, наверное, непросто всем джунам, не только техписам, но и в спокойные времена одного курса начинающему писателю без опыта в IT будет недостаточно. Я бы предположила, что будут смотреть не только на курсы, но и на портфолио, пет-проекты. Нужно показать конкретные примеры работ. То, что вы прошли курс, не значит, что вы научились применять его принципы в работе.
Как понять, техрайтинг — мое или нет
Может быть обидно потратить силы на обучение, а потом понять, что профессия не подходит по тем или иным причинам. Но пока не попробуешь — не узнаешь.
Для тех, кто не знает, подойдет ли ему профессия, есть простой эксперимент. Попробуйте написать инструкцию для какого-нибудь приложения на вашем телефоне. Например «Как создать канал в Telegram» или «Как загрузить свою музыку в Spotify». Распишите каждый шаг балансируя между деталями и критически-необходимой информацией. Затем сходите в доку продукта и сравните свою и их инструкции. Если было интересно — welcome aboard.
Увлеченность всем новым и неизвестным — ключевое качество технического писателя, без которого развиваться будет трудно.
Мои родственники и друзья до сих пор не понимают, чем я занимаюсь. Когда объясняю, что пишу инструкции для разработчиков, задают вопрос: откуда я знаю что писать, ведь я не разработчик.
В этом магия профессии — уметь объяснять сложные вещи, оставаясь при этом дженералистом. Типичный портрет технического писателя — это такой отличник, который по жизни любит фиксироваться на различных темах, досконально их изучать, а потом рассказывать о своих находках окружающим. И каждый раз сталкиваясь с новым доменом, хочет погрузится глубже, закончить пару курсов, выучить пару языков программирования. Но важно останавливать себя, ведь если я изучу Go, то стану программистом, а моя цель совершенствоваться как писатель.
Куда расти в профессии технического писателя
Некоторые рассматривать техрайтинг как «простую» точку входа в IT, чтобы потом плавно перейти в программирование. Но это не лучший вариант: если хотите быть разработчиком, зачем тратить время на обучение писательству? Техрайтинг — полноценная интересная и сложная профессия, и после освоения азов возможны разные пути роста.
Мне не нравится, когда technical writing рассматривают как вход в IT. Возможно, люди с такой установкой просто не видят возможностей роста, застревают на этапе написания user guide. Но поле для развития широкое: можно делать более сложную девелоперскую документацию или заниматься UX-райтингом — эта задача во многих компаниях тоже ложится на плечи технических писателей.
Еще один из треков карьерного развития — Knowledge Management.
Это ближе к продюсеру, то есть в фокусе не люди, а документация. Это образовательно-организаторская должность, с задачами вроде распространения знаний, сбора и обработки фидбека, вовлечения пользователей в создание и развитие документации.
Позиция достаточно новая и во многих компаниях не выделена в отдельную должность, а прячется в зоне ответственности лида техписов, например. Скорее такая позиция будет в международной крупной компании, с большой базой знаний и аудиторией. Наверное, если «переводить» эту позицию в понятную плоскость, например, в образовании — это методист.
И не забывайте заходить в Adviser — мы публикуем полезные материалы о профессиональном и личностном развитии, рекомендуем курсы, делимся новостями и спецпредложениями.
Читать на dev.by