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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Добавляйте чек-листы проверки себя. Когда вы проверяете документ, отчет, акт или регламент, постарайтесь зафиксировать в БЗ все ошибки, которые допустил сотрудник. Чтобы следующий сотрудник смог проверить себя и не допустить таких же ошибок. Постарайтесь фиксировать даже самые маленькие ошибки, вплоть до орфографии или отступов. Чтобы вам не приходилось по 10 раз проверять и объяснять одно и тоже. 

6. Если вы только начинаете создавать БЗ, не гонитесь за идеальной внутренней структурой. Начните просто ее наполнять материалами, используйте теги, классификаторы. Когда материалов станет достаточно много, тогда и станет понятно, как лучше все организовать. 

Командный подход: все работают с требованиями через базу знаний

Для полной картины сначала расскажу о жизненном пути нашего проекта.

• Анализ и сравнение. Собираем референсы, делаем прототипы, описываем концепцию.

• Проектирование. Описывает функциональные и технические требования, рисуем дизайн.

• Разработка. 

• Актуализация инструкций.

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

С командой мы работаем так:

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

Да, мы согласовываем дизайн также через базу знаний. Это удобно, потому что комментарии не теряются в Фигме, они всегда структурированы и перед глазами. Согласовываем все мы тоже через БЗ.

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

Про внутренние инструменты

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

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

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

Еще мы начали делать отчеты внутри ТИМЛИ. Это аналог плагинов Page Properties и Page Properties Report, которые есть в Confluence. Это удобно для руководителей, когда нужно сделать отчет на базе команд или функционала, который находится в работе. Я сразу вижу, какие проекты сейчас в работе, в каком они статусе и кто ответственный.

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

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

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

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

Коротко о главном или наши ключевые правила по работе с БЗ в командном режиме

1. Знания нужно создавать в базе знаний, а не сохранять. Поэтому не принимайте у сотрудников материалы на проверку, если они не зафиксированы в БЗ. Не верьте тем, кто приносит отчет в гугл‑доке и божится, что потом перенесет все в базу знаний. Это потом не наступит никогда, а компания а моменте начнет терять ключевой актив — знания.

2. Постарайтесь упаковать все самые важные знания в модуль онбординга. Все новые сотрудники должны приучаться к культуре работы через БЗ и находить там ответы на свои вопросы. Чем больше вы создаете знаний, тем легче будет вашим сотрудникам. 

3. Принимайте решение на основе данных. Но данные — это не всегда цифры, это статьи, сравнения, референсы, прототипы, описанный опыт. Когда все это хорошо структурировано в едином месте, принимать решение проще.

4. Если вам хоть раз пригодились материалы из базы знаний, поверьте, они понадобятся снова. И если они собраны в одном месте — вы всегда знаете, куда за ними можно пойти и послать коллег.

Вывод

Тут красноречиво все скажут цифры.

Сейчас у нас работает 5 команд, которые разрабатывают свыше 50 модулей. При этом мы в 1.5 раза улучшили качество и скорость разработки. 

 Отсюда вывод, что БЗ можно (а иногда даже нужно!) использовать не только в классическом режиме, но и в режиме командной работы, когда вся команда вовлечена в создание знаний и в проработке требований. Если вы хотите создать свою идеальную базу знаний — нужно приложить много усилий, но результат того стоит.

Новая концепция управления знаниями в компании

Записывайтесь на онлайн-презентацию! Продемонстрируем интерфейс и все возможности платформы

Получить демо