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

Одним из важных этапов на проекте внедрения 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. Соблюдение регламента контролируется. 

Кто должен писать документацию?

Собственно subj…

А если подробнее… Большие начальники решили пригрузить всех программистов в банке, где я работаю, и заставить их сделать краткое описание каждой программы + инструкцию пользователя. Кто как считает, должен ли программист писать инструкцию к программе, которую он написал, или этим должен заниматься кто-то другой? На западе, напр. этим занимается technical writer. Причем этот человек пишет вообще всю документацию, не только на программы (насколько я знаю).

Re: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Собственно subj…

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

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

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

В нормальном проекте такие вещи (кто, когда и какие документы пишет)
должны оговариваться на этапе планирования, но это похоже не твой случай.

Re: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Собственно subj…

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

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

… << RSDN@Home 1.0 beta 4 >>

Re[2]: Кто должен писать документацию?

Здравствуйте, bkat, Вы писали:

B>В целом ты конечно прав. Руководство для пользователей действительно
B>должны писать профессионалы (технические писатели).
B>Только вряд ли этот факт поможет тебе в борьбе с начальством.

Я бороться не собираюсь. Сказали писать — буду писать. Просто свою основную работу делать не буду

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

Я когда-то (года два назад) говорил с одним американцем, который в то время учился в колледже как раз по специальности technical writer. Ну и в общении с ним сделал такой вывод, что даже в том случае, если в фирме нет программистов, тех. документацию пишут как раз technical writers. И он очень долго не мог понять, что я таких очевидных вещей не понимаю, и что у нас такой специальности вообще нет. Он для этого в колледже 6 лет должен проучиться…

B>Чтобы действительно ответить на твой вопрос, по хорошему нужно определить,
B>что такое документация в твоем проекте.

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

B>В нормальном проекте такие вещи (кто, когда и какие документы пишет)
B>должны оговариваться на этапе планирования, но это похоже не твой случай.

Это не мой случай, поскольку у нас долгое время было принято, что программист не только пишет программы, но и делает постановку задачи и объясняет тупому юзеру, как он должен работать (не только какие кнопки нажимать, а именно ЧТО он должен делать).
А сейчас новый руководитель банка хочет все это как-то систематизировать.

Re[2]: Кто должен писать документацию?

Здравствуйте, XMbIPb, Вы писали:

XMI>В любом случае, тех. документацию должен писать программер.
XMI>Такую доку. надо иметь в первую очередь. И с не писателями
XMI>тех. доки. надо бороться, если надо, то и увольнять.

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

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

Re[3]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Я когда-то (года два назад) говорил с одним американцем, который в то время учился в колледже как раз по специальности technical writer. Ну и в общении с ним сделал такой вывод, что даже в том случае, если в фирме нет программистов, тех. документацию пишут как раз technical writers. И он очень долго не мог понять, что я таких очевидных вещей не понимаю, и что у нас такой специальности вообще нет. Он для этого в колледже 6 лет должен проучиться…

Похоже что есть проблема с понятиями «техническая документация» и «технический писатель».
Я могу сразу навскидку назвать несколько документов, которые на мой взляд (могу и заблуждаться )
являются техническими, но технический писатель врядли будет ими заниматься.
Например всевозможные планы (планы тестирования, СМ планы и прочее)
врядли имеет смысл поручать техническому писателю.
Спецификации системы, на мой взгляд, должен писать
именно разработчик (причем очень нехилой квалификации).
Дизайн системы, которые включает всевозможные диаграмы и схемы, — это тоже задача разработчика.

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

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

Re[4]: Кто должен писать документацию?

Здравствуйте, bkat, Вы писали:

B>Твой вопрос все же больше связан с планированием, в которое включается
B>определение ролей на проекте, исполнители, задачи, сроки выполнения задач и еще много чего…

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

Re[3]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

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

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

Re[5]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Нет, ты не так понял (или я не так объяснил). Нужно в первую очередь написать именно инструкции пользователя, причем на уже имеющиеся задачи.
E>А уже позже заставят описывать внутренности программ, для того, чтоб программистов можно было увольнять безбоязненно.

Скорей всего я понял тебе верно. Я рассуждаю теоретически.
А в твоем конкретном случае будет так, как скажет/сказал начальник

Re[4]: Кто должен писать документацию?

Здравствуйте, bkat, Вы писали:

B>Можешь на меня обижаться, но мудрый начальник увольняет таких людей при первом же подозрении

Ты случайно не начальник?

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

Re[3]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Это нужно для того, чтобы когда меня уволят, на моем месте легко справился бы другой программист.

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

E>Естественно, я не могу приветствовать это двумя руками.
Почему ? Ведь это вполне законное желание заказчика.
Исходники принадлежат работадателю (если отдельно не оговорено).
И заказчик диктует свои условия в данном случае.

… << RSDN@Home 1.0 beta 4 >>

Re[6]: Кто должен писать документацию?

Здравствуйте, bkat, Вы писали:

Спасибо тебе за быстрые ответы — я не успеваю новые вопросы печатать

B>Скорей всего я понял тебе верно. Я рассуждаю теоретически.
B>А в твоем конкретном случае будет так, как скажет/сказал начальник

Это я и сам понимаю. Мне только хотелось узнать, как это делается в других конторах, желательно в банках.

Re[7]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

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

… << RSDN@Home 1.0 beta 4 >>

Re[5]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Ты случайно не начальник?

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

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

Re[6]: Кто должен писать документацию?

Здравствуйте, bkat, Вы писали:

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

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

Re[4]: Кто должен писать документацию?

Здравствуйте, XMbIPb, Вы писали:

XMI>Еще это нужно, чтобы пользователи не бегали с вопросами к программеру: «А откуда эти цифры ???!!!» и вместо того, что бы мучительно долго вспоминать, что же там такого на самом деле, просто взять и ткнуть фейсом в бумаги.

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

E>>Естественно, я не могу приветствовать это двумя руками.
XMI>Почему ? Ведь это вполне законное желание заказчика.

Я на этот вопрос попытался уже ответить. См. мой сегодняшний ответ bkat.

XMI>Исходники принадлежат работадателю (если отдельно не оговорено).

У нас в Украине все наоборот. Если дополнительно не оговорено в контракте, исходники и все права принадлежат автору. Такие у нас законы.

XMI>И заказчик диктует свои условия в данном случае.

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

Re[5]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>У нас в Украине все наоборот. Если дополнительно не оговорено в контракте, исходники и все права принадлежат автору. Такие у нас законы.

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

Re[6]: Кто должен писать документацию?

Здравствуйте, kong, Вы писали:

E>>У нас в Украине все наоборот. Если дополнительно не оговорено в контракте, исходники и все права принадлежат автору. Такие у нас законы.
K> Я тоже работаю программистом в банке и тоже на Украине.

В каком банке, если не секрет?

K> Когда меня брали на работу я подписывал трудовое соглашение, в нем оговорено, что все что я сделаю во время работы принадлежит банку. Так что посмотри свое трудовое соглашение, у тебя скорее все тоже так.

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

K> А на счет документации тут ты не совсем прав. Я, например, пишу довольно сложную систему управления корпоративной сетью, которая состоит из большого числа модулей, помнить структуру каждого модуля я просто не в состоянии, поэтому сначала чисто для себя, а потом уже и для заказчика, я пишу документацию на структуру программы.

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

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

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

Re[7]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>Здравствуйте, kong, Вы писали:

E>В каком банке, если не секрет?

В Донецком региональном управлении ПриватБанка

E>Возможно у вас больше порядка, чем у нас. У нас долгое время каждый разработчик сам придумывал, что ему делать, сам выбирал язык программирования, сам делал себе постановку задачи и т.д. Исполнители (те, кто пользуется программами) в большинстве случаев имеют настолько низкую квалификацию, что программистам приходится объяснять не только то, как пользоваться программой, а и то, ЧТО ВООБЩЕ должен делать исполнитель. Даже базовые понятия приходится объяснять, напр. что такое ОКПО или ключ в счете и т.д.

Ну бардак у нас тоже знатный. Просто я работаю в отделе корпоративной сети и пишу программный комплекс для внутренних нужд (шеф хочет в перспективе получить нечто похожее на HP Open View ), поэтому у меня будут пользователи достаточно высокой квалификаци, а гланое понимающие что они хотят получить от программы.
Те кто пишет программы непосредственно для банковских нужд действительно вешаются, потому как наши работники зачастую имеют «очень» высокую квалификацию (правда сейчас у нас при приеме на работы ввели экзамен по начальным знаниям компьютера, так что хотя бы объяснять что такое мышь и виндоус уже не надо). Но у нас в банке есть такая практика: в основном все ПО пишется в головном банке, а в каждом подразделении есть несколько программистов, в задачу которых входит сопровождение программы на местах и борьба с пользователями. Так что разработчику в основном заниматься сексом с конкретными пользователями не приходиться, надо только объяснить все одному человеку (программисту подразделения), в се остальное это уже не его дело.

Re[7]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

E>……….. Другое дело, что мне совершенно не интересны эти продукты.

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

… << RSDN@Home 1.0 beta 6a >>

Re[7]: Кто должен писать документацию?

Здравствуйте, econt, Вы писали:

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

В соответствии с Российским законодательством:

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

Есть разница между имущественным и авторским правом.

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

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

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

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

 1. Стандарты

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

• 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 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

Также может оказаться полезной книга Юрия Кагарлицкого MetaGuide. Руководство для разработчиков технической документации к программному обеспечению.

2. Структура

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

Хорошее руководство пользователя должно содержать:

• Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение. Также рекомендуется писать краткую аннотацию в начале каждого крупного раздела.
• Введение, содержащее информацию о том, как лучше всего использовать данное руководство
• Содержание
• Главы, описывающие, как использовать ПО
• Глоссарий и
• Предметный указатель

Также руководство пользователя может содержать:

• FAQ и ответы на них
• Ссылки на дополнительную информацию по системе
• Раздел, описывающий возможные проблемы и пути их решения

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

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:

1. Click the Create button on toolbar.
2. On the Create Project overlay fill in all mandatory fields.
3. Click the Save button to save the project.

Хуже: To create project click the Create button on toolbar, on the Create Project overlay fill in all mandatory fields, click the Save button to save the project.

4.4 Не используйте будущее или прошлое время.  Например, часто встречаются руководства, в которых реакция системы на действие пользователя передается фразами, сформулированными в будущем времени. У ПО нет прошлого или будущего: всё случается в настоящем как прямой результат конкретного действия пользователя. Как только событие случается, ПО реагирует.

Хорошо: When user clicks the Start button, the program starts the process.

Хуже: When user clicks the Start button, the program will start the process.

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

Например, глагол «press» означает нажатие клавиши на клавиатуре, а «click» – нажатие кнопки или значка в окне программы при помощи мыши, а «hit» вообще является жаргонным словом.

Разумеется, орфографические ошибки недопустимы.

4.6 Не используйте синонимы для одного и того же термина. В IT литературе на английском (или любом другом) языке есть стандартный набор глаголов, обозначающих действия (click, double-click, select, type, press и т.д.) и такой же стандартный набор названий элементов управления. Определитесь с терминологией и придерживайтесь ее в рамках всего документа.

Например, не допускайте, чтобы в одной части документа выпадающий список назывался dropdown, а в другой точно такой же элемент – combobox или dropdown list. Это путает пользователя.

4.7 Разумно используйте сокращения и исключите жаргон.

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

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

5. Внешний вид

5.1 Продумайте стиль документа. Это может быть корпоративный шаблон или цветовая схема ПО или специально сделанный для документа дизайн.

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

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

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

6. Поддержка

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

Заключение

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

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

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

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

аналитик с 6-летним опытом в сфере.

Практическая работа №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 «Руководство оператора. Требования к содержанию и оформлению». Ниже для
сравнения приведены структуры документа согласно двум перечисленным стандартам.

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

15 секунд.

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

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

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

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

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

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. Произошла «глобальная» проблема: ошибка при работе с документами влечет нежелательные последствия для организации и ее первого лица (репутационные, финансовые и так далее).

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

Часто сотрудники подразделений пытаются оправдать собственные недоработки и переложить ответственность за те или иные нарушения на плечи секретаря (Схема 1).

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

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

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

Стандарты для управления документами 

Результаты работы организации зависят от системы управления, а создание документов и управление ими – неотъемлемая часть любого делового процесса организации. Персонал, работающий с документами, должен быть квалифицированным, знать свои обязанности и понимать ответственность за их недобросовестное выполнение. Об этом написано в международных стандартах, содержащих требования к системам менеджмента (например, в часто внедряемом на российских предприятиях ГОСТ Р ИСО 9001-2015 «Системы менеджмента качества. Требования»). Не секрет, что в нашей стране принятие принципов, зафиксированных в этих стандартах, дается непросто – многие воспринимают их как изложенную непростым языком теорию, не имеющую ничего общего с действительностью. Но положения этих документов на самом деле очень полезны.

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

1. ГОСТ Р ИСО 15489-1-2019 «Система стандартов по информации, библиотечному и издательскому делу. Информация и документация. Управление документами. Часть 1. Понятия и принципы» (далее – ГОСТ Р ИСО 15489-1-2019);

2. ГОСТ Р 7.0.101-2018/ИСО 30301:2011 «Система стандартов по информации, библиотечному и издательскому делу. Информация и документация. Системы управления документами. Требования» (далее – ГОСТ Р 7.0.101-2018/ИСО 30301:2011).

В ГОСТ Р ИСО 15489-1-2019 распределению ответственности между работниками уделено особое внимание. Так, установлено, что ответственность должна быть определена для:

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

Согласно ГОСТ Р ИСО 15489-1-2019 ответственность распространяется на всех сотрудников, которые создают и используют документы, и должна быть определена, установлена и доведена до их сведения (Таблица 1).

В соответствии с требованиями ГОСТ Р ИСО 15489-1-2019 в организации необходимо закрепить ответственность в ряде документов (Схема 2).

Для эффективного управления документами следует распределить ответственность между работниками. ГОСТ Р 7.0.101-2018/ИСО 30301:2011 регламентирует реализацию системы управления документами (далее – СУД), которая связывает управление документами с успешной деятельностью организации и подотчетностью путем создания структуры, включающей политику, цели и руководства для документов. Положения этого стандарта используют те организации, которые приняли решение о разработке и внедрении СУД.

Нормативные и методические документы по делопроизводству об ответственности 

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

1. Правила делопроизводства в государственных органах, органах местного самоуправления[1] (далее – Правила делопроизводства).

2. Методические рекомендации по разработке инструкции по делопроизводству в государственных органах, органах местного самоуправления[2] (далее – МР по разработке ИД).

3. Примерная инструкция по делопроизводству в государственных организациях[3] (далее – Примерная инструкция по делопроизводству).

В указанных нормативных актах между должностными лицами распределена ответственность за организацию документооборота (Таблица 2). В п. 3.1 МР по разработке ИД сказано, что аналогичные положения необходимо предусмотреть в разделе «Общие положения» локальной инструкции по делопроизводству.

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

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

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

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

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

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

Создание документов (документирование) 

Критериями для оценки эффективности процесса работы над проектом документа (документирования) можно считать:

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

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

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

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

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

1. В п. 4.4 Примерной инструкции по делопроизводству определен перечень подразделений и лиц, с которыми необходимо согласовывать проекты документов. В их числе – служба делопроизводства. И если, например, для юридической службы очерчен круг рассматриваемых документов (проекты ЛНА, проекты приказов), то согласно этому нормативному документу служба делопроизводства должна согласовывать все документы организации. По крайней мере те, требования к которым регламентированы в третьем разделе Примерной инструкции по делопроизводству. Одновременно с этим лишь для одной группы документов (а именно для распорядительных документов) оговорен обязательный контроль за правильностью оформления со стороны службы делопроизводства (см. п. 3.17 Примерной инструкции по делопроизводству). Рекомендуем в локальной инструкции по делопроизводству однозначно определить, какие виды документов согласовывает служба делопроизводства (секретарь) и что является предметом согласования.

2. Действующие нормативные акты по делопроизводству содержат требования к срокам выполнения тех или иных процедур. Так, например, согласно п. 5.36 Примерной инструкции по делопроизводству регистрация исходящих документов осуществляется в день их подписания или, в некоторых случаях, на следующий рабочий день. За регистрацию документов, как известно, отвечает служба делопроизводства или секретарь. Одновременно с этим в п. 7.11 Примерной инструкции по делопроизводству указано, что после подписания документа исполнитель передает его на регистрацию в порядке, установленном в локальной инструкции по делопроизводству. Кто будет виноват в срыве сроков и как обосновать это, если исполнитель забудет о подписанном документе на несколько дней? Рекомендуем обращать особое внимание на нюансы при разработке локальной инструкции по делопроизводству, продумать и описать единый порядок работы на тех этапах, которые в Примерной инструкции по делопроизводству не освящены и зависят от специфики организации. Как организован процесс передачи документов на подпись руководителю? Что происходит с документами после подписания? Как организовано взаимодействие исполнителя и службы делопроизводства (секретаря) на этом этапе? Ответы на эти вопросы желательно закрепить документально.

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

Исполнение документов (поручений) 

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

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

1. В соответствии с п. 6.8 Примерной инструкции по делопроизводству служба делопроизводства осуществляет проверку своевременности доведения документов, подлежащих исполнению, до работников. Однако практика показывает, что неправильно концентрировать всю ответственность в одном месте. В ЛНА целесообразно установить обязанность работников по регулярной проверке новых задач в СЭД, электронной почты, забору документов на бумажном носителе из ячеек структурных подразделений.

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

Резюме

1. Эффективность документооборота напрямую зависит от нормативного регулирования. Для качественной и бесконфликтной работы все сотрудники должны понимать свои обязанности и ответственность. Распределение ответственности – одно из основных правил, устанавливаемых международными стандартами по управлению документами. Глобально ответственность распределена и в действующих в Российской Федерации нормативных и методических документах по делопроизводству – их положения необходимо перенести в локальную инструкцию по делопроизводству (раздел «Общие положения»).

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

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