что делает технический писатель
Технический писатель
(буквальный перевод английского названия профессии technical writer) Кстати, в 2021 году центр профориентации ПрофГид разработал точный тест на профориентацию. Он сам расскажет вам, какие профессии вам подходят, даст заключение о вашем типе личности и интеллекте.
Технический писатель – специалист, занятый разработкой документации для решения технических задач. В частности, он может создавать руководства пользователя к приборам, разрабатывать и поддерживать документацию к компьютерным программам.
Особенности профессии
Главная задача технического писателя – объяснить пользователям, как им лучше использовать функции прибора или программы. Важно, чтобы текст легко читался и был понятен после первого прочтения.
В некоторых случаях технические писатели используют графические редакторы, чтобы сделать свои пояснения наглядными. В качестве иллюстраций используются не только статичные картинки, но и анимация (flash-ролики).
В случае с программными продуктами технический писатель может подключиться ещё на стадии разработки. Он принимает в ней участие, обсуждая возможные варианты дизайна программы, действия функций, а также проводит тестирование. Также он может участвовать в написании Технического задания, документа «Программа и методика испытаний», которым пользуется при приемке системы.
Рабочее место
Технические писатели работают в компаниях, разрабатывающих программные продукты, бытовую технику и аппаратуру для профессионального использования в медицине, науке и технике.
Важные качества
Технический писатель должен сочетать в себе свойства технаря и гуманитария. Интерес к технике и программированию, усидчивость и внимательность должны в нём сочетаться с желанием осваивать новое и делиться своими знаниями.
Знания и навыки
Необходимы технические знания в объёме, который позволяет разобраться в новом продукте, системное видение документирования как инженерной дисциплины, понимание процессов документирования.
Часто требуется владение письменным техническим английским, знание ГОСТов оформления технических проектов.
Очень важно уметь ясно выражать свои мысли в тексте.
Обучение на технического писателя
В учебных заведениях технических писателей не готовят. Начать карьеру технического писателя можно, получив высшее техническое образование.
Профессия технический писатель
Это хорошая профессия для людей, желающих работать на стыке технического и гуманитарного направлений. В отличие от копирайтинга, здесь меньше творчества и больше регламентов. В данной статье мы расскажем, кто такой технический писатель и что входит в его обязанности, как стать таким специалистом и где искать работу, в том числе удаленно.
Содержание статьи:
Кто такой технический писатель и чем он занимается?
Технический писатель – это специалист, который создает документацию к программам, интернет-сервисам, оборудованию и устройствам. Это могут быть как документы для инженеров и разработчиков, так и руководства для пользователей. Например, инструкция к смартфону, ноутбуку, метеостанции.
В функции технических писателей входит подготовка ТЗ, руководств, инструкций и других документов. По ним люди, которые будут пользоваться программами или оборудованием или участвовать в их доработке, смогут разобраться, что и как устроено и как работает. Технический писатель – это профессия, которая требует ответственности.
В должностные обязанности технического писателя входит:
Подготовка отчетов о проделанной работе.
Иногда в обязанности технических писателей включают работу над интерфейсами, локализацию. Например, необходимо перевести интерфейс программы с английского языка. Технический писатель подбирает термины на русском языке, которые наиболее близки к оригиналу, чтобы пользователи поняли, где и какие функции находятся.
Также в функции технических писателей включают подготовку простых графиков и диаграмм, скриншотов, учебных видео материалов. Иногда им поручают создание статей и рекламных материалов, хотя эту работу должен выполнять копирайтер.
Плюсы и минусы профессии технического писателя
Развивает системное мышление.
Сложности в карьерном росте. Если вы не желаете работать на руководящих должностях, это не будет для вас минусом.
Сколько зарабатывают технические писатели?
Зарплата начинающего технического писателя начинается от 40 тыс. руб. в месяц. Средняя зарплата специалиста с опытом 2-3 года – 60-80 тыс. руб. в месяц. Специалисты, создающие документацию на английском языке, могут получать больше 150 тыс. руб. в месяц. Например, так платят в ИТ-компаниях, которые создают софт для западных рынков.
Технический писатель может работать как в офисе, так и удаленно, а также быть фрилансером. Средние цены на создание технической документации – от 500-1000 руб. за страницу (1800 знаков с пробелами). Например, разработка технического задания у фрилансера может стоить от 20 тыс. рублей, руководства для администратора – от 25 тыс. рублей. При заказе в компаниях эти документы будут стоить в 2 раза дороже.
Что должен знать и уметь технический писатель?
Желательно знать английский язык.
Как стать техническим писателем с нуля?
В эту профессию приходят двумя путями. Первый – человек с техническим образованием понимает, что разработка и проектирование – это не его. Решает вместо работы инженером попробовать себя в новой сфере. Второй путь – человек с гуманитарным образованием желает работать в технической сфере, но не программировать. Тогда он становится писателем.
Если вы новичок, то можете поискать вакансии с минимальными требованиями на HH.ru. Например, для создания онлайн-справок могут взять человека без технического образования и опыта. Так вы сможете постепенно погружаться в предметную область, осваивать новые задачи и профессионально расти.
Бесплатные курсы для технический писателей проводятся в Академии Гипербатона от компании Яндекс. Обучение занимает 1 месяц. Для поступления необходимо справиться с тестовым заданием. Лучшим выпускникам могут предложить работу.
Будет полезно читать книги, например, «Разработка технической документации» Вадима Глаголева. Это справочник, в котором собраны ссылки на ГОСТы и выдержки из них.
Много информации для начала карьеры в профессии можно найти на форуме технических писателей Techwriters.ru и на YouTube.
Где искать работу?
Посмотрите открытые вакансии в местных ИТ-компаниях, интеграторах, разработчиках софта. Часто они набирают стажеров, которых потом могут брать в штат.
Копирайтер, UX-писатель и технический писатель: чем отличаются и сколько зарабатывают
Изначально техдокументацию и тексты интерфейсов писали разработчики. Те времена к счастью прошли, и сегодня создавать и улучшать цифровые продукты помогают копирайтеры, технические писатели и UX-писатели.
Рассказываем, в чём специфика работы этих специалистов и на какую зарплату они могут рассчитывать.
Чем занимается копирайтер
Хороший копирайтер — это не только автор текста, но и SEO-специалист, и маркетолог. Его фишкой может стать уникальный авторский стиль или владение разными стилями.
Копирайтер пишет тексты, которые помогают продавать товар или услуги. Это могут быть рекламные и информационные статьи, новости, дайджесты, описания товаров и услуг, слоганы, посты для соцсетей и другие.
Примеры текстов, которые создают копирайтеры:
Копирайтер пишет тексты для сайтов, интернет-магазинов — например, описание товаров и услуг
Дайджесты — важное звено в дистрибуции материалов. К тому же они позволяют общаться с аудиторией, а также услышать голос бренда. Например, дайджесты Нетологии отличает дружелюбный шутливый и самоироничный авторский стиль
Читать по теме: Как стать копирайтером
Кто такой технический писатель
Технический писатель, или техпис ― это специалист, который пишет техническую документацию для внешнего и внутреннего пользования.
Чаще всего технические писатели имеют техническое образование. Это не обязательное требование, и специалисты с гуманитарным складом ума могут разобраться в нюансах, но на практике такие случаи редки.
Что делает технический писатель:
Кроме специфических для компании часто встречаются такие требования к специалистам:
Для техписа главное ― разбираться в продукте. Красота стиля и подачи материала вторичны.
Новая роль в команде: технический писатель
Привет! Я Катя, руководитель группы технических писателей в Ozon. Сейчас нас уже 9 человек и целая платформа документации, но коллеги всё ещё не всегда понимают, чем мы занимаемся.
Из непонимания появляются запросы вида: “Хотим себе собственного техписателя в команду, но не знаем, чем именно он будет заниматься”. В итоге команда подстраивается под тренды и заводит себе документацию, но через пару месяцев оказывается, что доку не читают, а техписатель плавно превратился в аналитика.
Поэтому пришло время делиться опытом и рассказывать о каких-то концептуальных штуках 🙂
Кто вообще такие технические писатели?
Встречала разные ответы, от «ребята, которые пишут никому не нужные талмуды по ГОСТам» до вполне близких к моей реальности определений.
В Ozon технические писатели занимаются глобально тремя направлениями:
пользовательской документацией (Помощь, База знаний, FAQ),
документацией внешних API,
описанием внутренних систем — от онбордингов до сложных архитектурных взаимодействий.
Какое в итоге «правильное» занятие для техписа — поле для холивара — в Ozon вот так, в других компаниях может быть иначе. Когда я работала в Яндексе, например, конкретно моя команда не сильно занималась внутренними документами.
Ещё к нам часто приходят просто за качественными текстами — для лендингов, постов, обучающих курсов. Нам интересно, и мы не отказываем, но не могу сказать, что это попадает под именно техническое писательство.
При желании мы можем писать в принципе любые тексты, но будьте готовы, что от техписателя текст получится с уклоном в техническую часть, без завлекающих и рекламных заголовков.
Технические писатели описывают, как устроены какие-то системы и как с этими системами работать. Это может быть пользовательская инструкция по оформлению возврата или схема взаимодействия методов API — но это всегда ответ на вопрос «как что-то сделать».
Как понять, что пора заводить технического писателя?
Если у вас есть продукт, которым пользуется кто-то снаружи — час пробил. Даже если «снаружи» сидит в соседней команде. Любое погружение посторонних в ваш продукт или проект уже подразумевает документацию, а, следовательно, и позицию технического писателя.
Но есть нюансы:
Документации нет и это не создаёт никаких реальных проблем — техписатель не нужен.
Документацию уже кто-то пишет и ему проще делать это самостоятельно, чем объяснять техписателю — у вас уже есть технический писатель, только называется он «инициативный разработчик» или «ответственный аналитик».
В системе часто что-то меняется — чаще, чем приходится систему кому-то объяснять — проще рассказать на словах, чем поддерживать все изменения. Часто можно сказать: «Ребята, сейчас используем вот эту штуку, документация на официальном сайте», а не расписывать подробные инструкции, которые через пару месяцев уже будут не нужны.
Подумайте о документации как о продукте — оцените её потенциальную аудиторию и задачи, которые она должна решать. Возможно, вам нужна не документация а вебинар, скринкаст. Или даже стикерпак.
Где искать технических писателей и как оценивать кандидатов?
Я пришла в техписательство после бакалавриата компьютерных наук в Иннополисе, года автоматизированного тестирования и академии от Яндекса.
Кто-то приходит из лингвистов и филологов со стремлениями уйти в аналитику или разработку. Я стараюсь искать (особенно стажеров) по техническим вузам; там довольно много ребят, осознавших, что кодить 24/7 — не их стезя. А вот что-то рядом, но чуть гуманитарнее — наш идеальный кандидат.
Если нужен сильный специалист, который всё вам сделает под ключ — профильные сообщества, митапы. Если хватит и молодого, зеленого, но перспективного — чаще всего это кандидат совсем без опыта, но с сильным тестовым и пониманием мира IT.
Если это ваш первый технический писатель на проекте, дайте что-то про описание процесса или архитектуры. Оцените полноту описания, структуру и термины, которые использует кандидат. Прочитайте Ильяхова или подпишитесь на рассылку о текстах, чтобы примерно понимать, где хорошо, а где не очень. Но важнее, чтобы устраивало конкретно вас и попадало в формат компании, чем полное соблюдение концептов информационного стиля и 10 баллов по Главреду.
Как выстроить процесс?
Чаще всего у документации есть заказчик. Это может быть менеджер, разработчик, дизайнер — любой человек, осознавший, что есть какая-то проблема в понимании происходящего. Задача техписателя — определить, реальна ли проблема и в каком формате её нужно решать.
В общем виде документация создаётся по такому сценарию:
Определить цель документа и его аудиторию.
Набросать структуру, согласовать с заказчиком. Скорее всего, изменения будут, здесь важнее понять какие вопросы хочет покрыть заказчик.
Понять, кому и по каким темам можно задавать уточняющие вопросы — найти экспертов и договориться о формате работы с ними.
Наполнять документ и параллельно отдавать на вычитку коллегам-техписателям и экспертам.
Финализировать структуру и тексты — обязательно отдать кому-то на вычитку и после этого презентовать заказчику.
Этапы не должны затягиваться. Если пошёл уже пятый круг обсуждения структуры документа, который ещё даже не начали наполнять — что-то пошло не по плану. Финальное согласование с окончательной заморозкой структуры и текста происходит только тогда, когда уже всё написано и проверено.
Ещё один тонкий момент — что именно может править заказчик. Оговорите это сразу, при постановке задачи: важно, чтобы заказчик не пытался переписать ваш текст согласно своему субъективному взгляду. Факты и термины — да, тут он эксперт, но вкусовщину надо учиться фильтровать.
Часто слышу, что технический писатель, особенно если он один на проекте, просто сидит и что-то пишет целыми сутками, без вычиток и конкретных задач. «Ну он же технический писатель, пусть и пишет всё сам» — бесспорно, существуют люди, которым комфортно работать в таком режиме, но в очень редких случаях это ведёт к хорошей документации и довольному сотруднику.
Моя формула найма: 1.5 техписателя на проект. За половинку может считаться стажер или техписатель из другой команды — так есть и с кем экспертизой обменяться, и кто на время отпуска-болезни подхватит проекты.
Нужен ли вам техписатель: чеклист
Чтобы понять, действительно ли вам нужен технический писатель, задайтесь вопросами:
Кому может понадобиться документация к моему проекту? Моим же разработчикам, внешним пользователям?
Как проблема отсутствия документации решается сейчас? Система понятна и без дополнительного описания? Может, кто-то уже снял обзор по этой теме на YouTube?
Если документация всё же нужна, в каком виде её будет удобно потреблять? Всплывающие подсказки, вебинары, отдельный URL с базой знаний?
Чем будет заниматься технический писатель, когда напишет документацию? Продолжит её актуализировать? Перейдёт на соседний проект?
Начинайте поиски технического писателя, только если у вас сложилась общая картинка о месте документации в вашем проекте. Отнеситесь к документации как к полноценному продукту.
Что дальше?
Дальше — проверять полезность и качество документации, создавать и дополнять стайлгайды, развивать техписателей и повышать общую осознанность компании по теме текстов.
И, конечно же, ждать подробностей в следующих статьях :)
Технический писатель: обзор профессии
Мы — сплоченная команда технических писателей, — пишет Александр Клименков, ведущий технический писатель Bercut, в статье на tproger.ru. — Сейчас нас одиннадцать человек: десять писателей и один технический редактор-переводчик. Среди нас есть инженеры, программисты, филологи и педагоги. Мы все очень разные: по возрасту, характеру, увлечениям и образованию. Но нас объединяет одно общее интересное дело — документирование сложных систем и решений.
Бэкграунд
Меня зовут Александр Клименков, я — ведущий технический писатель, кандидат технических наук по специальности «Системный анализ, управление и обработка информации», закончил Санкт-Петербургский электротехнический университет («ЛЭТИ»). В компании 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 время, которые мы на них потратили за этот день.
Призвание
Работа технического писателя — сложная, но действительно интересная. Каждый день мы придумываем, как упростить и сделать понятными сложные алгоритмы, правила и системы, как сделать документацию удобной, полезной и красивой. В компании разрабатываются новые системы, постоянно добавляется функциональность в уже существующие системы. А это значит, что наша работа никогда не станет скучной и однообразной. Вносить ясность, добывать смысл, помогать читателю-пользователю решить любую задачу — в этом и есть наше профессиональное призвание.