Базы, карты, чек-листы, или Зачем бизнесу управляющий знаниями
Гарри Клейн — американский психолог, исследователь интуитивных решений в экстремальных ситуациях. В своей книге «Источники силы» Клейн описал один случай: пожарная команда приехала вызов, в жилом доме горела кухня. Команда вошла в помещение и начала тушить огонь, но он не затухал. В какой-то момент командир почувствовал тревогу и приказал срочно уходить. Когда все вышли из дома, пол на кухне провалился. Оказалось, что пожар начался в подвале, а потом перекинулся наверх, поэтому погасить его на кухне не удавалось.
Позже Гарри Клейн опрашивал командира, чтобы собрать материал для книги и ему удалось разобрать его интуитивное решение на части: огонь на кухне был слабым, но при этом слишком много жара и дыма для такого пламени. Командир почувствовал, что ситуация опасная и вывел команду. Это пример «неявного знания», которое спрятано так глубоко, что оно проявляется только в реальной ситуации.
Вытягивать «неявные знания», которые особенно помогают в экстренных ситуациях — одна из задач менеджера по управлению знаниями. Например, упал продакшн, серверы отказываются работать, но никто не знает почему. При этом полгода назад случалось что-то подобное и проблему решил Петя: «подшаманил», подкрутил и все заработало. Правда, Петя ушел в другую компанию, а ретроспективу не проводили, в базу знаний происшествие и решение не добавляли, потому что и базы-то никакой нет. Но если бы в команде был управляющий знаниями, возможно, последствий было бы меньше, а проблема бы решилась быстрее.
Управляющий знаниями — это не должность, а функция
Управляющий знаниями — это человек, который организует условия, чтобы индивидуальные знания экспертов и опыт компании не терялись, анализировались и использовались для эффективного решения задач. Например, в Microsoft Services для этого есть отдельная должность — директор по управлению знаниями (Chief Knowledge Officer), который управляет отдельным подразделением. У директора много полномочий: он может продавать услуги подразделения другим отделам, покупать оборудование или разработку ПО у других отделов и распоряжается отдельным бюджетом.
Основа системы управления знаниями (УЗ) в Microsoft Services — сообщества практиков, которые работают с 2005 года. Сообществ больше 100, а экспертов несколько тысяч. Разработчику или продакт-менеджеру не нужно гуглить или отнимать время у коллег: в сообществе за минуту он найдёт эксперта по любой теме, задаст вопрос и получит ответ.
Похожая система работает в КРОК — IT-компании, которая профессионально занимается управлением знаниями. С помощью сообществ создаётся почти вся экосистема знаний компании. Это необходимо по специфике работы: КРОК — консалтинговая компания и продаёт знания своих экспертов. На каждую активность в компании (проект, презентация, исследование) создаётся группа, и в неё поступает вся информация: материалы, идеи по проекту, переписки.
В Microsoft Services и КРОК большие системы управления знаниями. Чтобы начать внедрять отдельные практики из управления знаниями в своей компании и получать пользу, большие системы не нужны. Достаточно начать с малого. Например, с пяти простых (относительно) практик, которые решают типичные проблемы бизнеса.
База знаний
База знаний — это первое и самое простое в управлении знаниями. Хорошо помогает для служб поддержки или колл-центров, и незаменим для компаний с велосипедами.
«Как главный архитектор многих проектов, вместе с другими инициативными людьми, я создавал систему исчерпывающей документации. Первоначально — на SGML, с исходниками под системой контроля версий и автоматической сборкой обновлений RTF и CHM каждую ночь, а позже на основе wiki-систем (примерно 2005 год).
В базу знаний мы добавляли шаблоны описаний, типовые примеры и различные диаграммы. Для документации использовали комментарии, как основу. База не только сохранилась в компании до сих пор, но и поддерживается и развивается командами проектов по умолчанию».
Максим Цепков
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Примечание. Подробнее о том, какие документы полезны в управлении знаниями и что в них фиксировать, читайте в расшифровке доклада Максима на Teamlead Conf 2018.
Здесь менеджер по УЗ работает как архитектор: отвечает за планирование и разработку инфраструктуры базы знаний, за структуру и иерархию документов. Чтобы в базе не накапливались правки, комментарии и дубли, задает общие правила.
Например, эту роль в компании может взять на себя технический писатель и написать сценарии и любые другие артефакты для системы управления знаниями. Писатели обычно умеют работать с алгоритмами, инструкциями, регламентами и бизнес-процессами.
Проектный офис
Проектный офис — это «расширенная» база знаний. В офис добавляют принятые и непринятые решения, и причины, по которым они выбраны или отброшены.
Кто-то столкнётся с проблемой, найдет причину, решит её и запишет все это в базу, а следующий сотрудник решит эту же проблему быстрее. Время на исследования, на тесты и гипотезы меньше — time2market сокращается.
Для проектного офиса подойдут простые системы управления документами, например, Google Drive. В нём можно обмениваться документами, выдавать права доступа и добавлять комментарии.
«Проектный офис это не просто база знаний. Для него я анализировала, что происходит в проектах, проводила интервью с разработчиками и собирала обобщенный опыт. На этой основе писала статьи, инструкции и описывала практики разработки продуктов».
Светлана Новикова
Руководитель группы технических писателей компании Ozon. Активист сообщества Write the Docs Russia, участник ПК KnowledgeConf 2020, ведёт Телеграмм-канал @the_know_all.
Проектный офис незаменим, когда в проекте много legacy. В настроенном проектном офисе легко посмотреть, почему выбирались определённые технологии, зачем добавлялась каждая часть кода или костыли. После обновления частей кода все изменения также легко добавить в базу для следующих «поколений» разработчиков.
«В бытность техническим директором до «Флант» с нуля обучил отдел разработки документировать. Актуальные архитектурные документы по API складывались в отдельный репозиторий на GitLab. По необходимости легко выяснить из каких требований растёт каждая строка кода. Это помогло устранить конфликты между разработкой и Q&A, потому что все понимали причины всех решений.
Во «Флант» расширил эту идею: организовал хранение документации в GitLab, научил людей ей пользоваться, выработал принципы шаринга знаний в виде ключевых инструкций и добился того, чтобы это заработало».
Игорь Цупко
Директор по Неизвестному во «Флант», участник ПК KnowledgeConf 2020, ведёт Телеграмм-канал @lovely_it_hell.
Карта компетенций
Карта или матрица компетенций — инструмент повышения квалификации и его контроля. Обычно выглядит, как таблица: по строкам имена сотрудников, а по столбцам — то, что они знают.
Пример матрицы из статьи «Тут живут драконы: матрица компетенций как инструмент тимлида».
В таблице наглядно видны провалы в обучении сотрудников. Показывает, кто главный носитель определённого навыка (который потом его передаёт другим), а кто просто рядовой пользователь. Карту компетенций может составить тимлид или техлид, чтобы оценивать уровень разработчиков команд.
«До «Флант» я был техническим директором в компании-разработчике. Мне хотелось, чтобы команда росла и решала задачи сложнее, а сотрудники повышали квалификацию. Для этого требовались прозрачные правила роста, обратная связь. В этом помогала матрица компетенций.
Но матрица подходит не всем. В компании «Флант» она не работала для DevOps-инженеров, потому что от десятков технологий и сотен нюансов «распухнет» до огромных размеров. Поэтому я модернизировал матрицу в Performance Review. Это уже процесс, который позволяет выявлять систематические проблемы с наймом, адаптацией и ростом сотрудников».
Игорь Цупко
Директор по Неизвестному во «Флант», участник ПК KnowledgeConf 2020, ведёт Телеграмм-канал @lovely_it_hell.
Чек-листы адаптации
Найм нового сотрудника всегда стоит денег. Расходы складываются из времени и зарплат HR или рекрутера, руководителей (тимлида, техлида, CTO) и всех остальных, кто задействован в найме. Когда сотрудник приходит в компанию, время и силы тратятся на онбординг.
Поэтому одна из задач управляющего знаниями — мягко и безболезненно ввести нового сотрудника в работу, чтобы он не «потерялся» на тестовом периоде. Например, новые сотрудники Toyota работают под присмотром более опытных товарищей. Когда корпорация открывает новый завод, то на него отправляют отряд лучших работников и новичков. Через некоторое время опытные сотрудники возвращаются обратно, а новички продолжают работать.
«Организовал сообщество по управлению знаниями и проводил встречи с коллегами, на которых мы нашли, в частности, проблемы с онбордингом и проработали стратегию решения. Например, мы внедрили обобщенную вводную программу для всех сотрудников. Она включала общие знания и практики: task tracker, Wiki, общие технологии. Программу применяли профильные структуры компании, что помогло им повысить процент сотрудников, которые прошли испытательный срок».
Максим Цепков
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Улучшить онбординг можно уже сегодня. Дайте задание новому сотруднику записать свои действия и путь обучения. Вам это ничего не будет стоить. Все следующие новички будут идти по его пути, дописывать и дополнять документ. Когда увидите ваши процессы глазами новичка, вы увидите его путь и подготовите «чек-лист» адаптации.
Пример чек-листа из расшифровки доклада Алексея Петрова (QA Head of department в FunCorp) «Адаптационный чек-лист как инструмент мягкого введения в должность».
Карты коммуникаций
«Когда я организовал базу знаний, то появилось больше возможностей для развития, а после нескольких внутренних промо получал просьбы помочь организовать УЗ в смежных подразделениях. Я вел внутренние митапы о создании контента для внешних и внутренних баз знаний, делился с коллегами методологией, практиками, наработками, консультировал, писал в блог, договаривался о контактах в разных подразделениях, к которым можно обратиться с вопросами (для работы по методике SME). Но даже после этого, самый частый вопрос, который мне задавали: «А ты не знаешь, кого можно спросить про…?»:)»
Родион Нагорнов
Глава ПК KnowledgeConf 2020, финалист международного конкурса TSIA STAR AWARDS 2018 по номинации Innovation in Knowledge Management с проектами по управлению знаниями в «Лаборатории Касперского».
Даже с развитой системой управления знаниями, коммуникации — больной вопрос. В большой компании горизонтальные связи обычно плохо развиты: спросить коллегу из соседнего отдела уже проблема. Здесь поможет карта коммуникаций — список сотрудников компании или команды с должностями, контактами и зонами ответственности.
Для карты коммуникаций просто модернизировать матрицу компетенций. По вертикали ФИО сотрудников, должности и контакты, по горизонтали — область знаний, компетенции, с которыми они могут помочь.
Как внедрить систему управления знаниями
Начните внедрять отдельные практики из управления знаниями в своей компании уже сегодня. Отталкивайтесь от конкретной проблемы бизнеса, которую вы сможете решить инструментами управления знаниями. Например, организуйте локальную (командную) базу знаний в Google Docs.
Локальное решение проблемы презентуйте руководителю. Расскажите, как база помогла быстрее закрыть проект или сделать это с меньшими расходами на языке цифр. Затем предложите руководству масштабировать решение на другие отделы. Так, маленькими шажками внедрите управление знаниями.
Для этого даже не нужно нанимать отдельного человека. Например, в КРОК есть руководитель направления «Управление знаниями и корпоративными коммуникациями» (Алексей Сидорин), но отдельной команды, которая отвечает за базу знаний, нет.
В компании много внутренних корпоративных систем. Команда каждой системы добавляет информацию в базу отдельно. Каждый сотрудника выполняет часть функций управляющего знаниями. Это удобно по двум причинам.
УЗ — это долго, дорого и сложно. Это процесс, который включает сбор знаний, управление изменениями, социологию, аналитику, немного знаний архитектора, разработчика, менеджера и дизайнера. Один человек не сможет быть экспертом во всем, поэтому проще включить в управление знаниями всех сотрудников. Разработчики добавляют в базу знаний документацию, менеджеры — историю проектов, тестировщики — какие проблемы нашли и как они решены.
Для маленьких и средних компаний это дешевле: не нужно выделять бюджет под отдельного сотрудника, достаточно распределить немного новых функций и ролей на текущих. Удобнее «размывать» функции управляющего на несколько человек: кто-то управляет бизнес-процессами, кто-то выступает экспертом, кто-то собирает это все в одну базу.
Полезные ссылки:
На KnowledgeConf 2020 мы подробно, с примерами, алгоритмами и инструкциями поговорим об этих и новых инструментах. Конференция переходит в онлайн-формат, поэтому контента будет в два раза больше. Узкотематическое общение, круглые столы, воркшопы с демонстрациями экрана, коллективные обсуждения и мозговые штурмы, доклады с разными финалами, нетворкинг через совместное решение задач — нас ждёт очень много всего.Подписывайтесь на блог, чтобы не пропустить новые материалы, на Telegram-канал об управлении знаниями, и на чат конференции, где вы получите ответы на все вопросы об УЗ.
