Профессия "Технический писатель", или "Рыцари клавиатуры"

Глава 7. Основы создания технической документации

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

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

Первым шагом будет определение целевой аудитории вашего документа. Основные варианты ЦА были у нас рассмотрены ранее (см. раздел «Основные группы пользователей документации»), поэтому останавливаться на этом повторно мы не будем. Вам же нужно сделать выбор, от которого будут зависеть дальнейшие действия, поскольку поняв, кто будет конечным пользователем вашего текста, вы сможете выбрать стиль изложения, глубину подачи материала и всё остальное. Мы же в своём примере будем писать документ для опытных и корпоративных пользователей.

Вторым шагом будет выбор соответствующего уровня разъяснения. В зависимости от вашей ЦА, потребуется определить, что именно и насколько подробно разбирать в документе, чтобы человек с его предполагаемым набором знаний без труда смог разобраться в вашем тексте. Основные варианты:

1. Человек не знает ничего. По сути, это портрет домашнего пользователя. Ему нужно разжёвывать все действия подробно, сопровождая каждое скриншотом с дополнительными отметками (вроде подчёркивания кнопок, которые нужно нажать).

2. Человек знает систему, но не знает описываемое ПО. Портрет опытного пользователя. Вам нужно рассказать, как пользоваться программой, при этом можно значительно уменьшить размер документа за счёт скриншотов и описания однотипных действий. Но установку нужно описать подробно, можно со скриншотами, ибо ошибка в ней (например, пропуск важного компонента) чревата проблемами в дальнейшей работе. А многие остальные действия можно описывать уже только словами. Этот вариант подходит для руководств пользователей программного обеспечения, которое не требует мудрёной настройки и интеграции с системой (или требует, но для этого есть администратор со своей отдельной инструкцией).

3. Человек хорошо знает и железо, и систему, и при этом легко способен догадаться, как пользоваться вашим ПО. Иными словами, это администратор. Ему нужно подробно описать установку (всё по той же причине её критичности) и настройку вашего продукта (если в них есть тонкости, а в крупных комплексах они есть всегда), процесс его ввода в эксплуатацию и наиболее часто возникающие проблемы (и, если это известно, методы, которыми пользователи эти проблемы администратору поставляют — такая информация очень поможет администратору в работе). При этом обратите внимание, что установку и базовую настройку вы можете описать в руководящем стиле (нажмите, сделайте), то остальную работу с программой нужно описывать в справочном формате: за что отвечает та или иная опция или кнопка, как происходит выполнение основных действий и т. д.

4. Человек написал ПО, которое вы описываете, и тем же будет заниматься тот, кто придёт на его место и будет читать ваш текст. То есть это программист-разработчик. Здесь разъяснять не надо вообще ничего. Только комментировать краткими фразами, давая определения.

В нашем примере мы будем действовать по второму варианту.

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

1. Домашнему пользователю нужно предельно подробно описать, как он может выполнить его конкретные задачи, все остальные свойства программы можно привести в конце руководства в справочном формате. Описывать работу программы необходимо с самого начала, нажатия кнопки «Пуск», а установку — с вставки диска в привод или запуска браузера для скачивания дистрибутива. Таким образом, даже описание использования программы «Калькулятор Windows» займёт два десятка страниц.

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

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

4. Разработчику не надо вообще ничего описывать, от вас не будет никаких лишних слов. Просто констатация фактов в виде «сущность — определение». Рисунков, кроме блок-схем алгоритмов или схем БД, тут нет вообще. Сделанное подобным образом описание, к примеру, базы данных с сотней таблиц, может занять всего 50-60 страниц.

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

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

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

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

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

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

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

1. Домашние пользователи. Им легче осваивать ПО, если есть ощущение, что кто-то помогает им, буквально стоя рядом и держа за руку. Поэтому в описании лучше всего взять на себя роль этого самого находящегося под боком учителя: вы словно выполняете все действия вместе с пользователем, буквально держа свою руку поверх его и направляя все движения. Для создания этого эффекта везде идёт описание от первого лица во множественном числе: «мы сделаем то-то», «откроем папку», «чтобы получить то-то, сделаем это, напишем это» и т. д.).

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

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

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

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

В нашем примере лучше всего использовать форму «вы».

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

1. Для домашних пользователей нужно снабдить скриншотом каждое действие, а на самих скриншотах не помешает выделить нужные элементы с помощью графического редактора (например, обвести нужную кнопку и указать на неё стрелкой). То же касается и рисунков к статьям, предназначенным для этой ЦА — они должны присутствовать в достаточном количестве, «разбавляя текст». Здесь задача картинок буквально проиллюстрировать материал, чтобы пользователь увидел своими глазами всё, о чём говорится в документе.

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

3. Для администраторов снабжать рисунками нужно только те фрагменты инструкции, где есть значительное количество настроек, которые требуется менять при вводе программы в эксплуатацию или в процессе её использования. Если процесс настройки и базовой установки сложен, его можно «проскринить» полностью, опуская только очевидные моменты. Также нужно отметить, что если какой-то процесс содержит много ветвлений, то это повод изложить его в виде блок-схемы с комментариями, а не описывать всё словами. При написании статей для этой ЦА будет полезно использовать графики и схемы, поскольку одной из задач этих статей зачастую является сравнение и анализ каких-либо данных.

4. Для разработчиков не требуется ни скриншотов, ни картинок. При этом графики в документах для них может быть достаточно много — это и структурные схемы баз данных, и схемы алгоритмов (иногда имеют просто огромный размер и распечатать их очень затруднительно, картинка может иметь размер 2×5 метров в масштабе распечатки 100%). Какие именно схемы и блок-схемы изображать — нужно согласовывать с консультантами, которых выделит вам отдел разработки. Это связано с тем, что только сами разработчики могут сказать, какие графические пояснения будут полезны их коллегам, а какие будут ненужным отчётом Капитана Очевидности.

В описанном в начале темы примере удобно использовать второму варианту.

Шестым шагом будет определение последовательности описания элементов программы и действий с ними.

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

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

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

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

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