Привет! Меня зовут Виталий Чесноков. Эта статья — продолжение истории о том, как мы выстраивали систему управления знаниями в QSOFT.
В предыдущих сериях
В прошлой статье я рассказывал про то, как управление знаниями в QSOFT только начало формироваться.
Сначала это были блоги на корпоративном портале. В них не было редполитики, выстроенной системы документирования и управления актуальностью. Но, несмотря на несерьезный вид, свою задачу они все-таки выполняли.
Именно в этих блогах начала формироваться культура открытого обмена знаниями.
Можно было все, никаких рамок.
Например, в блоге одного сотрудника была запись про то, как он отмечал Новый год в Париже и рядом полезная инструкция для техподдержки. Эту инструкцию мог прочитать любой сотрудник и скинуть ссылку коллеге. Через несколько лет компания выросла, и нужен был новый подход к управлению всей информацией.
Новые вызовы при быстром росте компании
Когда прошла эйфория, мы поняли, что быстрый рост — это не только классные возможности, но и проблемы.
Вырос штат, появилась иерархия
Раньше можно было пойти и напрямую спросить все у генерального. Теперь нет. Пришло время внедрять бизнес-процессы и описывать их.
Не было времени обучать сотрудников
Мы открыты к людям с разным уровнем опыта. Я сам вырос от фронтендера до генерального директора. Но не только я: руководители программ обучения менеджеров и разработчиков, директор по развитию тоже выросли из рядовых сотрудников и до сих пор работают в компании. Перспективных джунов мы обучаем «под себя», а более опытных людей просто погружаем в процессы и особенности работы именно у нас.
Но когда к одному человеку приходит сразу три команды, нет времени ни на какие онбординги. И если ничего не менять, вся открытость испарится. Поэтому обучающие материалы нужны были позарез.
Решение напрашивалось само собой: нужно создать единую базу знаний внутри компании.
С чего мы начали
Сказано — сделано. На корпоративном портале мы создали единую структурированную базу знаний: QBok.
Для каждой ключевой компетенции сделали свои разделы знаний: проджекты, продажники, разработчики, дизайнеры, аналитики и маркетологи. Каждый отдел должен был сам его наполнять: писать инструкции, гайды, чек-листы и правила для своего отдела. Отдельно мы создали раздел, где описывали все бизнес-процессы компании.
В этих разделах, в отличие от блогов, уже было дерево статей, была обезличенность, легче было поддерживать актуальность. Единственный минус: нельзя было вести совместную работу. Рабочие документы создавались в одном месте, материалы, которые делали специально для базы знаний — в другом.
Наполнять разделы QBok начал топ-менеджмент и руководители отделов. Почему сразу не подключили сотрудников?
Логика очень простая:
У нас была цель донести до сотрудников, что изменится в их работе с внедрением бизнес-процессов. Никто лучше руководителя этого не расскажет.
Нужны были ответственные и инициативные люди, которые задавали бы вектор для всех остальных. У нас не было knowledge manager’a. Руководители вначале договаривались между собой, какими будут правила, и потом доносили их до подчиненных. Без четких и прозрачных договоренностей это было бы не управление, а анархия.
Если руководителю нет дела до базы знаний, то и остальным не будет.
Как наполнялась QBok
Расскажу на примере раздела с бизнес-процессами — самого интересного для гендиректора.
Для их внедрения мы пригласили человека с опытом работы в корпоративной среде. Все наши топ-менеджеры выросли в QSOFT, поэтому нужен был человек со свежим взглядом и абсолютно другой точкой зрения.
Он сам внедрял бизнес-процессы и описывал их в QBok. Раз в неделю он проводил обучение для сотрудников: читал лекции, объяснял как пользоваться базой знаний, отвечал на вопросы.
Каждая статья была очень подробной, хорошо структурированной и раскрывала тему. К тому же, она была красиво оформлена, её хотелось читать. К самым трудным темам было видео с пояснениями.
В результате у нас в разделе «Бизнес-процессы QSOFT» появилось 52 классных статьи, которые были хорошо оформлены, и закрывали много пробелов в знаниях. Причем, это были неявные знания, которые не всегда четко формулировали для себя даже сами сотрудники. Что такое неявные знания, я рассказывал в статье.
Казалось бы, цель достигнута. Пора открывать шампанское и праздновать. Бизнес-процессы описаны, эти статьи уже можно использовать как готовый материал для обучения джунов. Но задача не решилась в одно действие.
Как наполнялась QBok: действие второе
Мы сразу стали активно применять эти статьи в онбординге. И на практике получился неожиданный эффект. Те статьи, которые были понятны управленцам и топ-менеджерам, оказались абсолютно непонятны джунам.
Например, приходит новый менеджер. Ему дают задание: заполни SRS на своем проекте.
SRS (Software requirements specification) — это артефакт, где собраны все функциональные требования.
Руководитель отправляет его в QBok. Там человек читает, как собрать эти требования, как их правильно описать, какой инструмент использовать и так далее. Но непонятно, что конкретно надо сделать, чтобы выполнить задачу. С чего начать? Как поставить тикет? Сколько времени выделить на эту работу?
Поэтому мы взяли курс на то, чтобы переработать форму подачи статей. Цель: сделать их однозначными и более понятными.
Для нас главными были две вещи:
Скорректировать чисто стилистически. Корпоративный язык трудно было воспринимать. Поэтому мы отредактировали форму, добавили примеров и расшифровку терминов.
Сделать немного ближе к практике. Мы перерабатывали все статьи так, чтобы было наглядно и понятно: как меняются ответственные в этом проекте, из каких этапов и процессов он состоит на практике, какие есть контрольные точки.
Было:
Стало:
Проверка стирингами: как оценивали эффективность
Мы не ориентировались на формальные критерии: количество просмотров или комментариев. Нам не так важно, сколько именно человек прочитали статью. Важно, как хорошо люди усвоили её смысл. Основной критерий — это обратная связь.
Объясню на примере. У нас в QSOFT есть такой процесс как стиринги. Это встречи, на которых мы обсуждаем основные метрики проекта и смотрим, укладываемся ли в план по затратам времени и денег.
Каждый участник должен подготовить к стирингу документы и данные. Мы написали инструкцию «Как подготовиться к стирингу» и дали всем участникам ссылку.
А дальше на самом стиринге наблюдали, готов человек или нет. Если не готов, выясняли причину.
Чаще всего, их две: не читал/читал, но не понял. Если не читают, то менять надо не статью, а контекст. А если из 10 человек 9 прочитали, но не поняли — значит дело в самой статье.
Мы поняли, что добились своей цели, когда все, кто прочитал статью, пришли на стиринг готовыми. И никто перед этим не задавал коллегам очевидные вопросы.
Плюсы:
У нас появилась структурированная и наполненная база знаний.
Эти статьи помогали и в работе, и обучении сотрудников.
Появилось описание белых пятен: того, что было на практике, но не было нигде зафиксировано
После того, как мы переработали статьи по фидбеку, эти знания стали не формально, а реально применяться на практике.
Минусы:
Не была решена проблема с актуализацией. Что статью пора актуализировать, мы понимали только в процессе работы.
Неявные знания есть ещё в рабочих документах и чатах. Пока мы никак не могли их зафиксировать.
Базу знаний наполняли только руководители.
На этом результате мы не остановились, и продолжили дальше. В следующей статье я расскажу про то, как нам удалось подключить сотрудников к ведению базы знаний и как мы сделали для этого собственное ПО.
