И как сделать так, чтобы ими действительно пользовались
Представьте: вы работаете в отделе маркетинга и каждую неделю делаете email-рассылку по базе. Вам всё понятно, процесс уже отлажен. Но однажды к вам приставляют нового сотрудника. Выясняется, что без постоянных пояснений он не может включиться в работу и постоянно косячит. Приходит понимание: пора писать инструкцию. Но с чего начать?
Разберемся, как написать действительно рабочую инструкцию: как ее структурировать, что учесть при оформлении, где хранить и как убедиться, что ей будут пользоваться.
Любая инструкция (неважно, по какому процессу: от заведения тикета в техподдержке до выгрузки отчета из 1С) — это пошаговое описание того, как выполнять задачу. Ее цель — сократить количество вопросов, в идеале исключить ошибки и сделать процесс предсказуемым и повторяемым.
Инструкции по процессам ≠ должностные инструкции
Должностные инструкции — это формальные документы, которые описывают, за что отвечает сотрудник. Устанавливают его функции, задачи и зону ответственности. Они фиксируются в трудовых отношениях, подписываются обеими сторонами и чаще всего касаются юридической стороны вопроса.
В этой статье мы говорим не о них, а о практических, рабочих инструкциях — тех, которые помогают выполнить задачу, а не определить, кто за неё отвечает.
Частая ошибка — считать, что инструкции всегда должен писать технический писатель. В реальности это необходимо лишь в проектах, которые требуют определенных hard-скиллов в технической сфере.
Техпис — это отдельная роль в команде. Их нанимают на проекты, где нужно готовить сложную документацию, например, по архитектуре IT-систем, API, работе с инфраструктурой, внутренним протоколам.
В большинстве рабочих задач (особенно в операционной рутине) инструкции проще и быстрее писать самому исполнителю. Кто знает, как все устроено: из чего состоит задача, в каком порядке действовать, что может пойти не так. Такой человек более компетентен в вопросе, чем сторонний писатель. Например, это может быть руководитель направления, бухгалтер, офис-менеджер, project или product-менеджер.
Не страшно, если у человека, которому поручили писать инструкцию, нет опыта в текстах. Часто он отлично разбирается в процессе, просто не понимает, как изложить это просто и неформально, без перегрузки или канцелярита. А вот если поручить написание тому, кто сам задачу никогда не выполнял — инструкция с большой вероятностью получится формальной и мало применимой на практике.
Можно привлечь редактора или корректора на финальном этапе, чтобы он отсмотрел текст именно с точки зрения формы, например, расставил потерянные запятые или поправил грамматику.
Бывает так: инструкция вроде бы есть, но сотрудники продолжают задавать вопросы или действуют по-своему. Почему так происходит? Причин может быть несколько:
Инструкция громоздкая. В ней много лишнего текста, ненужных деталей или сложных формулировок. Читателю нужно приложить усилия, чтобы понять, что от него требуется. Намного проще и быстрее в который раз написать коллеге.
Инструкция слишком общая. Так бывает, когда процесс описан тезисно, без примеров. Нет пошагового плана выполнения, непонятно, где найти нужные материалы (нет ссылок), как проверить результат.
Нет структуры. Все идет сплошным текстом: без подзаголовков, выделений, таблиц или скриншотов. Такой текст очень сложен для понимания и запоминания. Разбивка хотя бы на подразделы с заголовками уже помогает подходить к чтению более системно.
Информация устарела. Например, в инструкции указано, что заявку на закупку согласовывает менеджер по снабжению. А на деле этот процесс давно передали в бухгалтерию. Сотрудник пробует следовать инструкции и получает отказ. После пары таких случаев доверие к документу теряется. Постепенно это начинает касаться всех инструкций, даже актуальных и написанных по делу.
Инструкция существует отдельно от процесса. Вы написали отличный гайд по работе с этапами в вашей CRM, но он лежит в какой-то папке, в которую никто не заглядывает. Или вы просто однажды отправили его в канал корпоративного мессенджера и надеетесь, что к нему порой возвращаются. Но сотрудники скорее всего просто забыли, что такой гайд существует (или им лень его искать).
Чтобы инструкция действительно помогала в работе, важно не только то, что в ней написано, но и как это написано. Разберем, на что стоит обращать внимание при написании.
Чтобы инструкция действительно помогала, в ней должны сходиться три элемента.
Инструкция — это не сочинение. Она должна быть линейной, пошаговой, без скачков с темы на тему и «лирических отступлений». Хорошо работает схема:
Каждый шаг — с отдельного абзаца, желательно с маркировкой (нумерацией, чек-боксами, буллитами).
Избегайте канцелярских формулировок вроде «при необходимости», «в случае возможности», «в установленные сроки» — они создают разночтения, непонятно, есть ли необходимость? Кто устанавливает сроки?
Старайтесь писать короткими фразами, используйте глаголы действия: «Откройте таблицу», «Заполните поля», «Отправьте на согласование Иванову Ивану из бухгалтерии (можно указать почту сотрудника)».
Не бойтесь повторов, не выдумывайте заместительных синонимов. Лучше повторить, чем наплодить сущностей и запутать.
| Плохо | Хорошо |
| Необходимо осуществить проверку заполнения всех обязательных полей, предусмотренных шаблоном. При выявлении ошибок производится возврат документа на доработку. | Проверьте, что поле с именем и личными данными заполнено правильно, по карточке контрагента. Если есть ошибки — верните документ отправителю на исправление. |
В плохом примере — канцелярит, пассивные конструкции и размытые формулировки. Такие тексты трудно читать. Еще труднее понять, что именно нужно сделать. Читателю приходится догадываться, кто исполнитель, какие сроки считаются «установленными» и где вообще искать нужные данные.
Инструкция должна звучать как ясное поручение: что делать, в каком порядке, что считать успешным результатом. Чем меньше двойных трактовок — тем выше шанс, что сотрудник выполнит всё правильно с первого раза.
Покажите на конкретном примере, что именно писать в поле, какой файл прикрепить, как выглядит нужный шаблон.
Если есть типовые ошибки — предупредите о них. Скриншоты, шаблоны, ссылки работают лучше любых описаний. Просто отлично, если покажете на скриншоте нужное поле, например, нарисовать стрелочку в фоторедакторе или обвести что-то рамкой.
Например, если нужно показать, где лежит документ, не нужно описывать путь к нему в CRM, лучше сделать скриншот и показать это.
Прежде чем выкладывать гайд в общий доступ, проверьте его на понятность и применимость. Вот два простых способа валидации:
Тест на «новичка». Попробуйте поставить себя на место человека, который только пришел в команду. Он не знает сокращений, аббревиатур, командного слэнга. Не понимает, где лежит вся документация и просто должен где-нибудь да ошибиться.
По шагам пройдите весь процесс, строго следуя только тому, что написано в инструкции. Намеренно ищите места, в которых можно допустить ошибку. Разберем на примере предложения: «Отправьте клиенту коммерческое предложение по шаблону письма на почту, указанную в CRM».
1. «Отправьте клиенту коммерческое предложение» ― какое коммерческое предложение? Где оно лежит? Лучше указать конкретный файл и путь к нему: дать ссылку на облако с документами или сделать скриншот.
2. «По шаблону» ― а где шаблон? Неясно, где его искать. Стоит указать, что шаблон, например, лежит на почте в черновиках.
3. «На почту, указанную в CRM» ― а где именно в CRM она указана? Тут лучше всего сделать скриншот или скринкаст рабочего стола и показать, куда нажимать. Например, вот так:
Мини-тест с коллегой. Попросите кого-то из команды выполнить задачу по вашей инструкции. Выберите человека, ни разу не выполнявшего задачу, которую вы хотите ему поручить.
Лучше всего для этого теста подойдет совсем зеленый новичок. Не подсказывайте, не вмешивайтесь, просто поставьте задачу: возьмешь в работу — придерживайся инструкции. Попросите собрать все возникшие вопросы и отправить вам. Потом разберите вместе, что было неочевидно, где нужны пояснения, ссылки, скриншоты.
С фидбэком, полученным после «проверки боем», будет проще доработать гайд, если в нем действительно есть проблемные места.
Главное правило ― инструкция должна быть в открытом доступе. Если документ сложно найти или он лежит на облачном диске автора и распространяется по личным сообщениям, эффективность инструкции стремится к нулю.
Так что важно сразу определить, где инструкции будут жить, а также кто будет отвечать за их доступность и актуальность.
Что важно:
Вот еще любопытный факт: даже если сотрудник прочел гайд, не факт, что он все запомнил. У человека ограниченный объем кратковременной памяти — по закону Миллера, это всего 7 ± 2 элемента. Причем касается это только осмысленных и знакомых данных. Например, проще запомнить слово «инструкция», чем «кеьтцлчщгоу». Поэтому нужно рассчитывать на то, что человек периодически будет к инструкциям возвращаться.
Мы пришли к тому, что нужно собрать единую внутреннюю базу знаний. Нет четких правил, в каком формате она должна быть. Можно даже просто вести большой Google Документ с множеством разных разделов. Впрочем, есть более удобные и технологичные способы.
Во многих случаях проще всего сделать базу знаний на сайте компании. Так, например, решил поступить Ozon и запустил большой информационный портал для селлеров.
Почему это хорошее решение:
С этим способом есть несколько сложностей. Для поднятия такой базы знаний потребуется помощь команды веб-разработки, которая занимается сайтом компании. Поддержка целого портала может стоить больших денег. Ну и если сайта в принципе нет, то этот вариант совсем не годится.
Даже несмотря на то, что Notion официально ушел из России в 2024 году, многие компании продолжают его использовать. Однако для работы с ним есть стопперы. Платформа не доступна без дополнительных инструментов, а еще у нее нет интерфейса на русском языке.
Если вам или команде кажется, что эти проблемы действительно серьезные, то лучше поискать другую платформу. Сейчас у Notion множество аналогов. Например, российские Teamly или Yonote. В этих органайзерах можно вести to-do-листы, делать канбан-доски и хранить все нужные документы.
Почему это хорошее решение:
Если выбрать из всего многообразия таск-трекеров такой, в котором можно не только вести календарик с задачами, но и создавать базу знаний, то получится совместить приятное с полезным.
Среди таких:
Почему это хорошее решение:
В чем может быть проблема: если у компании уже есть таск-трекер и в нем нет функций базы знаний, переходить на новый нецелесообразно. К тому же, во многих трекерах очень урезанный функционал работы с документами.
Например, в Kaiten можно совершать лишь простейшие действия: писать текст, создавать маркированные или нумерованные списки, собирать таблички. Сгодится, если не хочется сильно заморачиваться над созданием гайда. А если порой требуется, например, сделать схему или инфографику — стоит вернуться к решениям с более широким функционалом.
Простой ответ: нужно встроить работу с ними в ежедневную рутину. Если вы написали одну инструкцию — на этом лучше не останавливаться. Постарайтесь описать максимум повторяющихся процессов, даже самых простых. Чем больше задач задокументировано, тем выше шанс, что сотрудники начнут пользоваться базой знаний.
Важно, чтобы инструкции постоянно фигурировали в коммуникации:
Так создается привычка обращаться к базе знаний, а не каждый раз задавать один и тот же вопрос в личку. Постепенно сформируется более зрелый подход к просьбам о помощи — культура self-service. Как для «носителей знания», так и для самого сотрудника на самом деле намного проще, чтобы ответ находился самостоятельно.
Читайте только в Конверте
Каждый рубль, вложенный в рассылки, приносит от 10 до 50 рублей (исследование Litmus, 2025).
Искренние письма о работе и жизни, эксклюзивные кейсы и интервью с экспертами диджитала.
Проверяйте почту — письмо придет в течение 5 минут (обычно мгновенно)
