Обучение

Новости
О центре
Центр Профессионального развития
Сообщение об ошибке

Обучение

Ближайшие старты

IT Bootcamp

Новости

О центре

Центр Профессионального развития

Корпоративное обучение

Отзывы

Истории успеха

🎁 Подарочные сертификаты

Сообщение об ошибке
Введите поисковый запрос

Можно ли убрать из проекта технического писателя?

24 января 2022

«Эй, зачем убирать?», – возмутится техпис, техрайтер, технический автор или документатор (да-да, как только эту профессию не называют…)

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


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

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

Код главнее, но текста больше 

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

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

Кто-то подумает: «Почему в конце разработки проекту нужен ещё и технический писатель? Текстов же и так в избытке». На самом деле, они всё еще полностью не отвечают на главные вопросы, которые интересны пользователю: как работает программа и как настраивается. 

Разбираемся дальше.


Программисты пишут код, а не тексты

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

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

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

И здесь хочется спросить: «А кто-то вообще читает эту пользовательскую документацию? Если программа работает, не лагает, зачем столько дополнительного текста, который обычно никто полностью не читает?» 

Сейчас объясним. 


«На такую-то кнопку так сразу и не нажмёшь»

Помните эту фразу Гомера из «Симпсонов»? Она актуальна и для тех систем, которые развиваются уже много лет. В них появляются новые функциональности, в то время как старые отмирают или модифицируются. Настраивать такие системы сложнее. В пользовательском интерфейсе становится больше опций, которые связаны друг с другом непонятным образом. 

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

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

Не стоит забывать и о таком распространённом явлении, как плохо спроектированный интерфейс. Пользователь просто не понимает, на какую кнопку нужно нажать, чтобы получить нужный результат. Много каких-то одинаковых кнопок без названия, при этом никаких подсказок… Запутаться проще простого. Для таких случаев технический писатель и прописывает что-то в таком роде: «чтобы добавить поле, нажмите на правую кнопку панели инструментов в правом нижнем углу главного меню». 

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


Метаданные vs пользовательская документация

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

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

«Зоопарк» формулировок 

Каждая разветвленная система «живёт по своим понятиям». У нее даже есть свой «дворовый IT-жаргон». Чтобы участники проекта нормально коммуницировали друг с другом, они должны использовать единый глоссарий терминов. В крупных международных компаниях даже существуют свои отделы по управлению терминологией. Но это работает не у всех. Поэтому один и тот же объект кто-то может обозначить в документах как «системный параметр», а другой участник команды – как «запись в таблице параметров». Разработчики поймут оба названия, а вот пользователь может так и не осознать, что это всё относится к одному объекту. 

Для пользовательской документации еще важны общепринятые описательные фигуры, такие как «нажмите кнопку», «выполните следующие действия», «В приложении … есть несколько дополнительных настроек» и т.д. Эти фразы неоднократно встречались каждому. Мы к ним привыкли. Такие технические клише упрощают любую сложную инструкцию. Если в документе написано «выберите режим», а потом «перейдите в режим», мы можем засомневаться: нужно выполнить одно действие или два разных? 

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


«Лучший гуманитарий среди технарей»

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

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

С каждым годом профессия технического писателя становится популярнее. Раньше составлением пользовательской инструкции нередко занимались сами разработчики, хотя их обязанность – писать код, а не тексты. Но у них не всегда получалось составить документацию на простом языке, который будет понятен человеку без технического образования. Теперь же многие компании берут на проекты технических писателей. Как прогнозирует Министерства труда США, занятость техрайтеров будет расти каждый год на 7%. 

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

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

Приглашаем на курс «Technical writing» в IT-Academy.

Полная, частичная перепечатка или любое иное использование материалов с сайта IT-Academy разрешается только с указанием активной гиперссылки, ведущей на первоисточник (точный адрес страницы на www.it-academy.by).