Хорошая ИТ-инструкция позволяет выполнить одну конкретную задачу без устных подсказок автора. Для этого недостаточно записать последовательность кликов: нужны условия запуска, необходимые права, признаки успеха и понятный путь при ошибке. Ниже — структура для внутренней базы знаний службы поддержки и способ проверить её перед публикацией.
Начните с результата, а не со списка кнопок
Выберите один повторяющийся сценарий: подключить сетевой принтер, оформить заявку на доступ или проверить состояние резервного копирования. Не объединяйте в одну статью пользовательскую настройку и действия администратора на сервере. У этих процедур разные права, риски и аудитория.
Сформулируйте результат так, чтобы его можно было проверить. Вместо «Настройка печати» — «Подключить офисный принтер и напечатать тестовую страницу». Если документ описывает диагностику, результатом может быть собранный набор сведений для обращения в поддержку, а не обязательное устранение неисправности.
- Для кого: сотрудник, первая линия поддержки или администратор.
- Где применимо: система, версия приложения, способ подключения и нужная роль.
- Когда остановиться: нет требуемого доступа, интерфейс отличается, действие затрагивает рабочие данные.
- Что не входит: например, установка драйвера с повышенными правами или изменение политики безопасности.
Соберите карточку инструкции
Перед шагами разместите короткий блок с исходными условиями. Читатель должен понять, подходит ли ему процедура, ещё до первого действия. Для внутреннего документа укажите владельца и фактическую дату последней проверки, а не автоматически меняющуюся дату открытия страницы.
- Цель: одно проверяемое изменение или диагностический результат.
- Предварительные условия: доступ к корпоративной сети, установленное приложение, согласованная заявка или другая необходимая подготовка.
- Права: какую роль использовать и на каком шаге потребуется помощь администратора.
- Входные данные: где взять имя ресурса или номер заявки. Самих паролей и токенов в документе быть не должно.
- Ограничения: допустимое окружение, окно работ, запрет на выполнение в продуктивной системе без согласования.
- Проверка и восстановление: как убедиться в результате и что делать, если изменение не подошло.
Не добавляйте раздел «Откат» ради формальности. Для отправленной заявки может быть достаточно описать порядок отмены через поддержку. Для изменения серверной конфигурации нужна отдельная, проверенная процедура восстановления. Не называйте повтор исходной команды универсальным откатом.
Один шаг — одно понятное действие
Стройте шаг по схеме «действие → ожидаемый результат». Указывайте название элемента интерфейса и место, где он находится. Формулировка «нажмите справа» ненадёжна: расположение может зависеть от размера окна или версии приложения.
Например, вместо «зайдите в настройки и всё заполните» напишите: «Откройте раздел “Устройства”. В списке должен отображаться нужный принтер». Следующий шаг посвящайте уже выбору устройства. Названия разделов в реальной инструкции сверяйте с той версией системы, для которой она подготовлена.
Скриншот дополняет текст, но не заменяет его. Выделяйте только нужную область, сохраняйте читаемый масштаб и поясняйте, на что смотреть. Если на экране несколько похожих кнопок, подпишите контекст: вкладку, карточку или диалог. Для команд отдельно укажите оболочку, требуемые права, значения переменных и ожидаемый вывод. Не смешивайте в одном блоке команды для разных ОС.
Подготовьте безопасную запись процесса
Сначала выполните сценарий в тестовом окружении с демонстрационными данными. До записи закройте лишние вкладки, уведомления и окна с перепиской. Проверьте не только основную область приложения, но и адресную строку, имя профиля, списки последних файлов и всплывающие подсказки.
В инструкцию не должны попадать пароли, одноразовые коды, ключи API, ссылки с токенами, реальные персональные данные и сведения, не нужные читателю для выполнения задачи. Если запись уже захватила секрет, одного размытия на итоговом изображении недостаточно: исходный файл может продолжать храниться или быть доступен другим участникам. Следуйте внутреннему порядку обработки такого случая и подготовьте чистый материал.
Выбирайте формат по задаче. Для короткой проверки подходит текстовый чек-лист. Для последовательности в графическом интерфейсе полезны подписанные скриншоты. Для браузерных сценариев можно использовать Demiqo: сервис позволяет записать действия расширением Chrome и собрать пошаговую инструкцию со скриншотами. Перед размещением в базе знаний редактору всё равно нужно проверить порядок шагов, описания и отсутствие служебных данных.
Автоматически подготовленный текст не следует считать проверенным регламентом. Инструмент может зафиксировать нажатие кнопки, но объяснить, зачем оно нужно, при каких правах доступно и когда его нельзя выполнять, должен автор процедуры.
Добавьте развилки и условия остановки
У основной последовательности должен быть ясный конец. Ошибки вынесите в отдельный раздел: симптом, безопасная проверка и дальнейшее действие. Не отправляйте читателя повторять операцию бесконечно, особенно если она создаёт записи, рассылает уведомления или меняет данные.
- Нет нужного пункта меню: сверить роль и версию интерфейса; не предлагать обход ограничений доступа.
- Ресурс не найден: проверить имя и доступность требуемой сети; указать, какие сведения передать в поддержку.
- Появилось неожиданное предупреждение: остановиться и сохранить его текст без секретов; не советовать автоматически соглашаться.
- Результат не совпал с образцом: описать, на каком шаге прекратить процедуру и кому передать случай.
Для обращения в поддержку обычно полезны номер шага, время ошибки, версия приложения и обезличенный текст сообщения. Состав сведений задавайте под конкретную процедуру. Не требуйте присылать пароль или полный снимок рабочего экрана, если достаточно одного фрагмента.
Проверьте инструкцию без подсказок автора
Попросите другого исполнителя пройти безопасный тестовый сценарий с теми правами, которые указаны в документе. Автор наблюдает и отмечает затруднения, а не подсказывает пропущенные переходы. Иначе проверяется память команды, а не качество инструкции.
- Убедитесь, что предварительные условия доступны и понятны читателю.
- Пройдите шаги по порядку и сравните фактические результаты с описанием.
- Проверьте хотя бы типовую предусмотренную ошибку там, где её можно безопасно воспроизвести.
- Проверьте доступ к иллюстрациям и документу под ролью читателя, а не владельца.
- Исправьте пропущенные условия, двусмысленные формулировки и устаревшие изображения, затем повторите затронутые шаги.
Для опасных операций используйте согласованную тестовую среду. Проверка инструкции не является основанием запускать восстановление, удаление или изменение доступа в рабочей системе без разрешения.
Публикуйте одну действующую версию
Разместите документ в подходящем разделе базы знаний: по сервису или задаче, а не только по фамилии автора. Название должно совпадать с тем, как пользователь ищет решение. В ответах на обращения давайте ссылку на действующую инструкцию вместо копирования её текста в несколько чатов.
Назначьте владельца и основания для пересмотра: обновление интерфейса, смена ролей, изменение политики доступа, повторяющаяся ошибка читателей. Периодичность проверки выбирайте по риску и частоте изменений. Устаревший материал явно помечайте и связывайте с заменой; не оставляйте две противоречащие процедуры одинаково актуальными.
Перед публикацией пройдите короткий контроль: результат проверяем, аудитория и права указаны, секретов нет, шаги воспроизводимы, ошибки и остановка описаны, владелец назначен. Затем начните с одного часто повторяющегося обращения и доведите именно его инструкцию до состояния, в котором следующий читатель сможет обойтись без пояснений автора.