Для чего нужны руководства пользователей

Как с помощью руководства пользователя повысить качество информационной системы

В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери

Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.

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

Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.

Описание проблемы

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

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

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

2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.

3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.

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

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

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

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

Нужно было срочно исправлять ситуацию. Причем сделать это с минимальными затратами.

Поиск решения

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

Неактуальность документа

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

1. Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
2. Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
3. Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.

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

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

Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:

1. Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
2. Красный – процесс есть, но не нужен (удалить!).
3. Желтый – процесс отсутствует, но нужен (добавить!).
4. Серый – процесс отсутствует и не нужен.

Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.

Рисунок 1

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

Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный  —  для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.

Рисунок 2

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

Таблица соответствия в ходе работы над документом:

Рисунок 3

По завершении «покрасочных» работ обозначились приоритеты:

1. убрать оранжевый цвет – все должно быть описано корректно;
2. cделать светло-зеленые поля ярко-зелеными.

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

Отсутствие единообразия

При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).

Рисунок 4

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

Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.

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

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

В классический цикл разработки от анализа требований (1) до тестирования (4) добавляется этап подготовки документов, среди которых особое место занимает руководство пользователя. Почему же так важен этот документ? По нескольким причинам. В случае параллельной независимой разработки отдельных подсистем возможна потеря унификации (например, расположение управляющих элементов, наименования и т.д.). Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов.

Рисунок 5

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

Из рисунка 5 хорошо видно, что процесс разработки финализируется созданием руководства. Этот документ также активно используется на других этапах разработки.

Рисунок 6

Выводы

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

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

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

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

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

---

P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.

Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

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

From Wikipedia, the free encyclopedia

For a full guide to an item owned by its operator, see Owner’s manual.

A user guide, also commonly known as a user manual, is intended to assist users in using a particular product, service or application. It’s usually written by a technician, product developer, or a company’s customer service staff.

Most user guides contain both a written guide and associated images. In the case of computer applications, it is usual to include screenshots of the human-machine interface(s), and hardware manuals often include clear, simplified diagrams. The language used is matched to the intended audience, with jargon kept to a minimum or explained thoroughly.

Contents of a user manual[edit]

The sections of a user manual often include:

• A cover page
• A title page and copyright page
• A preface, containing details of related documents and information on how to navigate the user guide
• A contents page
• A Purpose section. This should be an overview rather than detail the objective of the document
• An Audience section to explicitly state who is the intended audience who is required to read, including optionals
• A Scope section is crucial as it also serves as a disclaimer, stating what is out-of-scope as well as what is covered
• A guide on how to use at least the main function of the system
• A troubleshooting section detailing possible errors or problems that may occur, along with how to fix them
• A FAQ (Frequently Asked Questions)
• Where to find further help, and contact details
• A glossary and, for larger documents, an index

History[edit]

User guides have been found with ancient devices. One example is the Antikythera Mechanism,^[1] a 2,000 year old Greek analogue computer that was found off the coast of the Greek island Antikythera in the year 1900. On the cover of this device are passages of text which describe the features and operation of the mechanism.

As the software industry was developing, the question of how to best document software programs was undecided. This was a unique problem for software developers, since users often became frustrated with current help documents.^[2] Some considerations for writing a user guide that developed at this time include:

• the use of plain language^[2]
• length and reading difficulty^[2]
• the role of printed user guides for digital programs^[3]
• user-centered design^[3]

Computer software manuals and guides[edit]

User manuals and user guides for most non-trivial software applications are book-like documents with contents similar to the above list. They may be distributed either in print or electronically. Some documents have a more fluid structure with many internal links. The Google Earth User Guide^[4] is an example of this format. The term guide is often applied to a document that addresses a specific aspect of a software product. Some usages are Installation Guide, Getting Started Guide, and various How to guides. An example is the Picasa Getting Started Guide.^[5]

In some business software applications, where groups of users have access to only a sub-set of the application’s full functionality, a user guide may be prepared for each group. An example of this approach is the Autodesk Topobase 2010 Help^[6] document, which contains separate Administrator Guides, User Guides, and a Developer’s Guide.

See also[edit]

• Owner’s manual
• Release notes
• Moe book
• Technical writer
• Manual page (Unix)
• Instruction manual (gaming)
• Reference card
• RTFM
• HOWTO

References[edit]

Одним из важных этапов на проекте внедрения 1С является обучение сотрудников новой программе. Этап становится довольно «болезненным», если заказчик не согласен на обучение. Тогда рассматривается альтернативный вариант – написать руководства пользователей.

В этой статье я поделюсь опытом написания инструкций на проекте внедрения 1С. Расскажу, как писать ПОНЯТНЫЕ руководства пользователей, и главное – как внедрить в компании регламент для сотрудников.

Руководство пользователя – это технический документ, который предназначен для оказания поддержки пользователям конкретной системы. В этом смысле используется и слово «мануал» (manual).

Рассмотрим основной алгоритм написания инструкций для пользователей программы 1С.

1. ОПРЕДЕЛЯЕМ ТЕМУ И ЦЕЛЕВУЮ АУДИТОРИЮ

Для чего мы пишем инструкцию? Самый важный вопрос, на который нужно ответить. Я выделила несколько основных вариантов:

• Инструкция для конкретного блока учета в программе, например, «Инструкция по блоку Продажи»,

• Инструкция для определенной должности сотрудника, например, «Инструкция для менеджера по оптовым продажам»,

• Инструкция по конкретной функции или процессу, например, «Инструкция по маркировке товаров».

Для кого мы пишем инструкцию? Необходимо понять для какого уровня пользователя нужно описать функционал программы – это новичок или опытный пользователь?

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

2. ПРОДУМЫВАЕМ СТРУКТУРУ СОДЕРЖАНИЯ

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

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

• Проектное решение – это документ, состоящий из методологического проектного решения, которое фиксирует функциональный объем проекта – определяет какие действия и сущности будут «покрыты» функционалом информационной системы, а также технического проектного решения, которое фиксирует объем, принципы и описание доработок конфигурации 1С и является основой для дальнейшей доработки – изменения типовых и создания новых объектов конфигурации 1С.

• Встречи с заказчиком.

Инструкция по блоку. Заголовок раздела – объект программы.

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

Инструкция для должности. Заголовок раздела – название процесса.

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

Инструкция по процессу. Заголовок раздела – название процесса, объекта программы, должности.

Пример: процесс – реализация маркированных товаров. Менеджер по продажам создает реализацию товаров, выгружает данные на терминал сбора данных, затем кладовщик на складе считывает товары на терминал сбора данных и заносит их в 1С. Тогда структура содержания может выглядеть следующим образом:

3. ПИШЕМ ИНСТРУКЦИЮ

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

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

Подробная или не очень

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

Если пользователь ранее работал в подобных программах, например, менеджер по продажам имеет опыт работы с программой 1С: Управление торговлей 11, тогда ему будет не сложно заполнить нормативно-справочную информацию и создать документы «Заказ клиента» и «Реализация товаров и услуг». Такая инструкция будет содержать меньше конкретики.

Полнота изложения

Не сокращайте слова, не используйте аббревиатуры и специальные термины, понятные только узкому кругу читателей. Текст должен быть понятен любому. Например, вместо «РТиУ» не поленитесь и пропишите полностью «документ Реализация товаров и услуг». Если без этого никак — оформите раздел «Глоссарий».

Ветвления

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

Если вы ссылаетесь на рисунок или таблицу, то воспользуйтесь механизмом «Перекрестная ссылка».

Структурированность.
Разбавьте текст заголовками, абзацами и списками для удобного восприятия читателем.

Заголовки – это обязательно.

Позволяют «просканировать» ваш текст и остановиться сразу на нужной части. Но главное – не нарушать их иерархию.

Абзацы – это не так просто.

Есть универсальное правило: одна мысль – один абзац. Он не должен быть огромным, чтобы не перегружать информацией. Но и делать абзац из одного предложения тоже не стоит. Оптимальная длина – 5 строк.

Списки – это удобно и понятно.

Маркированный список – это обычный список перечисления с маркерами, точками. В перечне элементы не упорядочены между собой. От их перестановки местами смысл не поменяется.

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

Пример: чтобы оформить приобретение товаров через подотчётное лицо, необходимо выполнить следующие действия:

1) Перейдите в раздел Закупки – Документы закупки (все).

2) Нажмите кнопку «Создать – Приобретение товаров и услуг – Закупка через подотчетное лицо».

3) Укажите на вкладке «Основное» следующие данные:

•  Организация,

•  Поставщик,

•  Контрагент,

•  Договор,

•  Склад.

4) Заполните вкладку «Товары».

5) Укажите на вкладке «Доставка» способ доставки.

6) Нажмите кнопку «Провести и закрыть».

Наглядность. Японское правило: «Одна картинка стоит тысячу слов».

Скриншоты 

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

Пример: чтобы установить значение цены номенклатуры в документе «Установка цен номенклатуры», необходимо выбрать подразделение, все влияющие и зависимые виды цен, затем перейти к установке:

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

• Lightshot. Скачать можно тут.

• Яндекс.Скриншот, входит в состав утилиты Яндекс.Диск. Посмотреть можно тут.

Важные фрагменты текста

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

Пример: Обратите внимание!!! Обычный менеджер не сможет отредактировать график оплаты в соглашении c клиентом. Для этого предусмотрена отдельная роль. Если данный функционал не доступен, то необходимо обратиться в ИТ-отдел.

Экспертность. Автор обязан хорошо разбираться в теме.

Если так вышло, что описываемый блок программы – новая тема для аналитика, тогда за основу типового функционала рекомендую взять инструкции с официального сайта 1С: ИТС.

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

Актуальность.
Инструкцию придется периодически обновлять.

Если порядок действий, интерфейс программы, который вы описываете, меняется, то инструкцию нужно обновлять. Вопрос – кто должен это делать?

• Если изменение произошло во время написания инструкции, например, обновилась версия программы или был доработан функционал, тогда сделать это нужно автору мануала в оперативном режиме.
• Если инструкции приняты заказчиком или проект уже закончен, в этом случае за актуальность отвечает заказчик.

4. ПРОВЕРЯЕМ, ПРОВЕРЯЕМ И ЕЩЕ РАЗ ПРОВЕРЯЕМ

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

Итак, мы написали руководство пользователя, проверили его и сдали заказчику. Следующий этап – внедрение инструкции для сотрудников на предприятии.

КАК ВНЕДРИТЬ ИНСТРУКЦИИ ДЛЯ СОТРУДНИКОВ

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

Правило №1. Должностные папки

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

Правило №2. Проверка знаний

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

Правило №3. Контроль выполнения

Служба ИТ-отдела должна проверять, как на самом деле выполняются регламенты в компании. Понятно, что мы не можем тратить на это много времени и ресурсов. Здесь нужно здравомыслие: просто устраивайте проверки с определенной периодичностью.

ПОДЫТОЖИМ. Для того, чтобы написать качественную инструкцию нам нужно:

1. Определить тему и целевую аудиторию.

2. Продумать структуру содержания.

3. Написать инструкцию, соблюдая следующие критерии:

• Содержательность,

• Структурированность,

• Наглядность,

• Экспертность,

• Актуальность.

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

Чтобы правильно внедрить регламент, необходимо соблюдать три правила:

1. Регламент попал к сотрудникам, и вы в этом убедились.

2. Сотрудник его прочитал, понял и прошел проверку знаний. 

3. Соблюдение регламента контролируется. 

Руководство
пользователя как программная
(эксплуатационная) документация
пользователя

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

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

Документация:
программная/эксплуатационная/документация
пользователя

Предмет:
программа,
программный компонент комплекса
или системы

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

Задачи:
обеспечить пользователям возможность
в полном объеме самостоятельно освоить
и применять программу

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

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

• Назначение
  системы;

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

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

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

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

Назначение
системы

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

Пример:

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

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

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

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

• Требования
  к аппаратному обеспечению – сюда можно
  включить требования к конфигурации
  компьютера пользователя, программное
  обеспечение необходимое для работы
  Системы, а также наличие дополнительного
  оборудования (принтер, сканер и т.п.),
  если таковое необходимо;

• Квалификация
  пользователя – данный подраздел должен
  содержать требования к навыкам и знаниям
  пользователя (пример:
  «Пользователи должны обладать умениями
  работать с операционной системой
  Windows»);

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

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

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

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

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

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

Пример:

«4.1
Согласование проекта

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

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

4.1.1
 Создание проекта

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

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

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

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

• Дата
  создания проекта – текущая дата;

• Автор
  – ФИО и должность автора проекта.»

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

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

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

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

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

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

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

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

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

Возможны
и другие пользовательские перспективы.
Бывают программы, посредством которых
пользователь контролирует состояние
того или иного объекта, скажем, промышленной
установки. Тогда руководство пользователя
строится по принципу таблицы: сообщение
программы — реакция или возможные
реакции пользователя.

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

Соседние файлы в папке Лекции_МПО_ч2

• #
• #
• #
• #
• #
• #