Продолжаю свою историю о службе поддержки в GlowByte. (“Начало”, “Врываемся в DevOps”, “Ищем баги”, “Упрощаем работу в поддержке и познаем код”). Не раз я упоминала базу знаний. Пришло время рассказать, как она зародилась и чем стала сейчас.
База знаний – это отдельный большой вопрос. С первых дней в GlowByte я оказалась в огромном потоке информации и боялась все забыть. А еще мне казалось странным, что коллеги передают знания из уст в уста и каждый новичок тратит большое количество времени на то, чтобы что-то узнать. Так что люди, у которых есть проблемы с коммуникацией или обучением (когда “в рот не вкладывают”), рисковали навсегда остаться на галерах. Передача знаний в моих глазах выглядела первобытной, и я подумала, что раз у других нет базы знаний, она будет у меня.
На просторах интернета я не обнаружила каких-то четких туториалов, как структурировать свои знания, но нашла множество подходов и приложений для ведения заметок. Кто-то писал, что нужно записывать только темы: чтобы напоминать себе в будущем, о чем было знание. Кто-то предлагал сохранять ссылки на статьи в интернете, чтобы потом по ним восстанавливать знания. Еще советовали записывать свои короткие заметки на пару предложений, чтобы потом прочитать это в интернете еще раз. Предлагали писать целые инструкции с подробным описанием, как книгу.
Я начала с Miro: сделала карточки с темами и от них – стрелки к смежным темам. Получились деревья знаний, но без содержательной информации. Недолго спустя все это разрослось и потеряло структуру. Стало вовсе не наглядно и не понятно, так что и желания перечитывать записанное не появлялось. Пришлось вернуться к изучению подходов фиксации информации.
Попробовала записывать полезные команды Linux и запросы к БД, полезные предложения и факты о чем-либо просто в блокноте. Получилось огромное длинное полотно, в котором было сложно ориентироваться. Снова не то.
Затем я просто открыла Word и начала писать “книгу”. Это было длительное объяснение всех моих знаний, последовательностей фактов, инструкции how-to. Получилось настолько трудозатратно, что в какой-то момент мой график рабочих активностей превратился в такой: днем я выполняю рабочие задачи, вечером реализую свою инициативу с базой знаний. Но, надо сказать, на тот момент это было очень увлекательно. К тому же я тогда решила структурировать и иные знания в сфере IT, не только те, что получаю в GlowByte: я боялась забыть что-то, на что потратила время ранее.
Спустя пару месяцев документ стал увесистым, и опять закралось сомнение в правильности подхода. Я решила поспрашивать знакомых и друзей, как именно они структурируют свои знания и делают ли это вообще. 80% мне ответили, что они вообще не думают об этом, не ведут никаких баз знаний и уж тем более не занимаются тем, чтобы учить других. Основной аргумент: если я знаю, я как-то это узнал, значит и другой сам может раздобыть эту информацию. Тогда я решила, что тоже не буду ничего записывать. Но внезапно в моей жизни случилось кураторство. Я стала тем самым человеком, который из уст в уста должен передать знания новому человеку.
Новичок, это было ожидаемо, не мог запомнить с первого раза, переспрашивал, и приходилось по нескольку раз разными словами объяснять одно и тоже. Это было утомительно и довольно скучно. Еще я понимала, что неэффективно тратится рабочий ресурс, неэффективно и само погружение людей, которые не имели до этого опыта работы, в задачи. И я вернулась к мнению тех самых 20% из числа опрошенных, которые рассказали мне, что они либо сами, либо вместе с рабочей командой ведут корпоративную базу знаний.
Я узнала о методе «Зеттелкастен». Его придумал социолог Луман. У него был шкаф с ящиками, в которых он хранил карточки с информацией. На каждой карточке была записана только одна идея. Карточки были пронумерованы, и связанные идеи были прилинкованы ссылками. Например, есть какой‑то факт про работу желудка («желудок ферментирует пищу»), и есть какой‑то факт про кишечник («в кишечник пища попадает после ферментирования пищи»). Мы записываем эти факты на отдельных карточках и нумеруем их 1 и 2 соответственно. Затем мы указываем, что факт 1 связан с фактом 2 (записываем связь на карточке). И аналогичным образом создаем обратную связь. Чтобы карточки было легко искать, нужно положить их в отсортированном порядке. Большие группы знаний можно поделить на отдельные непересекающиеся спейсы.
В современном мире для структурирования знаний таким образом есть много приложений. Мой выбор пал на Obsidian. Это бесплатный инструмент, который поддерживает синтаксис Markdown для написания заметок, имеет функционал древовидного содержания (сортировка карточек по алфавиту или нумерации) и имеет функционал отрисовки взаимных ссылок: такая карта помогает строить second brain и визуально отражает набор накопленных знаний. Так, руководствуясь методом «Зеттелькастен», я переписала свою «книгу» из Word и начала вместо пересказов присылать новичкам свои заметки. Это оказалось очень удобно и продуктивно: они стали меньше переспрашивать.
Я продолжила наполнять свой Obsidian, включая информацию, которая прямо не относилась к работе, но касалась IT‑тематики. Например, если одним из выходных вечеров я программировала что‑то для себя по С++ и узнавала что‑то новое, то это обязательно записывала в заметки. В конце дня, недели, месяца было приятно измерить прогресс количеством полученных заметок (= знаний) за период и верить в то, что время проходит продуктивно и с пользой.
Далее про мою базу знаний стали узнавать и спрашивать все больше и больше коллег из GlowByte. Возникла потребность не просто пересылать заметки в личные телеграм‑сообщения, а размещать на полноценном портале, куда может зайти каждый желающий и почитать то, что ему нужно. На тот момент казалось, что такой инструмент должен быть непременно бесплатным, и для платформы базы знаний мы выбрали Wiki.js. Это сервис, который можно установить на своем сервере из Git‑репозитория и переписать в нем в синтаксисе Markdown заметки. Он не поддерживает красивую карту ссылок, как Obsidian, но имеет веб‑интерфейс, и коллегам этого было достаточно.
Итак, я продолжала писать в Obsidian, а в Wiki.js я выкладывала то, чем хотелось поделиться с коллегами. Так было передано более 500 инструкций вида how‑to с объяснениями неочевидных вещей, архитектур систем и сервисов, полезными лайфхаками и прочим. Мы прожили на такой платформе ровно год, собрали обратную связь от всей команды поддержки и выявили недостатки как в платформе, так и в самой структуре базы знаний.
На основании чего сформировали требования к платформе:
Должен быть полнотекстовый поиск, а не только по названию статьи. Когда заметок становится свыше 500, а пользователей заметок — больше 25, то просто поиск по названию статьи (как это было в Wiki.js) — плохая история. Люди искали по вхождению слов внутри статей и не находили нужной информации.
Должно быть древовидное наглядное содержание. Очень важно иметь структуру во множестве заметок. Чтобы люди понимали, нужно ли им это читать, какую пользу несет статья, о чем эта статья, нужно наглядное содержание. В Wiki.js длинные названия заголовков обрезались, и часто содержание выглядело неинформативным.
Должна быть поддержка ссылок — как внутренних, так и внешних. И при изменении пути к внутренней статье, на которую есть ссылка, ссылка должна изменяться автоматически.
Должна быть поддержка вставки картинок, видео, документов. Мы проводим внутри митапы, записывая встречи. Записи хотелось бы сохранять в базе знаний и делиться ими с другими. При этом часто такие митапы являются закрытыми — нам не подходят публичные видеохостинги. В Wiki.js видео не поддерживались, и мы вставляли их только через ссылки на корпоративный диск.
Должен быть функционал комментариев и обратной связи от читателей. Обратная связь — это очень важно. Без нее будет непонятно, действительно ли база знаний нравится всем и есть ли у нее читатели. Также положительная обратная связь мотивирует старых и новых авторов писать больше и делиться своими знаниями. На основе аналитики обратной связи мы можем строить прогнозы по улучшению как самой платформы, так и структуры заметок.
Должны быть уведомления для подписчиков раздела. Очень грустно, когда автор добавляет что‑то в базу знаний, но про такую инструкцию узнают случайно или вообще не узнают. Когда наши статьи были в Wiki.js, нам пришлось создать внутренний Telegram‑канал, чтобы авторы вручную анонсировали выход новых статей и разделов. В этом процессе было много ручной работы, и в какой то момент авторы все реже стали делать анонсы, а в какой‑то момент и вовсе перестали.
Должна быть история версий и возможность отслеживать редактирование и авторство. Ранее мы модерировали все статьи вручную. Если автор ошибался или «затирал» изменения другого коллеги или вносил некорректную информацию, то за такие ошибки отвечал модератор, потому что он читал каждую статью и добавлял в базу знаний только то, что считал правильным. Этот ручной процесс был очень трудоемким, и мы поняли, что такой функционал, как контроль версий и имена авторов, является важным для полноценной хорошей платформы.
Должны быть гибкие права доступов. В какой‑то момент мы поняли, что можем делиться некоторыми статьями вовне (с заказчиком, с пользователями интернета и т. д.) и что у нас есть приватные заметки только для определенной группы лиц. Чтобы разграничивать права и реализовывать эту задумку, нужны гибкие права доступов: каждый пользователь должен видеть только то, что ему положено.
К контенту и структуре мы тоже выдвинули требования. Они сформировались также на проблемах и отзывах пользователей:
Должна быть структура end‑to‑end. В какой‑то момент у нас появились заметки, которые были не связаны друг с другом, но относились к одной теме. Для новых пользователей это был «белый шум». Например, по СУБД Oracle мы написали заметку про блокировки в БД, про системные запросы и про оператора INITCAP. Все заметки по отдельности нужные и полезные, все относятся к одной теме Oracle, но их нельзя прочитать как книгу от начала до конца и погрузиться в Oracle. Эту проблему мы в будущем решили тем, что по каждой теме сделали внутренний курс с содержанием, отражающим последовательность чтения.
Заметки не должны содержать много воды. Начинающие авторы часто писали заметки, в которых было много вводных слов, вспомогательной информации, которая мешала восприятию материала. Я сформировала правила для авторов и на начальном этапе деятельности каждого давала советы по улучшению заметок.
Заметки надо начинать писать как до начала поддержки нового проекта, так и в процессе. Зачастую заметки и документация пишутся либо до приемки проекта на сопровождение (что имеет более структурированный формат), либо в процессе решения инцидентов по системе (и часто такая заметка — это комментарий в Jira). В нашем случае важно совмещать оба подхода, потому для этапов приемки мы сформировали требования к обязательному минимуму заметок, а также донесли до сотрудников важность написания заметок в момент, когда они закрывают инцидент.
Как итог, мы в GlowByte выбрали в качестве платформы решение Notion, которое закрыло большинство наших требований. Для структурирования заметок стали формировать обособленные курсы: например, заметки по Kubernetes структурируются, дополняются последовательным содержанием и образуют модуль. Для модуля указано, нужно ли знать что‑то иное, чтобы начать его читать, а также что именно содержится в модуле. Несколько модулей могут составлять курс: например, по Kubernetes, Docker и по Linux‑командам. В свою очередь этот курс может быть включен в другой и так далее. На выходе у нас есть дорожная карта курсов и модулей.
На текущий момент мы в нашей команде в GlowByte сделали пилотный проект внутренних курсов и ждем обратной связи от всей команды, чтобы в будущем улучшать это, пополнять новым материалом и радовать читателей.