Типовой сценарий работы технического писателя

Профессия «Технический писатель» - чем занимаются технические писатели и кто это такие, что нужно знать и уметь (обязанности). Как стать Technical Writer и где учиться. Зарплаты и примеры вакансий в Москве, СПб, РФ и СНГ.

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

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

Что делают технические писатели и чем занимаются?

Обязанности на примере одной из вакансий:

  • разработка технической эксплуатационной документации и конструкторской документации на существующую и новую продукцию компании (ТУ, ТО, руководства по эксплуатации, паспорта, формуляры, чертежи, схемы и пр.);
  • подготовка документации в соответствии с требованиями ЕСКД, проверка КД на соответствие требованиям ЕСКД;
  • анализ требований проекта, требований ТЗ;
  • разработка/доработка ТЗ;
  • согласование технических решений с представителями разных подразделений компании, с заказчиком.

Что должен знать и уметь технический писатель? 

Требования к техническим писателям:

  • Собирать требования к задаче
  • Декомпозировать задачи
  • Проводить интервью с техническими специалистами
  • Передавать работу на вычитку и работать с правками
  • Планировать работу над задачей в Trello
  • Собирать данные по задаче
  • Разрабатывать техническую документацию
  • Разрабатывать техническое задание
  • Использовать языки разметки Markdown, RST, asciidoc, XML
  • Изучать целевую аудиторию продукта
  • Работать с чертежами, таблицами, графиками, блок-схемами

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

На сайте поиска работы в данный момент открыто 1 010 вакансий, с каждым месяцем спрос на технических писателей растет.

Количество вакансий с указанной зарплатой технического писателя по всей России:

  • от 70 000 руб. – 271
  • от 120 000 руб. – 142
  • от 175 000 руб. – 68
  • от 225 000 руб. – 26
  • от 275 000 руб. – 17

Вакансий с указанным уровнем дохода по Москве:

  • от 85 000 руб. – 122
  • от 130 000 руб. – 82
  • от 180 000 руб. – 42
  • от 230 000 руб. – 15
  • от 275 000 руб. – 11

Вакансий с указанным уровнем дохода по Санкт-Петербургу:

  • от 70 000 руб. – 65
  • от 105 000 руб. – 37
  • от 140 000 руб. – 22
  • от 175 000 руб. – 18
  • от 210 000 руб. – 9

Как стать техническим писателем и где учиться?

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

  • Самостоятельное обучение – всевозможные видео на YouTube, книги, форумы, самоучители и т.д. Плюсы – дешево или очень недорого. Минусы – нет системности, самостоятельное обучение может оказаться неэффективным, полученные навыки могут оказаться невостребованными у работодателя;
  • Онлайн-обучение. Пройти курс можно на одной из образовательных платформ. Такие курсы рассчитаны на людей без особой подготовки, поэтому подойдут большинству людей. Обычно упор в онлайн-обучении делается на практику – это позволяет быстро пополнить портфолио и устроиться на работу сразу после обучения.

Ниже сделали обзор 15+ лучших онлайн-курсов.

15+ лучших курсов для обучения технического писателя: подробный обзор

Стоимость: разная стоимость

  • Программа из 3 курсов
  • Упор на практику напишете 3 работы
  • Разбор кейсов
  • Бонусный курс по системе контроля версий Git.

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

Кому подойдёт этот курс:

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

Чему вы научитесь:

  1. Планировать рабочий процесс
    Будете оценивать, сколько времени требуется для работы над документацией в различных жанрах. Организуете рабочий процесс в Trello.
  2. Пользоваться инструментами
    Познакомитесь с важными для писателя функциями Microsoft Word, освоите OneDrive, Google Документы, языки разметки. Получите технические навыки: познакомитесь с HTML, CSS и git.
  3. Работать с фактурой
    Узнаете, как подготовиться к интервью с техническими специалистами, правильно задавать вопросы и вести конспекты. Научитесь собирать информацию из чертежей, таблиц, графиков.
  4. Писать грамотные тексты
    Познакомитесь с правилами стилистики, типографики и будете структурировать текст так, чтобы неподготовленный читатель всё понял. Облегчите общение между разработчиками ПО и нетехническими специалистами в компании.
  5. Разрабатывать и адаптировать документацию
    Будете создавать технические задания, паспорта, технические условия, руководства по эксплуатации и онлайн-справки. Оформлять проекты по стандартам ГОСТ, ISO, IEC и IEEE.
  6. Презентовать себя как специалиста
    Добавите в портфолио работы, которые сделаете на курсе. Сможете доказать свою ценность и полезность работодателю.

Программа

Вас ждут онлайн-лекции и практические задания на основе реальных кейсов.
23 модуля, 54 урока

Основные курсы

  1. Технический писатель. Базовый уровень
  • Введение в профессию.
  • Типовой сценарий работы технического писателя.
  • Microsoft Word и другие инструменты написания.
  • Работа с техническим текстом.
  • Зарубежные и отечественные стандарты.
  • Создание документа: техническое задание (ТЗ).
  • Создание документа: паспорт (ПС).
  • Создание документа: технические условия (ТУ).
  • Создание документа: руководство по эксплуатации (РЭ).
  • Создание онлайн-справки.
  • Управление знаниями.
  • Как получить работу технического писателя.
  1. Технический писатель-дизайнер
  • Введение.
  • Базовый HTML.
  • Базовый CSS. Часть 1.
  • Базовый CSS. Часть 2.
  • Подготовка к верстке.
  • HTML-разметка.
  • Flexbox.
  • Стилизация.
  1. Технический писатель PRO
  • Освоение инструментов визуализации.
  • Освоение технологий и средств для автоматизации документирования.
  • Technical documentation.
  1. Дипломные проекты
  • Руководство по эксплуатации

Дополнительные курсы

  1. Система контроля версий Git
  • Версии программного кода.
  • Установка Git.
  • Индекс и частичные коммиты.
  • Сравнение версий.
  • Отмена изменений и откат версий.
  • Репозитории и коллективная работа.
  • Ветки — создание и управление.
  • Слияние и разрешение конфликтов.
  • Полезные инструменты.
  • Правила работы с Git.

Дипломные проекты

  1. Руководство по эксплуатации
  • Оформите документ по ГОСТу с применением оглавления, стилей, сквозной автонумерации, перекрёстных ссылок.

Диплом Skillbox

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

Цели семинара/курса:

  • Получить знания методик и приемов подготовки технической документации;
  • Применять существующие стандарты документирования;
  • Использовать программные инструменты для технических писателей;
  • Грамотно вести переговоры с техническими специалистами;
  • Разрабатывать различные виды технических документов.

Профессиональный стандарт «Технический писатель»: содержание и требования:

  1. Техническая документация и технический писатель: основные термины и понятия. Введение в проблему.
  • Содержание работы технического писателя. Отличия технического писателя от обычного писателя и от писателя-аналитика.
  • Виды занятости, связанные с разработкой документации и основные виды создаваемых документов.
  • Навыки и умения технического писателя.
  • Задачи технического писателя. Группы читателей.
  • Варианты занятости и сферы деятельности технического писателя.
  1. Единые стандарты документирования.
  • Отечественные и зарубежные стандарты.
  • Классификация ГОСТов.
  • Зарубежные стандарты ИСО в области системной и программной инженерии.
  • Назначение стандартов.
  • ГОСТ 7.32-2001.
  • Практические рекомендации и примеры оформления технических документов на базе шаблонов, составленных по стандартам.
  • Система стандартов ГОСТ 19 и ГОСТ 34.
  • Унификация, стандартизация и нормоконтроль документирования. Единый стандарт программной документации (ЕСПД).
  • Система стандартов по информации, библиотечному и издательскому делу (СИБИД).
  • Единая система конструкторской документации (ЕСКД).
  • Единая система технологической документации (ЕСТД). Требования ГОСТ 7.32-2017 (введен 01.07.2018) к структуре и правилам составления отчетов.
  • Управление документированной информацией в контексте требований МС ISO 9001:2015.
  1. Виды и стили технических текстов.
  • Формат и структура технического документа: отчёт, ТЗ, ТП, статья: общие черты и различия.
  • Стили технической документации.
  1. Средства и методы создания технических текстов.
  • Блок целеполагания: цель, задачи, методы и средства.
  • Определение аудитории и уровня разъяснения материала.
  • Об описании БД, кодов. Создание руководств пользователя.
  • ПРАКТИКА: Корректировка имеющихся текстов: основы редактирования и корректуры.
  • Приёмы работы с техническими текстами.
  • Терминология в технической документации: правила применения единых терминов.
  • Визуализация и графическое сопровождение технических документов.
  • Работа над ошибками и лексические тонкости в технических документах.
  1. Создание векторных изображений и контроль ошибок в объемных документах.
  • Векторные изображения в документе.
  • Иллюстрации в MS Word.
  • Фотография и векторная иллюстрация в документах.
  • Методика отрисовки векторной графики в PowerPoint.
  • Специальная вставка изображений в MS Word.
  • Контроль ошибок в объемных документах.
  • Базовые процессы по контролю документации.
  • Версионирование. Системы баг-трекинга ПО — помощники технического писателя.
  • Организация контроля за ошибками и доработками в документах.
  1. Процесс перевода технической документации (на примере английского языка).
  • Сложности перевода на другой язык, основные подводные камни.
  • Грамматика и лексика в техническом переводе.
  • Правила и способы перевода технических текстов.
  • Применяемое программное обеспечение и приёмы его корректного использования.
  • Понятие локализации в технических переводах.
  • Практика: Перевод и редактирование технического текста.
  1. Программное обеспечение в работе технического писателя.
  • Базовые форматы документации: HTML, DOC(X), CHM, PDF.
  • HTML Help Workshop.
  • Средства MS Office.
  • Средства Adobe.
  • Платформа DocBook/XML.
  • Wiki-системы.
  • Облачные технологии (Google Docs, Evernote, Dropbox и др.).
  • Программное обеспечение создания презентаций и инфографики. Wiki-системы. Архитектура типизированной информации Darwin.

Цель курса:

  • Получить знания методик и приемов подготовки технической документации;
  • Применять существующие стандарты документирования;
  • Использовать программные инструменты для технических писателей;
  • Грамотно вести переговоры с техническими специалистами;
  • Разрабатывать различные виды технических документов.

Программа курса:

Техническая документация и технический писатель: основные термины и понятия. Введение в проблему.

  1. Содержание работы технического писателя. Отличия технического писателя от обычного писателя и от писателя-аналитика.
  2. Виды занятости, связанные с разработкой документации и основные виды создаваемых документов.
  3. Навыки и умения технического писателя.
  4. Задачи технического писателя. Группы читателей.
  5. Варианты занятости и сферы деятельности технического писателя.

Единые стандарты документирования.

  1. Отечественные и зарубежные стандарты.
  2. Классификация ГОСТов.
  3. Зарубежные стандарты ИСО в области системной и программной инженерии.
  4. Назначение стандартов.
  5. ГОСТ 7.32-2001.
  6. Практические рекомендации и примеры оформления технических документов на базе шаблонов, составленных по стандартам.
  7. Система стандартов ГОСТ 19 и ГОСТ 34.
  8. Унификация, стандартизация и нормоконтроль документирования. Единый стандарт программной документации (ЕСПД).
  9. Система стандартов по информации, библиотечному и издательскому делу (СИБИД).
  10. Единая система конструкторской документации (ЕСКД).
  11. Единая система технологической документации (ЕСТД). Требования ГОСТ 7.32-2017 (введен 01.07.2018) к структуре и правилам составления отчетов.
  12. Управление документированной информацией в контексте требований МС ISO 9001:2015.

Виды и стили технических текстов.

  1. Формат и структура технического документа: отчёт, ТЗ, ТП, статья: общие черты и различия.
  2. Стили технической документации.

Средства и методы создания технических текстов.

  1. Блок целеполагания: цель, задачи, методы и средства.
  2. Определение аудитории и уровня разъяснения материала.
  3. Об описании БД, кодов. Создание руководств пользователя.
  4. ПРАКТИКА: Корректировка имеющихся текстов: основы редактирования и корректуры.

Приёмы работы с техническими текстами.

  1. Терминология в технической документации: правила применения единых терминов.
  2. Визуализация и графическое сопровождение технических документов.
  3. Работа над ошибками и лексические тонкости в технических документах.

Создание векторных изображений и контроль ошибок в объемных документах.

  1. Векторные изображения в документе.
  2. Иллюстрации в MS Word.
  3. Фотография и векторная иллюстрация в документах.
  4. Методика отрисовки векторной графики в PowerPoint.
  5. Специальная вставка изображений в MS Word.
  6. Контроль ошибок в объемных документах.
  7. Базовые процессы по контролю документации.
  8. Версионирование. Системы баг-трекинга ПО — помощники технического писателя.
  9. Организация контроля за ошибками и доработками в документах.

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

  1. Сложности перевода на другой язык, основные подводные камни.
  2. Грамматика и лексика в техническом переводе.
  3. Правила и способы перевода технических текстов.
  4. Применяемое программное обеспечение и приёмы его корректного использования.
  5. Понятие локализации в технических переводах.
  6. Практика: Перевод и редактирование технического текста.

Программное обеспечение в работе технического писателя.

  1. Базовые форматы документации: HTML, DOC(X), CHM, PDF.
  2. HTML Help Workshop.
  3. Средства MS Office.
  4. Средства Adobe.
  5. Платформа DocBook/XML.
  6. Wiki-системы.
  7. Облачные технологии (Google Docs, Evernote, Dropbox и др.).
  8. Программное обеспечение создания презентаций и инфографики. Wiki-системы. Архитектура типизированной информации Darwin.

Для кого:

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

Программа:

  1. Профессиональный стандарт «Технический писатель»: содержание и требования.
  2. Единые стандарты документирования.
    Практические рекомендации и примеры оформления технических документов на базе шаблонов, составленных по стандартам. Система стандартов. Унификация, стандартизация и нормоконтроль документирования. Единый стандарт программной документации (ЕСПД). Система стандартов по информации, библиотечному и издательскому делу (СИБИД). Единая система конструкторской документации (ЕСКД). Единая система технологической документации (ЕСТД). Требования ГОСТ 7.32-2017 (введен 01.07.2018) к структуре и правилам составления отчетов. Управление документированной информацией в контексте требований МС ISO 9001:2015. Мастер-класс: «Сложности написания руководства пользователя по ГОСТ 34».
  3. Методы и приемы работы с техническими текстами.
    Методы аналитико-синтетической переработки, используемые в техническом писательстве. Этапы создания технического текста. Изучение целевой аудитории: метод сценариев. Создание плана технического текста: интеллектуальное картирование, определение структуры текста. Техническое аннотирование и реферирование. Оформление цитирования. Читабельный текст: функциональность стиля, информативность и дизайн. Виды функциональных стилей в технической коммуникации. Терминология в технической документации. Информационный дизайн технического документа. Визуализация информации и применение инфографики в техническом документе. Особенности создания и использования деловой графики. Мастер-классы: структурирование информации при создании технической документации. Создание инфографики для визуализации научно-технической информации. Создание и оформление технического задания, отчета, руководства пользователя.
  4. Техническая коммуникация и техническое писательство.
    Особенности технического документирования. Информационные барьеры технической коммуникации между разработчиком высокотехнологичного продукта и его потребителем и возможности их преодоления. Навыки, необходимые техническому писателю. Формат и структура технического документа. Методы копирайтинга научно-технической рекламы, используемые в техническом писательстве. Принципы популяризации научно-технического текста.
  5. Промышленный подход к разработке документации.
    Разработка документации на основе принципа единого источника. Стандарт DITA. Особенности внедрения технологии DITA на предприятии, целесообразность использования XML-подобных документов. Разработка структурированного контента разных типов, смысловая разметка документов, формирование документа из карты и топиков, профилирование. Oxygen. Практическое занятие.
  6. Принципы создания технических текстов.
    Целевое назначение технической документации: определение целей обращения пользователей к техническим документам. Метод сценариев и основы проектирования опыта взаимодействия для определения содержания технических документов. Практический опыт взаимодействия технического писателя и технического специалиста при сборе информации. Мастер-класс: создание научно-технического рекламного текста.
  7. Оформление текста по ГОСТ 2.105 «ЕСКД.
    Общие требования к текстовым документам». Параметры для оформления текста в электронном виде. Правила оформления таблиц.
  8. Документация, ориентированная на пользователя:
    Help и онлайн-справка. Confluence. Создание профессиональных справочных файлов. Формирование справки с помощью Robohelp.
  9. Документирование программного обеспечения, программно-аппаратных изделий.
    Предмет документирования: программный продукт, документация пользователя и ее характеристики. Документы, используемые при эксплуатации программного продукта.
  10. Создание векторных изображений и контроль ошибок в объемных документах.
    Векторные изображения в документе. Технический писатель или дизайнер? Иллюстрации в MS Word. Фотография и векторная иллюстрация в документах. Методика отрисовки векторной графики в PowerPoint. Специальная вставка изображений в MS Word. Контроль ошибок в объемных документах. Базовые процессы по контролю документации. Страхи при написании объемной документации. Версионирование. Системы баг-трекинга ПО помощники технического писателя. Организация контроля за ошибками и доработками в документах.
  11. Секреты мастерства.
    Инструменты, используемые техническими писателями. Microsoft Word — секреты мастерства для технического писателя. Шаблоны. Применение, создание и изменение стилей. Форматирование абзацев заголовка, текста, списка, таблицы. Многостраничные таблицы. Формирование оглавления. Создание многоуровневой нумерованной структуры документа. Добавление названий к объектам. Перекрестные ссылки. Специальные поля в документе. Автозаполнение типовых документов с помощью полей слияния. Автозамена и автотекст. Расширенные возможности поиска и замены. Регулярные выражения. Макетирование. Связанные надписи. Печать брошюры.
  12. Программное обеспечение в работе технического писателя.
    HTML Help Workshop, средства Adobe, платформа DocBook/XML. Облачные технологии (Google Docs, Evernote, Dropbox и др.). Программное обеспечение создания презентаций и инфографики. Wiki-системы. Архитектура типизированной информации Darwin. Практика: ознакомление с возможностями отдельных программных комплексов.

Стоимость: нет информации

Краткое описание курса:

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

Задания идут от простых к сложному. Сначала учишься писать деловое письмо, но очень быстро материал усложняется. Большая часть курса посвящена правильному написанию мануалов «от» и «до»: т.е. как описание всей функциональности продукта, так и описание FAQ.

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

Последнее задание — это написание технического отчета по выбранной теме.

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

Стоимость: нет информации

Краткое содержание курса:

Модуль 1 — Профессия технический писатель

  • Основные обязанности технического писателя
  • Маркетинговые и технические тексты
  • Технический писатель + Аналитик
  • Основные профессиональные навыки технического писателя
  • Дополнительные задачи технического писателя

Модуль 2 — Поиск работы технического писателя

  • Поиск вакансии
  • Составление резюме
  • «Хорошее» собеседование
  • Определение текущих навыков
  • Составление плана профессионального развития

Модуль 3 — Техническая документация

  • Структура технического документа
  • Программный продукт и программное средство
  • Стили технической документации
  • Единые стандарты документирования
  • Написание статей

Модуль 4 — Этапы документирования

  • Место технической документации в проекте
  • Постановка задачи для технического писателя
  • Интервью
  • Работа технического писателя в команде
  • Вычитка, тестирование и размещение документации

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

  • Особенности перевода
  • Техническая документация на английском языке
  • Названия основных элементов интерфейса на английском языке

Модуль 6 — Инфостиль

  • Инфостиль в технической документации
  • Основы инфостиля

Модуль 7 — Особенности организации процесса документирования

  • Оценка сроков документирования
  • Вёрстка документа

Модуль 8 — Текст в интерфейсе

  • Правила написания текста в интерфейсе
  • Психология пользователей

Модуль 9 — Видео-инструкции

  • Текст или видео
  • Процесс создания видео-инструкции

Модуль 10 — ПО в работе технического писателя

  • Список ПО технического писателя
  • Особенности работы в Confluence.

Стоимость: нет информации

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

  1. Выбор темы для видео инструкции
  2. Запись видео инструкции в виде скринкаста
  3. Размещение видео инструкции на видео хостинге
  4. Отправка задания на общественную экспертизу
  5. Дополнительные ресурсы.

Технический писатель (technical writer) в IT составляет техническую документацию к программам и поддерживает ее в актуальном состоянии. Его задача – донести до пользователя информацию об особенностях работы программы, ее основных функциях и проблемах, которые могут возникнуть.

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

Для кого этот курс:

  1. для студентов с хорошим знанием английского языка (уверенный Intermediate и выше);
  2. для копирайтеров, у которых есть навыки письма на английском, но нет опыта подготовки технической документации;
  3. для специалистов, которые занимаются написанием документации и сталкиваются с проблемой лаконичного изложения, грамотного структурирования и оформления текста;
  4. для всех, кто владеет английским на уровне Intermediate и выше и планирует попробовать себя в сфере IT.

Вы узнаете

Основа курса – получение теоретических и практических навыков создания документации:

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

Программа курса:

  1. Вводное занятие
  2. Работа на IT проектах
  3. Техническая документация в IT-проектах
  4. Описание пользовательского интерфейса
  5. Организация документа на микроуровне
  6. Организация документа на макроуровне
  7. Task-oriented documentation Часть 1
  8. Task-oriented documentation Часть 2
  9. Concept topic, reference topic, troubleshooting topic
  10. Визуализация информации
  11. Оформление и редактирование
  12. Инструменты управления проблемами, задачами, проектами и wiki software на примерах программ Jira и Confluence
  13. Инструменты создания пользовательской справки, статических сайтов
  14. Итоговое занятие
  15. Экзамен. Подготовка итогового проекта (2 недели)
  16. Защита итогового проекта.

Курсы для технических писателей, проводимые компанией «ПроТекст», являются первым в России полноценным образовательным проектом в области документирования. Курс разработан техническими писателями-практиками с большим стажем и одобрен Новосибирским государственным техническим университетом в 2012 году. В 2014 году курс также одобрил Белорусский государственный университет.

Цель курса: Подготовка специалистов в области разработки технической документации и аналитики в IT-сфере.

Стоимость: 16 800 ₽ — 21 100 ₽

Цель курса: Повышение квалификации специалистов в области разработки технической документации и аналитики в IT-сфере.

Темы курса:

  1. Введение в специальность
  2. Как стать техническим писателем
  3. Юридические и территориальные аспекты работы
  4. Типы текстов и их пользователей
  5. Форматы документации и статей
  6. Стили технических текстов
  7. Основы написания технических текстов
  8. Методика написания документации на ПО и оборудовании
  9. Методика написания технических и аналитических статей
  10. Методика разработки видеодокументации
  11. Методика разработки презентаций
  12. Методика описания программного кода, баз данных и принципиальных схем оборудования
  13. Методика разработки технических заданий
  14. Методика разработки маркетинговых текстов
  15. Работа с переводной документацией.
  16. Технические переводы
  17. Эргономика в сети. Как оформлять сайты
  18. Применяемое программное обеспечение
  19. Специфика работы технического редактора
  20. Производственные процессы
  21. Обзор дополнительных областей
  22. Стандарты в документировании
  23. Что можно освоить самостоятельно?
  24. Тестирование документации
  25. Итоговая практическая работа
  26. Итоговая работа включает в себя несколько заданий: документация на программное обеспечение; статья-обзор или аналитическая статья; презентация продукта для представления на публичном мероприятии или «продающий» текст.

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

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

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

Стоимость: 11 200 ₽ — 14 490 ₽

Компетенции, которые вы приобретёте в процессе обучения:

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

Вы научитесь:

  1. разрабатывать различные виды технических документов;
  2. применять существующие стандарты документирования;
  3. использовать программные инструменты для технических писателей;
  4. грамотно вести переговоры с техническими специалистами.

Программа курса:

  • Модуль 1. Техническая документация и технический писатель: основные термины и понятия. Введение в проблему (1 ак. ч.)
  • Модуль 2. Виды и стили технических текстов (2 ак. ч.)
  • Модуль 3. Средства и методы создания технических текстов (3 ак. ч.)
  • Модуль 4. Единые стандарты документирования (2 ак. ч.)
  • Модуль 5. Приёмы работы с техническими текстами (1 ак. ч.)
  • Модуль 6. Процесс перевода технической документации (на примере английского языка) (2 ак. ч.)
  • Модуль 7. Программное обеспечение в работе технического писателя (2 ак. ч.)
  • Модуль 8. Текущая аттестация (3 ак. ч.)

Стоимость: 10 900 ₽ — 12 900 ₽

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

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

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

Успешное окончание обучения по программе курса позволит специалистам:

Знать:

  • существующие виды и стили технических документов
  • основные принципы и единые стандарты технического документирования
  • этапы и тонкости разработки технической документации

  Уметь:

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

Владеть:

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

Содержание:

  1. Профессия технический писатель
  2. Особенности написания технической документации. Основные принципы написания технической документации
  3. Этапы документирования. Работа с задачей на документирование
  4. Особенности разработки ГОСТовой документации
  5. Разработка внутреннего руководство по стилю
  6. Типы программных продуктов
  7. Предмет документирования. Способы чтения документации пользователем
  8. Детальность изложения в технической документации
  9. ГОСТ 19. ГОСТ 34. Структура ТЗ
  10. Структура Руководства пользователя
  11. Международные стандарты документирования. Особенности написания документации на английском языке
  12. Правила вёрстки. Основные ошибки в вёрстке технической документации. Плюсы и минусы различных программ для вёрстки
  13. Основные принципы дизайна
  14. Роль скриншотов в документе. Правила оформления скриншотов. ПО для создания и оформления скриншотов
  15. ПО для планирования рабочего времени. ПО для написания документации
  16. ПО для создания иллюстраций и схематических изображений. ПО для работы с виртуальными машинами
  17. Создание обучающих видеороликов. ПО для создания обучающих видеороликов
  18. Практические задания:
  • Обсуждение фрагментов инструкции.
  • Написание простой инструкции.
  • Поиск необходимого документа и чтение необходимого ГОСТа.
  • Оформление Руководства пользователя по ГОСТу.
  • Сверстать документ.
  • Найти 3 некорректных и 3 корректных скриншота.
  • Написать инструкцию и вставить в неё скриншоты.

Стоимость: разная стоимость

Дистанционные курсы:

  1. Профессиональная разработка документа «Пояснительная записка» по ГОСТ
    Курс предназначен
    для технических писателей, разработчиков документации на программные продукты, программистов, руководителей проектов и IT-специалистов, занятых в области проектирования автоматизированных систем и программных продуктов для государственных и коммерческих заказчиков.
    В курсе подробно рассматривается процесс создания одного из самых сложных документов технического проекта — Пояснительной записки.
  2. Разработка и оформление эксплуатационной документации на техническое устройство согласно требованиям ГОСТ ( ЕСКД)
    Данный курс
    посвящен вопросам разработки, оформления и согласования эксплуатационной документации (ЭД) для технических устройств. Рассмотрены основные виды ЭД, комплектность ЭД, принципы формирования обозначения документа.
    Приведены правила согласования ЭД и примеры оформления документа. На примерах показана последовательность разделов документа.
    Объясняется структура и содержание разделов конкретных ЭД (паспорт, формуляр, руководство по эксплуатации, ведомость эксплуатационных документов и др.), правила оформления графической и текстовой информации. Приведены ссылки на стандарты, в соответствии с которыми разрабатывается ЭД.

И др.

Курсы:

  1. Открытый онлайн-курс по технической документации в IT-проектах
    Расскажем обо всем понемногу: о типах технических документов, об управлении документационными процессами и о документационном инструментарии.
  2. Technical Writing 101, базовый курс по документированию
    Курс будет интересен как будущим профессионалам в области документирования (мы помогаем нашим студентам с трудоустройством), так и компаниям: мы можем целевым образом подготовить вам сотрудников на целый документационный отдел.
  3. Advanced Technical Writing
    Семинар для практикующих техписателей.
    Расскажем тонкости и хитрости, интересные для специалистов с опытом.

И др.

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

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

Успешное прохождение курса позволит претендовать на позицию стажера или младшего технического писателя в Центр разработки Orion Innovation (ранее MERA).

Содержание курса:

  1. What is the job of a technical writer?
  2. Technical writing for IT products.
  3. Technical writing tools: overview.
  4. Technical writing style.
  5. Content development process.
  6. Planning documentation.
  7. Topic-based writing.
  8. Document review.
  9. Practice — Working with MS Word.
  10. Practice — Working with graphical tools.
  11. Practice — Writing task topics.

Разработка типовых сценариев работы с системой

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь

 

writer

Администратор

Сообщений: 1890
Баллов: 2422
Рейтинг:

80

Авторитет:

80

Регистрация: 03.04.2007

#1

Мне нравится0

20.06.2014 13:41:44

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

 

techwriter

Эксперт

Сообщений: 408
Баллов: 826
Рейтинг:

15

Авторитет:

15

Регистрация: 05.08.2013

#2

Мне нравится0

25.06.2014 09:23:06

А что из себя представляет типовой сценарий работы с ПО и чем он отличается от инструкции или руководства?

 

ADVANCED

Эксперт

Сообщений: 1782
Баллов: 1965
Рейтинг:

1

Авторитет:

1

Регистрация: 07.07.2010

#3

Мне нравится0

25.06.2014 10:59:13

А какая там структура может быть? Вопроc- ответ.

Как распечатать консолидированный отчет МСФО за 2014 год?
Открыть то-то, нажать то-то бла-бла-бла… ну и пару примечаний, про права доступа и проверку бумаги в принтере перед печатью. Все.  

 

Nadufka

Эксперт

Сообщений: 205
Баллов: 1164
Рейтинг:

12

Авторитет:

12

Регистрация: 18.03.2011

#4

Мне нравится0

25.06.2014 11:17:57

Мы расписываем по шагам:

Шаг 1:
Сделать то-то, результат такой-то, скрин со стрелками для наглядности. Ссылка на место в руководстве.

Работать надо не 12 часов, а головой.

 

#5

Мне нравится0

01.07.2014 11:51:33

Делюсь, набором анкет:
ЕМ-Д-01 Анкета для оценки инструкции по процессу/процедуре,
ЕМ-Д-02 Анкета для оценки Положения о подразделении,
ЕМ-Д-03 Анкета для оценки должностной инструкции,

скачать АНКЕТЫ — doc

PS: Найдено в открытых источниках интернета

 

Виктор Фигурнов

Эксперт

Сообщений: 303
Баллов: 782
Рейтинг:

6

Авторитет:

6

Регистрация: 29.05.2014

#6

Мне нравится0

01.07.2014 13:44:04

Цитата
ADVANCED пишет:
А какая там структура может быть? Вопроc- ответ.

Как распечатать консолидированный отчет МСФО за 2014 год?

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

 

ADVANCED

Эксперт

Сообщений: 1782
Баллов: 1965
Рейтинг:

1

Авторитет:

1

Регистрация: 07.07.2010

#7

Мне нравится0

01.07.2014 14:33:44

Цитата
Виктор Фигурнов пишет:

Цитата
ADVANCED пишет:
А какая там структура может быть? Вопроc- ответ.

Как распечатать консолидированный отчет МСФО за 2014 год?

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

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

 

Виктор Фигурнов

Эксперт

Сообщений: 303
Баллов: 782
Рейтинг:

6

Авторитет:

6

Регистрация: 29.05.2014

#8

Мне нравится0

01.07.2014 15:14:04

Цитата
ADVANCED Это рассказывается в предыдущем шаге также в виде Вопрос-Ответ с названиями окон, кнопок и форм. И скриншоты тоже добавляются.

Я спросил «как создать» — а вы отвечаете на совсем другой вопрос: «где это должно быть описано».    I-о

У меня рядом стоят две книжки о том, как составлять консолидированную финансовую отчетность по МСФО — одна на 370 страниц, другая — 720 страниц большого формата.

И я не могу сказать, что там есть что-то лишнее.

Вы уверены, что столь обширный и методически сложный предмет можно изложить в виде «предыдущего шага» с названиями окон, кнопок и форм, и скриншотов?  :D

 

ADVANCED

Эксперт

Сообщений: 1782
Баллов: 1965
Рейтинг:

1

Авторитет:

1

Регистрация: 07.07.2010

#9

Мне нравится0

01.07.2014 16:22:28

Цитата
Виктор Фигурнов пишет:

Цитата
ADVANCED Это рассказывается в предыдущем шаге также в виде Вопрос-Ответ с названиями окон, кнопок и форм. И скриншоты тоже добавляются.

Я спросил «как создать» — а вы отвечаете на совсем другой вопрос: «где это должно быть описано».

У меня рядом стоят две книжки о том, как составлять консолидированную финансовую отчетность по МСФО — одна на 370 страниц, другая — 720 страниц большого формата.

И я не могу сказать, что там есть что-то лишнее.

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

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

http://techwriters.ru/forum/messages/forum598/topic19760/message10420/#message10420

.    :)

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

Изменено: ADVANCED01.07.2014 16:35:53

 

writer

Администратор

Сообщений: 1890
Баллов: 2422
Рейтинг:

80

Авторитет:

80

Регистрация: 03.04.2007

#10

Мне нравится0

01.07.2014 20:42:27

Цитата
techwriter пишет:
А что из себя представляет типовой сценарий работы с ПО и чем он отличается от инструкции или руководства?

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

 

Виктор Фигурнов

Эксперт

Сообщений: 303
Баллов: 782
Рейтинг:

6

Авторитет:

6

Регистрация: 29.05.2014

#11

Мне нравится0

02.07.2014 12:06:19

Цитата
techwriter пишет:
А что из себя представляет типовой сценарий работы с ПО и чем он отличается от инструкции или руководства?

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

http://deseng.ryerson.ca/dokuwiki/design:usage_scenario
http://www.redline-software.com/eng/products/surfcop/scenarios/

Сценарии использования также широко используются на этапе проектирования. См., например, A. Cockburn «Writting Effective Use Cases»

http://alistair.cockburn.us/get/2465

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

Иногда различают «usage scenario» и «use case» — первый вид сценариев более персонализированный и конкретный, а второй — более общий, в котором может рассматриваться не конкретная задача, а класс задач, и в котором могут описываться различные варианты (ответвления) сценария.

 

writer

Администратор

Сообщений: 1890
Баллов: 2422
Рейтинг:

80

Авторитет:

80

Регистрация: 03.04.2007

#12

Мне нравится0

02.07.2014 14:34:25

Виктор, огромное спасибо за ссылки и грамотное объяснение того, что есть —  сценарии! vipivka-smile

 

techwriter

Эксперт

Сообщений: 408
Баллов: 826
Рейтинг:

15

Авторитет:

15

Регистрация: 05.08.2013

#13

Мне нравится0

02.07.2014 16:26:57

Цитата
writer пишет:
ну к примеру, есть банковское ПО, руководство пользователя описывает всю инструкцию для пользователя, что нужно и не нужно, а типовой сценарий работы, это что-то типа «Как положить денежку на карту», «Как снять денежку», «Как посмотреть баланс на карте» вот такие сценарии.

В руководстве пользователя разве эти действия не описываются? Изложение руководства пользователя может идти от интерфейса и от действий пользователя. Я обычно исхожу как раз от действий пользователя. Если изложение от действий, то в нем оно строится таким образом: цель, которую нужно достичь пользователю — действия, которые необходимо выполнить. Если достичь цель можно несколькими способами, то описываются все случаи. Я так понимаю, что сценарии просто кратко описывают процедуру выполнения действий пользователя для достижения целей (без подробного описания полей формы, например). Допустим, «Зайдите в такой-то раздел, нажмите такую-то кнопку, заполните такую-то форму и т.д., и т.п. Мне даже больше тест-кейсы напоминает, чем юз-кейсы. Только более мультимедийные.

techwriter.ru.com

 

techwriter

Эксперт

Сообщений: 408
Баллов: 826
Рейтинг:

15

Авторитет:

15

Регистрация: 05.08.2013

#14

Мне нравится0

02.07.2014 16:29:52

Цитата
Виктор Фигурнов пишет:
Более подробно смотрите здесь: http://deseng.ryerson.ca/dokuwiki/design:usage_scenario
http://www.redline-software.com/eng/products/surfcop/scenarios/

Такие сценарии, скорее, при проектировании пишутся.

techwriter.ru.com

 

writer

Администратор

Сообщений: 1890
Баллов: 2422
Рейтинг:

80

Авторитет:

80

Регистрация: 03.04.2007

#15

Мне нравится0

11.07.2014 08:31:56

Цитата
techwriter пишет:
В руководстве пользователя разве эти действия не описываются?

Не всегда, сценарии это на мой взгляд более жизненные примеры и , действительно, более наглядные.

 

techwriter

Эксперт

Сообщений: 408
Баллов: 826
Рейтинг:

15

Авторитет:

15

Регистрация: 05.08.2013

#16

Мне нравится0

15.07.2014 12:14:51

Цитата
writer пишет:
Не всегда, сценарии это на мой взгляд более жизненные примеры и , действительно, более наглядные.

Я сейчас как раз описываю примеры настройки интерфейса (списков, форм). Но я там пишу по такому принципу: если ввести такое-то значение, то будет так-то. И прилагаю скриншот с результатом.

techwriter.ru.com

 

techwriter

Эксперт

Сообщений: 408
Баллов: 826
Рейтинг:

15

Авторитет:

15

Регистрация: 05.08.2013

#17

Мне нравится0

31.07.2014 17:36:28

Случайно наткнулась:

http://www.agiledocs.com/writing-user-stories-agile-infographic/

techwriter.ru.com

Новая роль в команде: технический писатель

Привет! Я Катя, руководитель группы технических писателей в Ozon. Сейчас нас уже 9 человек и целая платформа документации, но коллеги всё ещё не всегда понимают, чем мы занимаемся.

Из непонимания появляются запросы вида: “Хотим себе собственного техписателя в команду, но не знаем, чем именно он будет заниматься”. В итоге команда подстраивается под тренды и заводит себе документацию, но через пару месяцев оказывается, что доку не читают, а техписатель плавно превратился в аналитика.  

Поэтому пришло время делиться опытом и рассказывать о каких-то концептуальных штуках ​  :)

Кто вообще такие технические писатели?

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

В Ozon технические писатели занимаются глобально тремя направлениями: 

  • пользовательской документацией (Помощь, База знаний, FAQ), 

  • документацией внешних API, 

  • описанием внутренних систем — от онбордингов до сложных архитектурных взаимодействий. 

Какое в итоге «правильное» занятие для техписа — поле для холивара — в Ozon вот так, в других компаниях может быть иначе. Когда я работала в Яндексе, например, конкретно моя команда не сильно занималась внутренними документами. 

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

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

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

Как понять, что пора заводить технического писателя?

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

 Но есть нюансы: 

  1. Документации нет и это не создаёт никаких реальных проблем — техписатель не нужен.  

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

  3. В системе часто что-то меняется — чаще, чем приходится систему кому-то объяснять — проще рассказать на словах, чем поддерживать все изменения. Часто можно сказать: «Ребята, сейчас используем вот эту штуку, документация на официальном сайте», а не расписывать подробные инструкции, которые через пару месяцев уже будут не нужны. 

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

Где искать технических писателей и как оценивать кандидатов?

Я пришла в техписательство после бакалавриата компьютерных наук в Иннополисе, года автоматизированного тестирования и академии от Яндекса. 

Кто-то приходит из лингвистов и филологов со стремлениями уйти в аналитику или разработку. Я стараюсь искать (особенно стажеров) по техническим вузам; там довольно много ребят, осознавших, что кодить 24/7 — не их стезя. А вот что-то рядом, но чуть гуманитарнее — наш идеальный кандидат. 

Если нужен сильный специалист, который всё вам сделает под ключ — профильные сообщества, митапы. Если хватит и молодого, зеленого, но перспективного — чаще всего это кандидат совсем без опыта, но с сильным тестовым и пониманием мира IT. 

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

Как выстроить процесс?

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

 В общем виде документация создаётся по такому сценарию: 

  1. Определить цель документа и его аудиторию.  

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

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

  4. Наполнять документ и параллельно отдавать на вычитку коллегам-техписателям и экспертам. 

  5. Финализировать структуру и тексты — обязательно отдать кому-то на вычитку и после этого презентовать заказчику. 

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

Ещё один тонкий момент — что именно может править заказчик. Оговорите это сразу, при постановке задачи: важно, чтобы заказчик не пытался переписать ваш текст согласно своему субъективному взгляду. Факты и термины — да, тут он эксперт, но вкусовщину надо учиться фильтровать. 

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

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

Нужен ли вам техписатель: чеклист 

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

  • Кому может понадобиться документация к моему проекту? Моим же разработчикам, внешним пользователям? 

  • Как проблема отсутствия документации решается сейчас? Система понятна и без дополнительного описания? Может, кто-то уже снял обзор по этой теме на YouTube? 

  • Если документация всё же нужна, в каком виде её будет удобно потреблять? Всплывающие подсказки, вебинары, отдельный URL с базой знаний? 

  • Чем будет заниматься технический писатель, когда напишет документацию? Продолжит её актуализировать? Перейдёт на соседний проект? 

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


Что дальше?

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

И, конечно же, ждать подробностей в следующих статьях ​:)

Статья размещена на сайте Мили Котляровой — фрилансера с 10-летним стажем, монтажера, контент-маркетолога и сценаристки. Если хотите каждый день читать о фрилансе, работе с заказчиками и освоении новой профессии, подписывайтесь на канал Digital Broccoli в Телеграме.

Упоминающиеся в тексте Instagram и Facebook признаны на территории РФ экстремистскими.

Текст Нины Ереминой

Всё больше компаний ищут специалистов на позицию технического писателя: на момент публикации на Хабре 167 вакансий по запросу «технический писатель», а на Upwork — 708. И, по версии Бюро статистики труда США, заинтересованность в профессии будет только расти, потому что на рынке постоянно появляются новые продукты. В среднем технический писатель зарабатывает 91 тысячу рублей.

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

Что делает технический писатель?

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

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

Создание документации

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

Виды документации: 

  • Пользовательская документация

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

  • Administrator Guide

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

  • Developer Guide

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

  • Whitepapers 

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

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

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

Техническая коммуникация

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

Например, если в пользовательской документации вы называете админку Admin dashboard, то она не должна внезапно стать Admin panel в одной из статей. Чтобы сохранить единство терминологии и стандартов, технический писатель разрабатывает внутреннюю базу знаний, где всё это прописано, и может обучать новых сотрудников компании.

Смежные области

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

Ещё можно приобрести экспертизу в смежных областях, например, можно стать:

  • UX-писателем — он помогает улучшить тексты в интерфейсе продукта или приложения;
  • инженером по документированию (DocOps) — он поддерживает процессы автоматизации документации и переводов;
  • инженером по локализации — он занимается техническим переводом;
  • техническим евангелистом (специалистом по Developer Relations) — он скорее технический маркетолог, и продвигает технические решения среди коллег или на рынке. Главное отличие евангелиста от маркетолога — знание всех технических аспектов продукта, и чаще всего технический бэкграунд.

Что нужно знать? Инструменты технического писателя

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

  • Язык

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

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

  • Копирайтерские навыки

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

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

  • Технические знания

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

  • Профессиональные текстовые редакторы

Инструменты, которыми пользуется технический писатель, зависят от задач и степени сложности. Начинать писать документацию можно и в Google Docs, но с увеличением количества связей и уровней будет сложно её поддерживать. Тогда на помощь приходят профессиональные редакторы для технических писателей: MadCap Flare или Confluence. 

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

  • Руководства по стилю

Руководства по стилю — это сборники правил, они помогают соблюсти требования к оформлению, принятые в определённой среде или типе документов. В них можно проверить правила пунктуации, выбора слов и форматирования. Например, Chicago Manual of Style чаще всего используют для написания работ, связанных с историей и общественными науками.

Примеры руководств:

  • Microsoft Manual of Style
  • The Guardian and Observer Style Guide
  • Apple Style Guide
  • Google Developer Documentation Style Guide

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

Александр Петрович, руководитель отдела технической документации из Macroscop, советует досконально изучать интересующую область: 

«Я считаю, что стартовать надо в той области знаний, в которой вы компетентны. Либо прокачать свои знания в той сфере, с которой вы планируете начать свой путь техписателя. Для работы в IT, например, я настоятельно рекомендую освоить как минимум HTML и CSS, а оптимально — ещё и основы JavaScript и распространённых веб-фреймворков.

Без владения современными инструментами подготовки визуального контента тоже не обойтись. Я имею в виду редакторы векторной и растровой графики, средства подготовки веб-анимации и другие подобные инструменты. А с учётом того, что мир стремительно “скатывается” из текста к видео, не исключено, что скоро от техрайтеров потребуются навыки видеосъёмки, монтажа, а возможно и актёрское мастерство».

Как сделать портфолио?

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

  • Включайте только документы, которые имеют отношение к техническому письму. 
  • На ClickHelp рекомендуют найти что-то близкое из того, что вы уже писали. Главное, чтобы это был формальный текст с чёткой структурой, например, отчёт. 
  • На Reddit делятся информацией о заданиях для техрайтеров, из которых можно собрать портфолио, даже если реальных задач ещё не было. Встречаются любопытные задания, например, переписать инструкцию по сборке мебели из IKEA словами.
  • Возьмите инструкцию к сервису и попробуйте её улучшить.
  • Примите участие в ежегодном Season of Docs от Google, где технические писатели создают документацию для реальных проектов.
  • Поищите опенсорсные проекты на GitHub и предложите им написать документацию для пользователей. Это поможет вам поработать над реальной задачей, получить отзывы, и повысит шансы на отбор в Season of Docs.

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

«Для себя я определилась: мне больше нравится писать на русском, нежели на английском или немецком. Навык работы с текстами и базовые знания о программировании у меня на тот момент уже были, поэтому я заполнила резюме на hh.ru, указала их все, а вместо опыта описала похожие на работу технического писателя активности на учёбе.

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

Где учиться?

Курсы

  • Бесплатный курс на Stepik начинается с теста на уровень английского, который состоит из четырех частей. Он проверяет грамматику и словарь и опирается в оценке на Кэмбриджскую систему оценки знаний. В нем освещаются темы грамматики, выбора слов, которые соответствуют стилю, и пунктуации. В конце курса вы сможете пройти тест. Курс не расскажет, как работать техрайтером, но поможет снять стресс насчет языка.
  • Курс по API документации на Udemy преподаёт Питер Грюнбаум (Peter Gruenbaum), разработчик, который стал техническим писателем и специализируется на API документации. Стоимость курса $24.99, но на Udemy часто бывают скидки.
  • Курс Technical Writing: Documentation on Software Projects создан для разработчиков, но его можно проходить тем, кто собирается заниматься только письмом. Автор курса детально разбирает процесс создания технических документов, даёт советы, как писать и оформлять документацию для разработчиков, тестировщиков и конечного пользователя. Платформа платная, но деньги списываются через 2 недели, за которые можно пройти курс.
  • TCTrain Professional Course полноценный курс от организации TeKom на 8 месяцев. С сертификатом и нагрузкой на 7 часов в день. Цена на сайте не указана. 
  • Бесплатный курс от Google, который предназначен для разработчиков, но вполне подойдёт для того, чтобы познакомиться с тем, как писать понятную техническую документацию, как её правильно форматировать и использовать язык разметки.
  • Курсы для тех, кому сначала хочется освоиться с технической частью. Легендарный курс CS50 по основам программирования поможет понимать, о чём говорят коллеги, и увереннее чувствовать себя в технических темах. На Coursera есть курс Google IT support, который поможет разобраться, как устроена техподдержка.

Каналы и блоги

  • Ютуб-канал documentat.io расскажет про основные инструменты и стандарты. На нем собраны видео с бесплатного курса, который периодически повторяется.
  • Интервью Как стать техническим писателем.
  • Тред /technicalwriting на Reddit помимо вопросов об инструментах или карьерном выборе содержит возможности для волонтёрства.
  • Телеграм-канал Technical Writing 101 публикует много полезностей, а ещё заходят HR с вакансиями, где можно посмотреть, какие тестовые задания просят сделать, и выполнить самому.
  • Телеграм-канал Techwriter’s Daily собирает статьи, анонсы мероприятий, курсов и вебинаров.
  • Телеграм-канал Shut up and write с советами, новостями, удачными примерами технической коммуникации, исследованиями. Например, вот подборка сайтов, где можно найти себе ментора.
  • Телеграм-канал DocOps с информацией про инструменты, техники и мероприятия. У канала также есть чат, где можно спросить совета и пообщаться с другими техрайтерами.
  • YouTube-канал технической писательницы Amruta Ranade, с отдельным плейлистом для начинающих техрайтеров.
  • Блог I’d rather be writing, в котором Том Джонсон, техрайтер из Сиэтла, пишет про API-документацию, техническую коммуникацию и тренды.
  • Блог ClickHelp про техническое письмо. Здесь вы найдёте советы, объявления о конференциях и авторские колонки.
  • Канал Write the Docs в Slack, где можно спросить совета, познакомиться с другими техрайтерами, узнать про отраслевые мероприятия или найти первую работу, там добавляют и вакансии.
  • На DocToolHub собрано 600+ статей на темы от построения карьеры до написания API документации.
  • Подкаст Cherryleaf часть блога про техническую коммуникацию, есть выпуски с отзывами на курсы и описанием трендов.

Книги

  • Technical Writing 101 написана простым языком и отвечает на вопросы про технические ресурсы, проблемы при создании документации и особенности планирования документации на проекте. Ещё в ней есть детальные описания процесса документации, от планирования и ресёрча до публикации. 
  • Handbook of Technical Writing была написана еще в 2003, и это её десятое переиздание. Конечно, IT-индустрия меняется гораздо быстрее, но в книге есть всё еще актуальные примеры документации, принципы организации и форматирования документов, и много информации о техническом языке.
  • Пиши, сокращай поможет с пользой для читателя и заботливыми формулировками.
  • Tech Writing Handbook — коротенькая книжка с совсем основами, но очень дружелюбная, и ответит на основные вопросы в самом начале пути технического писателя.
  • Technical Writing Course Manual — неплохое собрание теории, разве что часть про MSWord устарела.

Что можно сделать прямо сейчас?

  1. Прочитайте книгу «Пиши, сокращай» — что бы вы ни собирались сокращать, в технической документации ценится лаконичность.
  2. Пройдите любой бесплатный курс и посмотрите, кажутся ли интересными задачи.
  3. Напишите инструкцию к пользованию любимым сервисом для новичков. Разберитесь что к чему, соберите скриншоты и протестируйте на знакомом, который им не пользовался. Если по вашей инструкции всё вышло и вам понравилось — продолжайте писать.
  4. Добавьтесь в один из Телеграм-каналов из предыдущей секции, найдите вакансию для джуниоров и попробуйте выполнить техническое задание.
Основные курсы

Введение в профессию.

Типовой сценарий работы технического писателя.

Microsoft Word и другие инструменты написания.

Работа с техническим текстом.

Зарубежные и отечественные стандарты.

Создание документа: техническое задание (ТЗ).

Создание документа: паспорт (ПС).

Создание документа: технические условия (ТУ).

Создание документа: руководство по эксплуатации (РЭ).

Создание онлайн-справки.

Управление знаниями.

Как получить работу технического писателя.

Введение.

Базовый HTML.

Базовый CSS. Часть 1.

Базовый CSS. Часть 2.

Подготовка к верстке.

Layout. HTML-разметка.

Layout. Flexbox.

Layout. Стилизация.

Освоение инструментов визуализации.

Освоение технологий и средств для автоматизации документирования.

Technical documentation.

Руководство по эксплуатации

Дополнительные курсы

Версии программного кода.

Установка Git.

Индекс и частичные коммиты.

Сравнение версий.

Отмена изменений и откат версий.

Репозитории и коллективная работа.

Ветки — создание и управление.

Слияние и разрешение конфликтов.

Полезные инструменты.

Правила работы с Git.

Александр Клименков

Александр Клименков


кандидат технических наук, Tech Lead Bercut

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

Бэкграунд

Меня зовут Александр Клименков, я — ведущий технический писатель, кандидат технических наук по специальности «Системный анализ, управление и обработка информации», закончил Санкт-Петербургский электротехнический университет («ЛЭТИ»). В компании Bercut работаю более 5 лет, очень люблю свою профессию. До прихода в Bercut работал преподавателем, техническим писателем и ведущим бизнес-аналитиком.

Процессы и коммуникации в новой дистанционной реальности

Как и большинство наших коллег в IT-сфере, сейчас мы работаем из дома. Переход на удалённый режим работы, конечно, внёс некоторые коррективы в нашу повседневную деятельность, но рабочие процессы от этого почти не поменялись. Мы всё так же пишем пользовательскую документацию, всё так же общаемся с коллегами в Teams и Skype, пользуемся теми же рабочими инструментами и серверами. Разве что звонки по местным телефонам мы заменили перепиской и созвонами в мессенджерах.

Биоритмы и конвенции

Режим рабочего дня, как и процессы, тоже не особо изменился. Ещё до перехода на удалённый режим в нашей компании каждый сотрудник мог выбирать время начала рабочего дня: кто-то приходил на работу в 8 утра, кто-то — в 11. Главное, чтобы все были на месте в определённый дневной период и работали положенные 8 часов. На удалёнке эти правила сохранились. Среди нас есть свои «совы» и «жаворонки» и каждый начинает рабочий день в удобное ему время. В любом случае проснуться можно попозже — ведь не нужно тратить время на утренние сборы и дорогу до работы.

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

Инструменты писателя

Мы пишем документацию в формате DITA. Это формат, основанный на XML, который позволяет сохранять исходный текст документов в структурированном виде. Мы пишем исходники документации в этом формате, для этого у нас есть редактор oXygen XML Author. Затем из этих исходников мы можем собрать итоговый документ в любом нужном формате. Для этого есть специальный Toolkit, содержащий XSLT-преобразования. Наш Toolkit позволяет собирать документы во множестве форматов. Самый востребованный — это PDF, иногда собираем CHM или HTML. При желании мы можем собрать даже EPUB, если заказчик вдруг захочет почитать нашу документацию перед сном на электронной книге. По необходимости мы вносим правки в XSLT-преобразования, чтобы изменить правила сборки документов и их внешний вид.

Подробнее о формате

Формат DITA вообще оказался очень удобным инструментом именно для разработки технической документации с её специфическим содержанием. Например, мы можем повторно использовать любой блок текста или целый раздел из одного документа в другом документе. И это будет не привычный «copy-paste», а именно использование одного блока в разных документах. Если в этом блоке что-то изменится, нам достаточно будет поменять текст один раз — изменение автоматически попадёт во все документы. Ещё мы можем применять фильтрацию — написать один универсальный раздел, вставить в несколько документов и потом фильтровать его содержимое в зависимости от типа документа, заказчика, системы и других параметров. А ещё мы не задумываемся о перекрёстных ссылках между разделами — достаточно в нужном месте указать ключ раздела, на который мы хотим сослаться. Toolkit при сборке документа сам пронумерует разделы и сделает красивые гиперссылки.

Погружение в процесс

Каждый писатель редактирует DITA-файлы у себя в локальной копии, а затем выгружает изменения в SVN. Часто бывает так, что над одним документом работает несколько писателей. Чтобы в этом случае не было конфликта правок, у нас есть специальный чат, где можно оповестить своих коллег о начале работы с определённой частью документа или об обновлении общих коллекций, например — глоссария. Может, это и не самое технологичное решение, но оно работает. Никому из писателей не хочется потом «мёржить» (merge) куски сложных технических текстов.

После обновления локальной копии SVN начинается работа. Мы работаем по задачам в Jira. У нас есть специальный тип задач с префиксом DOC. Обычно они связаны с задачами на разработку или с запросами заказчиков. Задачи на документирование создают менеджеры, которые ведут проект, тестировщики, сотрудники службы поддержки. Заказчик тоже может инициировать изменение документации, задав вопрос, высказав пожелание или жалобу. Team Lead нашей команды планирует деятельность каждого писателя, распределяет задачи, следит за их выполнением и отгрузкой документов.

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

Внутренняя «кухня» — источники вдохновения

Начиная работать над очередной задачей, писатель изучает многочисленные источники информации и преобразует полученные оттуда данные в пользовательскую документацию. Источников у нас много. Самый главный — это технический проект (ТП), которые пишут бизнес-аналитики ещё до начала разработки. ТП — это закон для разработчиков, тестировщиков и технических писателей. В идеале всё должно быть реализовано именно так, как написано в ТП. На деле же оказывается, что итоговая реализация отличается от ТП. Вы знаете, как это бывает: что-то не учли, что-то поняли неправильно, что-то оптимизировали… Для того, чтобы узнать, как на самом деле всё было реализовано, мы используем техническое описание (ТО), которое пишут разработчики. Там есть больше технических подробностей, описаны изменения конкретных типов данных и таблиц в БД, приведены алгоритмы работы процедур серверного кода, приведены скриншоты добавленных или изменённых окон в клиентских приложениях. Без ТО нам было бы очень трудно написать полноценную документацию. К сожалению, разработчики иногда откладывают написание ТО на самый последний момент.

Есть ещё один важный источник — описание настроек интеграционного тестирования. Там подробно описаны все настройки, которые нужно сделать в системах, чтобы пройти все тестовые сценарии (тест-кейсы). Этот источник незаменим для написания руководств по настройке.

ТП, ТО и описание настроек — это основные источники, из которых писатель получает информацию. Но есть ещё множество дополнительных: исходный код серверных процедур и клиентских приложений, XML-описания параметров, страницы в базе знаний Wiki, наконец — вопросы разработчикам и тестировщикам в мессенджерах. Ну и, конечно, сами системы — их web-интерфейс, клиентские и серверные приложения.

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

Один в поле не воин

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

На поверку становись!

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

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

Праздник труда

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

Клиент всегда прав — отгрузка до 23.59.59

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

Большие надежды — портал bercut.web.docs

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

Да здравствует Команда!

Также по пятницам у нас обычно проходит еженедельное совещание нашей команды в Skype. Эта традиция появилась у нас с переходом на удалённый режим работы. На совещании наш Team Lead делится с нами свежими новостями компании Bercut, рассказывает о новых краткосрочных и долгосрочных задачах и планах. Писатели по очереди рассказывают о своих задачах и рабочих проблемах — что сделано за прошедшую неделю, что планируется сделать на следующей. Такое обсуждение помогает нам скоординировать свои действия, ведь часто над пакетом документов к очередной версии системы работает сразу несколько писателей.

Последний штрих

Заканчивается рабочий день технического писателя тем же, чем и начинался — синхронизацией с SVN. Конечно, мы часто выполняем промежуточные синхронизации и в середине дня, но вечером обязательно проверяем, все ли изменения выгружены на сервер. Будет обидно, если вся работа, сделанная за день, пропадет даром. И конечно, надо не забыть оформить трудозатраты — вписать в задачи Jira время, которые мы на них потратили за этот день.

Призвание

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

Мы, технические писатели, частенько задаемся вопросом: а читает ли кто-нибудь нашу документацию? Для кого мы, собственно, стараемся?

Недавно я нашла ответ на этот вопрос:

Если серьезно, то пишем мы, в первую очередь, для конечных пользователей. В моем случае – для пользователей компьютерных программ. Я технический писатель со стажем, работаю в этой сфере с 2007 года, и все это время пишу только о компьютерных программах. Поэтому не буду притворяться, что знаю, как писать документацию к другим вещам: технике, приборам, механизмам. Не знаю. Так что расскажу о техписательском труде на своих, IT-шных примерах.

Большинство читательской аудитории технического писателя в IT – это пользователи компьютерных программ. Аудитория это разношерстная: от новичков, для которых Интернет – это синенькая буковка “е” на рабочем столе, до продвинутых пользователей, способных обойтись без GUI и работать с программой через командную строку. Угодить им всем – не такая простая задача. Но в целом для конечных пользователей стараются писать попроще и попонятнее. Простой текст будет понятен и начинающему, и продвинутому пользователю.

Чтобы писать для конечного пользователя, обычно достаточно уметь внятно и грамотно выражать свои мысли и более-менее разбираться в предметной области, не бояться углубиться в нее. Многие из технических писателей даже не имеют специального (технического) образования. Среди нас много гуманитариев: лингвистов, филологов, психологов, педагогов – да кого угодно.

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

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

В целом, для кого бы вы ни писали, вам, конечно, придется общаться с создателями того чуда инженерной мысли, о котором нужно что-то написать. В моем случае – с программистами, системными аналитиками, проектировщиками интерфейса, тестировщиками. Нужно уметь общаться с ними на понятном им языке. И не только задавать правильные вопросы, но и понимать полученные ответы. Так что, как я уже писала выше, знание предметной области на уровне “выше среднего” совершенно необходимо техническому писателю.

Приветствуем вас, дорогие друзья!

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

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

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

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

Особенности профессии

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

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

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

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

Примеры результатов работы технического писателя:

  • стандарты документирования;
  • инструкция к смартфону или ноутбуку;
  • руководство по эксплуатации метеостанции;
  • сценарии для обучающих видео;
  • документация для внутренних систем по информационной безопасности;
  • раздел “Помощь” или FAQ на официальном сайте;
  • руководство по пользованию микроволновой печью или стиральной машиной;
  • технические задания для других специалистов;
  • описание архитектуры программных решений;
  • учебные материалы для новых сотрудников компании;
  • документация к компьютерным программам;
  • инструкция по сбору мебельной продукции и пр.

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

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

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

Технический писатель может работать в различных сферах. Например:

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

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

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

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

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

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

Обязанности технического писателя

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

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

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

В список задач технического писателя входит:

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

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

  1. Определить цель, задачи и целевую аудиторию документа.
  2. Составить план и структуру будущего документа, согласовать их с заказчиком.
  3. Внести изменения при необходимости и снова отправить на проверку.
  4. Разобраться с особенностями продукта, расспросить о нем специалистов, задействованных в создании.
  5. Заняться написанием текста.
  6. Подготовить иллюстрации, схемы, диаграммы и скриншоты.
  7. Отправить готовую работу на вычитку и проверку.
  8. Внести правки при необходимости.

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

Что должен знать и уметь

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

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

  1. Умение составлять понятные, четкие и структурированные инструкции, технические задания, руководства и другие виды документации.
  2. Умение искать и собирать информацию, анализировать и структурировать ее.
  3. Грамотная устная и письменная речь.
  4. Умение составлять таблицы, графики и схемы.
  5. Владение иностранным языком на высоком уровне.
  6. Знание специфических компьютерных программ, необходимых для работы в конкретной области деятельности.
  7. Умение работать с большими объемами информации.
  8. Знание языков разметки текста.
  9. Навыки работы с базами данных.
  10. Понимание процессов документирования.
  11. Умение наглядно демонстрировать информацию.
  12. Знание языков программирования.
  13. Знание нормативных документов, ГОСТов.
  14. Копирайтерские навыки.
  15. Умение понимать, что нужно заказчику.
  16. Знание графических программ.
  17. Хорошее знание объекта, о котором пойдет речь в документе, а также высокий уровень понимания своей профессиональной области в целом.
  18. Навыки работы с профессиональными текстовыми редакторами.
  19. Наличие интереса к техническим наукам и технике.
  20. Уверенное владение компьютером.
  21. Навыки самоорганизации и планирования режима работы.
  22. Умение упрощать сложные термины и писать более простым языком для обычных потребителей.
  23. Умение быстро “схватывать” новые данные.
  24. Навык быстрого переключения между несколькими задачами.
  25. Умение работать в команде.

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

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

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

Доход, поиск вакансий и карьерные перспективы

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

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

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

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

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

Часто в вакансиях указывается договорной заработок. Он зависит от конкретных обязанностей и условий работы. В среднем заработная плата российского специалиста находится на уровне от 40 до 80 тыс. руб. В Москве оплата труда может доходить и до 150 000 руб., но это редкость.

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

Развивать карьеру можно через повышение квалификации и уровня навыков и умений или можно переквалифицироваться в другого специалиста. Технический писатель может стать:

  • руководителем рабочей группы;
  • руководителем отдела или департамента технической документации;
  • UX-писателем;
  • инженером по документированию;
  • инженером по локализации;
  • менеджером проектов;
  • тестировщиком;
  • разработчиком;
  • бизнес-аналитиком.

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

Плюсы и минусы

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

Положительные стороны:

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

И значительные минусы специальности:

  • сложность профессии из-за двойной направленности;
  • монотонность работы;
  • высокая ответственность.

Обучение: онлайн-курсы и литература

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

Второй негативный момент – это отсутствие в открытом доступе достаточного количества обучающего материала. Часто это поверхностная информация, не дающая сведений об особенностях профессии в достаточной мере.

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

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

  • UX-писатель – Нетология
  • Технический писатель – Академия АйТи
  • Технический писатель – Профессиональный стандарт
  • Разработка технических текстов и документации – ПроТекст
  • Technical writing – IT-Academy
  • Технический писатель: создание технической документации – Специалист.ru

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

Претенденты на должность должны иметь опыт работы 1–3 года, но часто работодатели пренебрегают этим правилом и берут специалистов без какого-либо опыта, чтобы он учился сразу на практике. Но портфолио у человека, откликнувшегося на вакансию, быть должно.

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

Для правильного составления технического документа советую прочитать пару-тройку полезных книг:

  • В. Глаголев “Разработка технической документации”
  • Н. Галь “Слово живое и мертвое”
  • А. Орлов “Джедайские техники конструктивного общения”
  • М. Логачев, О. Семенова “Информационные системы и программирование. Технический писатель”

Заключение

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

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

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

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

На этом мы хотели бы попрощаться. Всего доброго и удачи!

13.09.2013

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


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

Вступите в STC

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

И хотя само по себе это не даст вам работу технического писателя, это предоставит вам множество контактов людей, которые могут помочь вам в вашей карьере. Налаживание деловых контактов – куда более эффективный метод для того, чтобы найти работу, чем наводнять рынок вашим резюме. Однако многие работодатели закрывают свои текущие вакансии только локальными членами STC; поэтому вы получите доступ к большему количеству предложений работы, если станете его членом.

Технические писатели в Индии могут предпочесть вступить в Сообщество технических писателей Индии (TWIN), которое содержит огромный список предложений работы.

Поиск работы онлайн

Многие работодатели никогда не рекламируют вакансии. Вместо этого они нанимают людей посредством сарафанного радио или пользуются услугами агентств, которые набирают им сотрудников. В свою очередь, эти агентства часто публикуют карьерные предложения в системах поиска работы онлайн. Чтобы их найти, наберите «поиск работы город» (где город – это название расположения, которое вам нужно) в поле для поиска вашей любимой поисковой системы. Один из самых хороших сайтов для поиска работы для северо-американских технических писателей – Dice.

Напишите резюме без ошибок

Убедитесь, что ваше резюме не содержит ошибок. Даже если у вас отличные навыки правописания, например, сделайте проверку орфографии вашего документа, прежде чем отправите его кому-либо. Также поищите слова, которые прошли проверку орфографии, но тем не менее, написаны неправильно. Например, постоянно все пишут «form» вместо «from» и «manger» вместо «manager». Убедитесь, что с точки зрения грамматики всё верно и обратите внимание на пунктуацию, особенно в конце отправляемых документов.

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

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

Пишите грамотно

Если у вас проблемы с грамотностью, вам техническое писательство может показаться скучным и неинтересным. К слову сказать, не у многих авторов идеальная грамматика; поэтому, как и во всём другом, не позволяйте небольшой неуверенности и незначительному чувству неполноценности отбить охоту от достижения собственных целей. Кроме того, хорошая грамматика – это навык, не талант. Вы можете улучшить свою грамматику! К сожалению, тексты по грамматике обычно ужасно скучные, и я бы лучше прочитал сотни других книг. Однако, весьма приятно читать книгу «Элементы стиля». «Современное использование английского языка Фоулера» также интересно читать, только, возможно, не от корки до корки. В «Правильно выставленных словах» помимо других достоинств, содержатся забавные примеры неправильного написания. Наконец, веб-сайт «Руководство по грамматике и стилю Линча» – и развлекательный, и информативный.

Принимается во внимание весь ваш писательский опыт

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

(продолжение следует)

Источник: Getting a Technical Writing Job, Even If You Have No Experience

Тэги: профессия, советы

По данным zarplan.com, средняя зарплата технических писателей в октябре 2022 года — около 100 000 рублей. Неудивительно, почему все больше людей собирается освоить эту специальность.

Действующие лица

Команда Документерры решила разобраться, как студенты учатся работать с документацией. Об этом нам рассказал Игорь Олегович Ситников — кандидат технических наук, преподаватель курса по технической документации в Уральском федеральном университете (УрФУ).

Документерра

Онлайн-платформа для технической документации

Ситников Игорь Олегович

Преподаватель курса по технической документации в УрФУ

Технический писатель — кто это?

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

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

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

Как долго учиться на технического писателя?

В университетах на профессию «технический писатель» не учат, есть только курсы. У них разная продолжительность: от пары дней до нескольких месяцев. Например, Игорь Олегович как раз ведет курс для студентов УрФУ.

Я веду курс «Современные технологии разработки технической документации» с 2017 года. Мои студенты — магистранты УрФУ. Они не учатся именно на технических писателей: их специальность гораздо шире. Но работа с документацией — важная компетенция для них.

Мой курс длится 36 часов. Четверть из них занимают лекции, а остальную часть — лабораторные работы. На все уходит чуть больше двух месяцев.

Ситников Игорь Олегович

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

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

Ситников Игорь Олегович

Что должен уметь технический писатель?

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

Мои студенты проходят практическую часть курса на Документерре. Там они учатся:

1) создавать проекты,

2) импортировать документы из различных форматов,

3) редактировать страницы,

4) применять технологию единого источника,

5) экспортировать проект в финальные форматы.

Ситников Игорь Олегович

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

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

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

  • Эффективнее работать с документацией. Например, шаблоны и готовые блоки контента позволяют создавать проекты за пару кликов. А глобальные поиск и замена, технология единого источника и другие функции — быстрее обновлять документацию.
  • Настраивать доступ к публикациям. Некоторые компании против того, чтобы их документация была в открытом доступе. В этом случае нужно выбрать программу, которая позволит защитить публикации паролем.
  • Комфортно работать в команде с коллегами. Например, Документерра позволяет оставлять на странице ревью комментарии и списки задач, чтобы авторам было легко вносить правки. Еще можно увидеть историю изменений каждой страницы, что помогает техническому писателю быстро восстановить содержимое, если другой автор случайно удалит какой-нибудь важный фрагмент.

Документерра как инструмент для обучения технических писателей

Документерра — российская разработка, поэтому мы предоставляем бесплатную лицензию для УрФУ. Мы понимаем, насколько важна практика для начинающих технических писателей, которые потом будут работать в России.

Если вашему вузу тоже нужна бесплатная лицензия Документерры для обучения студентов, свяжитесь с нами по адресу [email protected] — мы с радостью поможем!

Вот почему Документерра идеально подходит для обучения студентов:

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

Какие перспективы у профессии «технический писатель»?

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

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

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

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

Ситников Игорь Олегович

Заключение

Мы поговорили с Игорем Олеговичем об обучении технических писателей и поняли следующее:

  • Знать основы технического писательства недостаточно для работы. Необходимо также хорошо разбираться в прикладной области — например, в химии или медицине.
  • В университетах не учат на специальность «технический писатель», нужно проходить курсы. Их продолжительность — от пары дней до нескольких месяцев. Мы как раз недавно делали обзор курсов для техписов, рекомендуем почитать: «ТОП‑6 курсов для технических писателей».
  • Чтобы работать с документацией профессионально, необходимо использовать такие функции, как технология единого источника, создание динамического контента, экспорт и импорт проектов в различные форматы и не только. Все это можно сделать в Документерре.
  • Поскольку людям еще долго будет нужна документация, можно смело осваивать эту специальность.

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

Мы желаем Игорю Олеговичу успехов в преподавании, а нашим читателям — в освоении профессии «технический писатель».

Понравилась статья? Поделить с друзьями:
  • Типовой сценарий праздника
  • Типовой сценарий отказа дать надежду предполагает
  • Типовой сценарий отказа военная хитрость предполагает
  • Типовой договор на оказание услуг организации праздников
  • Типичный ход событий сценария варианта использования