Привет! Меня зовут Виталий Чесноков. Я генеральный директор QSOFT и сооснователь TEAMLY — платформы для совместной работы и управления знаниями.

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

Зачем было создавать базу знаний 

Все просто. Раньше вместо базы знаний у нас были блоги на корпоративном портале.
Кто‑то писал о том, как отметил Новый год в Париже, а кто‑то выкладывал инструкции для техподдержки. То есть польза была, но новичкам найти её иногда было сложно. Из‑за этого руководители тратили по часу, а иногда и по два часа каждый день, чтобы ответить на вопросы подчиненных о том, как у нас всё устроено.

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

Общая канва базы знаний

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

Кстати, если хотите подробностей о проектировании платформы и работой над юзер-френдли интерфейсом, дайте мне знать в комментариях, и я поделюсь этим опытом.

Итак, решающим критерием для нас была простота и понятность структуры базы знаний.

Было 4 основных тематических раздела:

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

2. Бизнес-процессы компании или QboK: сквозные процессы, которые затрагивают всех сотрудников. Время от времени туда заходят все, но чаще всего – менеджеры, т.к. они за эти процессы и отвечают.

3. Проекты для заказчиков: это артефакты и проектная документация по тому, что в работе.

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

Контентом их наполняли только руководители, а модерации не было. 

В какой-то момент к нам пришли даже офис-менеджеры и тоже попросили себе раздел. За ними потянулись и другие. Так мы поняли, что база знаний нужна.

Контент в разделах

Все разделы я сейчас обозревать не буду, возьму основной для всей компании – «Бизнес-процессы» или QboK. Руководитель этого направления сам внедрял новые бизнес-процессы и описывал их в статьях. Раз в неделю он проводил обучение для сотрудников: читал лекции, объяснял как пользоваться базой знаний, отвечал на вопросы.

Мы серьёзно заморочились с тем, чтобы каждая статья в базе знаний давала максимально полные ответы на часто возникающие вопросы: делали разбивку на тематические блоки, старались сделать красивое оформление, добавляли видео в конце и т.д. Работа была масштабная, я бы сказал – монументальная. Жаль, что мы так увлеклись процессом, что совершенно забыли о результате. База знаний была красивой, но неэффективной.

Как мы это поняли? Дали эти статьи нашим новым сотрудникам и ученикам школы менеджеров QSOFT. И ребята стали задавать вопросы, по которым мы поняли – они не понимают, что мы вообще написали.

Например, приходит новый менеджер. Ему дают задание: заполни SRS на своем проекте.

SRS (Software requirements specification) — это артефакт, где собраны все функциональные и требования. Мы на каждом проекте его составляем.

Руководитель отправляет его в QBok. Человек читает, видит очень увлекательную теорию. Но непонятно, что конкретно надо сделать, чтобы выполнить задачу. С чего начать? Как поставить тикет? Сколько времени выделить на эту работу? И идет спрашивать руководителя. Круг замкнулся. 

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

Действие второе: как мы по второму разу переделывали одни и те же статьи

Итак, что мы переделали, чтобы сделать статьи ближе к аудитории обычных сотрудников? Суть статей, в целом была верной. Но её не было видно за абстрактными формулировками и скучной подачей.

Что добавили, чтобы статьи работали лучше

Расшифровка терминов

Раньше все эти термины и аббревиатуры, да ещё на английском были прямо в теле статьи. И если не знаешь термин, приходилось спрашивать или гуглить. Мы сделали удобнее для пользователя: в начале статьи визуально выделили блок с расшифровкой и переводом. Если просто текстом, а не на каком-то цветном фоне, бывало не находили). Артефактам тоже всегда даем определение, потому что в разных компаниях их называют по-разному.

Краткое саммари метода + ссылка на источник

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

Схемы вместо полотна текста

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

Эту схему мы уже составляли применительно к нашей собственной работе. Конкретно в нашей компании за первичную обработку требований отвечают pre-sale аналитики. Они передают аккаунт-менеджеру первичную обработку требований заказчика, смету и план-график. Для детализации всех требований  аккаунт-менеджер составляет SRC. Затем на основе нескольких артефактов на следующем этапе уже формируется техническое задание. Просто нам кажется, что в виде схемы проще запомнить. 

Видеообзор раздела с тайм-кодами

Это видеозапись офлайн-лекции + список вопросов и ответов от сотрудников по теме статьи из базы знаний. Для тех, кто что-то не понял/ пропустил. Формат видео хвалили, но жаловались, что 1 час 28 минут просто не осилить. Поэтому мы добавили таймкоды, чтобы сэкономить людям время. 

Вопрос-ответ

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

Чек-лист

В конце статьи мы добавляем чек-лист для проверки самого себя, чтобы руководитель не тратил время на объяснение требований по каждой задаче. Нам кажется, что так меньше риск, что придется переделывать, потому что изначально все прописано довольно четко. 

Зона ответственности в процессе

Если мы описываем какой-то процесс, где задействовано сразу несколько участников, мы пишем в базе знаний: кто ответственный + описание роли. Этого изначально не было в базе знаний. Но эта несложная строчка по сути сняла нам много точек потенциального напряжения при работе в команде.

Когда человеку непонятна его зона ответственности, и он отвечает за все – начинается невротизация. Растет недовольство собой, процессами, коллегами. Отсюда выгорание, конфликты, увольнения и т.п. А так все публично прописано в базе знаний: за каждым закреплена его роль в проекте. И мы экономим время на выяснение, кто что должен + снимаем напряжение со всех членов команды.

Скорректировали стилистически

Давайте проведем мысленный эксперимент? Сколько раз вам нужно прочитать это предложение, прежде чем понять смысл?

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

Честно говоря, мне два.

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

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

Поклонники корпоративных формулировок брезгливо поморщились. Но статьи стали понятнее.

Проверка стирингами: как оценивали эффективность

Дальше мы стали проверять, в правильном ли направлении идем. Поэтому сначала переписать одну статью и проверить: правильная ли была гипотеза. У нас не стояло задачи измерить количество просмотров и т.д. Главное – честная обратная связь.

Объясню на примере. У нас в QSOFT есть такой процесс как стиринги. Это встречи, на которых мы обсуждаем основные метрики проекта и смотрим, укладываемся ли в план по затратам времени и денег. Каждый участник должен подготовить к стирингу документы и данные. Проблема была в том, что люди приходили на стиринг неподготовленными → если хотя бы один не готов, обсуждение затянется минимум на полчаса. 

Мы переписали инструкцию «Как подготовиться к стирингу» и дали всем участникам ссылку. Так и написали: “Ребята, это инструкция, что подготовить к стирингу. Обязательно прочитайте и подготовьтесь”. А дальше на самом стиринге наблюдали, готов человек или нет. Если не готов, выясняли причину. 

Чаще всего, их две: не читал/читал, но не понял. Если не читал, значит дело не в самой статье, а контексте вокруг. Слишком много задач, не успел. Либо человек неправильно расставляет приоритеты: думает, что у подготовки к стирингу – самый низкий. Кто-то просто ненавидит сам процесс подготовки, так же, как кто-то – заполнять таски. Кто-то просто не старается: читает по диагонали и готовится, лишь бы отстали.

А если из 10 человек 9 прочитали, но не поняли — значит дело в самой статье. 

После стиринга мы поговорили с ребятами. Всего было 10 человек. 6 после этой статьи пришли подготовленными. У 4 причины не готовиться были те, что я описал выше. Значит статьи свою функцию выполняют.

Конец

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

Но это тема отдельной статьи. Если интересно почитать наши материалы об управлении знаниями в другом формате, загляните в наш Телеграм-канал или на YouTube.