Гайды, регламенты, шпаргалки: как писать инструкции для сотрудников

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

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

Что такое инструкции и кто должен их писать

Любая инструкция (неважно, по какому процессу: от заведения тикета в техподдержке до выгрузки отчета из 1С) — это пошаговое описание того, как выполнять задачу. Ее цель — сократить количество вопросов, в идеале исключить ошибки и сделать процесс предсказуемым и повторяемым.

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

Техпис — это отдельная роль в команде. Их нанимают на проекты, где нужно готовить сложную документацию, например, по архитектуре IT-систем, API, работе с инфраструктурой, внутренним протоколам.

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

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

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

Почему инструкции не приносят пользы: типичные ошибки

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

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

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

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

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

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

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

Что делает инструкцию рабочей

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

Простая структура

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

1. Что нужно сделать.
2. В каком порядке.
3. Как понять, что все получилось (опционально).

Каждый шаг — с отдельного абзаца, желательно с маркировкой (нумерацией, чек-боксами, буллитами).

Понятный язык

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

Старайтесь писать короткими фразами, используйте глаголы действия: «Откройте таблицу», «Заполните поля», «Отправьте на согласование Иванову Ивану из бухгалтерии (можно указать почту сотрудника)».

Не бойтесь повторов, не выдумывайте заместительных синонимов. Лучше повторить, чем наплодить сущностей и запутать.

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

Инструкция должна звучать как ясное поручение: что делать, в каком порядке, что считать успешным результатом. Чем меньше двойных трактовок — тем выше шанс, что сотрудник выполнит всё правильно с первого раза.

Примеры и детализация

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

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

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

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

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

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

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

1. «Отправьте клиенту коммерческое предложение» ― какое коммерческое предложение? Где оно лежит? Лучше указать конкретный файл и путь к нему: дать ссылку на облако с документами или сделать скриншот.

2. «По шаблону» ― а где шаблон? Неясно, где его искать. Стоит указать, что шаблон, например, лежит на почте в черновиках.

3. «На почту, указанную в CRM» ― а где именно в CRM она указана? Тут лучше всего сделать скриншот или скринкаст рабочего стола и показать, куда нажимать. Например, вот так:

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

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

С фидбэком, полученным после «проверки боем», будет проще доработать гайд, если в нем действительно есть проблемные места.

Где писать и как хранить инструкции 

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

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

Что важно:

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

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

Собственная инфраструктура 

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

Почему это хорошее решение: 

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

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

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

Teamly и другие аналоги Notion

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

Если вам или команде кажется, что эти проблемы действительно серьезные, то лучше поискать другую платформу. Сейчас у Notion множество аналогов. Например, российские Teamly или Yonote. В этих органайзерах можно вести to-do-листы, делать канбан-доски и хранить все нужные документы.

Почему это хорошее решение: 

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

Таск-трекеры с базой знаний

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

Среди таких:

• Weeek;
• ПланФикс;
• Kaiten.

Почему это хорошее решение: 

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

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

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

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

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

Важно, чтобы инструкции постоянно фигурировали в коммуникации:

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

Так создается привычка обращаться к базе знаний, а не каждый раз задавать один и тот же вопрос в личку. Постепенно сформируется более зрелый подход к просьбам о помощи — культура self-service. Как для «носителей знания», так и для самого сотрудника на самом деле намного проще, чтобы ответ находился самостоятельно.