Оффлайн
- Регистрация
- 23.09.18
- Сообщения
- 12.347
- Реакции
- 176
- Репутация
- 0
Гарри Клейн — американский психолог, исследователь интуитивных решений в экстремальных ситуациях. В своей книге «Источники силы» Клейн описал один случай: пожарная команда приехала вызов, в жилом доме горела кухня. Команда вошла в помещение и начала тушить огонь, но он не затухал. В какой-то момент командир почувствовал тревогу и приказал срочно уходить. Когда все вышли из дома, пол на кухне провалился. Оказалось, что пожар начался в подвале, а потом перекинулся наверх, поэтому погасить его на кухне не удавалось.
Позже Гарри Клейн опрашивал командира, чтобы собрать материал для книги и ему удалось разобрать его интуитивное решение на части: огонь на кухне был слабым, но при этом слишком много жара и дыма для такого пламени. Командир почувствовал, что ситуация опасная и вывел команду. Это пример «неявного знания», которое спрятано так глубоко, что оно проявляется только в реальной ситуации.
Вытягивать «неявные знания», которые особенно помогают в экстренных ситуациях — одна из задач менеджера по управлению знаниями. Например, упал продакшн, серверы отказываются работать, но никто не знает почему. При этом полгода назад случалось что-то подобное и проблему решил Петя: «подшаманил», подкрутил и все заработало. Правда, Петя ушел в другую компанию, а ретроспективу не проводили, в базу знаний происшествие и решение не добавляли, потому что и базы-то никакой нет. Но если бы в команде был управляющий знаниями, возможно, последствий было бы меньше, а проблема бы решилась быстрее.
Управляющий знаниями — это не должность, а функция
Управляющий знаниями — это человек, который организует условия, чтобы индивидуальные знания экспертов и опыт компании не терялись, анализировались и использовались для эффективного решения задач. Например, в Microsoft Services для этого есть отдельная должность — директор по управлению знаниями (Chief Knowledge Officer), который управляет отдельным подразделением. У директора много полномочий: он может продавать услуги подразделения другим отделам, покупать оборудование или разработку ПО у других отделов и распоряжается отдельным бюджетом.
Основа системы управления знаниями (УЗ) в Microsoft Services — сообщества практиков, которые работают с 2005 года. Сообществ больше 100, а экспертов несколько тысяч. Разработчику или продакт-менеджеру не нужно гуглить или отнимать время у коллег: в сообществе за минуту он найдёт эксперта по любой теме, задаст вопрос и получит ответ.
Похожая система работает в КРОК — IT-компании, которая профессионально занимается управлением знаниями. С помощью сообществ создаётся почти вся экосистема знаний компании. Это необходимо по специфике работы: КРОК — консалтинговая компания и продаёт знания своих экспертов. На каждую активность в компании (проект, презентация, исследование) создаётся группа, и в неё поступает вся информация: материалы, идеи по проекту, переписки.
В Microsoft Services и КРОК большие системы управления знаниями. Чтобы начать внедрять отдельные практики из управления знаниями в своей компании и получать пользу, большие системы не нужны. Достаточно начать с малого. Например, с пяти простых (относительно) практик, которые решают типичные проблемы бизнеса.
База знаний
База знаний — это первое и самое простое в управлении знаниями. Хорошо помогает для служб поддержки или колл-центров, и незаменим для компаний с велосипедами.
«Как главный архитектор многих проектов, вместе с другими инициативными людьми, я создавал систему исчерпывающей документации. Первоначально — на SGML, с исходниками под системой контроля версий и автоматической сборкой обновлений RTF и CHM каждую ночь, а позже на основе wiki-систем (примерно 2005 год).
В базу знаний мы добавляли шаблоны описаний, типовые примеры и различные диаграммы. Для документации использовали комментарии, как основу. База не только сохранилась в компании до сих пор, но и поддерживается и развивается командами проектов по умолчанию».
Максим Цепков
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Примечание. Подробнее о том, какие документы полезны в управлении знаниями и что в них фиксировать, читайте
Здесь менеджер по УЗ работает как архитектор: отвечает за планирование и разработку инфраструктуры базы знаний, за структуру и иерархию документов. Чтобы в базе не накапливались правки, комментарии и дубли, задает общие правила.
Например, эту роль в компании может взять на себя технический писатель и написать сценарии и любые другие артефакты для системы управления знаниями. Писатели обычно умеют работать с алгоритмами, инструкциями, регламентами и бизнес-процессами.
Проектный офис
Проектный офис — это «расширенная» база знаний. В офис добавляют принятые и непринятые решения, и причины, по которым они выбраны или отброшены.
Кто-то столкнётся с проблемой, найдет причину, решит её и запишет все это в базу, а следующий сотрудник решит эту же проблему быстрее. Время на исследования, на тесты и гипотезы меньше — 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-инженеров, потому что от десятков технологий и сотен нюансов “распухнет” до огромных размеров. Поэтому я модернизировал матрицу в
Игорь Цупко
Директор по Неизвестному во «Флант», участник ПК KnowledgeConf 2020, ведёт Телеграмм-канал @lovely_it_hell.
Чек-листы адаптации
Найм нового сотрудника всегда стоит денег. Расходы складываются из времени и зарплат HR или рекрутера, руководителей (тимлида, техлида, CTO) и всех остальных, кто задействован в найме. Когда сотрудник приходит в компанию, время и силы тратятся на онбординг.
Поэтому одна из задач управляющего знаниями — мягко и безболезненно ввести нового сотрудника в работу, чтобы он не «потерялся» на тестовом периоде. Например,
«Организовал сообщество по управлению знаниями и проводил встречи с коллегами, на которых мы нашли, в частности, проблемы с онбордингом и проработали стратегию решения. Например, мы внедрили обобщенную вводную программу для всех сотрудников. Она включала общие знания и практики: task tracker, Wiki, общие технологии. Программу применяли профильные структуры компании, что помогло им повысить процент сотрудников, которые прошли испытательный срок».
Максим Цепков
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Улучшить онбординг можно уже сегодня. Дайте задание новому сотруднику записать свои действия и путь обучения. Вам это ничего не будет стоить. Все следующие новички будут идти по его пути, дописывать и дополнять документ. Когда увидите ваши процессы глазами новичка, вы увидите его путь и подготовите «чек-лист» адаптации.
Пример чек-листа из расшифровки доклада Алексея Петрова (QA Head of department в FunCorp) «
Карты коммуникаций
«Когда я организовал базу знаний, то появилось больше возможностей для развития, а после нескольких внутренних промо получал просьбы помочь организовать УЗ в смежных подразделениях. Я вел внутренние митапы о создании контента для внешних и внутренних баз знаний, делился с коллегами методологией, практиками, наработками, консультировал, писал в блог, договаривался о контактах в разных подразделениях, к которым можно обратиться с вопросами (для работы по методике SME). Но даже после этого, самый частый вопрос, который мне задавали: “А ты не знаешь, кого можно спросить про...?”
»
Родион Нагорнов
Глава ПК KnowledgeConf 2020, финалист международного конкурса TSIA STAR AWARDS 2018 по номинации Innovation in Knowledge Management с проектами по управлению знаниями в «Лаборатории Касперского».
Даже с развитой системой управления знаниями, коммуникации — больной вопрос. В большой компании горизонтальные связи обычно плохо развиты: спросить коллегу из соседнего отдела уже проблема. Здесь поможет карта коммуникаций — список сотрудников компании или команды с должностями, контактами и зонами ответственности.
Для карты коммуникаций просто модернизировать матрицу компетенций. По вертикали ФИО сотрудников, должности и контакты, по горизонтали — область знаний, компетенции, с которыми они могут помочь.
Как внедрить систему управления знаниями
Начните внедрять отдельные практики из управления знаниями в своей компании уже сегодня. Отталкивайтесь от конкретной проблемы бизнеса, которую вы сможете решить инструментами управления знаниями. Например, организуйте локальную (командную) базу знаний в Google Docs.
Локальное решение проблемы презентуйте руководителю. Расскажите, как база помогла быстрее закрыть проект или сделать это с меньшими расходами на языке цифр. Затем предложите руководству масштабировать решение на другие отделы. Так, маленькими шажками внедрите управление знаниями.
Для этого даже не нужно нанимать отдельного человека. Например, в КРОК есть руководитель направления «Управление знаниями и корпоративными коммуникациями» (Алексей Сидорин), но отдельной команды, которая отвечает за базу знаний, нет.
В компании много внутренних корпоративных систем. Команда каждой системы добавляет информацию в базу отдельно. Каждый сотрудника выполняет часть функций управляющего знаниями. Это удобно по двум причинам.
УЗ — это долго, дорого и сложно. Это процесс, который включает сбор знаний, управление изменениями, социологию, аналитику, немного знаний архитектора, разработчика, менеджера и дизайнера. Один человек не сможет быть экспертом во всем, поэтому проще включить в управление знаниями всех сотрудников. Разработчики добавляют в базу знаний документацию, менеджеры — историю проектов, тестировщики — какие проблемы нашли и как они решены.
Для маленьких и средних компаний это дешевле: не нужно выделять бюджет под отдельного сотрудника, достаточно распределить немного новых функций и ролей на текущих. Удобнее «размывать» функции управляющего на несколько человек: кто-то управляет бизнес-процессами, кто-то выступает экспертом, кто-то собирает это все в одну базу.
Полезные ссылки:
Позже Гарри Клейн опрашивал командира, чтобы собрать материал для книги и ему удалось разобрать его интуитивное решение на части: огонь на кухне был слабым, но при этом слишком много жара и дыма для такого пламени. Командир почувствовал, что ситуация опасная и вывел команду. Это пример «неявного знания», которое спрятано так глубоко, что оно проявляется только в реальной ситуации.
Вытягивать «неявные знания», которые особенно помогают в экстренных ситуациях — одна из задач менеджера по управлению знаниями. Например, упал продакшн, серверы отказываются работать, но никто не знает почему. При этом полгода назад случалось что-то подобное и проблему решил Петя: «подшаманил», подкрутил и все заработало. Правда, Петя ушел в другую компанию, а ретроспективу не проводили, в базу знаний происшествие и решение не добавляли, потому что и базы-то никакой нет. Но если бы в команде был управляющий знаниями, возможно, последствий было бы меньше, а проблема бы решилась быстрее.
Управляющий знаниями — это не должность, а функция
Управляющий знаниями — это человек, который организует условия, чтобы индивидуальные знания экспертов и опыт компании не терялись, анализировались и использовались для эффективного решения задач. Например, в Microsoft Services для этого есть отдельная должность — директор по управлению знаниями (Chief Knowledge Officer), который управляет отдельным подразделением. У директора много полномочий: он может продавать услуги подразделения другим отделам, покупать оборудование или разработку ПО у других отделов и распоряжается отдельным бюджетом.
Основа системы управления знаниями (УЗ) в Microsoft Services — сообщества практиков, которые работают с 2005 года. Сообществ больше 100, а экспертов несколько тысяч. Разработчику или продакт-менеджеру не нужно гуглить или отнимать время у коллег: в сообществе за минуту он найдёт эксперта по любой теме, задаст вопрос и получит ответ.
Похожая система работает в КРОК — IT-компании, которая профессионально занимается управлением знаниями. С помощью сообществ создаётся почти вся экосистема знаний компании. Это необходимо по специфике работы: КРОК — консалтинговая компания и продаёт знания своих экспертов. На каждую активность в компании (проект, презентация, исследование) создаётся группа, и в неё поступает вся информация: материалы, идеи по проекту, переписки.
В Microsoft Services и КРОК большие системы управления знаниями. Чтобы начать внедрять отдельные практики из управления знаниями в своей компании и получать пользу, большие системы не нужны. Достаточно начать с малого. Например, с пяти простых (относительно) практик, которые решают типичные проблемы бизнеса.
База знаний
База знаний — это первое и самое простое в управлении знаниями. Хорошо помогает для служб поддержки или колл-центров, и незаменим для компаний с велосипедами.
«Как главный архитектор многих проектов, вместе с другими инициативными людьми, я создавал систему исчерпывающей документации. Первоначально — на SGML, с исходниками под системой контроля версий и автоматической сборкой обновлений RTF и CHM каждую ночь, а позже на основе wiki-систем (примерно 2005 год).
В базу знаний мы добавляли шаблоны описаний, типовые примеры и различные диаграммы. Для документации использовали комментарии, как основу. База не только сохранилась в компании до сих пор, но и поддерживается и развивается командами проектов по умолчанию».
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Примечание. Подробнее о том, какие документы полезны в управлении знаниями и что в них фиксировать, читайте
You must be registered for see links
Максима на 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.
Карта компетенций
Карта или матрица компетенций — инструмент повышения квалификации и его контроля. Обычно выглядит, как таблица: по строкам имена сотрудников, а по столбцам — то, что они знают.
Пример матрицы из статьи «
You must be registered for see links
».В таблице наглядно видны провалы в обучении сотрудников. Показывает, кто главный носитель определённого навыка (который потом его передаёт другим), а кто просто рядовой пользователь. Карту компетенций может составить тимлид или техлид, чтобы оценивать уровень разработчиков команд.
«До “Флант” я был техническим директором в компании-разработчике. Мне хотелось, чтобы команда росла и решала задачи сложнее, а сотрудники повышали квалификацию. Для этого требовались прозрачные правила роста, обратная связь. В этом помогала матрица компетенций.
Но матрица подходит не всем. В компании “Флант” она не работала для DevOps-инженеров, потому что от десятков технологий и сотен нюансов “распухнет” до огромных размеров. Поэтому я модернизировал матрицу в
You must be registered for see links
. Это уже процесс, который позволяет выявлять систематические проблемы с наймом, адаптацией и ростом сотрудников».
Директор по Неизвестному во «Флант», участник ПК KnowledgeConf 2020, ведёт Телеграмм-канал @lovely_it_hell.
Чек-листы адаптации
Найм нового сотрудника всегда стоит денег. Расходы складываются из времени и зарплат HR или рекрутера, руководителей (тимлида, техлида, CTO) и всех остальных, кто задействован в найме. Когда сотрудник приходит в компанию, время и силы тратятся на онбординг.
Поэтому одна из задач управляющего знаниями — мягко и безболезненно ввести нового сотрудника в работу, чтобы он не «потерялся» на тестовом периоде. Например,
You must be registered for see links
работают под присмотром более опытных товарищей. Когда корпорация открывает новый завод, то на него отправляют отряд лучших работников и новичков. Через некоторое время опытные сотрудники возвращаются обратно, а новички продолжают работать.«Организовал сообщество по управлению знаниями и проводил встречи с коллегами, на которых мы нашли, в частности, проблемы с онбордингом и проработали стратегию решения. Например, мы внедрили обобщенную вводную программу для всех сотрудников. Она включала общие знания и практики: task tracker, Wiki, общие технологии. Программу применяли профильные структуры компании, что помогло им повысить процент сотрудников, которые прошли испытательный срок».
Архитектор и бизнес-аналитик, навигатор по миру Agile, бирюзовых организаций и спиральной динамики, участник ПК KnowledgeConf 2020.
Улучшить онбординг можно уже сегодня. Дайте задание новому сотруднику записать свои действия и путь обучения. Вам это ничего не будет стоить. Все следующие новички будут идти по его пути, дописывать и дополнять документ. Когда увидите ваши процессы глазами новичка, вы увидите его путь и подготовите «чек-лист» адаптации.
Пример чек-листа из расшифровки доклада Алексея Петрова (QA Head of department в FunCorp) «
You must be registered for see links
».
Карты коммуникаций
«Когда я организовал базу знаний, то появилось больше возможностей для развития, а после нескольких внутренних промо получал просьбы помочь организовать УЗ в смежных подразделениях. Я вел внутренние митапы о создании контента для внешних и внутренних баз знаний, делился с коллегами методологией, практиками, наработками, консультировал, писал в блог, договаривался о контактах в разных подразделениях, к которым можно обратиться с вопросами (для работы по методике SME). Но даже после этого, самый частый вопрос, который мне задавали: “А ты не знаешь, кого можно спросить про...?”
»
Глава ПК KnowledgeConf 2020, финалист международного конкурса TSIA STAR AWARDS 2018 по номинации Innovation in Knowledge Management с проектами по управлению знаниями в «Лаборатории Касперского».
Даже с развитой системой управления знаниями, коммуникации — больной вопрос. В большой компании горизонтальные связи обычно плохо развиты: спросить коллегу из соседнего отдела уже проблема. Здесь поможет карта коммуникаций — список сотрудников компании или команды с должностями, контактами и зонами ответственности.
Для карты коммуникаций просто модернизировать матрицу компетенций. По вертикали ФИО сотрудников, должности и контакты, по горизонтали — область знаний, компетенции, с которыми они могут помочь.
Как внедрить систему управления знаниями
Начните внедрять отдельные практики из управления знаниями в своей компании уже сегодня. Отталкивайтесь от конкретной проблемы бизнеса, которую вы сможете решить инструментами управления знаниями. Например, организуйте локальную (командную) базу знаний в Google Docs.
Локальное решение проблемы презентуйте руководителю. Расскажите, как база помогла быстрее закрыть проект или сделать это с меньшими расходами на языке цифр. Затем предложите руководству масштабировать решение на другие отделы. Так, маленькими шажками внедрите управление знаниями.
Для этого даже не нужно нанимать отдельного человека. Например, в КРОК есть руководитель направления «Управление знаниями и корпоративными коммуникациями» (Алексей Сидорин), но отдельной команды, которая отвечает за базу знаний, нет.
В компании много внутренних корпоративных систем. Команда каждой системы добавляет информацию в базу отдельно. Каждый сотрудника выполняет часть функций управляющего знаниями. Это удобно по двум причинам.
УЗ — это долго, дорого и сложно. Это процесс, который включает сбор знаний, управление изменениями, социологию, аналитику, немного знаний архитектора, разработчика, менеджера и дизайнера. Один человек не сможет быть экспертом во всем, поэтому проще включить в управление знаниями всех сотрудников. Разработчики добавляют в базу знаний документацию, менеджеры — историю проектов, тестировщики — какие проблемы нашли и как они решены.
Для маленьких и средних компаний это дешевле: не нужно выделять бюджет под отдельного сотрудника, достаточно распределить немного новых функций и ролей на текущих. Удобнее «размывать» функции управляющего на несколько человек: кто-то управляет бизнес-процессами, кто-то выступает экспертом, кто-то собирает это все в одну базу.
Полезные ссылки:
-
You must be registered for see links
-
You must be registered for see links.
- доклад Марии Мариничевой «
You must be registered for see links».
-
You must be registered for see links.
На
Подписывайтесь на блог, чтобы не пропустить новые материалы, на
You must be registered for see links
мы подробно, с примерами, алгоритмами и инструкциями поговорим об этих и новых инструментах. Конференция переходит в онлайн-формат, поэтому контента будет в два раза больше. Узкотематическое общение, круглые столы, воркшопы с демонстрациями экрана, коллективные обсуждения и мозговые штурмы, доклады с разными финалами, нетворкинг через совместное решение задач — нас ждёт очень много всего.Подписывайтесь на блог, чтобы не пропустить новые материалы, на
You must be registered for see links
об управлении знаниями, и на
You must be registered for see links
, где вы получите ответы на все вопросы об УЗ.