Сотруднику нужна не документация, а ответ на конкретный вопрос за минуту: «как оформить возврат», «что делать, если заявка не сохраняется», «кому писать, когда сломалось». Поэтому рабочая инструкция после внедрения — это не одно руководство на сто страниц, а 5–7 отдельных страниц, каждая из которых закрывает одну задачу целиком, и ещё две служебные: список типичных ошибок и лист контактов.
Толстое руководство появляется по понятной причине: его проще написать. Подрядчик описывает систему по разделам меню, потому что так устроен его взгляд, а сотрудник ищет по задачам, потому что так устроена его работа. Эти два оглавления никогда не совпадают, и документ, написанный по первому, не открывают дважды.
Ниже — формат страницы, обязательный минимум документов, расчёт стоимости на компании с 40 пользователями и правило, по которому инструкция не превращается в мусор через полгода. Обучение и документация — разные вещи и решают разные задачи: про первое у нас есть отдельный разбор форматов и сроков обучения, здесь речь только о том, что остаётся у людей на руках после.
Формат «одна задача — одна страница»
Единица документации — задача, которую сотрудник решает целиком и после которой встаёт из-за стола. Не «работа со справочником контрагентов», а «завести нового клиента и выставить ему счёт». Проверка простая: если страницу нельзя открыть в момент выполнения и пройти по ней сверху вниз до результата, задача выбрана неправильно.
- 1Заголовок — глаголом и словами сотрудника
«Оформить возврат от клиента», а не «Модуль возвратов». Название должно совпадать с тем, как человек формулирует задачу вслух, — по нему он будет искать. Если в компании говорят «пробить возврат», в заголовке пишется «пробить», а не литературный синоним.
- 2Шаги — от 5 до 9, каждый начинается с действия
Меньше пяти — задача мелкая, её можно присоединить к соседней. Больше девяти — внутри спрятаны две задачи, и страницу надо делить. Каждый шаг — одно действие и один результат: «нажмите «Создать» — откроется форма заявки».
- 3Скриншот — только там, где можно ошибиться
Не на каждый шаг, а на тот, где сотрудник впервые видит незнакомый экран или где два похожих поля рядом. Скриншотов на страницу обычно два-три. Каждый лишний — это ещё одно место, которое устареет при следующем обновлении интерфейса.
- 4Блок «если пошло не так» — обязателен
Три-четыре самые частые нештатные ситуации по этой задаче и что делать в каждой: кнопка неактивна, документ не проводится, поле требует значения, которого нет. Именно этот блок снимает большую часть обращений — не сама инструкция по шагам, а он.
Абстрактный макет одной страницы инструкции с обозначенными зонами. Сверху заголовок «Оформить возврат от клиента» и мелкая строка «обновлено: сентябрь 2026, владелец — руководитель отдела продаж». Далее нумерованный список из семи шагов, у шагов 3 и 6 — прямоугольники-заглушки скриншотов с подписями «форма возврата» и «выбор причины». Внизу выделенный блок «Если пошло не так» с тремя строками: «кнопка «Провести» неактивна», «нет нужной причины возврата», «документ не сохраняется». В самом низу строка «Не получилось — пишите: …». Чертёжный стиль, подписи по-русски.
Не из головы и не из меню системы, а из журнала обращений за первый месяц после запуска. Отсортируйте вопросы по частоте — первые пять-семь и есть ваши страницы. Так документация пишется под реальные затруднения, а не под воображаемые, и объём получается вдвое меньше, чем при попытке описать всё сразу.
Обязательный минимум и чем он отличается от документации подрядчика
Минимальный комплект, который должен остаться у компании после внедрения, — это 5–7 страниц по задачам плюс две служебные. Страница ошибок собирает нештатные ситуации, общие для всех сценариев, и говорит, какие из них сотрудник чинит сам, а какие — повод писать в поддержку. Лист контактов отвечает на вопрос «к кому идти», и он важнее, чем кажется: без него любая заминка идёт к тому, кто громче всех участвовал во внедрении.
Отдельно стоит развести два разных документа, которые в договорах часто называют одним словом «документация».
| Инструкция пользователя | Техническая документация подрядчика | |
|---|---|---|
| Кто читает | Сотрудник в момент работы | Инженер, который будет дорабатывать систему |
| Оглавление по | Задачам сотрудника | Модулям, интеграциям, структуре данных |
| Объём | 5–7 страниц по одной задаче | Зависит от системы, обычно десятки страниц |
| Когда открывают | Ежедневно первые два месяца | При доработке или смене подрядчика |
| Что будет без неё | Вопросы идут к коллегам, часть работы делается мимо системы | Следующий подрядчик изучает систему заново за ваш счёт |
Нужны обе, и требовать одну вместо другой бессмысленно: по описанию структуры базы кладовщик работать не начнёт, а по инструкции «нажмите «Создать» новый подрядчик не разберётся в интеграции с учётной системой. Техническая документация — это ещё и страховка от привязки к исполнителю, поэтому её состав имеет смысл обсуждать до подписания договора; что именно туда включать, разобрано в материале про то, что должно быть в договоре на разработку.
Сколько стоит написать и что она возвращает
Инструкцию часто не заказывают, потому что «это же просто описать». Описать действительно просто — сложно описать так, чтобы этим пользовались, и на страницу с проверкой на живом сотруднике уходит около двух часов. Считаем на компании с 40 пользователями системы.
Восемь-девять месяцев — честный, а не рекламный срок, и он говорит важную вещь: инструкция окупается не экономией, а устойчивостью. Прямая денежная выгода здесь скромная. Настоящая ценность в том, что новый сотрудник выходит на работу без наставника, а знание о процессе перестаёт жить только в голове человека, который присутствовал на внедрении. Через год именно это отличает систему, которой пользуются, от системы, которую обходят.
Обратите внимание на долю снимаемых вопросов — 60 %, а не 100 %. Остальные 40 % — это ситуации, которых нет ни в одной инструкции: нестандартный случай, ошибка в данных, вопрос «а можно ли вообще так». Их снимает не документ, а поддержка, и планировать надо оба контура сразу — про состав и цену второго у нас есть отдельный разбор поддержки после запуска.
Кто обновляет через год и что записать в договор
Инструкция без владельца устаревает после первого же обновления системы, и с этого момента она не нейтральна, а вредна: сотрудник делает по написанному, получает не тот результат и перестаёт верить документу целиком. Поэтому владелец назначается сразу — обычно это тот же человек, который отвечает за процесс, а не подрядчик и не «отдел кадров».
Обновление запускается не по календарю, а по событиям. Календарная ревизия раз в полгода нужна как страховка, но основную работу делают триггеры.
- Изменился экран или маршрут. Любая доработка, которая меняет порядок действий или внешний вид формы со скриншота, тянет за собой правку страницы. Практично требовать это от подрядчика в том же акте: доработка не принята, пока не обновлена затронутая страница.
- Изменилось правило. Владелец процесса решил, что возврат теперь принимается без чека при сумме до определённого порога, — правило меняется в инструкции в тот же день, иначе половина сотрудников будет работать по старому.
- Появился новый частый вопрос. Если одна и та же ситуация пришла в поддержку три раза за месяц, это заявка на новую страницу или на новую строку в блоке «если пошло не так».
- Пришёл новичок. Ввод нового сотрудника — бесплатная проверка документации на актуальность: всё, обо что он споткнулся, идёт в правку. Момент удобен тем, что новичок ещё не научился обходить неточности молча.
В договоре документацию имеет смысл сделать результатом этапа, а не жестом доброй воли. Формулировка, которая работает: этап «Запуск» считается сданным при передаче N страниц пользовательских инструкций по согласованному списку сценариев и технической документации в оговорённом составе. Тогда документация появляется до подписания акта, а не после — а после она не появляется практически никогда.
Схема: в центре блок «Страница инструкции» с подписью «владелец — владелец процесса». Слева четыре входящие стрелки-триггера с подписями: «изменился экран или маршрут», «изменилось правило», «вопрос пришёл третий раз за месяц», «вышел новый сотрудник». Справа одна пунктирная стрелка «ревизия раз в полгода» с пометкой «страховка, а не основной механизм». Внизу подпись: «Инструкция без владельца устаревает за один релиз». Чертёжный стиль, подписи по-русски.
Когда инструкцию писать не надо
Документация — расход, и он оправдан не всегда. Четыре случая, в которых мы сами не советуем закладывать её в смету.
- Пользователей меньше пяти и они сидят в одной комнате. Здесь дешевле показать один раз и ответить на вопрос голосом. Инструкция понадобится, когда появится шестой человек или когда первый уйдёт в отпуск.
- Процесс изменится в ближайшие два месяца. Писать страницы к промежуточному решению — гарантированно выбросить работу. Разумнее дождаться стабильной версии маршрута и до этого обойтись короткой памяткой в чате.
- Задача выполняется раз в год. Годовая инвентаризация, закрытие года, ежегодная отчётность — здесь работает не инструкция, а календарное напоминание со ссылкой на прошлогодний разбор. К моменту следующего раза страница всё равно устареет.
- Некому назначить владельца. Документ, за который никто не отвечает, через два релиза начинает врать. В этой ситуации честнее не писать инструкцию вовсе, а вложиться в поддержку и в понятные подсказки внутри самой системы — там правки живут вместе с функциональностью.
Если страница получается на два листа с двенадцатью шагами, проблема не в тексте, а в интерфейсе: сложную операцию описали честно. Такие места стоит помечать отдельно и отдавать в доработку, а не компенсировать объёмом документации. Хороший признак: количество страниц, которые сотрудники реально открывают через полгода. Если оно растёт, а не падает, значит, система не стала привычной — и это видно по метрикам использования раньше, чем по жалобам.
