Новая роль в команде: технический писатель
Привет! Я Катя, руководитель группы технических писателей в Ozon. Сейчас нас уже 9 человек и целая платформа документации, но коллеги всё ещё не всегда понимают, чем мы занимаемся.
Из непонимания появляются запросы вида: “Хотим себе собственного техписателя в команду, но не знаем, чем именно он будет заниматься”. В итоге команда подстраивается под тренды и заводит себе документацию, но через пару месяцев оказывается, что доку не читают, а техписатель плавно превратился в аналитика.
Поэтому пришло время делиться опытом и рассказывать о каких-то концептуальных штуках 🙂
Кто вообще такие технические писатели?
Встречала разные ответы, от «ребята, которые пишут никому не нужные талмуды по ГОСТам» до вполне близких к моей реальности определений.
В Ozon технические писатели занимаются глобально тремя направлениями:
пользовательской документацией (Помощь, База знаний, FAQ),
документацией внешних API,
описанием внутренних систем — от онбордингов до сложных архитектурных взаимодействий.
Какое в итоге «правильное» занятие для техписа — поле для холивара — в Ozon вот так, в других компаниях может быть иначе. Когда я работала в Яндексе, например, конкретно моя команда не сильно занималась внутренними документами.
Ещё к нам часто приходят просто за качественными текстами — для лендингов, постов, обучающих курсов. Нам интересно, и мы не отказываем, но не могу сказать, что это попадает под именно техническое писательство.
При желании мы можем писать в принципе любые тексты, но будьте готовы, что от техписателя текст получится с уклоном в техническую часть, без завлекающих и рекламных заголовков.
Технические писатели описывают, как устроены какие-то системы и как с этими системами работать. Это может быть пользовательская инструкция по оформлению возврата или схема взаимодействия методов API — но это всегда ответ на вопрос «как что-то сделать».
Как понять, что пора заводить технического писателя?
Если у вас есть продукт, которым пользуется кто-то снаружи — час пробил. Даже если «снаружи» сидит в соседней команде. Любое погружение посторонних в ваш продукт или проект уже подразумевает документацию, а, следовательно, и позицию технического писателя.
Но есть нюансы:
Документации нет и это не создаёт никаких реальных проблем — техписатель не нужен.
Документацию уже кто-то пишет и ему проще делать это самостоятельно, чем объяснять техписателю — у вас уже есть технический писатель, только называется он «инициативный разработчик» или «ответственный аналитик».
В системе часто что-то меняется — чаще, чем приходится систему кому-то объяснять — проще рассказать на словах, чем поддерживать все изменения. Часто можно сказать: «Ребята, сейчас используем вот эту штуку, документация на официальном сайте», а не расписывать подробные инструкции, которые через пару месяцев уже будут не нужны.
Подумайте о документации как о продукте — оцените её потенциальную аудиторию и задачи, которые она должна решать. Возможно, вам нужна не документация а вебинар, скринкаст. Или даже стикерпак.
Где искать технических писателей и как оценивать кандидатов?
Я пришла в техписательство после бакалавриата компьютерных наук в Иннополисе, года автоматизированного тестирования и академии от Яндекса.
Кто-то приходит из лингвистов и филологов со стремлениями уйти в аналитику или разработку. Я стараюсь искать (особенно стажеров) по техническим вузам; там довольно много ребят, осознавших, что кодить 24/7 — не их стезя. А вот что-то рядом, но чуть гуманитарнее — наш идеальный кандидат.
Если нужен сильный специалист, который всё вам сделает под ключ — профильные сообщества, митапы. Если хватит и молодого, зеленого, но перспективного — чаще всего это кандидат совсем без опыта, но с сильным тестовым и пониманием мира IT.
Если это ваш первый технический писатель на проекте, дайте что-то про описание процесса или архитектуры. Оцените полноту описания, структуру и термины, которые использует кандидат. Прочитайте Ильяхова или подпишитесь на рассылку о текстах, чтобы примерно понимать, где хорошо, а где не очень. Но важнее, чтобы устраивало конкретно вас и попадало в формат компании, чем полное соблюдение концептов информационного стиля и 10 баллов по Главреду.
Как выстроить процесс?
Чаще всего у документации есть заказчик. Это может быть менеджер, разработчик, дизайнер — любой человек, осознавший, что есть какая-то проблема в понимании происходящего. Задача техписателя — определить, реальна ли проблема и в каком формате её нужно решать.
В общем виде документация создаётся по такому сценарию:
Определить цель документа и его аудиторию.
Набросать структуру, согласовать с заказчиком. Скорее всего, изменения будут, здесь важнее понять какие вопросы хочет покрыть заказчик.
Понять, кому и по каким темам можно задавать уточняющие вопросы — найти экспертов и договориться о формате работы с ними.
Наполнять документ и параллельно отдавать на вычитку коллегам-техписателям и экспертам.
Финализировать структуру и тексты — обязательно отдать кому-то на вычитку и после этого презентовать заказчику.
Этапы не должны затягиваться. Если пошёл уже пятый круг обсуждения структуры документа, который ещё даже не начали наполнять — что-то пошло не по плану. Финальное согласование с окончательной заморозкой структуры и текста происходит только тогда, когда уже всё написано и проверено.
Ещё один тонкий момент — что именно может править заказчик. Оговорите это сразу, при постановке задачи: важно, чтобы заказчик не пытался переписать ваш текст согласно своему субъективному взгляду. Факты и термины — да, тут он эксперт, но вкусовщину надо учиться фильтровать.
Часто слышу, что технический писатель, особенно если он один на проекте, просто сидит и что-то пишет целыми сутками, без вычиток и конкретных задач. «Ну он же технический писатель, пусть и пишет всё сам» — бесспорно, существуют люди, которым комфортно работать в таком режиме, но в очень редких случаях это ведёт к хорошей документации и довольному сотруднику.
Моя формула найма: 1.5 техписателя на проект. За половинку может считаться стажер или техписатель из другой команды — так есть и с кем экспертизой обменяться, и кто на время отпуска-болезни подхватит проекты.
Нужен ли вам техписатель: чеклист
Чтобы понять, действительно ли вам нужен технический писатель, задайтесь вопросами:
Кому может понадобиться документация к моему проекту? Моим же разработчикам, внешним пользователям?
Как проблема отсутствия документации решается сейчас? Система понятна и без дополнительного описания? Может, кто-то уже снял обзор по этой теме на YouTube?
Если документация всё же нужна, в каком виде её будет удобно потреблять? Всплывающие подсказки, вебинары, отдельный URL с базой знаний?
Чем будет заниматься технический писатель, когда напишет документацию? Продолжит её актуализировать? Перейдёт на соседний проект?
Начинайте поиски технического писателя, только если у вас сложилась общая картинка о месте документации в вашем проекте. Отнеситесь к документации как к полноценному продукту.
Что дальше?
Дальше — проверять полезность и качество документации, создавать и дополнять стайлгайды, развивать техписателей и повышать общую осознанность компании по теме текстов.
И, конечно же, ждать подробностей в следующих статьях :)
Копирайтер, UX-писатель и технический писатель: чем отличаются и сколько зарабатывают
Изначально техдокументацию и тексты интерфейсов писали разработчики. Те времена к счастью прошли, и сегодня создавать и улучшать цифровые продукты помогают копирайтеры, технические писатели и UX-писатели.
Рассказываем, в чём специфика работы этих специалистов и на какую зарплату они могут рассчитывать.
Чем занимается копирайтер
Хороший копирайтер — это не только автор текста, но и SEO-специалист, и маркетолог. Его фишкой может стать уникальный авторский стиль или владение разными стилями.
Копирайтер пишет тексты, которые помогают продавать товар или услуги. Это могут быть рекламные и информационные статьи, новости, дайджесты, описания товаров и услуг, слоганы, посты для соцсетей и другие.
Примеры текстов, которые создают копирайтеры:
Копирайтер пишет тексты для сайтов, интернет-магазинов — например, описание товаров и услуг
Дайджесты — важное звено в дистрибуции материалов. К тому же они позволяют общаться с аудиторией, а также услышать голос бренда. Например, дайджесты Нетологии отличает дружелюбный шутливый и самоироничный авторский стиль
Читать по теме: Как стать копирайтером
Кто такой технический писатель
Технический писатель, или техпис ― это специалист, который пишет техническую документацию для внешнего и внутреннего пользования.
Чаще всего технические писатели имеют техническое образование. Это не обязательное требование, и специалисты с гуманитарным складом ума могут разобраться в нюансах, но на практике такие случаи редки.
Что делает технический писатель:
Кроме специфических для компании часто встречаются такие требования к специалистам:
Для техписа главное ― разбираться в продукте. Красота стиля и подачи материала вторичны.
Чем занимается технический писатель: опыт IT-компании Lad
Авторизуйтесь
Чем занимается технический писатель: опыт IT-компании Lad
Рассказывают технические писатели IT-компании Lad Екатерина Каляева, Анна Назолина, Ксения Скорынина
Когда нас спрашивают, в чем заключается работа технического писателя, на ум приходит сразу несколько ответов. Конечно, проще всего сказать: мы пишем документацию. Но теоретически документацией можно назвать практически всё, что угодно: от треда в рабочем мессенджере до технического задания размером в сто страниц. Поэтому стоит конкретизировать, какую документацию, для кого и как мы создаем.
Технические писатели и knowledge management
Технические писатели в компании выполняют разную работу. Например, часть команды занята в сфере управления знаниями внутри проектных групп. Она не привязана к единственному продукту или команде, а занимает позицию как бы вне конкретного проекта и готова подключиться к любому из них. Основная единица документации — статья в базе знаний. Статьи объединяются в проекты, при этом их внутренняя структура одинакова.
Так выглядит база знаний Центра Разработки. Слева — проекты и дерево статей, справа — непосредственно тексты статей.
Такой подход позволяет не писать «в стол» или для галочки, а создавать минимально необходимый пул статей для каждого продукта, а затем отслеживать уникальные потребности команды в документации по мере работы над проектом. В то же время технические писатели снижают уровень хаоса и экономят ресурсы других членов команды. Они документируют часто обсуждаемые фичи и процессы, когда проектные команды растут, и люди начинают чаще переходить между проектами. Качественная и актуальная база знаний позволяет снизить порог вхождения для новых членов команды.
Вместо того чтобы объяснять одно и то же разным людям несколько раз, коллегам достаточно один раз рассказать это техническому писателю, а потом давать ссылку на релевантную статью.
Технический писатель по канону
«Классический» технический писатель в компании занимается написанием не только внутренней документации на проекте, но и внешней — для заказчиков.
Внутренняя документация — это, например, описание админки, процесса продажи/возвратов/рассрочки, БД MongoDB. А внешняя обычно включает в себя описание верхнего уровня проекта: цели, требования, бизнес-эффект, а также мануал для работы сотрудников с разрабатываемым продуктом. Таким образом, технический писатель играет важную роль в команде вне зависимости от его специализации. Это не просто сотрудник, который пишет документацию, исходя из своей точки зрения и предпочтений. Техписатель-профессионал может почерпнуть «тайную» информацию от коллег-разработчиков и, что важно, принимает точку зрения каждого из коллег.
О том, почему документация — это непросто
При написании документации мы используем множество источников информации: это и собственные знания, и знания коллег, код, вся ранее написанная документация, если такая есть, и требования заказчиков. Самая важная задача здесь — это побывать в роли каждого сотрудника:
Поэтому основная цель при написании документации — отследить все информационное потоки, возникающие во время работы над продуктом. Чем полнее мы их увидим, тем лучше и качественнее получится итоговый документ.
Инструменты must-have
Для создания документации на разных этапах мы используем инструменты, которые облегчают нам работу, помогают видеть прогресс и писать лучше.
Как выполнять план без нервов
Каждый день из работы технического писателя — особенный. Иногда мы несколько дней вдумчиво работаем над написанием одной статьи. А порой все горит и появляются новые задачи, которые нужно оперативно решать. Ежедневно мы проверяем доску Agile, оцениваем количество оставшихся задач и их статус. Выбрав приоритетные на день, прописываем их детально в карточке задачи, а затем переносим эти микрозадачи в свой Google-календарь. Так они удобно комбинируются с митингами и другими запланированными мероприятиями. Таким образом удается эффективно распределять свое время и не хвататься за все сразу, а план на день успешно выполняется.
Например, так выглядит календарь технического писателя, который работает в компании около года и уже вовлечен во многие ее проекты.
Жизненные циклы задач
Один из важнейших инструментов технического писателя в нашей компании — это трекер задач YouTrack. В нем у нас есть своя Kanban-доска, на которой мы видим все задачи, которые лежат в бэклоге, находятся в работе, приостановлены или готовы. При помощи флажков мы выставляем задаче приоритет, в некоторых случаях обозначаем дедлайн. Пока мы работаем над задачей, оставляем к ней комментарии о том, что уже сделано, что еще предстоит, важные ссылки и контакты людей, а также ведем обсуждение.
С помощью такой доски удобно менять статус задачи и делать к ней пометки.
Задачи обычно приходят по нескольким каналам. В первую очередь, это техлид Центра Разработки или менеджер проекта. Мы практикуем регулярные встречи с ними, обычно в формате видеозвонка, чтобы обсудить прогресс по задачам: какие выполнены, какие сейчас в процессе, а что вызывает трудности. Другой путь формирования задач — это канал #docs в корпоративном мессенджере Slack. Мы используем его как инструмент коммуникации с командами: этой самый быстрый способ для них спросить технических писателей о чем-то или поручить написание статьи. В том же канале мы объявляем последний новости, связанные с базой знаний, и делаем анонсы статей.
Тон фидбека мы обычно определяем по реакциям в Slack.
И, наконец, третий вариант — техписательская наблюдательность. Мы состоим в миллионе разных каналов по всем проектам компании. С какими-то из них мы работали больше, с какими-то меньше, однако если вдруг мы видим, что ведется обсуждение какой-нибудь фичи или процесса, о которых потенциально будет полезно узнать другим, то подключаемся и предлагаем задокументировать и сложить в базу знаний. Обычно коллеги соглашаются.
Каждая задача проходит примерно одинаковый жизненный цикл. Вначале мы определяем цель и целевую аудиторию статьи. Сформулировав вопросы, отправляемся с этим к эксперту в предметной области (SME), формируем черновик статьи. После нескольких итераций, в течение которых редактируем контент и его представление, мы показываем готовый текст всем заинтересованным лицам. Наконец, документ или статья публикуются, и происходит обсуждение того, как мы будем поддерживать актуальность.
3 сигнала, что задачу можно закрывать
Понять, что задача успешно выполнена, можно по нескольким критериям.
Следуя своей тактике, технические писатели IT-компании Lad за полгода обработали около 40 документационных задач и создали свыше 100 статей в базе знаний Центра Разработки.
Технический писатель
Технический писатель написанием документации (инструкций) помогает рядовым пользователям разобраться в использовании какого-либо прибора или программы.
(буквальный перевод английского названия профессии technical writer) Кстати, в 2021 году центр профориентации ПрофГид разработал точный тест на профориентацию. Он сам расскажет вам, какие профессии вам подходят, даст заключение о вашем типе личности и интеллекте.
Технический писатель – специалист, занятый разработкой документации для решения технических задач. В частности, он может создавать руководства пользователя к приборам, разрабатывать и поддерживать документацию к компьютерным программам.
Особенности профессии
Главная задача технического писателя – объяснить пользователям, как им лучше использовать функции прибора или программы. Важно, чтобы текст легко читался и был понятен после первого прочтения.
В некоторых случаях технические писатели используют графические редакторы, чтобы сделать свои пояснения наглядными. В качестве иллюстраций используются не только статичные картинки, но и анимация (flash-ролики).
В случае с программными продуктами технический писатель может подключиться ещё на стадии разработки. Он принимает в ней участие, обсуждая возможные варианты дизайна программы, действия функций, а также проводит тестирование. Также он может участвовать в написании Технического задания, документа «Программа и методика испытаний», которым пользуется при приемке системы.
Рабочее место
Технические писатели работают в компаниях, разрабатывающих программные продукты, бытовую технику и аппаратуру для профессионального использования в медицине, науке и технике.
Важные качества
Технический писатель должен сочетать в себе свойства технаря и гуманитария. Интерес к технике и программированию, усидчивость и внимательность должны в нём сочетаться с желанием осваивать новое и делиться своими знаниями.
Знания и навыки
Необходимы технические знания в объёме, который позволяет разобраться в новом продукте, системное видение документирования как инженерной дисциплины, понимание процессов документирования.
Часто требуется владение письменным техническим английским, знание ГОСТов оформления технических проектов.
Очень важно уметь ясно выражать свои мысли в тексте.
Обучение на технического писателя
В учебных заведениях технических писателей не готовят. Начать карьеру технического писателя можно, получив высшее техническое образование.
Профессия технический писатель: чем занимается и как проходит типичный рабочий день
Авторизуйтесь
Профессия технический писатель: чем занимается и как проходит типичный рабочий день
кандидат технических наук, 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 нашей команды планирует деятельность каждого писателя, распределяет задачи, следит за их выполнением и отгрузкой документов.
18–20 ноября, Онлайн, Беcплатно
Для всех участников процесса разработки главное — не забыть создать задачу, ведь писатели должны откуда-то узнать о том, что что-то нужно задокументировать. К сожалению, у нас всё ещё бывают такие ситуации, когда подходит срок отгрузки новой системы, а заявка на документирование этой системы не создана. В этом случае чуда не произойдёт — документация не появится моментально.
Внутренняя «кухня» — источники вдохновения
Начиная работать над очередной задачей, писатель изучает многочисленные источники информации и преобразует полученные оттуда данные в пользовательскую документацию. Источников у нас много. Самый главный — это технический проект (ТП), которые пишут бизнес-аналитики ещё до начала разработки. ТП — это закон для разработчиков, тестировщиков и технических писателей. В идеале всё должно быть реализовано именно так, как написано в ТП. На деле же оказывается, что итоговая реализация отличается от ТП. Вы знаете, как это бывает: что-то не учли, что-то поняли неправильно, что-то оптимизировали… Для того, чтобы узнать, как на самом деле всё было реализовано, мы используем техническое описание (ТО), которое пишут разработчики. Там есть больше технических подробностей, описаны изменения конкретных типов данных и таблиц в БД, приведены алгоритмы работы процедур серверного кода, приведены скриншоты добавленных или изменённых окон в клиентских приложениях. Без ТО нам было бы очень трудно написать полноценную документацию. К сожалению, разработчики иногда откладывают написание ТО на самый последний момент.
Есть ещё один важный источник — описание настроек интеграционного тестирования. Там подробно описаны все настройки, которые нужно сделать в системах, чтобы пройти все тестовые сценарии (тест-кейсы). Этот источник незаменим для написания руководств по настройке.
ТП, ТО и описание настроек — это основные источники, из которых писатель получает информацию. Но есть ещё множество дополнительных: исходный код серверных процедур и клиентских приложений, XML-описания параметров, страницы в базе знаний Wiki, наконец — вопросы разработчикам и тестировщикам в мессенджерах. Ну и, конечно, сами системы — их web-интерфейс, клиентские и серверные приложения.
Задача писателя — объединить всю полученную информацию и написать простую, понятную и хорошо структурированную документацию о системе или решении. Тут нужно быть очень внимательным — ничего не перепутать, не забыть, описать именно то, что было реализовано. Писатель должен самостоятельно разобраться во всех особенностях реализации, понять все алгоритмы и принципы работы системы от начала и до конца. Только так получится хорошая и качественная документация.
Один в поле не воин
Часто думают, что технический писатель — это профессия, не требующая особых коммуникативных навыков. На практике оказывается, что для написания документации каждый день приходится консультироваться со множеством коллег: бизнес-аналитиками, разработчиками, тестировщиками. Бывает так, что в исходных документах авторы что-то опускают, что-то недоговаривают. Работа писателя — быть профессиональным занудой: уточнять, переспрашивать, перепроверять информацию много раз, чтобы правильно всё описать и не допустить ошибку в документе. Бывают случаи, когда писатели находят ошибки в реализации. Писатель выполняет свою работу на самом последнем рубеже перед отгрузкой системы и документации заказчику.
На поверку становись!
Когда писатель завершает работу над документом, он обязательно отправляет его на проверку. Документацию проверяют бизнес-аналитики, разработчики, тестировщики. Это очень важный этап, ведь писатель всегда может ошибиться — что-то неправильно понять, не учесть каких-то незадокументированных особенностей реализации.
Ещё наши документы проверяет наш профессиональный технический редактор. Он исправляет орфографические и грамматические ошибки, подчищает описки, следит за смысловой и логической чистотой документа, проверяет соблюдение руководства по стилю. Это руководство — наш маленький внутренний стандарт. В нём записаны разрешённые и запрещённые термины, правила оформления документов разных типов, приведены наиболее часто используемые фразы, конструкции и обороты. Руководство по стилю помогает нам писать документацию по общим для всех писателей правилам: единство стиля — прежде всего. В воображении читателя должен возникнуть собирательный образ одного крутого профессионала — писателя, который создаёт разные документы или разделы.
Праздник труда
Работа технического писателя не такая однообразная, как может показаться со стороны. Мы пишем очень разные документы — у нас есть и справочники с большими таблицами параметров или полей БД. Есть руководства пользователя с подробным описанием каждой кнопки интерфейса. Есть руководства администратора со множеством технических подробностей о работе и установке системы. Но самый сложный, и при этом самый интересный, тип документа — это руководство по настройке. В нём комплексно описывается реализация определённого решения в разных системах и подробно объясняется что и где нужно настроить, чтобы это решение заработало. Писателю приходится писать разные типы документов — сегодня часами описывать один за другим параметры системы, а завтра думать над тем, как понятнее и проще описать алгоритм работы решения в руководстве по настройке. Но в любом случае писатель должен быть внимательным, аккуратным и педантичным.
Клиент всегда прав — отгрузка до 23.59.59
После проверки мы отгружаем документы заказчику. Документы на систему мы отгружаем одновременно с передачей готовой системы. Новые версии ранее отгруженных документов мы, по сложившейся традиции, передаём в пятницу. Документацию мы пока отгружаем в формате PDF — вместе с новой версией системы заказчик получает пакет файлов. Их можно скачать на специальном портале, где каждому заказчику доступна документация по тем системам и их версиям, которые у него установлены. Кстати, нашей документацией пользуются не только заказчики: многие сотрудники компании Bercut тоже обращаются к нашим документам, чтобы разобраться в каком-то сложном вопросе по функционированию той или иной системы.
Большие надежды — портал bercut.web.docs
Конечно, PDF-файлы — это не самый удобный формат пользовательской документации. К примеру, поиск нужной информации можно выполнять только в рамках одного PDF-файла. Нельзя поискать описание какого-то параметра сразу во всей документации по системе. Это очень неудобно, ведь количество документов на одну систему часто исчисляется десятками. Если не знать, в каком документе искать нужные данные, то поиск превращается в нетривиальную задачу. Сейчас мы работаем над созданием портала, на который сможем выгрузить документацию в формате HTML. Там будет предусмотрен удобный полнотекстовой поиск по всем страницам или по части документации, например, по страницам на определенную версию определенной системы.
Да здравствует Команда!
Также по пятницам у нас обычно проходит еженедельное совещание нашей команды в Skype. Эта традиция появилась у нас с переходом на удалённый режим работы. На совещании наш Team Lead делится с нами свежими новостями компании Bercut, рассказывает о новых краткосрочных и долгосрочных задачах и планах. Писатели по очереди рассказывают о своих задачах и рабочих проблемах — что сделано за прошедшую неделю, что планируется сделать на следующей. Такое обсуждение помогает нам скоординировать свои действия, ведь часто над пакетом документов к очередной версии системы работает сразу несколько писателей.
Последний штрих
Заканчивается рабочий день технического писателя тем же, чем и начинался — синхронизацией с SVN. Конечно, мы часто выполняем промежуточные синхронизации и в середине дня, но вечером обязательно проверяем, все ли изменения выгружены на сервер. Будет обидно, если вся работа, сделанная за день, пропадет даром. И конечно, надо не забыть оформить трудозатраты — вписать в задачи Jira время, которые мы на них потратили за этот день.
Призвание
Работа технического писателя — сложная, но действительно интересная. Каждый день мы придумываем, как упростить и сделать понятными сложные алгоритмы, правила и системы, как сделать документацию удобной, полезной и красивой. В компании разрабатываются новые системы, постоянно добавляется функциональность в уже существующие системы. А это значит, что наша работа никогда не станет скучной и однообразной. Вносить ясность, добывать смысл, помогать читателю-пользователю решить любую задачу — в этом и есть наше профессиональное призвание.