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

3. Основная часть.Здесь сосредоточен основной материал — анализ, сравнение, описание или повествование — в зависимости от типа статьи.

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

5. Заключение.Во всех типах статей, кроме аналитики, авторские выводы (именно личные авторские) пишутся тут. Вместо личного мнения автора могут быть его размышления о дальнейшем развитии темы. Например, рассказывая в статье про обстановку в городском ЖКХ, он может упомянуть о планах по изменению законодательства и перспективах по внедрению каких-либо новых технологий. Заключение присутствует в тексте не всегда, поскольку автор имеет право оставить все выводы и мысли «на совести читателя», не вплетая в материал свою субъективную оценку или мнение.

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

Стоит отметить, что хоть статьи «для широкого круга читателей» и являются некой точкой пересечения приёмов технических и классических писателей, большая часть вольностей в них недопустима. Например, если автор рассказа может себе позволить недосказанность, которая более-менее проясняется к середине теста, а то и к концу, то в статье все должно быть разложено по полочкам с самого начала — заставлять читателя ничего додумывать нельзя. В то же время, публицистические статьи, написанные живым разговорным языком, пусть даже с применением синонимов и литературных приёмов (гипербола, иносказание и т.д.) воспринимаются гораздо лучше, чем изложенные сухим техническим языком.

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

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

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

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

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

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

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

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

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