Как мы внедрили свою же базу знаний в команду разработки базы знаний: какую придумали структуру, шаблоны и инструменты

Сначала небольшая предыстория

Когда мы только начинали создавать платформу для управления знаниями и совместной работы TEAMLY, у нас в команде было 5 человек и мы сидели в одной комнате. Это было 2 года назад.В таких условиях делиться информацией было очень легко. Каждый из нас знал обо всех изменениях, которые происходили в проекте. Бизнес начал стремительно развиваться, а с ним стала расти и команда. Это означало частый онбординг.

Каждый новый сотрудник должен был влиться в команду так, чтобы мы не потеряли в скорости разработки. У нас уже была сырая БЗ в разработке и с командой мы приняли решение, что все накопленные знания мы упакуем в свою же TEAMLY. Да, мы начали разрабатывать TEAMLY в TEAMLY. Получилось, что мы тренируемся на кошках, точнее на самих себе и других отделах, на которые вскоре масштабировали ТИМЛИ.

Мы внедряем фичу, тестируем на очевидные баги, о неочевидных рассказывают сотрудники, а не клиенты, мы фиксим и дорабатываем функционал по честным отзывам своих же сотрудников.

Немного теории

Есть два подхода к укрощению корпоративных знаний, которые мы используем:

Классический подход. Когда небольшое количество людей создают материалы, как правило, руководители отдела или тимлиды, а все остальные сотрудники с этими материалами работают.

Командный подход. При таком подходе вся команда вовлечена в создание знаний, если проще - каждый работает в базе знаний. Здесь вся команда управляет и прорабатывает требования в процессе создания проекта.

Побольше конкретики

Классический подход

Этот блок будет интересен руководителям подразделений, отделов или проектов. Рассказываю, как я и мои коллеги описываем в базе знаний регламенты, инструкции и бизнес-процессы.

Когда я только начал это делать, то понял, что оптимальнее всего фиксировать инструкции в едином шаблоне. Так сотрудникам проще с ними работать и лучше усваивается информация. 

Появился шаблон: вначале идет описание процесса, затем блок про то, без чего процесс не может быть начат, далее описываете каждый шаг процесса со ссылками на инструкции, как правильно его выполнить. Потом идет блок итога данного процесса. А в самом низу два ключевых раздела: вопрос-ответ и чек-лист проверки себя. 

Еще мы с коллегами описываем все инструкции по работе с базой знаний внутри своей базы знаний. Здесь выбрали другую структуру, потому что функционала в разработке много. Мы раздробили его на маленькие модули, а эти модули — на функции. Каждую функцию мы стараемся описывать по принципу userstory и use case.

Но мы столкнулись с типичной проблемой: сотрудники неохотно хотели узнавать информацию из базы знаний. Тогда мы поняли, что культуру работы с БЗ надо внедрять с младых ногтей, т. е. с первых дней работы в команде.

Все описанные материалы упаковали в модуль обучения и запустили курс онбординга — там же, в базе знаний, наш функционал позволяет. Теперь каждый сотрудник у нас с первых дней проходит этот курс и приучается искать и, главное, находить нужную информацию в БЗ.

Также с командой мы ведем статью с релизами, где описываем все функционалы, которые отгружаем. Здесь мы детально описываем тот или иной функционал и как он может влиять на другой функционал. Похоже на заколдованный круг, но это удобно: каждый в команде, прочитав эту статью, может понять, как тот или иной функционал может влиять конкретно на его работу и внести корректировки в работу тех функций, которые находятся на этапе разработки.

Внутри базы знаний мы создаем рабочие пространства для каждой компетенции в компании: дизайнеров, разработчиков, сисадминов и тд. Тем, кто работал в Confluence такая работа в пространствах знакома.

В каждом пространстве всегда есть четыре ключевых раздела:

1. Регламенты, по которым работает эта компетенция;

2. Раздел примеров. Здесь стараемся любой материал, который мы когда‑либо делали, упаковать в пример и добавить в БЗ. Когда в будущем сотрудник будет делать похожую задачу, ему не придется изобретать велосипед. Он просто найдет похожий пример и на его основе с первого раза хорошо выполнит задачу;

3. Готовые решения. Когда мы разрабатываем какой‑либо функционал, мы заворачиваем его в готовый модуль. В будущем его можно будет переиспользовать: будь то отчеты или реальные функции в проекте;

4. Полезная информация. К этому разделу есть доступ у всех сотрудников компании. Сюда можно добавлять полезные статьи, референсы и другую интересную информацию.

У меня есть несколько советов, как мы используем базу знаний в режиме классического использования:

1. Описывайте регламенты в едином шаблоне Это удобно. Сотрудники знают где что находится, они привыкают к этому шаблону и легче работают с большим объемом материалов, описанных разными людьми со своими взглядами на жизнь.

2. Начинайте описывать регламенты от процесса: опишите каждый шаг и к нему сделайте ссылку на инструкцию, как правильно выполнить этот шаг процесса.

3. Добавляйте в статью визуальные решения: графики, таблицы, диаграммы из Diagrams.net — визуал всегда запоминается лучше.

4. Важный совет: добавляйте в каждый регламент и инструкцию блок с вопросами и ответами. В следующий раз, когда к вам придет сотрудник с какими-то вопросами, постарайтесь ответить на них через базу знаний. Постарайтесь описать