Как создать практичную базу знаний для команды
Большинство команд, создающих базу знаний, сталкиваются с одной и той же проблемой: инструмент настраивается, первая партия документов пишется — и потом она медленно перестаёт использоваться. Вопросы продолжают поступать через Slack. Ответы снова печатаются по памяти. База знаний превращается в исторический архив, которому никто не доверяет.
Проблема почти никогда не в программном обеспечении. Дело в подходе. Это руководство о том, как создать базу знаний, которой небольшие команды и knowledge workers будут реально пользоваться — что в неё помещать, как структурировать, кто должен ею владеть и как не дать ей устареть.
Для чего на самом деле нужна база знаний
База знаний — это централизованное, доступное для поиска место, где команда хранит ответы на вопросы, которые люди задают чаще одного раза. Не заметки со встреч. Не задачи проектов. Не архив документов. Переиспользуемые ответы на повторяющиеся вопросы.
Тест на то, что должно войти в базу знаний: кто-то уже спрашивал об этом больше одного раза, или спросит ещё? Если да — запишите один раз и дайте ссылку. Если нет — это, вероятно, относится к документу проекта, заметке со встречи или не нуждается в постоянном хранении вовсе.
Что документировать в первую очередь
Начните с пяти вещей, о которых ваша команда реально спрашивает неоднократно. Не полный операционный мануал. Пять вопросов, отнимающих больше всего времени.
Типичные отправные точки для небольших команд:
- Как новые люди настраиваются (инструменты, доступы, первые шаги)
- Как работают повторяющиеся процессы (выставление счетов, онбординг клиентов, публикации, отчётность)
- Где что находится (какая папка, какой инструмент, какая версия актуальная)
- Решения, которые пересматриваются снова и снова (почему выбрали X, а не Y, какова политика по Z)
- Ответы на вопросы клиентов, которые команда получает регулярно
Сопротивляйтесь соблазну документировать всё при запуске. База знаний с пятью хорошо поддерживаемыми страницами полезнее той, где пятьдесят устаревших.
Структура, работающая для небольших команд
Держите структуру верхнего уровня плоской. Трёх-пяти разделов достаточно для большинства небольших команд:
- Как мы работаем — процессы, инструменты, нормы, решения
- Начало работы — шаги онбординга, доступы, первые задачи
- Справочник — шаблоны, глоссарий, ключевые контакты, утверждённые тексты
- Клиенты / Проекты — если применимо
Сопротивляйтесь построению глубокой иерархии. Каждый уровень вложенности усложняет поиск. Если статью можно разместить в двух местах, она, вероятно, не принадлежит ни к одному из них и нуждается в лучшем заголовке.
Как писать статьи, которые читают
Статьи баз знаний не работают, когда они слишком длинные, слишком расплывчатые или написаны для автора, а не для читателя.
Практические правила:
- Пишите для человека, задающего вопрос, а не для того, кто знает ответ
- Один вопрос на статью. Если отвечаете на два вопроса — напишите две статьи
- Используйте шаги для процессов, маркеры для списков, короткие абзацы для объяснений
- Ставьте ответ в начало, а не в конец длинной преамбулы
- Добавляйте дату «последней проверки», чтобы читатели знали, можно ли доверять информации
Владение: часть, которую большинство команд пропускает
У каждой статьи в базе знаний должен быть владелец — именованный человек, ответственный за поддержание её актуальности. Без владения ничего не обновляется. Владелец не обязан писать каждое правки, но должен замечать, когда что-то не так, и исправлять это.
Для небольших команд владение обычно простое: тот, кто ведёт процесс, владеет документом этого процесса. Человек, занимающийся выставлением счетов, владеет статьёй о выставлении счетов. Человек, управляющий онбордингом, владеет страницами онбординга.
Как не дать базе знаний устареть
База знаний устаревает, когда обновляется реактивно — только после того, как кто-то замечает проблему. Выстройте минимальный цикл проверки:
- Помечайте каждую статью датой проверки (ежеквартально достаточно для большинства контента)
- Когда процесс меняется — обновляйте статью как часть изменения, а не потом
- Добавляйте примечание вверху, если что-то устарело и пересматривается — это лучше, чем оставлять неверную информацию
- Удаляйте или архивируйте статьи, утратившие актуальность. Устаревший контент подрывает доверие ко всему остальному
Выбор инструмента — после определения процесса
Самая распространённая ошибка — выбирать программное обеспечение до определения того, что база знаний должна делать. Инструмент должен соответствовать реальному воркфлоу команды, а не наоборот.
Для большинства небольших команд инструмент для базы знаний должен удовлетворять короткому списку: лёгкость написания для нетехнических людей, быстрый поиск, чистое отображение, простые разрешения. Сверх этого различия между инструментами менее важны, чем то, насколько последовательно команда использует любой выбранный.
Распространённые варианты: Notion, Confluence, Slab, Tettra, Outline (открытый код, самостоятельный хостинг), AFFiNE (открытый код). Общая папка в Google Drive или Dropbox Paper тоже может работать для маленьких команд с простым контентом. Лучший инструмент — тот, который ваша команда реально будет открывать.
Минимально жизнеспособный запуск
Чтобы начать работу базы знаний на этой неделе без долгой фазы планирования:
- Выберите один инструмент, который команда уже использует или готова попробовать
- Напишите пять статей, отвечающих на пять самых частых вопросов
- Назначьте владельца каждой статье
- Поделитесь ссылкой в чате команды и объясните, для чего это
- Добавляйте новые статьи, когда отвечаете на повторяющийся вопрос — не по расписанию, а в момент
База знаний растёт из использования, а не из планирования. Начинайте маленько, поддерживайте точность и расширяйтесь оттуда.