Привет! Меня зовут Виталий Чесноков. Эта статья — продолжение истории о том, как мы выстраивали систему управления знаниями в QSOFT.

В предыдущих сериях

В прошлой статье я рассказывал про то, как управление знаниями в QSOFT только начало формироваться.  

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

Именно в этих блогах начала формироваться культура открытого обмена знаниями.

Можно было все, никаких рамок. 

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

Новые вызовы при быстром росте компании

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

Вырос штат, появилась иерархия

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

Не было времени обучать сотрудников   

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

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

Решение напрашивалось само собой: нужно создать единую базу знаний внутри компании. 

С чего мы начали

Сказано — сделано. На корпоративном портале мы создали единую структурированную базу знаний: QBok. 

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

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

Наполнять разделы QBok начал топ-менеджмент и руководители отделов. Почему сразу не подключили сотрудников?

Логика очень простая:

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

• Нужны были ответственные и инициативные люди, которые задавали бы вектор для всех остальных. У нас не было knowledge manager’a. Руководители вначале договаривались между собой, какими будут правила, и потом доносили их до подчиненных. Без четких и прозрачных договоренностей это было бы не управление, а анархия. 

• Если руководителю нет дела до базы знаний, то и остальным не будет. 

Как наполнялась QBok

Расскажу на примере раздела с бизнес-процессами — самого интересного для гендиректора.  

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

 Он сам внедрял бизнес-процессы и описывал их в QBok. Раз в неделю он проводил обучение для сотрудников: читал лекции, объяснял как пользоваться базой знаний, отвечал на вопросы. 

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

В результате у нас в разделе «Бизнес-процессы QSOFT» появилось 52 классных статьи, которые были хорошо оформлены, и закрывали много пробелов в знаниях. Причем, это были неявные знания, которые не всегда четко формулировали для себя даже сами сотрудники. Что такое неявные знания, я рассказывал в статье.  

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

Как наполнялась QBok: действие второе

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

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

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

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

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

 Для нас главными были две вещи:

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

2. Сделать немного ближе к практике. Мы перерабатывали все статьи так, чтобы было наглядно и понятно: как меняются ответственные в этом проекте, из каких этапов и процессов он состоит на практике, какие есть контрольные точки.

   Было:

Стало:

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

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

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

Каждый участник должен подготовить к стирингу документы и данные. Мы написали инструкцию «Как подготовиться к стирингу» и дали всем участникам ссылку. 

А дальше на самом стиринге наблюдали, готов человек или нет. Если не готов, выясняли причину. 

Чаще всего, их две: не читал/читал, но не понял. Если не читают, то менять надо не статью, а контекст. А если из 10 человек 9 прочитали, но не поняли — значит дело в самой статье. 

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

Плюсы:

• У нас появилась структурированная и наполненная база знаний. 

• Эти статьи помогали и в работе, и обучении сотрудников.

• Появилось описание белых пятен: того, что было на практике, но не было нигде зафиксировано

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

  Минусы:

• Не была решена проблема с актуализацией. Что статью пора актуализировать, мы понимали только в процессе работы.

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

• Базу знаний наполняли только руководители. 

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