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

Расширенный поиск

• Войти
  • Логин:

  • Пароль

  Регистрация
  Забыли пароль?

Всего найдено: 7

Здравствуйте! Прошу аргументированного, с точки зрения грамотного присвоения наименования документу, разъяснения. Составляю инструкцию для оператора пункта приёма заявлений, которая будет утверждена приказом руководителя организации. Как правильно сформулировать название документа, «Инструкция оператору пункта выдачи» или «Инструкция оператора пункта выдачи»? Заранее благодарю!

Ответ справочной службы русского языка

В ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» зафиксирован пример заголовка для инструкции с формой родительного падежа без предлога: Должностная инструкция ведущего эксперта. И эта модель является широко распространенной в делопроизводстве.

«Словарь грамматической сочетаемости слов русского языка» Е. М. Лазуткиной (М., 2012) указывает на возможные варианты управления: инструкция для кого (чаще) и инструкция кому. Эта рекомендация, по-видимому, обусловлена тем, что конструкция с родительным падежом без предлога в некоторых контекстах двусмысленна: ее можно понять и как «инструкция, адресованная кому-то», и как «инструкция, составленная кем-то».

Будьте любезны. Подскажите правильность написаниязаголовка документа: «Инструкция пользователя или инструкция пользователю»

Ответ справочной службы русского языка

В ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» зафиксирован пример заголовка для инструкции с формой родительного падежа без предлога: Должностная инструкция ведущего эксперта. И эта модель является широко распространенной в делопроизводстве.

«Словарь грамматической сочетаемости слов русского языка» Е. М. Лазуткиной (М., 2012) указывает на возможные варианты управления: инструкция для кого (чаще) и инструкция кому. Эта рекомендация, по-видимому, обусловлена тем, что конструкция с родительным падежом без предлога в некоторых контекстах двусмысленна: ее можно понять и как «инструкция, адресованная кому-то», и как «инструкция, составленная кем-то».

Как правильно согласовать слова:
— должностная инструкция для менеджера,
— должностная инструкция менеджеру
— должностная инструкция менеджера

Ответ справочной службы русского языка

В ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» зафиксирован пример заголовка для инструкции с формой родительного падежа без предлога: Должностная инструкция ведущего эксперта. И эта модель является широко распространенной в делопроизводстве.

«Словарь грамматической сочетаемости слов русского языка» Е. М. Лазуткиной (М., 2012) указывает на возможные варианты управления: инструкция для кого (чаще) и инструкция кому. Эта рекомендация, по-видимому, обусловлена тем, что конструкция с родительным падежом без предлога в некоторых контекстах двусмысленна: ее можно понять и как «инструкция, адресованная кому-то», и как «инструкция, составленная кем-то».

Как правильно: инструкция кладовщиКУ или инструкция кладовщиКА, согласно Указа или Указу?

Ответ справочной службы русского языка

Корректно: инструкция для кладовщика, инструкция кладовщику; согласно указу.

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

Ответ справочной службы русского языка

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

Как правильно: «инструкция для…» или «инструкция по…»?

Ответ справочной службы русского языка

Выбор зависит от контекста.

Скажите, пожалуйста, как правильно: «инструкция методисту» или «инструкция методиста», если она пишется ДЛЯ методиста. Заранее спасибо за ответ.

Ответ справочной службы русского языка

В ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» зафиксирован пример заголовка для инструкции с формой родительного падежа без предлога: Должностная инструкция ведущего эксперта. И эта модель является широко распространенной в делопроизводстве.

«Словарь грамматической сочетаемости слов русского языка» Е. М. Лазуткиной (М., 2012) указывает на возможные варианты управления: инструкция для кого (чаще) и инструкция кому. Эта рекомендация, по-видимому, обусловлена тем, что конструкция с родительным падежом без предлога в некоторых контекстах двусмысленна: ее можно понять и как «инструкция, адресованная кому-то», и как «инструкция, составленная кем-то».

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

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 можно ознакомиться здесь:

From Wikipedia, the free encyclopedia

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

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

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

Contents of a user manual[edit]

The sections of a user manual often include:

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

History[edit]

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

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

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

Computer software manuals and guides[edit]

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

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

See also[edit]

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

References[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ветвления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•  Поставщик,

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

•  Договор,

•  Склад.

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

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

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

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

Скриншоты 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Была ли эта статья полезной?

Значение словосочетания «руководство пользователя»