На основании чего сформировали требования к платформе:
- Должен быть полнотекстовый поиск, а не только по названию статьи. Когда заметок становится свыше 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‑командам. В свою очередь этот курс может быть включен в другой и так далее. На выходе у нас есть дорожная карта курсов и модулей.