admin Начните базу знаний с вопросов, из-за которых сотрудники регулярно ждут ответа в чате. Опишите несколько рабочих сценариев, назначьте владельцев инструкций и проверьте, может ли коллега выполнить действие по тексту без созвона. После этого расширяйте разделы и переносите остальные материалы.
Для удалённой команды особенно важно, чтобы ответ был доступен в удобное сотруднику время. Ниже — порядок запуска небольшой внутренней базы: от отбора материалов до обновления инструкций. Он не требует переносить всю документацию компании за один раз.
Что должно входить в базу знаний
База знаний для сотрудников — место, где можно найти действующие инструкции, правила и ответы на рабочие вопросы. У материала должны быть понятное назначение и владелец. Файл, который когда-то отправили в чат, становится полезной инструкцией после проверки актуальности и размещения там, где его смогут найти.
Разделите документы по назначению. Инструкция объясняет, как выполнить действие. Регламент описывает порядок и ответственность. Журнал решений хранит выбранный вариант и причины выбора. Справочная страница помогает быстро найти контакт, термин или нужный ресурс. Не обязательно смешивать все эти задачи в одном шаблоне.
В качестве примера открытого подхода можно изучить справочник GitLab: компания использует handbook как центральный источник сведений о своей работе. Копировать его объём небольшой команде не нужно. Возьмите сам принцип доступного общего места для согласованных правил.
Для связи базы с ежедневной работой сначала стоит описать процессы команды. Так станет понятно, какие инструкции действительно нужны исполнителю на каждом шаге.
Соберите вопросы для первого раздела
Выберите один процесс, где повторяются похожие обращения. Например, получение доступа, подготовка еженедельного отчёта или передача результата на согласование. Просмотрите недавние рабочие вопросы и выпишите, какой ответ нужен сотруднику, какие материалы уже существуют и что в них устарело.
Удобно собрать короткий реестр: вопрос, аудитория, действующий ответ, владелец и следующий шаг. Не переносите все найденные файлы автоматически. Если два документа описывают разные версии процедуры, сначала попросите владельца процесса определить действующую.
Для первого запуска выберите небольшой набор частых вопросов, который команда реально успеет проверить. Например, пять инструкций по работе с клиентской заявкой. Число пять здесь — удобный масштаб пилота, а не обязательный стандарт. Для другого процесса может хватить трёх материалов.
Проверьте, что тема статьи названа словами сотрудника. «Как запросить доступ к проекту» обычно проще использовать как поисковую формулировку, чем внутренний номер положения. Официальное название документа можно сохранить внутри страницы.
Постройте навигацию по рабочим действиям
Сделайте стартовую страницу с несколькими понятными входами: начать работу, получить доступ, выполнить типовую задачу, согласовать результат, найти ответственного. Внутри разделов располагайте материалы по ходу действий. Если сотрудники работают в нескольких ролях, добавьте короткие маршруты для каждой.
Не создавайте несколько редактируемых копий одной инструкции. Оставьте один основной материал, а из других разделов поставьте ссылки на него. При переносе страницы проверьте старые ссылки в задачах и сообщениях, которые продолжают использовать сотрудники.
| Раздел | Что сотрудник должен найти | Кто подтверждает содержание |
|---|---|---|
| Начало работы | Первые действия и контакты | Владелец адаптации |
| Типовые задачи | Проверенную последовательность шагов | Владелец процесса |
| Согласования | Куда передать результат и что приложить | Ответственный за приёмку |
| Инструменты | Порядок получения доступа и обращения за помощью | Ответственный за инструмент |
Названия ролей в таблице — пример. В небольшой команде несколько функций может выполнять один человек. Важно, чтобы читатель понимал, куда сообщить об ошибке, а не разыскивал автора старого файла.
Используйте короткий шаблон инструкции
Описывайте инструкцию через рабочий результат. В начале напишите, когда она нужна и что должно получиться. Затем перечислите необходимые доступы и материалы, шаги выполнения, способ проверки и действия при исключении.
Вот заготовка для страницы «Как передать отчёт на проверку»:
- Когда использовать: отчёт подготовлен и готов к проверке руководителем проекта.
- Что подготовить: ссылку на отчёт, период, использованные данные и список открытых вопросов.
- Что сделать: проверить доступ проверяющего, разместить ссылку в согласованной задаче, указать ожидаемую дату обратной связи.
- Как проверить: ссылка открывается у проверяющего, материал относится к нужному периоду, вопросы видны рядом с результатом.
- Если есть проблема: отметить препятствие в задаче и обратиться к владельцу процесса.
- Владелец и актуальность: роль или имя ответственного, дата последней проверки, причина следующего пересмотра.
Это учебный пример, который нужно адаптировать под ваш процесс. Не закрепляйте случайный способ работы только потому, что он первым попал в шаблон. Согласуйте порядок с теми, кто передаёт и принимает результат.
Скриншот используйте там, где он помогает найти элемент интерфейса. Существенное действие опишите текстом: после обновления программы картинка может устареть. Не включайте в иллюстрации пароли, токены, личные данные и материалы клиентов, которые не нужны читателю инструкции.
Проверьте инструкцию без помощи автора
Попросите коллегу из целевой аудитории выполнить действие по черновику. Если инструкция предназначена новичку, опытный автор процесса не заменит такого читателя. Наблюдайте, где приходится угадывать термин, запрашивать доступ или искать недостающий пример.
Записывайте обнаруженные пробелы и исправляйте страницу. Если вопрос касается самого процесса, сначала согласуйте решение, затем обновите текст. Когда читатель останавливается из-за отсутствия полномочий, добавление ещё одного скриншота не решит проблему доступа.
Для удалённой команды тест можно провести асинхронно: дать задачу, попросить отмечать непонятные места и собрать вопросы в одном документе. Такой режим удобно связать с правилами, которые помогают наладить асинхронную работу.
Выберите место хранения и доступы
Сравнивайте инструменты на собственном сценарии: сотрудник ищет страницу, открывает связанные материалы, предлагает исправление и видит актуальную версию. Проверьте поиск, историю изменений, назначение прав, ссылки на разделы и возможность выгрузить содержание. Наличие функции в описании тарифа лучше подтвердить на пилоте.
Разделите права читателя, редактора и владельца. Материалы для всей команды и инструкции с ограниченным доступом могут требовать разных разделов. Не делайте базу публичной ради удобной ссылки, если в ней есть внутренние сведения.
Список доработок удобно вести отдельно от справочных страниц. В Strive можно организовать общие задачи: «Написать», «Проверить», «Обновить». В карточке укажите ссылку на материал и ожидаемое исправление. Такой список помогает контролировать подготовку базы; инструмент хранения документов выбирайте по требованиям к самой базе.
Другой вариант для очереди обновлений — показать этапы подготовки на доске Канбано. Каждая карточка может соответствовать одной инструкции: от найденного вопроса до проверенного материала. Выберите одну доску для этой очереди, чтобы не поддерживать несколько копий статусов. Саму инструкцию храните в выбранной базе знаний, а в карточке укажите ссылку на неё.
Если вместе с базой меняется система рабочих задач, полезно заранее выбрать подходящий трекер. На пилоте проверьте переход от карточки к инструкции под обычной учётной записью сотрудника.
Сделайте обновление частью процесса
Назначьте владельца каждой опубликованной страницы и способ сообщить об ошибке. Причиной пересмотра может быть изменение инструмента, состава ролей, порядка согласования или обнаруженная проблема при выполнении. Периодическая проверка дополняет эти события.
При обновлении укажите, что изменилось и кому нужно это знать. Для существенной правки отправьте сотрудникам краткое уведомление со ссылкой на действующую страницу. Полностью копировать инструкцию в сообщение не стоит: следующая версия снова потребует синхронизации.
Если материал больше не действует, обозначьте его статус и дайте ссылку на замену. Архивный документ может быть нужен для истории, но читатель должен сразу понимать, можно ли следовать его шагам сегодня.
Что проверить после запуска
Оцените несколько реальных сценариев: находят ли люди нужную страницу, открываются ли ссылки, какие вопросы остаются без ответа и какие инструкции требуют помощи автора. Количество страниц само по себе не отвечает на эти вопросы.
Для первого разбора составьте список найденных пробелов и выберите несколько исправлений. Не обещайте заранее процент экономии времени: его можно обсуждать только после измерения в вашем процессе. В распределённой команде полезно также проверить доступность ответственных и правила ожидания ответа — это помогает согласовать правила взаимодействия.
Начните с одного процесса и нескольких проверенных инструкций. Когда команда сможет находить их и выполнять описанные действия, добавляйте соседние разделы. Такой порядок позволяет исправлять структуру, пока объём базы ещё небольшой.