iT-эскизы
09 июля 2004 г.
Как написать инструкцию по работе с программой
Вообще, необходимо два типа инструкций. Одна - общая, описывающая порядок работы с программой в целом. Другие - частные, индивидуальные инструкции для каждого пользователя. Давайте посмотрим, как должна выглядеть общая инструкция.
О Документе
Необходимо указать, к какой версии программы относится создаваемый документ. Можно написать, для кого этот документ предназначен: для информационного администратора системы, для других специалистов информационной службы.
Термины и сокращения
Желательно не "размахиваться" в этом разделе. Нужны лишь самые специфичные термины и сокращения. Воды и наукообразия также не нужно.
Состав программы
Перечислите, из каких модулей состоит программа, система. Опишите назначение каждого модуля.
Пользователи системы и их полномочия
Информационная система - это не только техника и программы, но и люди, которые со всем этим работают.
Здесь не лишней будет табличка с ролями и их правами в системе.
Последовательность работы с системой
Раз. Два. Три. Последовательность работы с системой. Как правило последовательность такая:
1. Настройка словарей системы
2. Выполнение основного бизнес-процесса (то, для чего и создана система). Например - "согласование договоров".
3. Выполнение процессов управления. Например -- "контроль процесса согласования договоров"
4. Выполнение обслуживающих процессов. Например - "сбор статистики по маршрутам согласования" или "Архивирование баз данных"
Обратите внимание, что последующие разделы инструкции по работе с программой следуют в вышеуказанном порядке.
Настройка словарей системы
1. Неплохо сначала указать перечень словарей
2. …а потом описать, для чего нужен каждый словарь и как их настраивать
3. Будет красиво и правильно, если для каждого словаря будут вставлены скриншоты, например:
Состав и структура бизнес-процессов системы
Прежде, чем приступать к описанию каждого бизнес-процесса, необходимо указать их состав и структуру. Смотрите:
Догадались, что дальнейшие инструкции будут построены в соответствии с этой схемой?
Ну логично ведь!
Основной процесс
...Инициирование
...Согласование
...Ознакомление
...Утверждение
...Завершение
...Формирование протокола
Управляющие процессы
...Контроль сроков рассмотрения и рассылка напоминаний
Вспомогательные (обслуживающие) процессы
...Сбор статистики по маршрутам согласования договоров
Как описывать каждый процесс
Раз. Два. Три. Последовательно. Прикладывая скриншоты и давая комментарии. Короткие комментарии можно писать на графических выносках к скриншотам, вот так:
Сначала опишите процесс, выполняемый в нормальном режиме, а потом уже его "ненормальные" варианты.
Какую информацию выносить в Приложения?
Образцы входных и выходных форм, листинги программ и все, что не помещается на 2-3 экранах желательно вынести в приложения, в конец инструкции.
08 июля 2004 г.
Дураку нельзя показывать наполовину сделанную работу
Это мудрость строителей. Они стараются не показывать недострой клиенту. Испугается, занервничает, начнет делать глупости.
В iT-проектах "заготовки" нужно показывать очень аккуратно, подготовив к этому заказчика. Вычистить все сообщения об ошибках, пропускать узкие места (ой, смотрите, птичка полетела!), акцентировать внимание на отлаженных участках. Если, например, по сценарию предполагается формирование выходной формы, а она не готова, то можно достать уже заготовленную заполненную форму и показать: "А вот такая форма распечатается, когда мы нажмем на эту кнопку…"
