Профессия "Технический писатель", или "Рыцари клавиатуры" - [32]
1. Человек не знает ничего. По сути, это портрет домашнего пользователя. Ему нужно разжёвывать все действия подробно, сопровождая каждое скриншотом с дополнительными отметками (вроде подчёркивания кнопок, которые нужно нажать).
2. Человек знает систему, но не знает описываемое ПО. Портрет опытного пользователя. Вам нужно рассказать, как пользоваться программой, при этом можно значительно уменьшить размер документа за счёт скриншотов и описания однотипных действий. Но установку нужно описать подробно, можно со скриншотами, ибо ошибка в ней (например, пропуск важного компонента) чревата проблемами в дальнейшей работе. А многие остальные действия можно описывать уже только словами. Этот вариант подходит для руководств пользователей программного обеспечения, которое не требует мудрёной настройки и интеграции с системой (или требует, но для этого есть администратор со своей отдельной инструкцией).
3. Человек хорошо знает и железо, и систему, и при этом легко способен догадаться, как пользоваться вашим ПО. Иными словами, это администратор. Ему нужно подробно описать установку (всё по той же причине её критичности) и настройку вашего продукта (если в них есть тонкости, а в крупных комплексах они есть всегда), процесс его ввода в эксплуатацию и наиболее часто возникающие проблемы (и, если это известно, методы, которыми пользователи эти проблемы администратору поставляют — такая информация очень поможет администратору в работе). При этом обратите внимание, что установку и базовую настройку вы можете описать в руководящем стиле (нажмите, сделайте), то остальную работу с программой нужно описывать в справочном формате: за что отвечает та или иная опция или кнопка, как происходит выполнение основных действий и т. д.
4. Человек написал ПО, которое вы описываете, и тем же будет заниматься тот, кто придёт на его место и будет читать ваш текст. То есть это программист-разработчик. Здесь разъяснять не надо вообще ничего. Только комментировать краткими фразами, давая определения.
В нашем примере мы будем действовать по второму варианту.
Третьим шагом нужно определить необходимый уровень описания. От глубины изложения он отличается тем, что является, по сути, количеством данных, которые писатель выливает на пользователя.
1. Домашнему пользователю нужно предельно подробно описать, как он может выполнить его конкретные задачи, все остальные свойства программы можно привести в конце руководства в справочном формате. Описывать работу программы необходимо с самого начала, нажатия кнопки «Пуск», а установку — с вставки диска в привод или запуска браузера для скачивания дистрибутива. Таким образом, даже описание использования программы «Калькулятор Windows» займёт два десятка страниц.
2. Опытному пользователю требуется изложить все возможности программы с достаточным для понимания уровнем пояснения. Скриншоты по мере необходимости без дополнительных надписей. Вы описываете только работу с программой, ничего сопутствующего — вставить диск или сохранить файл стандартным способом эта ЦА способна самостоятельно.
3. Администратору нужно изложить настройки, описать типовые действия (установку, заведение пользователей и т. д.), максимально кратко, как можно больше использовать списки с перечислением и краткие инструкции. Скриншотами снабжать имеет смысл только наиболее сложные моменты в инструкции. Про непосредственное использование ПО в таком документе можно вообще ничего не писать, для этого есть руководство пользователя.
4. Разработчику не надо вообще ничего описывать, от вас не будет никаких лишних слов. Просто констатация фактов в виде «сущность — определение». Рисунков, кроме блок-схем алгоритмов или схем БД, тут нет вообще. Сделанное подобным образом описание, к примеру, базы данных с сотней таблиц, может занять всего 50-60 страниц.
Как и в прошлом пункте, в нашем примере мы будем действовать по второму варианту.
Четвёртым шагом должен стать выбор манеры общения с читателем и подбор стиля и логики изложения для максимальной простоты восприятия материала. Поскольку основная задача писателя — сделать так, чтобы читающий его документацию пользователь легко и быстро извлёк из неё именно то, что ему требуется и, желательно, в приятной ему манере. Стиль изложения во всех случаях желательно использовать официально-деловой, без разговорных терминов и сокращений.
Стоит заметить, что есть сторонники иного подхода, утверждающие, что инструкцию можно сделать весёлой, так как это облегчит её восприятие. Увы, как показывает практика, этот подход ни к чему хорошему не приводит. Связано это с двумя факторами:
1. Чтобы писать «лёгкую и весёлую инструкцию», нужно быть настоящим мастером языка, в противном случае очень легко превратить серьёзный по своей сути текст в банальную клоунаду, которую будет неприятно читать.
2. Многие пользователи открывают инструкцию только тогда, когда у них уже возникли проблемы с программой. Естественно, что настроение у них в этот момент не самое радужное, а настроя посмеяться и вовсе нет. В таком случае даже хорошо и легко написанный текст будет воспринят ими негативно, просто потому что «я тут влип, а они дурью маются!»
