Кто такой технический писатель и как им стать
Привет, меня зовут Ольга Громыко. Я работаю техническим писателем в R‑Style Softlab и создаю документацию по банковскому ПО, которая помогает пользователям разобраться в работе сервисов. В статье подробно расскажу, чем занимается технический писатель, какие навыки помогают ему в работе и какие перспективы есть у таких специалистов.
Чем занимается технический писатель
Технический писатель — специалист, который готовит документацию к ПО. Руководства дают пользователям ответы на вопросы о работе продукта, помогают быстро сориентироваться в настройках и познакомиться со всеми возможностями системы. Чтобы собрать нужную информацию и описать решение, техпис общается с аналитиками, разработчиками, тестировщиками, дизайнерами и менеджерами проекта.
Идеальная техническая документация, в первую очередь, должна быть понятной. Чтобы пользователь мог легче ориентироваться в тексте, нужно продумать структуру, логику описания и навигацию, использовать списки, схемы и таблицы, добавить скриншоты интерфейса и иллюстрации.
Как попасть в профессию и найти первый проект
Для того чтобы работать техническим писателем, желательно иметь техническое образование. Но это не обязательное условие. Я закончила филологический факультет и раньше преподавала в школе русский язык и литературу.
В ИТ‑сферу я попала, можно сказать, случайно: мне предложили попробовать себя в роли технического писателя в R‑Style Softlab в 2019 году. Обязанности показались мне интересными, я прошла собеседование и вышла на работу в ДСЭБО (Департамент систем электронного банковского обслуживания). Моим первым проектом стал большой продукт для РСХБ по дистанционному банковскому обслуживанию юридических лиц.
Признаюсь, что освоиться было сложно. Чтобы разобраться в банковских терминах, документах и криптографической защите, приходилось много читать и смотреть видеоуроки. Параллельно я проходила курсы от тимлидов‑техписов из других компаний.
Некоторые считают, что в этой сфере у специалиста обязательно должно быть техническое образование. Иначе не получится грамотно рассказать о работе ИТ‑продукта. На самом деле, образование может быть любым. Главное, чтобы было желание разобраться в тонкостях профессии.
Какие бывают типы технической документации
Технический писатель может разрабатывать разные типы документов. Все зависит от компании и продукта. В одной организации специалист может составлять руководства администратора и пользователя, в другой — выпускать обновления к релизу, а в третьей делать и то, и другое. Чаще всего технические писатели готовят следующие типы документов:
Руководство пользователя. Такие инструкции объясняют простыми словами, как использовать продукт. Обычно они содержат пошаговые указания, скриншоты системы и советы по решению проблем.
Документация для технических специалистов. В данных документах описываются системные требования, настройка серверов, раздача прав доступа и другие детали.
API‑документация. В таких руководствах описывают, как использовать интерфейсы прикладного программирования (API), которые применяются для интеграции различных систем. API‑руководство должно содержать информацию о доступных функциях, методах, параметрах, типах данных и примерах кода.
Документация по обновлениям. Когда выходит новая версия продукта, все изменения нужно отражать в руководствах. В них рассказывают о новых функциях, исправленных ошибках и технических ограничениях.
В R‑Style Softlab я пишу инструкции для клиентов, системных администраторов и работников банка (операционисты, которые обслуживают клиентов в отделениях банка: оформляют карты и кредиты, помогают сделать переводы и консультируют по финансовым вопросам). При этом для каждого пользователя необходимо учитывать специфику его работы в приложении.
У многих техписов есть правило: писать так, чтобы поняла «гипотетическая бабушка». Конечно, не все ИТ‑продукты можно описать очень простым языком, но всегда можно сделать так, чтобы любой человек открыл документ, выполнил действия по шагам и получил результат.
Как выстраивать работу над проектом
В зависимости от того, как строится работа на проекте (водопад или аджайл), технический писатель создает документацию на финальном этапе или обновляет руководства параллельно с разработкой продукта. Чаще всего работа технического писателя строится строится следующим образом.
Постановка задачи. Технический писатель получает задачи от менеджеров продукта или руководителей отделов. Обычно в техзадании указывают сферу работы программы, а также объем и тип технической документации, назначают дедлайны и ответственных сотрудников. Детали задачи я уточняю в Jira: пользоваться системой удобно, потому что кроме ТЗ там можно найти дополнительные документы и пояснения к ним.
Сбор и анализ информации. Этот шаг — один из самых сложных и времязатратных. Чтобы получить все нужные данные, пользуюсь разными источниками:
Изучаю документацию от банка и аналитиков. Читаю функциональные требования, технические задания, спецификации, архитектуру проекта, описания отдельных компонентов системы, пояснительные записки. Также изучаю работу продукта как пользователь, смотрю тестовые стенды.
Задаю вопросы коллегам. Первым делом иду к аналитикам и собираю информацию о продукте: они ставят задачи на разработку, поэтому хорошо разбираются в работе продукта. Если нужно уточнить нюансы, обращаюсь к тестировщикам: в ходе тестирования также можно понять, как конкретно работают те или иные функции. Иногда задаю вопросы разработчикам, чтобы получить больше данных о деталях и логике работы систем.
Скрин главной страницы мобильного приложения РСХБ ФЛ
Написание текста. На этом этапе все зависит от того, нужно ли соблюдать ГОСТы в технической документации. Если технический писатель готовит руководства или инструкции по стандартам, они должны соответствовать требованиям ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология». Обычно такая документация нужна государственным компаниям.
Писать техническую документацию без требования к соответствию ГОСТ проще: не нужно соблюдать множество нормативов. Я работаю как раз с такими текстами. Использую шаблон в Word, который разработали в компании еще до меня. В нем уже есть базовый формат и структура. Клиентам тоже привычнее получать и согласовывать руководства в таком виде, но многие техписы используют специальное ПО.
Проверка документации. Ошибки в руководствах могут привести к серьезным последствиям. Например, если технический писатель неправильно прописал команды для установки в инструкции к банковскому ПО, сисадмину придется тратить много времени на поиск ошибки.
Чтобы избежать подобных проблем, готовую документацию нужно перепроверять. В некоторых компаниях это делают тестировщики, а в R‑Style Softlab организовали перекрестную проверку: технические писатели ищут в документации друг друга ошибки и несоответствия.
У нас нет каких‑то универсальных сроков на подготовку технической документации. Все зависит от объема задачи и опыта технического писателя. В среднем на написание одного руководства уходит около месяца.
Согласование документации. Когда руководство готово, его нужно отправить заказчику, чтобы он изучил документ и внес правки. Здесь тоже бывает по‑разному: одни принимают документацию сразу, а другие заставляют пройти несколько итераций правок.
Обновление документации. Когда выходит следующая версия продукта, нужно скорректировать техническую документацию: описать новые функции, убрать неактуальные, а иногда переписать весь раздел для удобного чтения.
Какие навыки нужны для работы
Если рассматриваете для себя работу техническим писателем, проверьте свои навыки.
Грамотность. Техпис должен разбираться в стилистике, грамматике, орфографии и пунктуации. Грамотный текст — это, в первую очередь, уважение к читателю. Кроме того, ясный и однозначный текст легче понять.
Логическое мышление и структурирование текста. Логика в тексте отвечает за причинно‑следственные связи. Понятная структура и простые предложения помогают читать по диагонали и быстро находить нужный раздел или описание в документе. Я всегда разбиваю текст на блоки, использую подзаголовки, таблицы и списки.
Коммуникативные навыки. Технический писатель должен уметь задавать вопросы и получать конкретные ответы от коллег. Правильно заданный вопрос — это половина успеха. Не бойтесь переспрашивать, если не получили ответ сразу же. Помните, что коллеги могут быть заняты другими задачами и пропустить ваше письмо в почте.
Чтобы упростить получение нужной информации, я часто вместе с вопросом присылаю варианты возможных ответов и нумерую их. Так собеседник может просто отправить цифру в чат, не отвлекаясь от рабочих задач.
Также необходимо кратко прописать уже пройденные шаги или специфические условия, чтобы коллега не тратил время на разъяснение отдельных моментов.
Если я не разобралась в вопросе с первого раза, снова обращаюсь к коллегам. Они всегда идут навстречу — объясняют другими словами, приводят понятные примеры, демонстрируют экран и показывают наглядно работу приложения.
Усидчивость. Подготовка технической документации занимает много времени и требует внимательности. Нужно собрать и изучить информацию, переработать ее и написать документ. Если человеку тяжело сконцентрироваться и он легко отвлекается, ему будет трудно.
Стрессоустойчивость. Будьте готовы к правкам. Замечания — это рабочий процесс, так что не стоит принимать их близко к сердцу. Помню, когда только начинала свой путь, коллега оставляла много комментариев к моим текстам. На пятом круге хотелось сдаться, но правки дают свои плоды: со временем я стала писать лучше.
Желание учиться и развиваться. В этой профессии приходится работать с разными продуктами. У каждого своя специфика и особенности, и документация тоже будет различаться по объему и содержанию. Технологии постоянно развиваются, поэтому часто приходится знакомиться с новыми темами и вникать в детали.
Сейчас многие технические писатели используют нейросети в работе. Я тоже часто задаю в Chat GPT вопросы о работе смежных систем, чтобы не тратить лишнее время на их детальное изучение, или прошу пояснить значение того или иного термина. Но мы готовим документацию для людей, поэтому руководства должны быть написаны живым языком —, а ИИ пока так не может.
Куда расти в профессии
Хорошие технические писатели всегда на вес золота, потому что быстро и качественно написанная документация помогает развивать и продавать продукт. Но позиция техписа может быть и хорошим стартом для другого профиля в ИТ:
Аналитик. Технический писатель может перейти в сферу аналитики: у такого специалиста есть навыки, которые помогут быстрее влиться в работу, например, сбор, структурирование и объединение информации. Помимо этого, аналитику нужно общаться напрямую с заказчиком, составлять функциональные требования и ставить задачи разработчикам.
Тестировщик. Для работы в этом направлении у технического писателя тоже есть нужные навыки. Когда специалист готовит документацию, он проходит весь процесс по шагам и приобретает, пожалуй, основной навык тестировщика — находить баги в реализации.
На позиции, связанные с разработкой продуктов и менеджментом проектов, переход также возможен, но сделать это будет сложнее. Техпис понимает особенности ведения проектов и даже может быть знаком с азами языков программирования, но в этих профессиональных областях много специфики и часто требуются глубокие знания.
На июль 2024 года вакансий технического писателя на рынке не так много — например, на портале HeadHunter их всего около 1000. Для сравнения, по запросу «разработчик» выходит список из 61 000 предложений.
Низкий спрос на технических писателей можно связать с тем, что во многих компаниях техническую документацию пишут другие специалисты, например, аналитики, тестировщики, разработчики. Порой работодателям кажется, что нет смысла открывать еще одну позицию в штате. Я считаю, что каждый сотрудник должен заниматься своим делом. Если один работник выполняет обязанности двух разных специалистов, он может допустить ошибку и не справиться с задачей.
Требования к кандидатам бывают разные: например, техническое образование, опыт работы с Linux‑системами и языками разметки. В R‑Style Softlab мы часто нанимаем специалистов без опыта. Главное для нас — это желание учиться и разбираться в материале, общаться с людьми и задавать вопросы. Собеседуем кандидатов в несколько этапов.
Тест на грамотность. Кандидату предлагается исправить ошибки (орфографические и пунктуационные) в техническом тексте. За счет того, что большинство слов не знакомы соискателю, этот этап хорошо демонстрирует общую эрудицию, способность разбираться в структуре предложения, ориентироваться в незнакомой области знаний.
Проверка умения работы со списками и структурой текста. На этом этапе соискатель должен прочитать текст, проанализировать информацию и логически правильно расположить отдельные части текста. Приветствуется структурирование данных в виде списков разного уровня.
Творческое тестовое задание. Далее кандидату предлагается описать своими словами скриншот раздела реальной системы. Это задание показывает и уровень грамотности соискателя, и логику изложения, и манеру построения предложений.
Тест на логику. Предлагаем пройти тест. Если кандидат допустил немного ошибок, мы даем шанс исправиться самостоятельно. В случае если человек смог дать верные ответы, засчитываем прохождение данного этапа.
После выхода на работу для соискателя разрабатывается индивидуальный план обучения. Примерный срок 一 три месяца, но он может быть сокращен в зависимости от успехов сотрудника. Во время испытательного срока коллеги подробно объясняют особенности проекта, на котором обучается работник, помогают разобраться с требованиями к текстам, а также знакомят с корпоративным стилем.
После прохождения испытательного срока работник не остается наедине с задачами и проблемами, коллеги продолжают некоторое время проверять документацию. Так сотрудник может меньше переживать из‑за ошибок и спокойно погружаться в профессию.
