Пример описания руководства

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

инструкции для сотрудников

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

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

3 основных вида инструкций

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

Пошаговая инструкция

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

Пошаговое руководство

Вот как может выглядеть краткое пошаговое руководство по замене картриджа в лазерном принтере Brother HL-1110R:

  1. Откройте верхнюю крышку и извлеките блок фотобарабана
  2. Установите в нижнее положение переключатель в правом нижнем углу блока фотобарабана
  3. Вытащите тонер-картридж
  4. Поставьте на его место новый
  5. Подвигайте в разные стороны зеленую лапку в левом верхнем углу фотобарабана. Обязательно верните ее в исходное положение
  6. Установите фотобарабан обратно в принтер
  7. Закройте крышку
  8. Сделайте пробную печать. Если появляется сообщение «Замените тонер», значит фотобарабан установлен неправильно, и шаги 1-7 нужно проделать заново. Если неисправность не исчезает обратитесь к системному администратору

Инструкция по использованию

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

инструкция по использованию

В отличие от пошагового алгоритма, акцент делается не на достижении определенного результата, а на особенностях применения. Например, вот как можно кратко написать инструкцию по использованию ламинатора Rayson LM 330iD:

  • В зависимости от толщины пленки устанавливают необходимую температуру. Например, для 75 mic нужно 100-120°C, а для 250 mic 160-180°C.
  • Максимальное время работы ламинатора 4 часа. Затем нужно сделать получасовой перерыв.
  • Если внутри ламинатора застрял документ, нажмите кнопку «Реверс» и извлеките его. 
  • Внимание! Не ламинируйте влажные образцы жидкость может повредить электронные компоненты!
  • После ламинирования 10-15 листов, нужно очистить аппарат от клейкого материала. Для этого ламинатор отключают от сети и протирают валы тканью с моющим средством. 
  • Внимание! Не используйте для очистки бензин и растворители – это приводит к возгоранию! 

Должностная инструкция

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

Должностная инструкция

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

  1. Работник обязан выполнять погрузочно-разгрузочные работы на территории склада Организации
  2. При работе он может пользоваться спецтехникой (электрокаром) если у него есть необходимые допуски
  3. Бригадир раздает списки, по которым комплектуются грузы. 
  4. Отобранный товар кладут на паллету и закрепляют соблюдая технику безопасности при перевозке грузов
  5. Если есть необходимость, грузчик может привлекаться к другим работам на территории склада уборке, контролю за въездом транспорта и пр.

Должностная инструкция – это скорее юридический документ, чем пользовательский. А чтобы понятным языком проинструктировать сотрудника по его работе, обычно составляют отдельное обучение – «Пособие по должности». В нем подробно рассказывают о роли и ценном конечном продукте, описывают систему мотивации, метрики и алгоритмы выполнения работы. И размещают эти материалы на платформе для онлайн-обучения.

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

Общие правила при подготовке инструкций

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

  • Определите уровень подготовленности аудитории. В зависимости от опыта читателей, меняется стиль подачи и структура текста. Пишите на понятном для них языке
  • Не жалейте времени на сбор и обработку информации. Автор должен разбираться в предмете изложения – выступать экспертом или внимательно изучить необходимую документацию. Если первоначальной компетентности недостаточно, нужно проконсультироваться со специалистом
  • Определите исходные данные и результат. Например, «на входе» есть решение руководства о новых правилах доступа в здание, а «на выходе» должно получиться руководство по пользованию электронным пропуском
  • Структурируйте информацию исходя из типа документа. Так, для пошагового алгоритма нужно разбить процедуру на несколько этапов. А должностная инструкция подразумевает серию отдельных описаний с обязанностями. В зависимости от типа меняется и форма подачи
    Как структурировать много данных →
  • Предупреждайте о проблемах, с которыми может столкнуться человек. В первую очередь это касается ситуаций, опасных для жизни и здоровья. Разместите надписи с предостережениями, которые будут выделяться ярким цветом или более крупным размером шрифта

Алгоритм разработки руководства: 9 шагов

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

  1. Собрать информацию
  2. Сгруппировать ее по отдельным этапам
  3. Изложить последовательность выполнения каждого этапа с учетом уровня подготовки читателя

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

Шаг 1. Изучить ситуацию

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

Шаг 2. Разложить все на отдельные этапы

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

  1. Запустить программу Microsoft Word
  2. Создать новый документ
  3. Набрать необходимый текст
  4. Отформатировать его 
  5. Сохранить файл
  6. Сообщить в бухгалтерию, что заявление подготовлено 

Шаг 3. Описать каждый этап

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

Не стоит бояться слишком заурядных объяснений – скорее всего найдутся те, кто еще не знает этого, а остальные легко пропустят такое описание. Например, для тех, кто не работал с программой Word, нужно пояснить как создается файл:

2. Нажмите на раздел «Новый документ» в правой части экрана 

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

Совет. Старайтесь не нагромождать вашу инструкцию ненужными действиями. Например, лишней будет информация о том, какой шрифт использовать для заявления – в большинстве случаев пользователь столкнется с шаблоном Normal, где стоит подходящий Calibri размером 11 пунктов. 

Шаг 4. Рассмотреть нестандартные варианты развития ситуации

Стараясь предусмотреть форс-мажорные обстоятельства, улучшите свой алгоритм, предлагая варианты решения. Например:

3. <…> Если печатаются латинские символы, поменяйте раскладку. Для этого одновременно нажмите клавиши «Shift» и «Ctrl» в левой нижней части клавиатуры 

Шаг 5. Подобрать изображения и привести примеры

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

Шаг 6. Придумать заголовок

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

  • «Как написать инструкцию по подготовке заявления»
  • «6 шагов для подготовки электронного документа»
  • «Простой способ написать заявление на компьютере»
  • «Подробный алгоритм подготовки документа для безбумажного оборота»

Шаг 7. Оценить промежуточный вариант

В результате должен получиться подобный текст:

Как написать простую инструкцию (образец): 

  1. Запустите программу Microsoft Word
  2. Нажмите на раздел «Новый документ» в правой части экрана 
  3. Наберите необходимый текст в открывшемся окне. Образец приведен ниже.
  4. Отформатируйте набранный текст с помощью верхней панели программы Word.
    • Сначала Выделите шапку заявления (адресата и составителя заявления). Нажмите на кнопку «Выравнивание по правому краю» на верхней панели программы Word. Строки переместятся вправо
    • Аналогичным способом отформатируйте заголовок (используем кнопку «Выравнивание по центру»)
    • Выделите список спецодежды и примените к нему функцию «Маркированный список» 
  1. Сохраните файл. Для этого:
    • Нажмите сочетание клавиш «Ctrl+S» или на иконку дискеты в левом верхнем углу
    • Выберите путь сохранения файла
    • В строке «Имя файла» удалите текущее содержимое и напишите: «Заявление от …». Вместо многоточия укажите фамилию, инициалы заявителя и дату, например «Заявление от Иванова В.И. 27.03.2022»
    • Нажмите кнопку «Сохранить»
  2. Сообщите в бухгалтерию (внутренний телефон: 2-31) или секретарю зам. директора по персоналу (т.: 2-42), что заявление подготовлено. 

Пример объявления, на который можете ориентироваться при подготовке:

Шаг 8. Тестирование

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

Проверьте алгоритм с помощью этих вопросов:

  • Понятен ли указанный порядок действий? Да, мы улучшали его в шагах 2-5
  • Все ли нюансы учтены? Да, последовательность шагов охватывает всю необходимую процедуру
  • Есть ли в алгоритме сложные этапы, которые можно разбить на несколько частей? Нет, все они были скорректированы на предыдущих шагах
  • Достигнут ли результат? Будет ли он неизменным при разных условиях использования алгоритма? Да, на выходе мы получаем файл для безбумажного оборота. При правильном следовании приведенной последовательности, результата можно достичь вне зависимости от того, кто составляет заявление – грузчик или уборщица

Шаг 9. Обучить сотрудников по инструкции

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

Особенности такого обучения:

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

Примеры готовых инструкций

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

Вывод

Резюмируя все изложенное, можно составить требования к идеальной инструкции:

  • Актуальность. В тексте нет устаревших сведений
  • Информативность и целостность. Подготовленное руководство содержит все необходимые сведения
    по обозначенной теме. У пользователя не остается вопросов
  • Лаконичность. Приоритеты для составителя – это точность формулировок и отсутствие второстепенных сведений. Часто бывает, что инструкцию смотрят в сложных ситуациях, когда нужно быстро получить ответ на возникший вопрос
  • Наглядность. Информация сопровождается примерами и иллюстрациями
  • Конкретный результат. Руководство помогает получить конечное решение
  • Соотносимость с текущими знаниями пользователя. Чем ниже уровень знаний аудитории, тем подробнее объяснения
  • В тексте нет сложных конструкций. Они разбиты на несколько частей. Каждый пункт списка – это отдельное действие, которое дополняется комментариями и пояснениями

Вам будет интересно

тестирование

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

План обучения менеджера по продажам

Оценка эффективности обучения персонала: проверенный алгоритм

Перейти на главную блога

Документ «Руководство пользователя»

Документ «Руководство пользователя»


РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов: <…>.

УКАЗАНИЯ ГОСТ:
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию документов, разрабатываемых при создании АС.

Руководство пользователя

  1. Структура документа:
  2. 1. Введение
  3. 1.1 Область применения
  4. 1.2 Краткое описание возможностей
  5. 1.3 Уровень подготовки пользователя
  6. 1.4 Перечень эксплуатационной документации
  7. 2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
  8. 2.1 Виды деятельности, функции
  9. 2.2 Программные и аппаратные требования к системе
  10. 3 ПОДГОТОВКА К РАБОТЕ
  11. 3.1 Состав дистрибутива
  12. 3.2 Запуск системы
  13. 3.3 Проверка работоспособности системы
  14. 4 ОПИСАНИЕ ОПЕРАЦИЙ
  15. 4.1 Наименование операции
  16. 4.2 Условия выполнения операции
  17. 4.3 Подготовительные действия
  18. 4.4 Основные действия
  19. 4.5 Заключительные действия
  20. 4.6 Ресурсы, расходуемые на операцию
  21. 5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
  22. 6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ

УКАЗАНИЯ ГОСТ:
Документ содержит разделы:
1) введение;
2) назначение и условия применения;
3) подготовка к работе;
4) описание операций;
5) аварийные ситуации;
6) рекомендации по освоению.

1. Введение

1.1 Область применения

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.2.1».

1.2 Краткое описание возможностей

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Описание автоматизируемых функций, п.п.2.».

1.3 Уровень подготовки пользователя

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.4.1.2 Требования к численности и квалификации персонала системы»

1.4 Перечень эксплуатационной документации

ПРИМЕР СОДЕРЖАНИЯ:
Перечень эксплуатационных документов, с которым необходимо ознакомиться:
— АС Кадры. «Руководство администратора»;
— АС Кадры. «Руководство пользователя»;
— т.д.
— пр.;

2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ

УКАЗАНИЯ ГОСТ:
В разделе «Назначение и условия применения» указывают:
1) виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
2) условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).

ПРИМЕР СОДЕРЖАНИЯ:

2.1 Виды деятельности, функции

ПРИМЕР СОДЕРЖАНИЯ:
АС Кадры предназначена для автоматизации следующих видов деятельности:
Наполнение раздела можно взять в документе «Описание автоматизируемых функций, раздел ЦЕЛИ АС И АВТОМАТИЗИРУЕМЫЕ ФУНКЦИИ».

2.2 Программные и аппаратные требования к системе

ПРИМЕР СОДЕРЖАНИЯ:
Пример требований к программному обеспечению приведен в документе «Пояснительная записка, п.п.3.10».
Пример требований к аппаратному обеспечению приведен в документе «Техническое задание, п.п.4.3.5».

3 ПОДГОТОВКА К РАБОТЕ

УКАЗАНИЯ ГОСТ:
В разделе «Подготовка к работе» указывают:
1) состав и содержание дистрибутивного носителя данных;
2) порядок загрузки данных и программ;
3) порядок проверки работоспособности.

3.1 Состав дистрибутива

ПРИМЕР СОДЕРЖАНИЯ:
В состав дистрибутива АС Кадры входит:
— СУБД Oracle 10.2g;
— Приложение установки базы данных;
— Серверная часть Windows приложения АС Кадры;
— Клиентская часть Windows приложения;
— т.д.;
— пр.

3.2 Запуск системы

ПРИМЕР СОДЕРЖАНИЯ:
Предварительно необходимо выполнить установку системы. Информацию об установке системы можно получить в документе РД И3(А) АС Кадры, который входит в состав проектной документации.
1. Для того, чтобы запустить АС Кадры, откройте папку, в которую была установлена программа, и запустите файл kadry.exe.
2. В открывшемся окне заполните следующие поля в области окна Общие параметры:
— Логин — логин (логическое имя) пользователя;
— Пароль — пароль для входа в систему;
3. т.д.
пр.

3.3 Проверка работоспособности системы

ПРИМЕР СОДЕРЖАНИЯ:
Программное обеспечение работоспособно, если в результате действий пользователя, изложенных в п.п.3.2, на экране монитора отобразилось главное окно клиентского приложения без выдачи пользователю сообщений о сбое в работе.

4 ОПИСАНИЕ ОПЕРАЦИЙ

УКАЗАНИЯ ГОСТ:
В разделе «Описание операций» указывают:
1) описание всех выполняемых функций, задач, комплексов задач, процедур;
2) описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
1) наименование;
2) условия, при соблюдении которых возможно выполнение операции;
3) подготовительные действия;
4) основные действия в требуемой последовательности;
5) заключительные действия;
6) ресурсы, расходуемые на операцию.

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

4.1 Наименование операции

ПРИМЕР СОДЕРЖАНИЯ:
Просмотр справочной информации.

4.2 Условия выполнения операции

ПРИМЕР СОДЕРЖАНИЯ:
Приложение запущено, успешно функционирует, не выполняет никакх операций, блокирущих доступ к пунктам меню.

4.3 Подготовительные действия

ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.

4.4 Основные действия

ПРИМЕР СОДЕРЖАНИЯ:
Открыть пункт меню «Помощь», выбрать раздел «Справка». Появится всплывающее окно, содержащее разделы со справкой.

4.5 Заключительные действия

ПРИМЕР СОДЕРЖАНИЯ:
После завершения работы со справочной информацией, закрыть вплывающее окно со справкой.

4.6 Ресурсы, расходуемые на операцию

ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.

5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ

УКАЗАНИЯ ГОСТ:
В разделе «Аварийные ситуации» указывают:
1) действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств;
2) действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных;
3) действия в случаях обнаружении несанкционированного вмешательства в данные;
4) действия в других аварийных ситуациях

ПРИМЕР СОДЕРЖАНИЯ:
При сбое в работе аппаратуры восстановление нормальной работы системы должно производиться после:
— перезагрузки операционной системы;
— запуска исполняемого файла системы;

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

6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ

УКАЗАНИЯ ГОСТ:
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

ПРИМЕР СОДЕРЖАНИЯ:
Для успешного освоения приложения АС Кадры необходимо иметь навыки работы с ПК и изучить следующее:
— Нормативно-правовую базу по вопросам управления государсвенными кадрами;
— Раздел «Описание процесса деятельности» документа «Пояснительная записка (Технический проект)»;
— Раздел «Описание автоматизируемых функций» документа «Пояснительная записка (Технический проект)»;
— Настоящее «Руководство пользователя».

Контрольный пример работы с системой
Ниже рассмотрен пример работы с системой, начиная с ее запуска и заканчивая оформлением документов:
1. Запустите систему.
2. т.д.
3. пр.

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

Журавлев Денис

Что такое руководство пользователя и для чего его создавать

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

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

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

Общие советы по созданию пользовательской документации

Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.

После этого важно подумать о том:

  • Где пользователь будет к нему обращаться: дома, на работе, в машине?
  • Как часто он будет его просматривать?
  • Насколько объективно сложен для понимания продукт?

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

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

Структура руководства пользователя

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

В первом разделе желательно рассказать общую информацию о программе:

  • Для чего создан продукт.
  • Какие задачи он решает.
  • Какие основные выгоды от использования для клиента.

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

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

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

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

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

Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.

Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.

Видео-обзор основных возможностей программы Dr.Explain

Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.

Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.  

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

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

Структура разделов руководства пользователя

У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.

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

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

Создание руководства пользователя по ГОСТ 34 и ГОСТ 19

Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.

Аннотирование скриншотов пользовательского интерфейса в руководстве пользователя

Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами.  По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.  

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

Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.

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

Павел Свиридов

Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»

«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.

Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».

Руководство пользователя к программе Вега Матрица

Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке


Наталья Обухова

Наталья Обухова, бизнес-аналитик компании CRM Expert

«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.

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

Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.

Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».

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

Прочитать полный кейс компании CRM Expert


Николай Вальковец

Николай Вальковец, разработчик компании 2V

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

Руководство к программе 2V Стоматология

Прочитать кейс компании V2  


Подытожим

Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.

Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/

Успешных вам разработок!

Смотрите также

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

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

Время на прочтение
12 мин

Количество просмотров 16K

Есть устоявшеёся мнение, что для хороших продуктов руководство пользователя не нужно. Очередной холивар на эту тему разгорелся в нашем рабочем чате. Я не до конца согласен с этим утверждением. 

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

  • Пользователи бывают разные. То есть они могут отличаться как по возрасту, отрасли и опыту, так и по количеству мотивации. Мотивация особенно касается b2b сервисов. Многие пользователи попадают в продукты, потому что «Начальник сказал».

  • Продукты бывают сложные. Быстро разобраться и понять все их фишки без документации сложно или невозможно.

Документация помогает пользователю решить проблему или помочь разобраться с особенностями и фишками продукта. В любой документации люблю раздел Tips&Tricks.

Что входит в пользовательскую документацию

Пользовательская документация — это не юридические документы. У них другие цели.

Пользовательская документация — это материалы, которые помогают пользователю использовать продукт на максималках.

Что еще можно отнести к пользовательской документации

Документация для разработчиков и администрированию: доки по API, инструкции по установке и администрированию. Но сейчас их касаться не буду.

В пользовательскую документацию я включаю:

  • Ответы на часто задаваемые вопросы (FAQ).

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

  • Краткое руководство пользователя. Короткая презентация или документ для быстрого начала. Описывает базовые функции, возможности и советы для начала. Главное отличие от полного руководства — быстрее читаются, дают базовое представление о продукте и особенно помогают при внедрении b2b продуктов.

  • Описание отдельных фишек (Tips&Tricks). Чаще всего их делают в формате видеоуроков, но можно наткнуться и на текстовые.

  • Релизноуты. Считаю их важной частью пользовательской документации. И, говоря релизноуты, я имею ввиду не разовые, которые выкладываются в магазины приложений или к себе на сайт. А написанные раз в какой-то период. Можно раз в месяц. При работе над прошлым продуктом мы писали всё, что исправили или добавили за месяц. Хорошим тоном, на мой взгляд, будет писать самое важное. 

  • Видеоуроки. Считаю их частью пользовательской документации, но это скорее вкусовщина, чем правило.

Почему это важно?

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

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

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

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

Красоты B2B рынка

Прошлый продукт, над которым мы с командой работали, умел и в облако, и в on-premise.
С облаком все понятно. Динамическая документация на сайте или в другом сервисе. Документация для корпоративных заказчиков имеет определенные особенности. 

Особенность #1: Корпорации любят печатную документацию. Очень сильно.
Мой знакомый сейлз любит рассказывать истории про это. 

Резюме его историй:

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

Поэтому чем толще кипа бумаги — тем лучше.

Особенность #2: Нужно отдавать дополнительные пакеты документов.
В дополнительные пакеты документов входит: документация по установке вашего ПО и документацию по его администрированию, а может ещё что-то, если попросят.

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

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

Где делать?

Много думал, долго смотрел. Переделывал наш гайд раз пять.

Когда искал, ставил для себя следующие задачи:

  • Документацию можно сделать динамической. То есть возможность грузить видео, гифки, делать кросс-ссылки.

  • Поддерживается базовое форматирование: заголовки, жирный, курсив, code, code block.

  • Возможность экспортировать в .pdf.

Небольшой совет

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

  • Есть возможность выложить документацию на свой домен.

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

Какие вариант рассматривал:

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

  • Google Docs.
    Стоимость: Free
    Плюсы: очень удобно работать с вёрсткой документа; привычный, при этом более простой интерфейс, относительно MS Docs; есть синхронизация с облаком; есть экспорт в .pdf.
    Минусы: очень тяжело работать с визуальной частью — скринами; отношу в категорию не динамичных, так как выложить ссылочку на сайт на Google Doc конечно можно, особенно учитывая их последние апдейты, но это выглядит как-то не серьезно. 

  • Notion.
    Стоимость: можно Free, если работает один человек, а так от 8-10$ за человека.
    Плюсы: очень удобно делать динамическую документацию, которую не стыдно выложить на сайт, по моим ощущениям; удобно работать в паре, есть все необходимое; можно вставить любое медиа, хоть ссылку, хоть видео, хоть схему из miro.
    Минусы: не самый широкий спектр инструментов для работы с версткой; если неправильно сверстать, скопировать кусочек текста в другое место бывает накладно; не для всех пользователей привычная навигация по страницам.

  • Другие инструменты для wiki. Я смотрел на несколько вариантов wiki.js, Stonly 2, Dropbox Paper, Outline

    Смотрел давно, поэтому ничего вразумительно сказать не смогу. Помню, только что из всего выше, зацепил Dropbox и Wiki.js. В процессе написания этой статьи наткнулся ещё на один интересный сервис — GitBook. Он удовлетворяет всем моим запросам к подобным инструментам, но прошел мимо меня когда выбирал. 

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

С чего начать?

Не скажу ничего нового.
Начинать нужно с ответа на вопрос «Зачем мы это будем делать?». Мы начинали писать первую версию как раз для корпоративного заказчика. Но эта итерация была небольшой. Писали краткий гайд.

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

После того, как поняли зачем, накидайте план, а точнеё оглавление. План подразумевает последовательность, а оглавление позволяет вам писать не последовательно. Я писал непоследовательно. Сначала писал то, что помнил на память, потом все остальное.

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

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

Основные правила

Понятный и простой язык

Я не буду писать о важности соблюдения правил русского языка: орфографии, пунктуации. И не буду рассказывать «Как писать хорошо?». Я сам далеко не эксперт в этом вопросе, поэтому когда мне нужно написать хороший текст я всегда обращаюсь к заветам Ильяхова и сервисам Главред, Яндекс.Спеллер и LanguageTools.

Любой текст должен быть простым и понятным.

Самое главное всегда это помнить.

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

Понятное и аккуратное форматирование

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

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

  • Кавычки.
    Все то ли ленятся, то ли не знают где на клавиатуре находятся наши кавычки. У меня есть предположение, что эта привычка пошла со школ, потому что руками мы пишем другие кавычки. 

    Основные кавычки оформляются елочкой «», внутренние кавычки оформляются лапками „“. Например, «Нажмите на вкладку „Контакты“ в левом верхнем углу», забугорные кавычки выглядят так «_».

    Рекомендации по оформлению текста от Риановости

    Рекомендации по оформлению текста от Риановости

    P.S. Иностранные названия в русском тексте кавычками не выделяются. 

  • Тире и дефис.
    Все знают про тире и дефис. Оказалось, что многие не знают про среднее тире.

    Дефис (-) используется для присоединения частиц (что-то), для присоединения префиксов (по-братски), в словосочетаниях и сложносоставных словах (бизнес-ланч).
    Среднее тире (–) применяется в числовом обозначении диапазонов и интервалов: 2011–2022, 11–12 ноября.
    Длинное тире (—) используется для выделения прямой речи, указания маршрутов (Москва — Санкт-Петербург), между подлежащим и сказуемым.

Рекомендации по оформлению текста от Риановости

Рекомендации по оформлению текста от Риановости
  • Оформление списков.
    Существуют два вида списков: нумерованный и маркированный.

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

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

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

    Ещё один важный момент. 

    • Если пункт списка начинается с большой буквы, на конце всегда точка.

    • Если пункт списка один или два слова и начинается с маленькой буквы, на конце запятая, в конце списка точка.

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

  • Оформление дат и чисел.
    Если в тексте присутствуют даты, то лучше писать 15 мая 2021, а не 15.05.2021. Помогите пользователю думать только о важном.

    Если есть числа, то их нужно тоже оформить правильно. Не 2221, а 2 221. Отделяйте тысячные, это очень сильно упрощает восприятие.

  • Вы или вы.
    Мое стойкое мнение — если это не коммуникация с кем-то из государственной организации в переписке, всегда писать вы и ваш с маленькой буквы. Иначе выглядит, что вы кричите на пользователя, а на пользователя нельзя кричать. 

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

  • Буква Ё.
    С этой буквой у меня особые отношения. Исторически моя фамилия пишется через Ё, но из-за передергивания правил русского языка в советском союзе моя фамилия теперь пишется через Е. Поэтому я долгое время принципиально везде писал Е. Годы идут. Мозгов прибавилось. Теперь стараюсь писать Ё везде, где ей место. Так действительно проще воспринимать текст.

  • Эмодзи в тексте 🦄
    По этому поводу много споров как у нас в команде, так и в кругах пишущих. Я придерживаюсь мнения, что эмодзи в тексте допустимы, но очень дозировано.

    Я использовал эмодзи для визуального подчеркивания каких-то кнопок в интерфейсе.
    Например: Нажмите на символ ⚙️ в правом верхнем углу.

    Для поиска символов пользуюсь Glyphy.

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

Если ваш продукт международный

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

Удобная навигация

Нет единого мнения — как правильно. Если самопис, я рекомендую делать вертикальную навигацию слева. Такая часто встречается в технических документациях.

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

  • Блок общего и важного.

    • Описание вашего решения. Вдруг пользователь попал сначала на ваш гайд, а не на сайт.

    • FAQ.

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

    • Наши обновления.

  • Блок «Как начать». Сюда писать общие вещи, которые касаются всего сервиса. Особенно важный блок, если у вас мультиплатформенное решение.

  • Блок с руководством пользователя. Если у вас мультиплатформенное решение, то на каждую платформу лучше писать свое руководство. Можно объединять мобильные приложения и ПК версию. Так можно делать если нет глобальной разницы.

    У нас, например, исторически разницы не было. Поэтому iOS и Android лежат на странице «Мобильные приложения». Но сейчас мы начали разделять, поэтому в будущем будет разделение на ОС.

Связность

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

Если хочется сделать по красоте, то можно внимательно изучить методологию Zettelkasten, например.

Удобный поиск

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

Вот как мы это в Notion решили.

Логичность

Всё, что вы пишите должно быть логичным. 

Порядок элементов в тексте и интерфейсе должен быть одинаковым. Пользователь ломается, когда написано: «Нажмите на вторую вкладку „Контакты“», а вторая вкладка — «Чаты». 
Или когда в интерфейсе элемент называется «Назначить админом», а написано «Назначить администратором». 

Понятная визуалка

Этот пункт я бы хотел разбить на два блока: работа с медиа и работа с Step-by-Step.

Работа с медиа

Я сторонник динамичных гайдов. Когда есть .gif или видео презентация. Это помогает увидеть наглядно. Если есть возможность, наполняйте вашу документацию .gif.
С видео все сложнее. Оно требует дополнительного действия от пользователя — включить, плюс весит больше чем .gif. Поэтому видео использую редко. Чаще для каких-то больших блоков или полноценных видеоуроков.

Иногда нет возможности сделать документацию динамической, особенно если вы работаете с корпоративными клиентами. Тогда делайте скриншоты реального интерфейса. Для этого лучше завести демо-стенд с близким к реальности наполнением. И там делать скриншоты.
Можно нарисовать демо-стенд в Figma и из этого собирать медиа для гайда. У меня такой подход не прижился, сложнеё управляться.

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

Очень не люблю стрелочки. Считаю, что лучше выделить место геометрической фигурой и поставить номер шага. Но иногда стрелочки приемлемы, тут вкусовщина.

Из хороших приемов — блюрить лишнюю часть интерфейса или делать выделение лупой важной части.

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

Step-by-step

Step-by-Step — это пошаговое описание всех действий, которые нужно выполнить пользователю, чтобы получить результат.

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

  • Делать нумерованные списки. Если есть подпункты, то нумеровать их соответственно и делать сдвиг вправо 1.1, 1.2, 1.2.1 и тд.

  • Писать сначала «Что нажать», потом «Где нажать». Исхожу из простой логики — сначала нужно понять «Что искать» и только потом «Где искать».

    Например: «Нажмите на кнопку „Включить“ в правом верхнем углу», а не «В правом верхнем углу нажмите на кнопку „Включить“».

  • Вставлять визуальные элементы для кнопок, особенно если они без подписи. Для этой истории приходится немного костылить, если делать это в том же Notion, но в Google Docs это делать проще. Использую стандартные эмодзи и сервис Glyphy.

    Например: Нажмите на символ ⚙️ в правом верхнем углу.

    Не люблю слово иконка, поэтому пишу символ, чтобы была однозначность. Тоже вкусовщина.

  • Если одно действие можно сделать из разных мест, описывать все места и каждое по пунктам.

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

  • Все названия кнопок, сущностей, элементов — должны иметь такое же название как в интерфейсе.

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

Поддержка и послесловие

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

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

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

Раз в 3-6 месяцев заходить и перечитывать, лучше если это каждый раз будет делать новый человек. Это нужно делать по трем причинам:

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

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

3. Всегда есть что улучшить. Текст это такой же продукт.

Хочется верить, что эта статья сэкономит кому-то время, а кому-то поможет стать немного лучше.
Я не претендую на истину в последней инстанции. Описал свой опыт и мнение.

p.s. Пользовательская документация с которой все началось. Скажу сразу, там очень много чего можно и нужно улучшить. Бэклог по апдейту документации уже перевалил за 30 задач. Постепенно обновляем.

p.s.s. буду благодарен за конструктивный фидбек в комментариях и ещё больше, если поделитесь вашим опытом. 

Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

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

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

  1. Введение.
  2. Назначение и условия применения.
  3. Подготовка к работе.
  4. Описание операций.
  5. Аварийные ситуации.
  6. Рекомендации по освоению.

1. Введение

В разделе «Введение» указывают:

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

1.1. Область применения

Требования настоящего документа применяются при:

  • предварительных комплексных испытаниях;
  • опытной эксплуатации;
  • приемочных испытаниях;
  • промышленной эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:

  • формирование табличных и кросс-табличных отчетов;
  • построение различных диаграмм;
  • экспорт и импорт результатов анализа;
  • печать результатов анализа;
  • распространение результатов анализа.

1.3. Уровень подготовки пользователя

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:

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

Квалификация пользователя должна позволять:

  • формировать отчеты в Oracle Discoverer Plus;
  • осуществлять анализ данных.

1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю

  • Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
  • Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения Oracle Discoverer Plus

В разделе «Назначение и условия применения» указывают:

  1. виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
  2. условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).

Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе «Подготовка к работе» указывают:

  1. состав и содержание дистрибутивного носителя данных;
  2. порядок загрузки данных и программ;
  3. порядок проверки работоспособности.

3.1. Состав и содержание дистрибутивного носителя данных

Для работы с ИАС КХД необходимо следующее программное обеспечение:

  1. Internet Explorer (входит в состав операционной системы Windows);
  2. Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.

3.2. Порядок загрузки данных и программ

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

  1. Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
  2. Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator» …’ Нажимаем на кнопку «Да».
  3. После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.

3.3. Порядок проверки работоспособности

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

  1. Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
  2. Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
  3. В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
  4. Убедиться, что в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.

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

В разделе «Описание операций» указывают:

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

Для каждой операции обработки данных указывают:

  1. наименование;
  2. условия, при соблюдении которых возможно выполнение операции;
  3. подготовительные действия;
  4. основные действия в требуемой последовательности;
  5. заключительные действия;
  6. ресурсы, расходуемые на операцию.

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

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

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

4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач

Ниже приведено описание пользовательских операций для выполнения каждой из задач.

Задача: «Визуализация отчетности»

Операция 1: Регистрация на портале ИАС КХД

Условия, при соблюдении которых возможно выполнение операции:

  1. Компьютер пользователя подключен к корпоративной сети.
  2. Портал ИАС КХД доступен.
  3. ИАС КХД функционирует в штатном режиме.

Подготовительные действия:

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

Основные действия в требуемой последовательности:

  1. На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
  2. В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».

Заключительные действия:

Не требуются.

Ресурсы, расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия, при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале ИАС КХД.

Подготовительные действия:

Не требуются.

Основные действия в требуемой последовательности:

1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle Discoverer

2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle Discoverer

Заключительные действия:

После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы, расходуемые на операцию:

15 секунд.

Задача: «Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

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

В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.

В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.

Класс ошибки Ошибка Описание ошибки Требуемые действия пользователя при возникновении ошибки
Портал ИАС КХД Сервер не найден. Невозможно отобразить страницу Возможны проблемы с сетью или с доступом к порталу ИАС КХД. Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД.
Ошибка: Требуется ввести действительное имя пользователя При регистрации на портале ИАС КХД не введено имя пользователя. Ввести имя пользователя.
Ошибка: Требуется ввести пароль для регистрации При регистрации на портале ИАС КХД не введен пароль. Ввести пароль.
Ошибка: Сбой аутентификации. Повторите попытку Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД.
Сбой в электропитании рабочей станции Нет электропитания рабочей станции или произошел сбой в электропитании. Рабочая станция выключилась или перезагрузилась. Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
Повторить попытку подключения (входа) в ИАС КХД
Сбой локальной сети Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД.

6. Рекомендации по освоению

В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

Рекомендуемая литература:

  • Oracle® Business Intelligence Discoverer Viewer User’s Guide
  • Oracle® Business Intelligence Discoverer Plus User’s Guide

Рекомендуемые курсы обучения:

  • Discoverer 10g: Создание запросов и отчетов

В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.

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

инструкции для сотрудников

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

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

3 основных вида инструкций

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

Пошаговая инструкция

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

Пошаговое руководство

Вот как может выглядеть краткое пошаговое руководство по замене картриджа в лазерном принтере Brother HL-1110R:

  1. Откройте верхнюю крышку и извлеките блок фотобарабана
  2. Установите в нижнее положение переключатель в правом нижнем углу блока фотобарабана
  3. Вытащите тонер-картридж
  4. Поставьте на его место новый
  5. Подвигайте в разные стороны зеленую лапку в левом верхнем углу фотобарабана. Обязательно верните ее в исходное положение
  6. Установите фотобарабан обратно в принтер
  7. Закройте крышку
  8. Сделайте пробную печать. Если появляется сообщение «Замените тонер», значит фотобарабан установлен неправильно, и шаги 1-7 нужно проделать заново. Если неисправность не исчезает обратитесь к системному администратору

Инструкция по использованию

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

инструкция по использованию

В отличие от пошагового алгоритма, акцент делается не на достижении определенного результата, а на особенностях применения. Например, вот как можно кратко написать инструкцию по использованию ламинатора Rayson LM 330iD:

  • В зависимости от толщины пленки устанавливают необходимую температуру. Например, для 75 mic нужно 100-120°C, а для 250 mic 160-180°C.
  • Максимальное время работы ламинатора 4 часа. Затем нужно сделать получасовой перерыв.
  • Если внутри ламинатора застрял документ, нажмите кнопку «Реверс» и извлеките его. 
  • Внимание! Не ламинируйте влажные образцы жидкость может повредить электронные компоненты!
  • После ламинирования 10-15 листов, нужно очистить аппарат от клейкого материала. Для этого ламинатор отключают от сети и протирают валы тканью с моющим средством. 
  • Внимание! Не используйте для очистки бензин и растворители – это приводит к возгоранию! 

Должностная инструкция

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

Должностная инструкция

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

  1. Работник обязан выполнять погрузочно-разгрузочные работы на территории склада Организации
  2. При работе он может пользоваться спецтехникой (электрокаром) если у него есть необходимые допуски
  3. Бригадир раздает списки, по которым комплектуются грузы. 
  4. Отобранный товар кладут на паллету и закрепляют соблюдая технику безопасности при перевозке грузов
  5. Если есть необходимость, грузчик может привлекаться к другим работам на территории склада уборке, контролю за въездом транспорта и пр.

Должностная инструкция – это скорее юридический документ, чем пользовательский. А чтобы понятным языком проинструктировать сотрудника по его работе, обычно составляют отдельное обучение – «Пособие по должности». В нем подробно рассказывают о роли и ценном конечном продукте, описывают систему мотивации, метрики и алгоритмы выполнения работы. И размещают эти материалы на платформе для онлайн-обучения.

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

Общие правила при подготовке инструкций

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

  • Определите уровень подготовленности аудитории. В зависимости от опыта читателей, меняется стиль подачи и структура текста. Пишите на понятном для них языке
  • Не жалейте времени на сбор и обработку информации. Автор должен разбираться в предмете изложения – выступать экспертом или внимательно изучить необходимую документацию. Если первоначальной компетентности недостаточно, нужно проконсультироваться со специалистом
  • Определите исходные данные и результат. Например, «на входе» есть решение руководства о новых правилах доступа в здание, а «на выходе» должно получиться руководство по пользованию электронным пропуском
  • Структурируйте информацию исходя из типа документа. Так, для пошагового алгоритма нужно разбить процедуру на несколько этапов. А должностная инструкция подразумевает серию отдельных описаний с обязанностями. В зависимости от типа меняется и форма подачи
    Как структурировать много данных →
  • Предупреждайте о проблемах, с которыми может столкнуться человек. В первую очередь это касается ситуаций, опасных для жизни и здоровья. Разместите надписи с предостережениями, которые будут выделяться ярким цветом или более крупным размером шрифта

Алгоритм разработки руководства: 9 шагов

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

  1. Собрать информацию
  2. Сгруппировать ее по отдельным этапам
  3. Изложить последовательность выполнения каждого этапа с учетом уровня подготовки читателя

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

Шаг 1. Изучить ситуацию

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

Шаг 2. Разложить все на отдельные этапы

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

  1. Запустить программу Microsoft Word
  2. Создать новый документ
  3. Набрать необходимый текст
  4. Отформатировать его 
  5. Сохранить файл
  6. Сообщить в бухгалтерию, что заявление подготовлено 

Шаг 3. Описать каждый этап

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

Не стоит бояться слишком заурядных объяснений – скорее всего найдутся те, кто еще не знает этого, а остальные легко пропустят такое описание. Например, для тех, кто не работал с программой Word, нужно пояснить как создается файл:

2. Нажмите на раздел «Новый документ» в правой части экрана 

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

Совет. Старайтесь не нагромождать вашу инструкцию ненужными действиями. Например, лишней будет информация о том, какой шрифт использовать для заявления – в большинстве случаев пользователь столкнется с шаблоном Normal, где стоит подходящий Calibri размером 11 пунктов. 

Шаг 4. Рассмотреть нестандартные варианты развития ситуации

Стараясь предусмотреть форс-мажорные обстоятельства, улучшите свой алгоритм, предлагая варианты решения. Например:

3. <…> Если печатаются латинские символы, поменяйте раскладку. Для этого одновременно нажмите клавиши «Shift» и «Ctrl» в левой нижней части клавиатуры 

Шаг 5. Подобрать изображения и привести примеры

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

Шаг 6. Придумать заголовок

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

  • «Как написать инструкцию по подготовке заявления»
  • «6 шагов для подготовки электронного документа»
  • «Простой способ написать заявление на компьютере»
  • «Подробный алгоритм подготовки документа для безбумажного оборота»

Шаг 7. Оценить промежуточный вариант

В результате должен получиться подобный текст:

Как написать простую инструкцию (образец): 

  1. Запустите программу Microsoft Word
  2. Нажмите на раздел «Новый документ» в правой части экрана 
  3. Наберите необходимый текст в открывшемся окне. Образец приведен ниже.
  4. Отформатируйте набранный текст с помощью верхней панели программы Word.
    • Сначала Выделите шапку заявления (адресата и составителя заявления). Нажмите на кнопку «Выравнивание по правому краю» на верхней панели программы Word. Строки переместятся вправо
    • Аналогичным способом отформатируйте заголовок (используем кнопку «Выравнивание по центру»)
    • Выделите список спецодежды и примените к нему функцию «Маркированный список» 
  1. Сохраните файл. Для этого:
    • Нажмите сочетание клавиш «Ctrl+S» или на иконку дискеты в левом верхнем углу
    • Выберите путь сохранения файла
    • В строке «Имя файла» удалите текущее содержимое и напишите: «Заявление от …». Вместо многоточия укажите фамилию, инициалы заявителя и дату, например «Заявление от Иванова В.И. 27.03.2022»
    • Нажмите кнопку «Сохранить»
  2. Сообщите в бухгалтерию (внутренний телефон: 2-31) или секретарю зам. директора по персоналу (т.: 2-42), что заявление подготовлено. 

Пример объявления, на который можете ориентироваться при подготовке:

Шаг 8. Тестирование

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

Проверьте алгоритм с помощью этих вопросов:

  • Понятен ли указанный порядок действий? Да, мы улучшали его в шагах 2-5
  • Все ли нюансы учтены? Да, последовательность шагов охватывает всю необходимую процедуру
  • Есть ли в алгоритме сложные этапы, которые можно разбить на несколько частей? Нет, все они были скорректированы на предыдущих шагах
  • Достигнут ли результат? Будет ли он неизменным при разных условиях использования алгоритма? Да, на выходе мы получаем файл для безбумажного оборота. При правильном следовании приведенной последовательности, результата можно достичь вне зависимости от того, кто составляет заявление – грузчик или уборщица

Шаг 9. Обучить сотрудников по инструкции

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

Особенности такого обучения:

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

Примеры готовых инструкций

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

Вывод

Резюмируя все изложенное, можно составить требования к идеальной инструкции:

  • Актуальность. В тексте нет устаревших сведений
  • Информативность и целостность. Подготовленное руководство содержит все необходимые сведения
    по обозначенной теме. У пользователя не остается вопросов
  • Лаконичность. Приоритеты для составителя – это точность формулировок и отсутствие второстепенных сведений. Часто бывает, что инструкцию смотрят в сложных ситуациях, когда нужно быстро получить ответ на возникший вопрос
  • Наглядность. Информация сопровождается примерами и иллюстрациями
  • Конкретный результат. Руководство помогает получить конечное решение
  • Соотносимость с текущими знаниями пользователя. Чем ниже уровень знаний аудитории, тем подробнее объяснения
  • В тексте нет сложных конструкций. Они разбиты на несколько частей. Каждый пункт списка – это отдельное действие, которое дополняется комментариями и пояснениями

Вам будет интересно

агрегаторы курсов

Готовые курсы для бизнеса: проверенные агрегаторы онлайн курсов

как учиться эффективно

Как учиться эффективно: проверенная технология обучения

платформы для вебинаров

Где провести вебинар: лучшие программы для вебинаров

Перейти на главную блога

Примеры и рекомендации удобных инструкций

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

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

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

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

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

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

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

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

Clear screen/clear desk

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

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

На этом завершаю примеры и рекомендации. Серию подобных постов я продолжу, если будет интерес.

Источник

ocnova.ru

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

Ответить Аналитика Сентябрь 23rd, 2010 Аналайзер

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее формируем следующую структуру:

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

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

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

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

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

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

Источник

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

РД 50-34.698-90 Руководство пользователя (пример оформления)

images db 2

Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

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

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

1. Введение

В разделе «Введение» указывают:

1.1. Область применения

Требования настоящего документа применяются при:

1.2. Краткое описание возможностей

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:

1.3. Уровень подготовки пользователя

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:

Квалификация пользователя должна позволять:

1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю

2. Назначение и условия применения Oracle Discoverer Plus

В разделе «Назначение и условия применения» указывают:

Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе «Подготовка к работе» указывают:

3.1. Состав и содержание дистрибутивного носителя данных

Для работы с ИАС КХД необходимо следующее программное обеспечение:

3.2. Порядок загрузки данных и программ

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

3.3. Порядок проверки работоспособности

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.

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

В разделе «Описание операций» указывают:

Для каждой операции обработки данных указывают:

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

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

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

4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач

Ниже приведено описание пользовательских операций для выполнения каждой из задач.

Задача: «Визуализация отчетности»

Операция 1: Регистрация на портале ИАС КХД

Условия, при соблюдении которых возможно выполнение операции:

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

Основные действия в требуемой последовательности:

Ресурсы, расходуемые на операцию:

Операция 2: Выбор отчета

Условия, при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале ИАС КХД.

Основные действия в требуемой последовательности:

1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».

user guide 1

2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:

user guide 2

После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы, расходуемые на операцию:

Задача: «Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

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

В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.

В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.

Класс ошибки Ошибка Описание ошибки Требуемые действия пользователя при возникновении ошибки
Портал ИАС КХД Сервер не найден. Невозможно отобразить страницу Возможны проблемы с сетью или с доступом к порталу ИАС КХД. Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД.
Ошибка: Требуется ввести действительное имя пользователя При регистрации на портале ИАС КХД не введено имя пользователя. Ввести имя пользователя.
Ошибка: Требуется ввести пароль для регистрации При регистрации на портале ИАС КХД не введен пароль. Ввести пароль.
Ошибка: Сбой аутентификации. Повторите попытку Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД.
Сбой в электропитании рабочей станции Нет электропитания рабочей станции или произошел сбой в электропитании. Рабочая станция выключилась или перезагрузилась. Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
Повторить попытку подключения (входа) в ИАС КХД
Сбой локальной сети Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД.

6. Рекомендации по освоению

В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

Рекомендуемые курсы обучения:

В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.

Источник

Руководство пользователя. Советы для составления

instruction manual

Существует множество видов предоставления справочной информации пользователю – это и FAQ (frequently asked questions, часто задаваемые вопросы) и онлайн справка и руководство пользователя (user guide) и популярные сегодня подсказки (coachmarks, см. пример ниже), обучающие видео и другие.

sovety polzovatelu

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

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

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

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. Поддержка

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

Заключение

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

Помните главное: документ должен помогать пользователям.

Статью подготовила

NadiaТарасюк Надежда, участник сообщества analyst.by,

Источник

Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

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

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

  1. Введение.
  2. Назначение и условия применения.
  3. Подготовка к работе.
  4. Описание операций.
  5. Аварийные ситуации.
  6. Рекомендации по освоению.

1. Введение

В разделе «Введение» указывают:

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

1.1. Область применения

Требования настоящего документа применяются при:

  • предварительных комплексных испытаниях;
  • опытной эксплуатации;
  • приемочных испытаниях;
  • промышленной эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:

  • формирование табличных и кросс-табличных отчетов;
  • построение различных диаграмм;
  • экспорт и импорт результатов анализа;
  • печать результатов анализа;
  • распространение результатов анализа.

1.3. Уровень подготовки пользователя

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:

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

Квалификация пользователя должна позволять:

  • формировать отчеты в Oracle Discoverer Plus;
  • осуществлять анализ данных.

1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю

  • Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
  • Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения Oracle Discoverer Plus

В разделе «Назначение и условия применения» указывают:

  1. виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
  2. условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).

Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе «Подготовка к работе» указывают:

  1. состав и содержание дистрибутивного носителя данных;
  2. порядок загрузки данных и программ;
  3. порядок проверки работоспособности.

3.1. Состав и содержание дистрибутивного носителя данных

Для работы с ИАС КХД необходимо следующее программное обеспечение:

  1. Internet Explorer (входит в состав операционной системы Windows);
  2. Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.

3.2. Порядок загрузки данных и программ

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

  1. Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
  2. Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator» …’ Нажимаем на кнопку «Да».
  3. После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.

3.3. Порядок проверки работоспособности

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

  1. Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
  2. Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
  3. В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
  4. Убедиться, что в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.

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

В разделе «Описание операций» указывают:

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

Для каждой операции обработки данных указывают:

  1. наименование;
  2. условия, при соблюдении которых возможно выполнение операции;
  3. подготовительные действия;
  4. основные действия в требуемой последовательности;
  5. заключительные действия;
  6. ресурсы, расходуемые на операцию.

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

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

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

4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач

Ниже приведено описание пользовательских операций для выполнения каждой из задач.

Задача: «Визуализация отчетности»

Операция 1: Регистрация на портале ИАС КХД

Условия, при соблюдении которых возможно выполнение операции:

  1. Компьютер пользователя подключен к корпоративной сети.
  2. Портал ИАС КХД доступен.
  3. ИАС КХД функционирует в штатном режиме.

Подготовительные действия:

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

Основные действия в требуемой последовательности:

  1. На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
  2. В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».

Заключительные действия:

Не требуются.

Ресурсы, расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия, при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале ИАС КХД.

Подготовительные действия:

Не требуются.

Основные действия в требуемой последовательности:

1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle Discoverer

2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle Discoverer

Заключительные действия:

После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы, расходуемые на операцию:

15 секунд.

Задача: «Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

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

В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.

В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.

Класс ошибки Ошибка Описание ошибки Требуемые действия пользователя при возникновении ошибки
Портал ИАС КХД Сервер не найден. Невозможно отобразить страницу Возможны проблемы с сетью или с доступом к порталу ИАС КХД. Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД.
Ошибка: Требуется ввести действительное имя пользователя При регистрации на портале ИАС КХД не введено имя пользователя. Ввести имя пользователя.
Ошибка: Требуется ввести пароль для регистрации При регистрации на портале ИАС КХД не введен пароль. Ввести пароль.
Ошибка: Сбой аутентификации. Повторите попытку Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД.
Сбой в электропитании рабочей станции Нет электропитания рабочей станции или произошел сбой в электропитании. Рабочая станция выключилась или перезагрузилась. Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
Повторить попытку подключения (входа) в ИАС КХД
Сбой локальной сети Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД Перезагрузить рабочую станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД.

6. Рекомендации по освоению

В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

Рекомендуемая литература:

  • Oracle® Business Intelligence Discoverer Viewer User’s Guide
  • Oracle® Business Intelligence Discoverer Plus User’s Guide

Рекомендуемые курсы обучения:

  • Discoverer 10g: Создание запросов и отчетов

В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.

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

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

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

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

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

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

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

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

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

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

Задачи:

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

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

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

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

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

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

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

Располагаем документами:

  • «метагайдом» Кагарлицкого;
  • суперсовременным IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
  • классическими отечественными ГОСТами 19-й системы, включающим в себя перечисленные ниже документы «описательного» характера:
    • ГОСТ 19.402-78 ЕСПД. Описание программы;
    • ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению;
    • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению;
    • ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению;
    • ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

Возможно, существуют и иные документы, но автору, основательно порывшемуся в рунетовской свалке, ничего более подходящего заполучить пока не удалось. Яндекс обнаружил в своих недрах еще одну страничку с названием «Как сделать хорошее руководство пользователя», автор которой именует себя на американЬский манер (типа 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:

Component

See subclause

Required?

Identification data (package label/title page)

4.3

Yes

Table of contents

5.7.1

Yes, in documents of more than eight pages after identification data

List of illustrations

5.7.2

Optional

Introduction

3.2

Yes

Information for use of the documentation

4.4

Yes

Concept of operations

4.5

Yes

Procedures

4.6, 4.7

Yes (instructional mode)

Information on software commands

4.8

Yes (reference mode)

Error messages and problem resolution

4.9

Yes

Glossary

4.10

Yes, if documentation contains unfamiliar terms

Related information sources

4.11

Optional

Navigational features

5.8

Yes

Index

5.7.3

Yes, if documents of more than 40 pages

Search capability

5.7.4

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.402-78, структура разделов

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

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

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

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

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

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

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

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

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

Ни ГОСТ 19.505-79, ни ГОСТ 19.504-79, ни ГОСТ 19.503-79, взятые по одельности, не могут похвастаться достаточной полнотой структуры.

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

А почему не попытаться объединить все «описательные» документы? Объединить идентичные и схожие разделы документов, выделить специфические разделы? Быть может, удастся избавиться от неполноты ГОСТ 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

*

••Формат и возможные варианты команд для выполнения функции 1

*

••Ответы программы на команды выполнения функции 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, но времени «наморщить ум» всегда не хватает, руководство пользователя, как всегда, должно было быть готово еще на прошлой неделе.

Показать связи разделов обобщенного руководства пользователя с разделами ГОСТ 19.201-78 ЕСПД. Техническое задание, требования к содержанию и оформлению автор поленился, поскольку указанные связи очевидны.

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

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

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

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

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

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

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

ГОСТ 19.ххх

IEEE Std 1063-2001

Аннотация

Introduction

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)

•Тексты сообщений, выдаваемых в ходе (настройки, проверки, выполнения) программы

аналогичный подраздел отсутствует

••Описание содержания

то же

••Описание действий, которые необходимо предпринять по этим сообщениям

»

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

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

Составление документации для пользователей имеет свои особенности, связанные с тем, что пользователь, как правило, не является профессионалом в области разработки программного обеспечения. В книге С. Дж. Гримм [17] даны рекомендации по написанию подобной программной документации:

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

излагайте ясно, используйте короткие предложения;

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

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

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

общие сведения о программном продукте;

описание установки;

описание запуска;

инструкции по работе (или описание пользовательского интерфейса);

сообщения пользователю.

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

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

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

Раздел Инструкции по работе обычно содержит описание режимов работы, форматов ввода-вывода информации и возможных настроек.

303

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

11.4. Руководство системного программиста

По ГОСТ 19.503–79 руководство системного программиста должно содержать всю информацию, необходимую для установки программного обеспечения, его настройки и проверки работоспособности. Кроме того, как указывалось выше, в него часто включают и описание необходимого обслуживания, которое раньше приводилось в руководстве оператора (ГОСТ 19.505–79) и/или руководстве по техническому обслуживанию (ГОСТ 19.508–79). В настоящее время данную схему используют для составления руководства системному администратору.

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

общие сведения о программном продукте,

структура,

настройка,

проверка,

дополнительные возможности,

сообщения системному программисту.

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

ипараметрам внешних устройств, требования к программному обеспечению и т. п.).

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

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

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

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

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

304

11.5. Основные правила оформления программной документации

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

Оформление текстового и графического материала. Текстовые документы оформляют на листах формата А4, причем графический материал допускается представлять на листах формата A3. Поля на листе определяют в соответствии с общими требованиями: левое – не менее 30, правое – не менее 10, верхнее – не менее 15, а нижнее – не менее 20 мм. В текстовых редакторах для оформления записки параметры страницы заказывают в зависимости от устройства печати. При ручном оформлении документов параметры страницы выбирают из соображений удобства.

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

Наименование разделов пишут прописными буквами в середине строки. Расстояние между заголовками и текстом, а также между заголовками раздела и подразделов должно быть равно:

при выполнении документа машинописным способом – двум интервалам;

при выполнении рукописным способом – 10 мм;

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

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

при выполнении документа машинописным способом – трем интервалам;

при выполнении рукописным способом – не менее 15 мм;

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

иметь порядковые номера 1, 2, и т. д. Номер подраздела включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделенные точкой. Например: 2.1, 3.5. Ссылки на пункты, разделы и подразделы указывают, используя порядковый номер раздела или пункта, например, «в разд. 4», «в п. 3.3.4».

305

Текст разделов печатают через 1,5-2 интервала. При использовании текстовых редакторов высота букв и цифр должна быть не менее 1,8 мм (шрифты № 11-12).

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

Оформление рисунков, схем алгоритмов, таблиц и формул. В соответствии с ГОСТ 2.105–79 «Общие требования к текстовым документам» иллюстрации (графики, схемы, диаграммы) могут быть приведены как в основном тексте, так и в приложении. Все иллюстрации именуют рисунками. Все рисунки, таблицы и формулы нумеруют арабскими цифрами последовательно (сквозная нумерация) или в пределах раздела (относительная нумерация). В приложении – в пределах приложения.

Каждый рисунок должен иметь подрисуночную подпись – название, помещаемую под рисунком, например:

Рис.12. Форма окна основного меню

На все рисунки, таблицы и формулы в записке должны быть ссылки в виде: «(рис. 12)» или «форма окна основного меню приведена на рис. 12».

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

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

Рис. 12. Продолжение

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

Схемы алгоритмов должны быть выполнены в соответствии со стандартом ЕСПД. Толщина сплошной линии при вычерчивании схем алгоритмов должна составлять от 0,6…1,5 мм. Надписи на схемах должны быть выполнены чертежным шрифтом, высота букв и цифр должна быть не менее 3,5 мм.

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

Ссылки на таблицы в тексте пояснительной записки указывают в виде слова «табл.» и номера таблицы. Например:

306

Результаты тестов приведены в табл. 4.

Номер формулы ставится с правой стороны страницы в круглых скобках на уровне формулы. Например:

Ссылка на номер формулы дается в скобках. Например: «расчет значений проводится по формуле (12)».

Оформление приложений. Каждое приложение должно начинаться с новой страницы с указанием в правом углу слова «ПРИЛОЖЕНИЕ» прописными буквами и иметь тематический заголовок. При наличии более одного приложения все они нумеруются арабскими цифрами: ПРИЛОЖЕНИЕ 1, ПРИЛОЖЕНИЕ 2 и т. д. Например:

ПРИЛОЖЕНИЕ 2

Титульный лист расчетно–пояснительной записки

Рисунки и таблицы, помещаемые в приложении, нумеруют арабскими цифрами в пределах каждого приложения с добавлением буквы «П». Например:

Рис. П. 12 – 12-й рисунок приложения; Рис. П1.2 – 2-й рисунок 1-го приложения.

Если в приложении приводится текст программы, то каждый файл оформляют как рисунок с наименованием файла и его назначением, например:

Рис. П2.4. Файл menuran.pas – программа движения курсора основного меню.

Оформление списка литературы. Список литературы должен включать все использованные источники. Сведения о книгах (монографиях, учебниках, пособиях, справочниках и т. д.) должны содержать: фамилию и инициалы автора, заглавие книги, место издания, издательство, год издания. При наличии трех и более авторов допускается указывать фамилию и инициалы только первого из них со словами «и др.». Издательство надо приводить полностью в именительном падеже: допускается сокращение названия только двух городов: Москва (М.) и Санкт–Петербург (СПб.).

Сведения о статье из периодического издания должны включать: фамилию и инициалы автора, наименование статьи, издания (журнала), серии (ес-

307

Соседние файлы в предмете Программирование

  • #
  • #
  • #

Практическая работа №13

Тема: Руководство пользователя.                                                                    

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

Теоретические
сведения.

Руководство
пользователя (
user guide или user
manual
), руководство по эксплуатациируководство
оператора
 — документ, назначение которого — предоставить людям помощь
в использовании некоторой системы. Документ входит в состав 
технической
документации
 на систему и, как правило,
подготавливается 
техническим писателем.

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

Содержание

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

·       
Аннотацию, в
которой приводится краткое изложение содержимого документа и его назначение

·       
Введение,
содержащее
ссылки на связанные документы и информацию о том, как лучше всего использовать
данное руководство

·       
Страницу
содержания

·       
Главы,
описывающие, как использовать, по крайней мере, наиболее важные функции
системы

·       
Главу, описывающую
возможные проблемы и пути их решения

·       
Часто
задаваемые вопросы
 и ответы
на них

·       
Где
ещё найти информацию по предмету, контактная информация

·       
Глоссарий и, в
больших документах, 
предметный указатель

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

Стандарты

Структура и
содержание документа Руководство пользователя автоматизированной
системы регламентированы подразделом 3.4 документа РД 50-34.698-90. Структура и
содержание документов Руководство оператора, Руководство
программиста
Руководство системного программиста регламентированы
ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

·       
Комплекс
стандартов и руководящих документов на автоматизированные системы (ГОСТ 34)

·     РД
50-34.698-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

·       
Единая система конструкторской документации (ЕСКД)
определяет документ «Руководство по эксплуатации» и другие документы:

·     ГОСТ
2.601-2013 Эксплуатационные документы

·     ГОСТ
2.610-2006 Правила выполнения эксплуатационных документов

·       
Единая
система программной документации
 (ЕСПД)
определяет документы «Руководство оператора», «Руководство по техническому обслуживанию»
и их структуру:

·     ГОСТ
19.101-77 Виды программ и программных документов

·     ГОСТ
19.105-78 Общие требования к программным документам

·     ГОСТ
19.505-79 Руководство оператора. Требования к содержанию и оформлению

·     ГОСТ
19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и
оформлению.

Руководство
пользователя согласно требованиям ГОСТ

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

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

Руководящими
стандартами для создания документа Руководство пользователя  могут
являться как 
РД
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
 Создание проекта. Для того чтобы создать Проект необходимо на панели «…»
нажать на кнопку «…» и в появившейся форме заполнить следующие поля:

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

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

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

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

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

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

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

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

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

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

Ниже представлен пример (образец)
документа
«Руководство пользователя«, разработанного на
основании методических указаний 
РД
50-34.698-90
.

Данный документ формируется
IT-специалистом, или функциональным специалистом, или техническим писателем в
ходе разработки рабочей документации на систему и её части на стадии «Рабочая
документация».

Для формирования руководства пользователя
в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической
системы «Корпоративное хранилище данных».

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

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

1.     
Введение.

2.     
Назначение и
условия применения.

3.     
Подготовка к
работе.

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

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

6.     
Рекомендации по
освоению.

1. Введение

В разделе «Введение»
указывают:

1.     
область применения;

2.     
краткое
описание возможностей;

3.     
уровень
подготовки пользователя;

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

1.1. Область применения

Требования настоящего документа
применяются при:

·  предварительных комплексных
испытаниях;

·  опытной эксплуатации;

·  приемочных испытаниях;

·  промышленной эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая
система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации
технологии принятия тактических и стратегических управленческих решений
конечными бизнес-пользователями на основе информации о всех аспектах
финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность
работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью
используется инструмент пользователя Oracle Discoverer Plus, который
предоставляет следующие возможности:

·  формирование табличных и
кросс-табличных отчетов;

·  построение различных диаграмм;

·  экспорт и импорт результатов
анализа;

·  печать результатов анализа;

·  распространение результатов
анализа.

1.3. Уровень подготовки
пользователя

Пользователь ИАС КХД должен иметь
опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet
Explorer, Oracle Discoverer, а также обладать следующими знаниями:

·  знать соответствующую предметную
область;

·  знать основы многомерного анализа;

·  понимать многомерную модель
соответствующей предметной области;

·  знать и иметь навыки работы с
аналитическими приложениями.

Квалификация пользователя должна
позволять:

·  формировать отчеты в Oracle
Discoverer Plus;

·  осуществлять анализ данных.

1.4. Перечень эксплуатационной
документации, с которой необходимо ознакомиться пользователю

·  Информационно-аналитическая
система «Корпоративное хранилище данных». ПАСПОРТ;

·  Информационно-аналитическая
система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения
Oracle Discoverer Plus

В разделе «Назначение и
условия применения» указывают:

1.     
виды
деятельности, функции, для автоматизации которых предназначено данное средство
автоматизации;

2.     
условия, при
соблюдении (выполнении, наступлении) которых обеспечивается применение средства
автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация
технических средств, операционная среда и общесистемные программные средства,
входная информация, носители данных, база данных, требования к подготовке
специалистов и т. п.).

Oracle Discoverer Plus в составе
ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по
показателям деятельности, а также для углубленного исследования данных на
основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в
составе ИАС КХД возможна всегда, когда есть необходимость в получении
информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в
составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе «Подготовка к работе»
указывают:

1.     
состав и
содержание дистрибутивного носителя данных;

2.     
порядок
загрузки данных и программ;

3.     
порядок
проверки работоспособности.

3.1. Состав и содержание
дистрибутивного носителя данных

Для работы с ИАС КХД необходимо
следующее программное обеспечение:

1.     
Internet
Explorer (входит в состав операционной системы Windows);

2.     
Oracle
JInitiator устанавливается автоматически при первом обращении пользователя к
ИАС КХД.

3.2. Порядок загрузки данных и
программ

Перед началом работы с ИАС КХД на
рабочем месте пользователя необходимо выполнить следующие действия:

1.     
Необходимо
зайти на сайт ИАС КХД ias-dwh.ru.

2.     
Во время
загрузки в появившемся окне «Предупреждение о безопасности», которое
будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator»
…’ Нажимаем на кнопку «Да».

3.     
После чего
запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next
и затем OK.

3.3. Порядок проверки
работоспособности

Для проверки доступности ИАС КХД с
рабочего места пользователя необходимо выполнить следующие действия:

1.     
Открыть
Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer»
на рабочем столе или вызвать из меню «Пуск».

2.     
Ввести в
адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».

3.     
В форме аутентификации
ввести пользовательский логин и пароль. Нажать кнопку «Далее».

4.     
Убедиться, что
в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle
Discoverer Plus не запускается, то следует обратиться в службу поддержки.

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

В разделе «Описание
операций» указывают:

1.     
описание всех
выполняемых функций, задач, комплексов задач, процедур;

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

Для каждой операции обработки
данных указывают:

1.     
наименование;

2.     
условия, при
соблюдении которых возможно выполнение операции;

3.     
подготовительные
действия;

4.     
основные
действия в требуемой последовательности;

5.     
заключительные
действия;

6.     
ресурсы, расходуемые
на операцию.

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

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе
ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

Функции

Задачи

Описание

Обеспечивает многомерный
анализа в табличной и графической формах

Визуализация отчетности

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

Формирование табличных и
графических форм отчетности

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

4.2. Описание операций
технологического процесса обработки данных, необходимых для выполнения задач

Ниже приведено описание
пользовательских операций для выполнения каждой из задач.

Задача:
«Визуализация отчетности»

Операция 1: Регистрация на портале
ИАС КХД

Условия,
при соблюдении которых возможно выполнение операции:

1.     
Компьютер
пользователя подключен к корпоративной сети.

2.     
Портал ИАС КХД
доступен.

3.     
ИАС КХД
функционирует в штатном режиме.

Подготовительные
действия:

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

Основные
действия в требуемой последовательности:

1.     
На иконке «ИАС
КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.

2.     
В открывшемся
окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя.
Нажать кнопку «Далее».

Заключительные
действия:

Не требуются.

Ресурсы,
расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия,
при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале
ИАС КХД.

Подготовительные
действия:

Не требуются.

Основные
действия в требуемой последовательности:

1. В появившемся окне «Мастер
создания рабочих книг» поставить точку напротив пункта «Открыть существующую
рабочую книгу».

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle Discoverer2. Выбрать нужную рабочую книгу и
нажать кнопку «Откр.»:

РД 50-34.698-90 Руководство пользователя (пример формирования). Oracle DiscovererЗаключительные действия:

После завершения работы с отчетом
необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы,
расходуемые на операцию:

15 секунд.

Задача:
«Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

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

В разделе «Аварийные
ситуации» указывают: 1. действия в случае несоблюдения условий выполнения
технологического процесса, в том числе при длительных отказах технических
средств; 2. действия по восстановлению программ и/или данных при отказе
магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях
обнаружении несанкционированного вмешательства в данные; 4. действия в других
аварийных ситуациях.

В случае возникновения ошибок при
работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к
сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к
ответственному Администратору ИАС КХД.

Класс ошибки

Ошибка

Описание ошибки

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

Портал ИАС КХД

Сервер не найден.
Невозможно отобразить страницу

Возможны проблемы с
сетью или с доступом к порталу ИАС КХД.

Для устранения проблем с
сетью обратиться к сотруднику подразделения технической поддержки
(HelpDesk). В других случаях к администратору ИАС КХД.

Ошибка: Требуется ввести
действительное имя пользователя

При регистрации на
портале ИАС КХД не введено имя пользователя.

Ввести имя пользователя.

Ошибка: Требуется ввести
пароль для регистрации

При регистрации на
портале ИАС КХД не введен пароль.

Ввести пароль.

Ошибка: Сбой
аутентификации. Повторите попытку

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

Нужно повторить ввод
имени пользователя и пароля, однако после третей неудачной попытки
регистрации учетная запись блокируется. Если учетная запись
заблокирована, нужно обратиться к администратору ИАС КХД.

Сбой в электропитании
рабочей станции

Нет электропитания
рабочей станции или произошел сбой в электропитании.

Рабочая станция
выключилась или перезагрузилась.

Перезагрузить рабочую
станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие
команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
Повторить попытку подключения (входа) в ИАС КХД

Сбой локальной сети

Нет сетевого
взаимодействия между рабочей станцией и сервером приложений ИАС КХД

Отсутствует возможность
начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС
КХД

Перезагрузить рабочую
станцию.
Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие
команды:
— нажать кнопку «Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать команду telnet ias_dwh.ru 80
— если открылось окно Telnet, значит соединение возможно.
После восстановления работы локальной сети повторить попытку подключения
(входа) в ИАС КХД.

6. Рекомендации по освоению

В разделе «Рекомендации по
освоению» указывают рекомендации по освоению и эксплуатации, включая
описание контрольного примера, правила его запуска и выполнения.

Рекомендуемая литература:

·  Oracle® Business Intelligence Discoverer
Viewer User’s Guide

·  Oracle® Business Intelligence Discoverer
Plus User’s Guide

Рекомендуемые курсы обучения:

·  Discoverer 10g: Создание запросов
и отчетов

В качестве контрольного примера
рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в
п. 4.2. настоящего документа.

Ход
работы:

Задание 1.
Изучите
свой вариант руководства пользователя. Опишите его по следующему плану:

1) для
какого продукта, предназначено руководство пользователя (наименование, модель);

2)
основные технические характеристики продукта;

3)
основные разделы руководства пользователя (название раздела и краткое его
описание)

Задание 2.
Откройте 
документ «Образец руководства пользователя», заполните в нем первые разделы для
своего вымышленного программного продукта.

Сделайте
вывод

о проделанной работе.

Контрольные
вопросы:

1) Дайте
определения понятиям «руководство пользователя», «инструкция по эксплуатации»

2) Какие
основные разделы должно содержать руководство пользователя?

3) Какие
стандарты описывают Руководство пользователя Руководство оператора, Руководство
программиста, Руководство системного программиста?

4) Что
описывает раздел «назначение системы»?

5) Что
указывается в разделе «условия применения системы»?

6) Какая
информация содержится в разделе «Описание операций»?

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

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

2. Руководство пользователя экономит время и силы техподдержки.

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

А теперь к советам!

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

Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

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

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

Структура руководства пользователя

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

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

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

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

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

В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.

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

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

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

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

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

1. Понятность.

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

2. Наглядность.

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

3. Видео.

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

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

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

Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.

И напоследок, переведите пользовательскую документацию в формат PDF, чтобы клиенты могли скачать и распечатать руководство.

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

Инструменты

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

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

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

Импортируйте в программу заранее написанные фрагменты документации.

Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!

Какой можно сделать вывод

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

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

Работая с Dr.Explain, можно быстро написать пользовательскую документацию, которая будет помогать клиентам разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

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

Время на прочтение
8 мин

Количество просмотров 2.1K

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

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

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

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

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

Хочешь, чтобы никто не нашел, назови не думая

Название инструкции — это не название статьи в интернете. Ему не надо привлекать внимание и вызывать какие-то эмоции. Пользователь по названию должен понять, какая процедура описана в инструкции. Инструкцию надо называть так, чтобы её было несложно найти в интернете. Давайте более подробно разберёмся с этим.

Название инструкции не должно вызывать эмоции

Я использую два вида названий:

  • название-проблема;
  • название-процесс.

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

Что такое «название-процесс»

Цель инструкции с таким названием — объяснить какой-то процесс.

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

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

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

Пример названия-процесса: «Работа с программой Рутокен Диск».

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

Его поисковый запрос: “как сохранить файл в защищённом разделе” или “как работать с Рутокен Диском”.

Он открывает инструкцию, выбирает свою операционную систему и раздел с названием “Работа с защищённым разделом”. Такой поиск у него займёт несколько секунд. Дальше он выполнит все действия этой процедуры и поймёт процесс.

Ещё один пример названия-процесса: «Работа с Рутокен через КриптоПро CSP в macOS”.

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

Его поисковый запрос: “Рутокен КриптоПро macOS”.

Он открывает инструкцию и выполняет последовательно все шаги из неё.

Пример плохого названия инструкции: “Инструкция по форматированию Рутокена и установке нового PIN-кода для клиентов, переходящих с системы ДБО”.

Ситуация, когда будут искать эту инструкцию: пользователю необходимо отформатировать токен перед тем как использовать его в другой системе или ему просто надо сменить PIN-код.

Мне это название не нравится по трём причинам:

  • Оно слишком длинное.
  • В нём фигурирует две процедуры: форматирование токена и смена PIN-кода.
  • Название сформулировано не так, как его будет искать пользователь.

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

Плохое название может привести к финансовым потерям

Сейчас по запросу “как изменить PIN-код Рутокена” пользователь найдёт нашу инструкцию.

Что такое «название-проблема»

Цель инструкции с таким названием — помочь решить проблему.

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

Поисковый запрос может начинаться со слов “что делать, если” или “отобразилась ошибка”. Здесь пользователю надо максимально быстро получить ответ.

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

Пример такого названия: Недоступна смарт-карта Рутокен.

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

Его поисковый запрос: “токены или смарт-карты недоступны”. Он описывает проблему так, как она сформулирована в окне с ошибкой.

Он находит эту инструкцию и выполняет необходимые действия в системе.

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

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

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

Его поисковый запрос будет таким: “что делать, если PIN-код Пользователя заблокирован”.

Он откроет эту инструкцию, найдёт нужный раздел и разблокирует PIN-код.

Пример плохого названия инструкции: Рутокен вставлен, но красный диод не горит. Что делать?

Что мне не нравится в этом названии:

  • Оно слишком длинное, в нём указаны лишние подробности, а именно то, что Рутокен вставлен. За счёт этого можно было сократить название.
  • Я бы заменила слово “диод”, не каждый пользователь его знает.

Давайте сделаем общие выводы:

  1. Прежде чем придумывать название для инструкции необходимо понять — для кого эта инструкция и в какой ситуации пользователь будет её искать.
  2. При составлении названий используйте слова из мира пользователей.
  3. Подумайте о том, какой запрос пользователь введёт, когда будет искать инструкцию.
  4. Перед публикацией инструкции ещё раз прочитайте название и подумайте, может быть вы указали какие-то лишние подробности.

Хочешь, чтобы никто не нашёл, забудь про навигацию

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

Содержание как карта

Главное требования к содержанию инструкции — оно должно быть логичным.
Цель содержания, как и у любой карты — ускорить процесс поиска. Помочь пользователю быстро найти нужный раздел. Да, кто-то скажет, что в инструкции всегда можно воспользоваться внутренним поиском, нажав Ctrl+F, но это не всегда удобно. Если страниц в инструкции много, то внутренний поиск может только запутать пользователя.

Содержание должно быть логичным

Здесь тоже не обойтись без примеров. Давайте посмотрим на навигацию в одной из моих инструкций.

Самый простой случай, когда описана программа, которая работает в одной операционной системе. В нашем случае это программа Рутокен Логон. Посмотрим на то, как устроена навигация в инструкции для неё.

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

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

Установка -> Запуск -> Настройка -> Процесс работы -> Удаление

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

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

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

Такая последовательность изложения выглядит так:

Выбор операционной системы -> Запуск -> Настройка -> Процесс работы -> Удаление

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

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

У пользователя полминуты на то, чтобы найти нужный раздел

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

Вот пример такой инструкции. Она написана для пользователей Рутокен U2F.

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

Содержание может всё испортить

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

Последний пример в этой статье как раз будет про это. Инструкция о том, как удалить сертификат. В самом её начале я объясняю пользователю, что прежде чем удалить сертификат, надо определить криптопровайдера или формат сертификата и записать имя контейнера. Это важно, так как можно удалить не тот сертификат, а вернуть его будет уже невозможно.

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

Давайте сделаем общие выводы:

  1. При составлении содержания учитывайте логику взаимодействия пользователя с тем, что вы описываете.
  2. Если пользователь пропустил содержание, то ему может помочь навигация в разделе.
  3. Если пропускать шаги в инструкции нельзя, то навигация не нужна.

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

Требования к структуре руководства пользователя по ГОСТ 34 устанавливаются РД 50-34.698-90. В общем случае документ должен состоять из следующих разделов:

1 Введение
1.1 Область применения
1.2 Краткое описание возможностей
1.3 Уровень подготовки пользователя
1.4 Перечень эксплуатационной документации, с которыми необходимо ознакомиться пользователю
2 Назначение и условия применения
2.1 Виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации
2.2 Условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.)
3 Подготовка к работе
3.1 Состав и содержание дистрибутивного носителя данных
3.2 Порядок загрузки данных и программ
3.3 Порядок проверки работоспособности
4 Описание операций
4.1 Описание всех выполняемых функций, задач, комплексов задач, процедур
4.2 Описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур
4.2.1 Наименование операции
4.2.2 Условия, при соблюдении которых возможно выполнение операции
4.2.3 Подготовительные действия
4.2.4 Основные действия в требуемой последовательности
4.2.5 Заключительные действия
4.2.6 Ресурсы, расходуемые на операцию
5 Аварийные ситуации
5.1 Действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств
5.2 Действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных
5.3 Действия в случаях обнаружении несанкционированного вмешательства в данные
5.4 Действия в других аварийных ситуациях
6 Рекомендации к освоению

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

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

Примечание

Эти и другие требования к структуре и содержанию руководства пользователя по ГОСТ 34 подробнее см. РД 50-34.698-90

Документ выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД).

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

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

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

Примечание

Эти и другие требования по оформлению руководства пользователя по ГОСТ 34 подробнее см. ГОСТ 2.105-95

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

Журавлев Денис

Что такое руководство пользователя и для чего его создавать

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

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

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

Общие советы по созданию пользовательской документации

Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.

После этого важно подумать о том:

  • Где пользователь будет к нему обращаться: дома, на работе, в машине?
  • Как часто он будет его просматривать?
  • Насколько объективно сложен для понимания продукт?

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

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

Структура руководства пользователя

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

В первом разделе желательно рассказать общую информацию о программе:

  • Для чего создан продукт.
  • Какие задачи он решает.
  • Какие основные выгоды от использования для клиента.

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

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

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

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

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

Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.

Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.

Видео-обзор основных возможностей программы Dr.Explain

Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.

Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.  

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

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

Структура разделов руководства пользователя

У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.

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

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

Создание руководства пользователя по ГОСТ 34 и ГОСТ 19

Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.

Аннотирование скриншотов пользовательского интерфейса в руководстве пользователя

Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами.  По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.  

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

Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.

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

Павел Свиридов

Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»

«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.

Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».


Руководство пользователя к программе Вега Матрица

Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке


Наталья Обухова

Наталья Обухова, бизнес-аналитик компании CRM Expert

«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.

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

Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.

Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».

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

Прочитать полный кейс компании CRM Expert


Николай Вальковец

Николай Вальковец, разработчик компании 2V

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

Руководство к программе 2V Стоматология

Прочитать кейс компании V2  


Подытожим

Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.

Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/

Успешных вам разработок!

Смотрите также

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

Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?

Руководство пользователя

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

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

Состав типового руководства пользователя

Конкретный подход к написанию определяется многими факторами:

– назначением программы и областью ее применения;

– сложностью программы;

– количеством разнообразных вариантов использования.

Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:

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

– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;

– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;

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

– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;

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

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

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

Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.

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

Наименование документа

Наименование стандарта

Стоимость разработки

РП на автоматизированную систему

РД 50-34.698

70 тыс. р.

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

Возможно, вас также заинтересует:

– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.


На чтение 10 мин Просмотров 1.1к. Опубликовано 30.10.2021

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

Зачем писать практические руководства?

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

Например, посчитайте, сколько людей каждый день ищут в Google «Как [любое слово]»:

Как написать подробное руководство

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

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

Достаточно сказать: практические руководства стоит добавить в ваш арсенал контента.

Как сделать практическое руководство

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

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

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

  • Проведите исследование ключевых слов, чтобы узнать, что люди хотят узнать.
  • Используйте Ahrefs, SEMrush или любой другой инструмент SEO для определения похожих ключевых слов и запросов. Это может помочь вам создать всестороннюю статью, которая ответит на все вопросы ваших читателей и поможет вам получить рейтинг в Google.
  • Посмотрите на своих конкурентов, чтобы увидеть, как они пишут свои руководства.

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

Понять проблемы и проблемы вашей целевой аудитории.

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

Например, если вы пишете «Как создать стратегию контент-маркетинга», вы можете выполнить следующие действия:

  • Начните с ответов на вопрос «Что такое контент-маркетинг?» На Яндекс.Кью, например. Эти пользовательские ответы могут помочь вам определить общие темы, заблуждения или путаницу в контент-маркетинге.
  • Обратитесь к своей исследовательской маркетинговой группе, чтобы определить общие болевые точки или вопросы, которые они видели в опросах или фокус-группах относительно «контент-маркетинга». Например, вы можете обнаружить, что большая часть вашей аудитории считает контент-маркетинг для них приоритетом, но они не знают, как это сделать в рамках бюджета.
  • Проведение подобного качественного исследования предоставит вам информацию, необходимую для того, чтобы в вашем практическом руководстве были рассмотрены все актуальные проблемы по данной теме.

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

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

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

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

Расскажите читателю, почему это важно.

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

Как написать практическое руководство

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

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

Существует огромная разница между читателями, которые ищут «Что такое запрос предложения?», И теми, кто ищет «Как написать запрос предложения?».

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

При написании практического руководства следует помнить о некоторых методах:

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

Практические руководства часто привлекают широкий круг читателей, каждый с разным уровнем знаний.

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

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

Есть ли разница в том, как вы пишете руководство пользователя и практическое руководство?

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

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

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

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

Примеры практического руководства

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

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

  2. Практическое руководство для B2B.В статье Atlassian «Как написать идеальный 90-дневный план» приведены важные контекстные детали для 90-дневного плана, в том числе «Что такое 90-дневный план?» и «Что должно быть включено в 90-дневный план?» Публикация хорошо проработана и написана с сочувствием.Лучше всего то, что в руководстве есть загружаемый PDF-файл с 90-дневным планом, так что читатели могут сразу загрузить и использовать план Atlassian со своей командой.

    Вывод: подумайте, какие электронные книги, PDF-файлы, диаграммы, дизайны Canva или Google Таблицы вы можете создать самостоятельно и предложить читателям для загрузки. Читатели оценят возможность немедленно применить то, что они узнали.

  3. Практическое руководство для B2C.Руководство «Как стать фрилансером» от FlexJobs отлично справляется с предоставлением соответствующих ссылок и данных для создания всестороннего обзора того, что такое фриланс. Кроме того, в сообщении используются глаголы действия, чтобы вдохновить читателя.В разделе «Как начать внештатный бизнес». вы увидите такие советы, как «Делайте домашнее задание», «Создайте бренд» и «Планируйте заранее». Язык, использованный в этом посте, во многом побуждает читателей немедленно приступить к работе.

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

  4. Практическое руководство по продукту.Статья How-To Geek под названием «Как найти данные в Google Таблицах с помощью ВПР» не обязательно является самой интересной темой. Тем не менее, бренд эффективно поддерживает интерес к контенту с помощью чутких заявлений вроде: «ВПР может показаться запутанным, но это довольно просто, если вы поймете, как это работает».Кроме того, How-To Geek включает полезные оригинальные изображения, демонстрирующие каждый совет, который они описывают. Эти изображения не обязательно должны быть ультрасовременными визуальными эффектами, созданными профессиональной командой дизайнеров — как показывает этот пост, несколько простых снимков экрана имеют большое значение для того, чтобы помочь читателям понять сложную тему.

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

  5. Практическое руководство по образу жизни.Еще один пример — пост на Medium под названием «11 способов быстро избавиться от стресса в вашей жизни». Ожидается, что в ней будет нескольких простых и быстрых советов, как избавиться от стресса. Но первый раздел поста — «Влияние стресса на вашу жизнь». В этом случае важно, чтобы читатели понимали, почему, а не как .

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

Шаблон для написания практического руководства можно получить как гуглдок здесь. Чтобы сохранить к себе, нажмите Файл -> Создать копию. Там же шаблоны и других материалов для блога.

Статья является адаптированным переводом https://blog.hubspot.com/marketing/how-to-guide.

Читайте также:

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

Photo by James McKinven on Unsplash.

Понравилась статья? Поделить с друзьями:
  • Должностная инструкция помощник технолога на производстве
  • Брелок сигнализации старлайн мануал
  • Биотуалет кампа потти инструкция по применению видео
  • Пентовит витамины для чего принимают женщины отзывы инструкция по применению
  • Книга руководство гипертоника