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

Привет! Меня зовут Владимир Манеров, я исполнительный директор компании TEAMLY. А еще руковожу отделом разработки продукта. Мы делаем базу знаний и параллельно сами в ней же и работаем над разработкой, т. е. делаем продукт в продукте. Решил рассказать, какой от этого профит мне — руководителю и моим сотрудникам.

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

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

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

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

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

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

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

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

2 Командный подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вообще совместная работа предполагает, что все в команде должны знать обо всех изменениях, которые происходят в проекте. Без этого никак.

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

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

Вообще совместная работа предполагает, что все в команде должны знать обо всех изменениях, которые происходят в проекте. Без этого никак.

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

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

Тут красноречиво все скажут цифры. Сейчас у нас работает 5 команд, которые разрабатывают свыше 50 модулей. При этом мы в 1.5 раза улучшили качество и скорость разработки. Отсюда вывод, что БЗ можно (а иногда даже нужно!) использовать не только в классическом режиме, но и в режиме командной работы, когда вся команда вовлечена в создание знаний и в проработке требований. Если вы хотите создать свою идеальную базу знаний — нужно приложить много усилий, но результат того стоит.

Для тех кому интересно больше об управлении знаниями, – заходите в наш Телеграм-канал или на YouTube. Там много полезного: советы по организации базы знаний, фреймворки для командной работы и кейсы создания крупных систем управления знаниями. А ещё, там мы первым делом анонсируем все наши образовательные мероприятия. Подписывайтесь, чтобы не пропустить!