для чего нужно руководство пользователя
Руководство пользователя
Руководство пользователя (англ. user guide или user manual), руководство по эксплуатации, руководство оператора — документ, назначение которого — предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему и, как правило, подготавливается техническим писателем.
Большинство руководств пользователя помимо текстовых описаний содержит изображения. В случае программного обеспечения, в руководство обычно включаются снимки экрана, при описании аппаратуры — простые и понятные рисунки или фотографии. Используется стиль и язык, доступный предполагаемой аудитории, использование жаргона сокращается до минимума либо подробно объясняется.
Содержание
Содержание
Типичное руководство пользователя содержит:
Все главы и пункты, а также рисунки и таблицы, как правило, нумеруются, с тем, чтобы на них можно было сослаться внутри документа или из другого документа. Нумерация также облегчает ссылки на части руководства, например, при общении пользователя со службой поддержки.
Стандарты
Структура и содержание документа Руководство пользователя автоматизированной системы регламентированы подразделом 3.4 документа РД 50-34.698-90. Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.
Руководство пользователя. Советы для составления
Существует множество видов предоставления справочной информации пользователю – это и FAQ (frequently asked questions, часто задаваемые вопросы) и онлайн справка и руководство пользователя (user guide) и популярные сегодня подсказки (coachmarks, см. пример ниже), обучающие видео и другие.
Существуют разные причины, по которым требуется написать руководство пользователя системы. Начиная с просьб заказчика (в моей практике был случай, когда заказчику надо было поставлять руководство пользователя после каждой итерации, чтобы с его помощью он смог бы провести приемочное тестирование функциональности итерации) и заканчивая условиями контракта, касающимися поставки готового ПО, если говорить о разработке ПО на заказ. В случае разработки собственного продукта написание руководства пользователя тоже часто имеет место.
К созданию руководства часто привлекают аналитика, если нет возможности поручить техническому писателю. В подавляющем большинстве случаев самыми полными знаниями о системе обладает именно аналитик, он же обладает умением ясно излагать свои мысли в письменной форме в силу специфики профессии. Поэтому, мне не однократно приходилось сталкиваться с созданием руководств пользователя.
Ниже я приведу несколько практик для составления хорошего руководства пользователя. Часть из них, возможно, кому-то будут полезны и при написании спецификаций требований.
1. Стандарты
Часто бывает нужно написать документ, который бы удовлетворял требованиям действующих стандартов. Это могут быть:
Если потребности проекта позволяют вам не следовать жестким стандартам, в любом случае изучение этих документов может послужить стартовой точкой для написания качественного документа.
Также может оказаться полезной книга Юрия Кагарлицкого MetaGuide. Руководство для разработчиков технической документации к программному обеспечению.
2. Структура
Хорошо продумайте структуру документа: она должна покрывать все функциональные возможности системы, быть полной и понятной.
Хорошее руководство пользователя должно содержать:
Также руководство пользователя может содержать:
Все главы и пункты, а также рисунки и таблицы лучше нумеровать, чтобы на них можно было сослаться внутри этого документа или из другого документа.
3. Пользователи
Подумайте о типичных пользователях данного ПО: необходимо, чтобы документ помогал им решать их насущные задачи.
Возможно, даже имеет смысл сделать разные разделы (или даже разные документы) для разных групп пользователей, если их взаимодействие с системой будет кардинально различаться. Например, администраторов системы (людей, отвечающих за учетные записи, права доступа и т.д.) будет интересовать совсем другая функциональность, нежели обычных пользователей.
Уважайте пользователей системы, не пишите инструкции в пренебрежительном стиле.
4. Особенности изложения
Помните, что стиль изложения в устной речи или в деловом письме отличается от оного в технической документации, и в частности, в руководстве пользователя.
Стиль руководства должен быть нейтрально-формальным – использование стилистически окрашенных слов отвлекает пользователя от сути.
Для составления хорошего документа пригодятся знания грамматики и немного психологии.
4.1 Пишите кратко и логично. Не давайте лишних деталей, не дублируйте информацию. Последовательность упоминания информации в руководстве пользователя должна совпадать с последовательностью действий пользователя:
Хорошо: In File menu, select Save item.
Хуже: Select Save item from File menu.
4.2 Используйте повелительное наклонение, не употребляйте вежливые обороты (please, could и т.д.) — излишняя вежливость именно здесь будет помехой.
Хорошо: Click Logout to log out current user account from the system.
Хуже: It is needed to click Logout to log out current user account from the system.
Хуже: If user wants to log out current user account from the system (s)he needs to click Logout.
4.3 Структурируйте информацию. Часто можно встретить совет, что надо стараться избегать списков, однако, структурированная по шагам информация всегда лучше воспринимается.
Хорошо:
To create project:
Хуже: To create project click the Create button on toolbar, on the Create Project overlay fill in all mandatory fields, click the Save button to save the project.
4.4 Не используйте будущее или прошлое время. Например, часто встречаются руководства, в которых реакция системы на действие пользователя передается фразами, сформулированными в будущем времени. У ПО нет прошлого или будущего: всё случается в настоящем как прямой результат конкретного действия пользователя. Как только событие случается, ПО реагирует.
Хорошо: When user clicks the Start button, the program starts the process.
Хуже: When user clicks the Start button, the program will start the process.
4.5 Проверяйте значение слов. Если необходимо писать документ на иностранном языке, надо стараться максимально избегать ошибок, связанных с недостаточным знанием языка.
Например, глагол «press» означает нажатие клавиши на клавиатуре, а «click» – нажатие кнопки или значка в окне программы при помощи мыши, а «hit» вообще является жаргонным словом.
Разумеется, орфографические ошибки недопустимы.
4.6 Не используйте синонимы для одного и того же термина. В IT литературе на английском (или любом другом) языке есть стандартный набор глаголов, обозначающих действия (click, double-click, select, type, press и т.д.) и такой же стандартный набор названий элементов управления. Определитесь с терминологией и придерживайтесь ее в рамках всего документа.
Например, не допускайте, чтобы в одной части документа выпадающий список назывался dropdown, а в другой точно такой же элемент – combobox или dropdown list. Это путает пользователя.
4.7 Разумно используйте сокращения и исключите жаргон.
Считается, что сокращения использовать не стоит, но если длинный термин употребляется несколько раз, то при первом упоминании в тексте надо писать полное название и рядом — аббревиатуру в скобках, а далее по тексту можно использовать только аббревиатуру. Если в документе есть глоссарий или раздел с сокращениями, они должны быть там расшифрованы.
Не используйте жаргонные слова, метафоры и термины, заимствованные из языка отличного от языка руководства.
5. Внешний вид
5.1 Продумайте стиль документа. Это может быть корпоративный шаблон или цветовая схема ПО или специально сделанный для документа дизайн.
При написании не стесняйтесь выделять важные вещи стилями или цветами (например, названия кнопок выделять жирным шрифтом). Но важно понимать, что неправильно подобранные шрифты и цвета могут затруднить восприятие содержимого документа.
5.2 Не экономьте место – разбивайте текст на короткие абзацы, используйте сравнительно крупные заголовки, начинайте новый раздел с новой страницы. Это облегчит восприятие прочитанной пользователем информации.
5.3 Используйте пиктограммы и иллюстрации. Существует мнение, что не стоит увлекаться иллюстрациями, а также включать в текст пиктограммы (icons) в руководстве пользователя. Однако графическая информация всегда лучше воспринимается и запоминается, поэтому снимки экрана и нужные пиктограммы должны присутствовать в хорошем руководстве в достаточном, но разумном количестве.
6. Поддержка
Не упускайте из виду тот факт, что ПО со временем меняется, а значит, ваш документ тоже должен меняться, чтобы оставаться актуальным.
Заключение
Примите к сведению, что раздражение от некачественного документа может быть спроецировано пользователем на ПО и, тем самым, повлиять на решение использовать продукт.
Помните главное: документ должен помогать пользователям.
Статью подготовила
Тарасюк Надежда, участник сообщества analyst.by,
Руководство пользователя для пользователя
Екатерина Филатова, 12.06.2006
Известно, что пользователи часто даже не заглядывают в инструкции, прилагаемые к программным продуктам, предпочитая постигать все премудрости работы программы на практике. Получается, что руководство, призванное помочь пользователю, никак не облегчает его жизнь, а многие полезные функции программного продукта так и остаются недопонятыми и невостребованными. Почему так происходит?
Очевидны две базовые проблемы. Авторы руководств:
Выход прост, но используется лишь частично: создаваемое руководство пользователя должно соответствовать своему названию — объяснять и помогать, а не просто описывать функциональность программы. То есть автору руководства следует хорошо представлять себе:
И с учетом этих представлений создавать текст руководства.
Главными составляющими качества руководства пользователя, безусловно, являются его структура и собственно текст. И от того, насколько эти составляющие отвечают нуждам пользователя, зависит качество всего руководства.
Структура руководства
Большая, детально разработанная и разветвленная структура руководства, с одной стороны, является показателем профессионализма технического писателя, однако, с другой стороны, часто запутывает пользователя. В поисках нужной информации приходится долго и нудно просматривать многостраничное содержание, состоящее из множества пунктов и подпунктов. А ответ на вопрос, как лучше выполнить ту или иную задачу, может находиться в нескольких различных разделах, посвященных разным функциям программного продукта, причем последовательность в описании действий пользователя иногда нарушается.
Заглянув в такое руководство и потратив впустую некоторое время, пользователь вряд ли воспользуется им вновь. Поэтому очевидно, что:
Попробуем применить эти принципы к конкретному руководству. Проанализируем структуру руководства пользователя для работы с Автоматизированной информационно-аналитической системой «Библиотека». Его содержание:
Как видно, структура этого руководства довольно большая и нечеткая, формулировки расплывчаты, разделы дублируют друг друга. Рассмотрим наиболее характерные ошибки и способы их решения:
С учетом обозначенных замечаний получаем более простую и логичную структуру руководства:
Приведенное в качестве примера руководство вполне обычно. Инструкций подобного качества, к сожалению, множество. Собственно именно это и заставляет многих авторов и пользователей считать, что руководство пишется ради самого руководства («чтобы было»), и никто его не читает. Но эту ситуацию вполне можно изменить.
Безусловно, помимо правильной разбивки текста существуют и другие важные условия, необходимые для создания практичного руководства, например:
Игнорирование любой из этих деталей способно испортить руководство и затруднить восприятие текста пользователем. Однако здесь нужно не перестараться и не перегрузить текст лишними деталями. Пестрящий подчеркиваниями, предупреждениями и ссылками текст рассеивает внимание читателя. Обо всех особенностях текста и верстки необходимо рассказать пользователю в начале руководства.
Краткость и стиль
Хорошее руководство пользователя отличается не только продуманной структурой, но и качеством текста. Установленных критериев здесь нет, так же как нет единого стиля. Главные принципы — текст руководства должен давать пользователю четкие и исчерпывающие ответы, не перегружать читателя лишними и не нужными ему техническими деталями, легко читаться и быть грамотным.
Как применить эти принципы на практике рассмотрим на примерах с типичными ошибками.
Список может содержать информацию ссылочного типа. Стандартным действием для просмотра этой информации является нажатие клавиши Enter для выбранной строки списка. В том случае, когда для ссылочной информации предусмотрен режим редактирования в отдельной форме, открывается эта форма. Если информация для списка находится в состоянии «Только просмотр» (не разрешено редактирование), то информация в открываемой форме тоже будет недоступна для редактирования.
Это тяжело читаемый, слишком большой и стилистически неправильный текст, отдающий канцеляризмом. В него приходится вчитываться, чтобы понять, о чем же идет речь. Пользователю придется потратить много сил, чтобы выудить из такого руководства нужную информацию. А ведь достаточно всего лишь сообщить, что пункты списка могут быть ссылками, ведущими на отдельную форму с подробной информацией, а также объяснить, в каких ситуациях и для чего он может менять эту информацию.
Пользователей в системе могут заводить администраторы или руководители подразделений. Существует еще один способ заведения пользователей в системе. Пользователь может сам подать заявку на регистрацию, которая должна быть одобрена администратором.
Расплывчатая формулировка с повторами, не объясняющая разницу в регистрации. Следует указать, что существуют именно два способа, и разъяснить когда именно применяется каждый их них.
Перед тем, как начинать вводить данные в программу, необходима предварительная настройка программы, т.к. не всегда значения по умолчанию могут отвечать специфике вашей организации.
Нет нужды изъясняться так длинно и витиевато, к тому же это предложение несогласованно. Достаточно написать Перед началом работы установите параметры, соответствующие вашей организации.
В этой части базы данных отображается вся информация об учете. Выражаясь более подробно, можно сказать, что здесь находятся все акты, сопроводительные документы, личные дела сотрудников, формы суммарного и индивидуального учета, читательские формуляры.
Лишние и вводные слова затрудняют восприятие текста. Кроме того, создается впечатление, что автор сам не уверен в написанном. Здесь хранится вся учетная информация: акты документы, формы и т.д.
Ниже приведена рекомендуемая последовательность действий, которую необходимо произвести перед началом работы.
Такой шаблонно-бюрократический текст не только непонятен, но и отпугивает пользователя. Руководство, написанное похожим языком, вряд ли когда-либо будут читать. Фраза Перед началом работы выполните следующие действия проще в разы.
Для возможности составления акта поступления литературы необходимо составить список источников поступления.
Главным действующим лицом здесь должен быть не некий документ, а пользователь, который собственно и должен уяснить, что без списка источников он не сможет создать нужный документ. Помимо этого, фраза для возможности составления безграмотна.
Для работы с программой необходимо, чтобы в базе данных было зарегистрировано ваше учреждение, были назначены подразделения библиотеки, было сформировано строение книг суммарного и индивидуального учета, был подготовлен список читателей.
Элементарные грамматические ошибки или обычные недочеты, как в данном случае — многократное повторение слова «было», не добавят доверия к руководству и его автору.
Выводы
Итак, если руководство пользователя создается для пользователя, а не для описания программного продукта, оно должно отвечать нескольким требованиям:
Как с помощью руководства пользователя повысить качество информационной системы
В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери
Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.
Отношение к руководству пользователя бывает разным. Многие совсем не задаются вопросом, каковы место и роль документа в процессе разработки больших гетерогенных информационных систем, для других же все и так ясно. Не спешите. В статье мы рассмотрим подходы к организации процесса создания и поддержания в актуальном состоянии этого важного документа, оценим значимость руководства пользователя для всей информационной системы в целом и придем к некоторым неожиданным выводам.
Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.
Описание проблемы
Некоторое время назад я в качестве аналитика начала работу на проекте по разработке информационной системы федерального масштаба. Для быстрого погружения в предметную область мне было предложено заняться руководством пользователя: провести аудит и организовать процесс доработки документа под стремительно расширяющийся функционал системы.
Отдельно остановлюсь на особенностях проекта, поскольку подходы и принципы, о которых пойдет речь, разработаны и адаптированы специально для следующих условий.
1. Масштаб.
Большая гетерогенная распределенная информационная система, которая включает десятки взаимодействующих между собой подсистем.
2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.
3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.
4. Относительно универсальный и стандартизированный набор бизнес-процессов в рамках проекта.
БОльшая часть процессов имеет постоянную сходную с другими бизнес-процессами часть.
Даже поверхностный взгляд на актуальную на тот момент версию руководства пользователя позволил сделать вывод о невысоком качестве документа. Основных проблем было две: неактуальность и отсутствие единообразия при описании сходных функций и процессов.
Низкое качество руководства пользователя может привести к ряду негативных последствий для всего проекта. Выделю основные:
Поиск решения
Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.
Неактуальность документа
Неактуальность документа содержит два класса проблем: устаревшее описание имеющегося функционала и отсутствие описания новых возможностей системы. Алгоритм устранения проблемы был выбран такой.
После этого была проведена каталогизация всех описаний (актуальная проблема, поскольку общее количество описаний превышало 100 шт.). Если процесс был описан в руководстве пользователя, то в ячейке на пересечении соответствующих строки и столбца проставлялся номер пункта (раздела).
Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:
Рисунок 1
Началась работа над документом. Подспорьем на данном этапе опять же стала таблица: если процесс редактируется в одном блоке, то и в другом он создается схожим процентов на 80 образом.
Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный — для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.
Рисунок 2
В итоге общая картина предстала в цвете: были видны обширные оранжевые пятна проблемных областей, много светло-зеленого и практически отсутствие ярко-зеленого.
Таблица соответствия в ходе работы над документом:
Рисунок 3
По завершении «покрасочных» работ обозначились приоритеты:
Отсутствие единообразия
При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (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 соответственно.
Обобщенная структура руководства пользователя, построенная на основе анализа перечисленных стандартов, приведена здесь. Общую методологию можно посмотреть в этой статье.