Оформление руководства пользователя по госту. Кратко и к месту: как правильно составлять инструкции пользователям. Объясним специальные термины

Документ «Руководство пользователя» относится к пакету эксплуатационной документации. Основная цель руководства пользователя заключается в обеспечении пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой.

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

Руководящими стандартами для создания документа Руководство пользователя могут являться как РД 50-34.698-90 в п.п. 3.4. «Руководство пользователя» , так и ГОСТ 19.505-79 «Руководство оператора. Требования к содержанию и оформлению» . Ниже для сравнения приведены структуры документа согласно двум перечисленным стандартам.

РД 50-34.698-90 (п.п. 3.4 Руководство пользователя)	ГОСТ 19.505-79 Руководство оператора
Введение
Область применения
Описание возможностей
Уровень подготовки пользователя
Перечень эксплуатационной документации, с которыми необходимо ознакомиться пользователю
Назначение и условия применения
Виды деятельности и функции, для автоматизации которых предназначена программа	Назначение программы
Условия, при которых обеспечивается применение программы	Условия выполнения программы
Подготовка к работе	Выполнение программы
Порядок загрузки данных и программ	Порядок загрузки, запуска и завершения программы
Проверка работоспособности
Описание операций	Описание функций
Описание всех выполняемых функций, задач, комплексов задач, процедур
Описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур
Аварийные ситуации (действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных, и т.п.)	Сообщения оператору

Таким образом, мы можем выделить следующие основные разделы руководства пользователя:

• Назначение системы;
• Условия применения системы;
• Подготовка системы к работе;
• Описание операций;
• Аварийные ситуации.

Назначение системы
Данный раздел документа Руководство пользователя должен содержать информацию о назначении системы, ее целях и задачах.

Пример:

«Корпоративный интранет портал предназначен для повышения корпоративной культурыр организации эффективного взаимодействия сотрудников.

Основной целью Порта является создание единого информационного пространства предприятия и оптимизация работы сотрудников путем облегчения коммуникаций между ними и оптимизации ряда бизнес-процессов.»

Условия применения системы

Данный раздел документа Руководство пользователя должен включать все те факторы, которые необходимы для корректной работы системы. Здесь можно выделить несколько подразделов:

• Требования к аппаратному обеспечению - сюда можно включить требования к конфигурации компьютера пользователя, программное обеспечение необходимое для работы Системы, а также наличие дополнительного оборудования (принтер, сканер и т.п.), если таковое необходимо;
• Квалификация пользователя - данный подраздел должен содержать требования к навыкам и знаниям пользователя (пример: «Пользователи должны обладать навыками работы с операционной системой Windows XP» );

Подготовка системы к работе

Данный раздел документа Руководство пользователя должен содержать пошаговую инструкцию для запуска приложения. К этапу подготовки системы к работе можно отнести установку дополнительных приложений (при необходимости), идентификацию, аутентификацию и т.п.

Описание операций

Это основной раздел документа Руководство пользователя, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем.

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

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

Пример:

«4.1 Согласование проекта
Данный процесс предназначен для организации работы сотрудников, участвующих в разработке и согласовании проекта.
Автор проекта создает запись в Системе и прикрепляет пакет необходимой документации, далее проект передается на согласование руководящими лицами. Руководители после ознакомления с проектом могут подтвердить его или отправить на доработку Автору.

4.1.1 Создание проекта
Для того чтобы создать Проект необходимо на панели «…» нажать на кнопку «…» и в появившейся форме заполнить следующие поля:

• Наименование проекта;
• Описание проекта;

Следующие поля заполняются автоматически:

• Дата создания проекта - текущая дата;
• Автор - ИФО и должность автора проекта.»

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

Чем подробнее будут описаны действия с системой, тем меньше вопросов возникнет у пользователя. Для более легкого понимания всех принципов работы с программой стандартами в документе Руководство пользователя допускается использовать схемы, таблицы, иллюстрации с изображением экранных форм.

Для крупных автоматизированных систем рекомендуется создавать отдельное руководство для каждой категории пользователя (пользователь, модератор и т.п.). Если в работе с системой выделяются дополнительные роли пользователей, то в документе Руководство пользователя целесообразно поместить таблицу распределения функций между ролями.

Аварийные ситуации

Данный раздел документа Руководство пользователя должен содержать пошаговые инструкции действий пользователя в случае отказа работы Системы. Если к пользователю не были предъявлены особые требования по администрированию операционной системы и т.п., то можно ограничиться фразой «При отказе или сбое в работе Системы необходимо обратиться к Системному администратору».

Создавая новый продукт (онлайн-сервис, интернет-магазин, мобильное приложение), мы стараемся обеспечить надежность, быстродействие и безопасность продукта. Чтобы выделиться на фоне конкурентов, мы рисуем необычный дизайн, добавляем новые фишки в интерфейс. Опираясь на собственный опыт, считаем, что пользователям будут понятны все нововведения.

Но в большинстве случаев нестандартные решения приводят к потере текущих пользователей и увеличивают стоимость привлечения новых.

Почему после запуска проекта ожидания не равны результатам

Наблюдения за продвижением разных онлайн-сервисов показывают практически одинаковые результаты. Если после запуска сервиса опросить первых 100 пользователей, мы получим примерно такую картину:

• 40 человек не воспользуются сервисом, пока не ознакомятся с инструкциями, скриншотами и видеозаписями, созданными консультантами сервиса. За инструкциями они будут обращаться в техподдержку;
• 20 человек самостоятельно ознакомятся с инструкциями, изучат функции сервиса;
• еще 20 не поймут с чего начать работу и не воспользуются сервисом;
• только 10 пользователей выполнят все настройки правильно, не буду читать инструкции и обращаться в службу технической поддержки;
• оставшиеся 10 человек оценивали сервис, сравнивали его с конкурентами, пока не решили, будут ли его использовать.

Большинство пользователей не разбираются в функциях и навигации онлайн-сервиса; 40% пользователей не читают инструкции на сайте и обращаются за помощью к консультантам. Лишь 10% приступают к работе с сервисом без дополнительной помощи, поскольку имеют необходимый пользовательский опыт .

Как сделать сервис более понятным

Известный специалист в области юзабилити Якоб Нильсен утверждает, что “система должна быть равным образом приемлема для двух групп пользователей - новичков и опытных” (принцип гибкости и эффективности, одно из “10 эвристических правил дизайна пользовательского интерфейса”).

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

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

О чем спрашивают начинающие пользователи

Новые пользователи задают два вопроса:

1. С чего начать, чтобы пользоваться сервисом? (пользователь плохо понимает сервис) .
2. Как выполнить ту или иную задачу? (не понимает последовательности действий, сценария работы) .

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

• Пользователь не нашел инструкцию.
• Пользователь не разобрался в многостраничной документации.

Якоб Нильсен еще в 1995 году сформулировал правило: “лучше всего, если системой можно пользоваться, не читая документацию, но при необходимости нужно обеспечить справочную информацию, которая не должна быть слишком объёмной и должна предлагать список конкретных действий”.

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

В “10 эвристических правилах дизайна пользовательского интерфейса” Якоба Нильсена содержится целый ряд рекомендаций и правил по оформлению пользовательских инструкций.

Мы адаптировали эти советы.

Хорошая справочная статья	Плохая справочная статья
Содержит четкие описания шагов, которые приведут пользователя к цели	Предлагает пользователю самостоятельно определить проблему и выбрать решение из списка
Предлагает инструкции для решения только текущей задачи Нажмите «ОК» и ваше письмо уйдет адресату	Содержит список советов, относящихся к данному этапу работы с системой: Чтобы написать письмо - нажмите «Создать» Чтобы удалить письмо - нажмите «В Корзину» Чтобы отправить письмо - нажмите «ОК»
Размещена на видном месте, появляется, если пользователь зашел на сайт и 10 секунд не выполняет никаких действий	Спрятана в разделе «Помощь по сайту», который никто не читает
Умещается в нескольких предложениях	Содержит много страниц и ссылок

Правила американского юзабилиста дополняет российский специалист, автор книги “Shareware: профессиональная разработка и продвижение программ” Станислав Жарков:

“При описании пути решения проблемы, как и при написании любой документации, нужно избегать составления слишком объемных текстов, т. к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Лучше всего составить что-то наподобие пошаговой инструкции, каждый шаг из которой составляет 1—2 предложения” (“Shareware: профессиональная разработка и продвижение программ”, СПб., 2001).

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

Создаем инструкции с помощью подсказок

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

Известные компании, например, Google и Facebook, помогают пользователям подсказками. Вы встречали их, если создавали на Facebook страницу компании или работали с текстом в Google Docs.

А это пример подсказки для пользователей Google Plus .

Краткие инструкции в подсказках обращают внимание пользователей на новые или дополнительные функции. Система автоматически показывает их новым пользователям в начале работы. Они отображаются лишь один раз, их можно закрыть (пропустить), либо перейти в справочный раздел ресурса и прочитать больше. Чтобы объяснить последовательность действий, разработчики сервисов объединяют такие подсказки в демо-туры. Подобные инструкции предлагают своим пользователям Google Plus и Youtube.

Чек-лист для разработки эффективной инструкции в форме подсказок

1. Опишите подсказками конкретные шаги пользователей.

2. Создайте обучающие туры для сценариев работы.

3. Объясните подсказками назначение сложных функций и специальных терминов.

4. Подскажите пользователям, как ускорить выполнение часто повторяющихся действий.

5. Показывайте подсказки автоматически только один раз, при первом посещении пользователя.

6. Разрешите пользователю включать демо-туры в любой момент.

7. Оформите подсказки в едином для сервиса дизайне.

Инструменты для создания подсказок

Для создания одностраничных инструкций (для одного окна интерфейса) подходят готовые библиотеки кода Java Script: Intro.js и Bootstro.js . Для создания кросс-страничных подсказок подойдут сервисы Hintarea и Walkme.com .

Подсказки могут помочь тем, кто:

• установил новое мобильное приложение;
• воспользовался онлайн-сервисом (системой бронирования, доской объявлений);
• оформляет заказ в интернет-магазине;
• работает с бизнес-приложением (CMS, CRM).

Пример: подсказки для обучения пользователей CMS Wordpress

Представим типичную ситуацию. Веб-студия разработала сайт и передала его компании-владельцу. Наполнять сайт контентом будет менеджер компании. Скорее всего, он не имеет серьезного опыта работы с CMS (пусть в нашем примере это будет WordPress). Панель администрирования вызовет у него ряд вопросов:

• с чего начать работу;
• что означают названия и термины;
• где найти справочную информацию;

Веб-студия сильно упростит клиентам работу с сайтом, если заранее создаст для них подсказки в сложных местах.

Можно придумать десятки подсказок и объединить их в демо-туры, чтобы не заставлять пользователя пролистывать страницы документации или просматривать видео-уроки. Чтобы понять, какие бывают подсказки, напишем пояснения к ключевым задачам.

Объясним пользователю, с чего начинать

Пользователь нажимает на кнопку “Добавить новую”. Появляется окно редактирования новой страницы и следующая подсказка.

Научим правильно заполнять формы

Обратим внимание на важные функции

Формируем понимание работы с контентом

Объясним специальные термины

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

Еще раз о пользе

Ценность подсказок для пользователей очевидна - те, кому раньше требовалась помощь, осваивают сервис или приложение самостоятельно.

Разработчики приложений или сервисов сэкономят на подготовке и публикации технической документации и справочных материалов. Подсказки снизят нагрузку на службу техподдержки.

Владельцы интернет-магазинов, разместившие подсказки, например, на странице оформления заказа, избавятся от части «брошеных корзин», повысят конверсию и доход магазина.

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

Это перевод статьи, ранее опубликованной в американском журнале для интернет-предпринимателей sandhill.com.

Специально для онлайн-издания “ПроГрабли” материал значительно расширен, главным образом за счет включения информации по аспектам UX-дизайна при разработке веб-продукта.

Снова здравствуй, уважаемый хабралюд!

В продолжении своего поста решил написать, как лучше всего создавать инструкции для пользователей и администраторов.

Всем, кому интересно, прошу под хабракат.

KISS

Принцип Keep It Simple Stupid хорошо известен в программировании, но почему-то его редко используют для написания инструкций и руководящих документов, предпочитая растекаться мыслею по древу. В 70% ситуаций эта документация необходима только для того, что бы отмахаться от наших бодрых регуляторов, но при этом забывают, что с этой документацией придётся работать, причём не всегда технически подкованным и грамотным в области информационной безопасности людям.

Для начала напишу несколько правил, которые помогут создать рабочий и удобный документ:

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

Пример инструкции для пользователей

Ниже приведен пример инструкции по заведению аккаунта пользователя в корпоративной сети.

Clear screen/clear desk

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

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

P.S. В посте приведены скрины реально внедренных и работающих инструкции и политик. Все совпадения с существующими организациями случайны. Все названия отделов и бюро изменены.

Эх… вот она «жизнь»!

На личном примере убедилась, что писать руководства пользователя – не такая уж и простая задача… Особенно если не знаешь программный продукт по которому его нужно составить!

Так как же написать руководство пользователя?

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

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

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

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

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

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

Еще есть такой хороший момент – это ГОСТы! Для описания руководств пользователя существует такой замечательный ГОСТ, как ГОСТ 19.505-79 (описание см. в разделе сайта ).

Как написать руководство пользователя:

Основным ориентиром для написания руководства можно выделить следующее описание:

• назначение программы (зачем она вообще нужна, на кого ориентирована и т.п.);

• сообщения оператору (описание возможных ошибок, сообщений пользователей и т.п.).

• условия выполнения программы (min и max аппаратные и программные требования);

• выполнение программы (описание функционала программы, последовательность действий оператора и т.п.);

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

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

1.Краткое описание

2.Модуль А

• Подмодуль А.1
• Подмодуль А.2

3.Модуль В

• Подмодуль В.1
• Подмодуль В.2

В раздел «Краткое описание» помещается краткое описание модулей А и В, а также описываются те повторяющиеся пункты меню, наименования полей и т.п., характерные для обоих модулей. Далее в описании самого модуля/подмодуля описывается краткий алгоритм работы с модулем/подмодулем (загрузка, просмотр, добавление, редактирование, удаление, формирование отчетов и т.д), после чего осуществляется более подробное описание всего функционала и всех имеющихся полей.. Иными словами все в деталях!

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

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

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

Бесспорно, что данная методика носит обобщенный характер! Но из своего опыта могу сказать точно, очень удобна! Удобно пользователю, удобно разработчику руководства пользователя! Все довольны.. 😉

Но как говорится, на вкус и цвет товарища нет! Остается пожелать успешных разработок!

См. похожие статьи

руководств по ЕСПД и IEEE Std 1063-2001 с учетом «манифеста Кагарлицкого». Показано, что обобщенная структура руководства пользователя, собранная согласно требованиям «устаревших» ГОСТов 19-й системы, существенно превосходит структуру руководства, рекомендуемую суперсовременным IEEE Std 1063-2001. Редакция от 20.06.2018.

Как писать руководство пользователя? Часть I - обобщенная структура руководства пользователя по ГОСТам 19-й системы и сравнительный ее анализ с рекомендациями IEEE Std 1063-2001

Создан 11.02.2005 11:14:22

Когда умирает надежда, приходит отчаяние.

Мудрая латинская поговорка

Как писать руководство? Создать древовидную руководства пользователя и заполнить ее разделы. И вся любовь.

Где взять структуру разделов руководства пользователя? С руководствами на (руководство по эксплуатации по) и на () все более или менее ясно. А вот сам документ «Руководство пользователя» программы в ГОСТах 19-й системы отсутствует как класс.

Каким содержимым наполнять разделы руководства пользователя? Как быть? Главное - не отчаиваться.

Цели и задачи статьи

Как всегда, - попытаться облегчить жизнь руководства пользователя программы.

• проанализировать существующие и по разработке, выявить достоинства и недостатки каждого документа по отдельности;
• вывести некую обобщенную структуру руководства пользователя по ГОСТам 19-й системы из имеющегося набора эксплуатационных программных документов;
• сравнить ее со структурой, рекомендованной IEEE Std 1063-2001;
• а все прочие задачи перекочевали во 2-ю часть статьи...

Примечание от 10.07.2014 г. - В феврале 2005 года был проведен, пожалуй, даже не сравнительный анализ, а скорее сравнительные испытания, показавшие неоспоримое превосходство ГОСТов 19-й системы стандартов над буржуйскими и практически полную несостоятельность последних.

Вопросы, на которые должно дать ответы руководство пользователя

Подарите ребенку незнакомую ему электронную игрушку. Перечень вопросов будет примерно таким (если сразу же не разломает):

• а что это;
• а что им можно делать;
• а что им нельзя делать (у особо одаренных);
• а что надо, чтобы оно работало;
• а что там у него внутри (у детей, склонных к глубокому);
• а как его настроить, чтобы работало так, как я хочу;
• а как его проверить, работает оно или не работает;
• а что и где надо нажимать;
• а что оно еще может делать;
• а что оно говорит, если что-то не так нажимаешь?

Последовательность вопросов может оказаться самой разнообразной. И документ под названием «Руководство пользователя» должен дать ответы на все поставленные вопросы. Все просто. Не так страшен черт, как его малюют.

Руководство пользователя: четыре источника и четыре составных части

Располагаем:

• «метагайдом» Кагарлицкого;
• суперсовременным IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
• классическими отечественными ГОСТами 19-й системы, включающим в себя перечисленные ниже документы «описательного» характера:

Крайняя четверка из перечня - эксплуатационные программные документы.

Возможно, существуют и иные документы, но автору, основательно порывшемуся в рунетовской свалке, ничего более подходящего заполучить пока не удалось. Яндекс обнаружил в своих недрах еще одну страничку с названием «Как сделать хорошее руководство пользователя», автор которой именует себя на американЬ ский манер (типа John P. Morgan). Двухстраничное «наставление» с радостными возгласами было немедленно отправлено в корзину.

Манифест Кагарлицкого

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

(цитаты из манифеста Кагарлицкого)

Мы стремились свести в единую систему всю совокупность типовых требований, которые должны, с нашей точки зрения, предъявляться к технической документации: руководствам, справочникам и т.д. При этом мы основывались на стандартах(!!!) ГОСТ , стандартах компании Microsoft, опыте наших сотрудников и других разработчиков технической документации.

Начало обнадеживающее.

В состав технической документации входят две стержневые части, которые мы будем называть соответственно руководством пользователя и справочником пользователя, или коротко: руководством и справочником (по аналогии с английскими словосочетаниями User"s Guide и User"s Reference). Они могут быть оформлены в виде отдельных документов (для крупных программных продуктов), а могут, напротив, существовать в интегрированном виде. Между ними даже может не быть четкой границы: единый текст способен совмещать в себе черты руководства и черты справочника.

Руководство и справочник - это не столько части документации, сколько , которые воплощают собой два подхода к описанию программного продукта.

По-понятиям так по-понятиям, вот только пацаны начинают нервничать. Руководство не есть понятие, а есть.

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

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

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

Жаль... А так все хорошо начиналось. Со «стандартов ГОСТ » - «стандартов » - простим г-на Кагарлицкого за тавтологию. Только вот решения первой задачи, поставленной автором настоящей статьи, в семидесятидвухстраничном манифесте (Arial"ом 12pt) нет. Уважаемый автор манифеста лишь поставил нам задачу . Что ж, нет пророка в своем отечестве. Может, есть пророк в отечестве буржуйском?

Руководство пользователя по IEEE Std 1063-2001 «IEEE Standard for Software User Documentation»

Забугорный «пророческий» документ IEEE Std 1063-2001 (IEEE в простонародье - «ай-яй-яй») в подразделе 1.2 (Puprose) содержит такую строчку:

This revision provides requirements for the structure, information content, and format of both printed and electronic documentation.

В авторском понимании назначение (намерение, цель, замысел, стремление) документа IEEE Std 1063-2001 состоит в «обеспечении требований к структуре, информационному наполнению, (оформлению) как, так и печатной пользовательской документации по программным средствам». Что ж, подходяще. Какую же структуру руководства пользователя предлагает IEEE Std 1063-2001?

Структура руководства пользователя по IEEE Std 1063-2001

Опциональная типовая структура руководства пользователя содержится в таблице из раздела Structure of software user documentation документа IEEE Std 1063-2001:

Identification data (package label/title page)
Table of contents		Yes, in documents of more than eight pages after identification data
List of illustrations
Concept of operations
		Yes (instructional mode)
		Yes (reference mode)
		Yes, if documentation contains unfamiliar terms
Related information sources
Navigational features
		Yes, if documents of more than 40 pages
Search capability		Yes, in electronic documents

For purposes of this standard, the following non-mandatory nomenclature is used for the structural parts of software user documentation. A printed document is structured into logical units called chapters, subdivided into topics, which may be subdivided into subtopics, and printed on physical units called pages.

Здорово. IEEE Std 1063-2001 предлагает «все взять и поделить» - разбить разделы руководства на главы, топики, субтопики и т.д. И наступит всем счастье.

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

Introduction

Какие сведения должны быть изложены в разделе Introduction согласно IEEE Std 1063-2001? А вот какие

The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment.

Что ж, замечательно. Структура подразделов Introduction начинает как-то вырисовываться.

Information for use of the documentation

The documentation shall include information on how it is to be used (for example, help on help), and an explanation of the notation (a description of formats and conventions-see 5.8). At least one document in a document set shall identify all documents in the set by title and intended use, including recommendations on which members of the audience should consult which sections of the documentation. In document sets comprising many volumes or products, this information may be provided in a separate "road map" or guide to the document set. Documentation may include identification and discussion of notable changes from the previous version of the document set and the software.

Весьма полезный раздел (в разработки руководства пользователя). Руководство по руководству.

Concept of operations

Documentation shall explain the conceptual background for use of the software, using such methods as a visual or verbal overview of the process or workflow; or the theory, rationale, algorithms, or general concept of operation. Explanations of the concept of operation should be adapted to the expected familiarity of the users with any specialized terminology for user tasks and software functions. Documentation shall relate each documented function to the overall process or tasks. Conceptual information may be presented in one section or immediately preceding each applicable procedure.

Концептуальная информация безусловно важна.

Procedures

Task-oriented instructional mode documentation shall include instructions for routine activities that are applied to several functions:

Software installation and de-installation, if performed by the user

Orientation to use of the features of the graphical user interface (see 5.6)

Access, or log-on and sign-off the software

Navigation through the software to access and to exit from functions

Data operations (enter, save, read, print, update, and delete)

Methods of canceling, interrupting, and restarting operations

These common procedures should be presented once to avoid redundancy when they are used in more complex functions.

И пошла конктерика. Молодцы, буржуи!

Information on software commands

Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax. Documentation may be provided on the development and maintenance of macros and scripts. Reference mode documentation shall contain a reference listing of all reserved words or commands. Examples should illustrate the use of commands. Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated.

Error messages and problem resolution

Documentation should address all known problems in using the software in sufficient detail such that the users can either recover from the problems themselves or clearly report the problem to technical support personnel. Reference mode documentation shall include each error message with an identification of the problem, probable cause, and corrective actions that the user should take. A quick reference card may address error messages by referring the user to more detailed reference documentation. The documentation on resolving problems shall also include contact information for reporting problems with software or its documentation and suggesting improvements.

Выводы по IEEE Std 1063-2001

Но счастье оказалось неполным... Структура разделов первого уровня руководства показана в таблице явно. А дальше - «милый мой, хороший, догадайся сам» («догадайся, мол, сама»). IEEE Std 1063-2001, конечно, «provides requirements for the structure», но не предлагает явной структуры руководства пользователя до рекомендованного ГОСТ 2.105 четвертого уровня вложенности.

Рекомендации типа «Documentation shall explain...», «Examples should illustrate...», «Documentation shall describe...» и им подобные, безусловно, проверены временем. В руководстве пользователя надо и объяснять, и иллюстрировать, и описывать - без всякого сомнения. Но все это и козе понятно, и в ГОСТах 19-й системы прописано.

Итак, вряд ли разрабатывать руководства пользователя, основываясь исключительно на рекомендациях IEEE Std 1063-2001. Причины, как минимум, две:

• отсутствие в IEEE Std 1063-2001 четко регламентированной структуры руководства пользователя;
• «поверхностность» IEEE Std 1063-2001, отсутствие «широты охвата» и «глубины проработки».

Отсутствие четко регламентированной структуры руководства пользователя даст возможность ТРЕТИРОВАТЬ , см. хотя бы. Бедняга-разработчик будет вынужден, по указке заказчика, изо дня в день менять местами разделы руководства пользователя (гарантированный минимум, полученный опытным путем).

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

По мнению автора, рекомендации IEEE Std 1063-2001, разработанного при участии сотни забугорных спецов, весьма и весьма поверхностны. Не сможет разработчик, работая по IEEE Std 1063-2001, охватить максимум «характеристик», свойственных программе. В IEEE Std 1063-2001 многие из них попросту не прописаны. Отсутствуют «широта охвата» и «глубина проработки», свойственные отечественным документам.

В крайнем разделе настоящей статьи приведена таблица соответствия ГОСТ 19 и IEEE Std 1063-2001, которую автор статьи начал было составлять, затем бросил и проверять не стал. А выводы пусть каждый сделает сам для себя. И, возможно, в чем-то поправит автора.

Пользовательские документы по ГОСТ 19 (ЕСПД)

В отличие от суперсовременного буржуйского IEEE Std 1063-2001, древние, многими ругаемые отечественные стандарты 19-й системы (Единая система программной документации - ЕСПД) содержат не пространные рассуждения о том, что и как должно разъяснять, иллюстрировать и описывать руководство пользователя, а конкретные требования к структуре и содержанию пользовательских (эксплуатационных) документов.

Перечень ГОСТов 19 «описательного» характера, на основе которых можно, не мудрствуя лукаво, сформировать четкую структуру разделов каждого из «описательных» документов, приведен в разделе Источники. Основной прием - детализация - подробно описан в статье «». Далее - сформированные «детализацией» структуры разделов документов согласно ГОСТам из перечня.

Структура разделов описания программы по ГОСТ 19.402-78

Структура разделов описания применения по ГОСТ 19.502-78

Структура разделов руководства системного программиста по ГОСТ 19.503-79

Структура разделов руководства программиста по ГОСТ 19.504-79

Структура разделов руководства оператора по ГОСТ 19.505-79

Выводы по ГОСТам 19.ххх

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

Зато структуры «описательных» документов ГОСТ 19 обладают как полностью идентичными (по тексту названий), так и схожими по тексту названий разделами и подразделами. К идентичным разделам относятся, к примеру, разделы «», имеющие место во всех документах согласно. К схожим (фактически - идентичным) можно отнести подразделы «Назначение программы» и «».

А почему не попытаться объединить все «описательные» документы? Объединить идентичные и схожие разделы документов, выделить специфические разделы? Быть может, удастся избавиться от неполноты ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 и получить обобщенную структуру «описательного» документа и обозвать сам документ руководством пользователя программы?

ГОСТы 19.ххх допускают «вводить дополнительные разделы или объединять отдельные разделы», а также «вводить новые». Согласно ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]»

Сказано - сделано. Только мы нарушим ГОСТы и создадим объединенный документ под названием «Руководство пользователя».

Обобщенная структура руководства пользователя по ГОСТам 19-й системы

Путем слияния структур «описательных» документов ГОСТов 19-й системы в единую структуру, удаления «лишних» одноименных разделов, слияния схожих разделов сформирована общая структура руководства пользователя программы. В табличке сведены и «* » отмечены разделы, присутствующие в каждом отдельном документе.

ГОСТ 19.ххх - обобщенная структура разделов руководства	ГОСТ 19.402-78	ГОСТ 19.502-78	ГОСТ 19.503-79	ГОСТ 19.504-79	ГОСТ 19.505-79
Аннотация
Назначение документа
Общие сведения о программе
Обозначение и программы
На которых написана программа
Сведения о назначении программы
Информация, достаточная для понимания и ее
Возможности программы
Классы решаемых задач
Описание задач
Методы решения задач
Временные характеристики
Режим работы
Условия применения программы
Сведения о и, обеспечивающих выполнение программы
Типы, используемые при работе программы
Требования к составу и параметрам
Описание логической структуры
Программы
Используемые методы
Сведения о
Сведения о программы
Сведения о и
Сведения о входных данных
Сведения о выходных данных
Формат, описание и способ выходных данных
Выбор функций
Поясняющие примеры
Описание способов проверки программы
Контрольные примеры
Методы прогона
Результаты
Выполнение программы
Запуск программы
Входные точки в программу*
Способы передачи управления и данных
Выполнение программы
Формат и возможные варианты для выполнения функции 1
Дополнительные возможности
Тексты, выдаваемых в ходе (настройки, проверки, выполнения) программы
Описание содержания

Выводы по обобщенной структуре руководства пользователя по ГОСТ 19.ххх

Обобщенная структура руководства пользователя по ГОСТ 19.ххх явно не страдает, как IEEE Std 1063-2001, отсутствием широты охвата. Избыток, как известно, рождает качество. Перечислено все, чем может характеризоваться программа. Отдельные подразделы могут показаться даже излишними, к примеру, подраздел «Языки программирования, на которых написана программа».

Казалось бы, какое дело пользователю, на каком языке был написан исходный текст программы? С другой стороны, может «...это кому-нибудь нужно? Значит - это необходимо...». Ведь хочется при покупке буржуйского телевизора заполучить и принципиальную схему на него. Самсунги и соньки тоже выходят из строя. А вдруг неисправность пустяковая и устранить ее представляется возможным в домашних условиях, без поездки в сервисный центр?

В то же время, при всей широте охвата, в явном виде отсутствуют:

• Software installation and de-installation, if performed by the user;
• Orientation to use of the features of the graphical user interface;
• Access, or log-on and sign-off the software;
• Navigation through the software to access and to exit from functions и многое другое.

Автору удалось разбросать кое-что в разделе Таблица соответствия ГОСТ 19.ххх и IEEE Std 1063-2001, но времени «наморщить ум» всегда не хватает, руководство пользователя, как всегда, должно было быть готово еще на прошлой неделе.

Показать связи разделов обобщенного руководства пользователя с разделами автор поленился, поскольку указанные связи очевидны.

Выводы по источникам

Итак, если первые три задачи в целом решены, крайняя задача осталась нерешенной.

Автор манифеста более склонен к рекомендациям по подбору слов * и построению предложений, IEEE Std 1063-2001, в лучшем случае, приводит требования к структуре руководства пользователя, но не дает особой конкретики, в ГОСТ 19.ххх не прописаны процедуры заполнения разделов руководства. Может, организовать эдакую смесь французского с нижегородским? Использовать все четыре источника в качестве четырех составных частей?

* Нынче в моде буржуйское - т.н. контролируемый язык . Среди представителей «просвещенной русской интеллигенции» наибольшей популярностью пользуется отечественный аналог в глагольной форме повелительного наклонения - фильтруй базар !

Смесь французского с нижегородским

Почему бы нет? Взять лучшее из ГОСТов 19-й системы, - обобщенную структуру руководства пользователя, добавить к ней немногочисленные толковые из IEEE Std 1063-2001 и разбавить неисчерпаемой стилистической культурой и ресурсами из манифеста Кагарлицкого? Придать смеси стройный строгий вид, сформировать очередной с подробными комментариями? А что делать, если ни один из перечисленных выше источников и составных частей в отдельности не способны дать ответы на все поставленные вопросы?

Таблица соответствия ГОСТ 19 и IEEE Std 1063-2001

ГОСТ 19.ххх	IEEE Std 1063-2001
Аннотация
	The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment
Назначение документа	purpose for the document (Introduction)
Краткое изложение основной части документа	scope (Introduction)
Общие сведения о программе
Обозначение и наименование программы
Языки программирования, на которых написана программа
Сведения о назначении программы	brief overview of the software purpose (Introduction)
Информация, достаточная для понимания функций программы и ее эксплуатации	аналогичный подраздел отсутствует
Возможности программы
Классы решаемых задач
Описание задач
Методы решения задач	Documentation shall relate each documented function to the overall process or tasks
Функции, выполняемые программой	brief overview of the software ... functions (Introduction)
Описание основных характеристик и особенностей программы	аналогичный подраздел отсутствует
Временные характеристики
Режим работы
Средства контроля правильности выполнения и самовосстанавливаемости программы
Ограничения области применения программы
Сведения о функциональных ограничениях на применение
Условия применения программы	If different versions of the software are available for different operating environments, the title page should specify the applicable operating environment(s), including version(s) of hardware, communications, and operating system(s) (4.3. Content of identification data)
Условия, необходимые для выполнения программы	аналогичный подраздел отсутствует
Сведения о технических и программных средствах, обеспечивающих выполнение программы	Documentation for the hardware and software environment (4.11 Information on related information sources)
Требования к техническим средствам	аналогичный подраздел отсутствует
Устройств, используемые при работе программы
Объем оперативной памяти
Минимальный и (или) максимальный состав аппаратурных и программных средств
Требования к составу и параметрам периферийных устройств
Программное обеспечение, необходимое для функционирование программы	brief overview of the ... operating environment (Introduction)
Требования к программному обеспечению	аналогичный подраздел отсутствует
Требования к другим программам
Требования и условия организационного, технического и технологического характера
Описание логической структуры
Алгоритм программы	algorithms (4.5 Concept of operations)
Используемые методы	using such methods as a visual or verbal overview of the process or workflow (4.5 Concept of operations)
Сведения о структуре программы	аналогичный подраздел отсутствует
Сведения о составных частях программы
Описание функций составных частей
Сведения о связях между составными частями программы
Сведения о связях с другими программами
Сведения о входных и выходных данных
Общие характеристики входной и выходной информации	аналогичный подраздел отсутствует
Сведения о входных данных
Характер, организация и предварительная подготовка входных данных
Сведения о выходных данных
Характер и организация выходных данных
Формат, описание и способ кодирования выходных данных
Описание кодирования информации
Настройка программы	Identification of technical or administrative activities that must be done before starting the task (4.7 Information for procedures and tutorials)
Описание действий по настройке программы	аналогичный подраздел отсутствует
Настройка на состав технических средств
Выбор функций
Поясняющие примеры
Проверка программы
Описание способов проверки работоспособности программы	аналогичный подраздел отсутствует
Контрольные примеры	Examples should illustrate the use of commands (4.8 Information on software commands)
Методы прогона	аналогичный подраздел отсутствует
Результаты
Выполнение программы
	Software installation and de-installation, if performed by the user (4.6 Information for general use of the software)
Запуск программы	аналогичный подраздел отсутствует
Входные точки в программу*	Access, or log-on and sign-off the software (4.6 Information for general use of the software)
Способы передачи управления и параметров данных	аналогичный подраздел отсутствует
Выполнение программы
Описание выполняемой функции 1	A brief overview of the purpose of the procedure and definitions or explanations of necessary concepts not elsewhere included (4.7 Information for procedures and tutorials)
Формат и возможные варианты команд для выполнения функции 1	Navigation through the software to access ... functions (4.6 Information for general use of the software) Instructional steps shall be presented in the order of performance (4.7 Information for procedures and tutorials) Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax (4.8 Information on software commands)
Ответы программы на команды выполнения функции 1	Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated (4.8 Information on software commands)
Завершение выполнения программы	Navigation through the software ... to exit from functions Methods of canceling, interrupting, and restarting operations (4.6 Information for general use of the software)
Дополнительные возможности
Описание дополнительных функциональных возможностей программы	аналогичный подраздел отсутствует
Описание применения дополнительных функциональных возможностей программы
Сообщения программы	Relevant warnings, cautions, and notes that apply to the entire procedure (4.7 Information for procedures and tutorials)
Тексты сообщений, выдаваемых в ходе (настройки, проверки, выполнения) программы	аналогичный подраздел отсутствует
Описание содержания
Описание действий, которые необходимо предпринять по этим сообщениям