2020-06-06: KnowledgeConf-2020 - качественный контент, вау-доклады и крутой online-формат

Материал из MaksWiki
Перейти к: навигация, поиск

18-19 мая в online-формате прошла Knowledge Conf, конференция по управлению знаниями в online-варианте. Она не замысливалась как online, готовилась обычная конференция. Но в марте стало понятно, что offline точно не получится, и организаторы, и я в их числе как член ПК, решили провести online-формат, попробовать что получится. Получилось удачно. В завершающем посте первого дня я отмечал: Была не только трансляция потоков, но и нетворкинг. Дискуссионные зоны в зум после каждого спикера. А еще - митапы, лайт-трек, мини-интервью, экспресс-консультации. А также чаты, предложение тем для обсуждение и поиск собеседников по ним.

А вот отзыв Марии Мариничевой, которая делала доклад и вела экспертную комнату: "Очень интересно организована эта конференция, он-лайн формат использован по полной, отличная поддержка, все-вовремя! Чувствую - он-лайн вообще эффективнее и мне больше нравится. Очень радостно и приятно увидеть и услышать хорошо и очень давно знакомых людей, по-прежнему вовлеченных в тему КМ. В отличие от прошлой конференции 2019, где аудитория была не очень подготовлена к моему достаточно непростому кейсу, сегодня много специалистов-практиков, их опыт очень важен."

Экспертную комнату я тоже проводил, в первый день. Это формат, когда эксперт в 15-минутных слотах консультирует 1:1. Для меня это - новый опыт, но судя по реакции собеседников, получилось дать ценность в таком кратком формате. И для меня это тоже было интересно, потому что приходят самые разные люди со своими проблемами. Правда, часть людей записались, но не пришли, отняв тем самым возможность послушать у других желающих. Зато "на огонек" забредали другие люди, и когда это происходило в свободное время, то у них получалась консультация. Ну и с записью организаторы тоже оперативно разобрались, у меня была самая первая комната, и там до последнего ждали, что придут те, кто записался, даже если они не откликались на сообщения организаторов. Судя по всему, люди записались "на всякий случай". Для следующих экспертов организаторы оперативно выходили на связь, а если человек не откликался - то освобождали слот для других.

Кроме экспертной комнаты я вел еще обсуждение актуальных тем современного управления знаниями. Идея мне пришла уже во время конференции, и я заявил в одном из пустых слотов. Список тем был в этом голосовании https://mtsepkov.org/KM20-Topics, сначала был краткое представление тем-тезисов, а потом пошло обсуждение в порядке, определенном голосованием. Те, кто голосовал за тему - задавали контекст обсуждения подробнее. Получился неплохой разговор, хотя я бы, наверное, хотел больше интерактива.

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

Мне лично не хватило спонтанного нетворкинга, он - интереснее организованного. Но, забегая вперед, отмечу что на РИТ-2020, который был через неделю после KnowledgeConf, у организаторов получилось сделать online-нетворкинг на afterparty оба дня конференции так, что до 11 вечера люди точно оставались. Люди объединялись в группы, как обычно бывает вокруг столов, и там были обсуждения не менее интересные, чем обычно на afterparty. У нас же был afterparty в zoom, тоже с интересным разговором, вот его фотка.

Все это в очередной раз меняет формат вопроса о самоопределении: в каких конференциях участвовать. Три-пять лет назад все было понятно: "по моей специализации есть 1-3 профильных конференции, на одну я хожу каждый год, она крута, на другие - заглядываю через год". У меня лично на это накладывалось несколько разных профессиональных специализаций, а также участие в региональных конференциях, поэтому было больше, но не сильно. Правда, был 2011 год, когда я поставил себе цель "выступить на всех конференциях" и там получилось шесть различающихся докладов. Но это был такой вызов, который я потом не повторял, хотя все равно участвовал в большем числе конференций, чем выступал.

А вот за последние годы по всем темам начали бурно развиваться серии конференций. Особенно в IT - ontico, jug. Идет несколько конференций каждую неделю. И тут возникает вопрос - на какие из них ходить. Старая логика не работает, когда конференций не 3-5, а 10-20. А нынешний выход в online еще раз поменял ситуацию - организаторы научились делать не просто трансляции, а реальное пространство общения. И очевидно не будут от этого отказываться, возможно, будут развивать композитные форматы. И у тебя получается 100+ потенциально доступных конференций и вебинаров по разным темам. Как быть - у меня пока нет версии ответа. Буду искать.

На этом я, пожалуй, закончу с общими впечатлениями и, как обычно, соберу свои о докладах, которые писал прямо во время конференции. Все доклады круты. Но если говорить о вау-эффекте узнавания чего-то принципиально нового, то это доклад Антона Морева про освобождающие структуры. Вы знали, что это такое? Я - нет, а это очень интересно. И доклад Евгения Селевича о том, что уже в следующем году обычный онбординг, в котором ставится задача погружения в компанию, чтобы сотрудник быстрее вышел на проектную мощность, замениться работой с employee experience (EE или EX), в которой ставится задача создания позитивного впечатления для удержания сотрудника в компании. И не только в IT. Такие гримасы дефицитного рынка труда.

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

Содержание

Valery Andrianova. Как устроен процесс обмена знаниями в JetBrains в целом и в команде Space

Пост на FB Valery Andrianova (JetBrains) Как устроен процесс обмена знаниями в JetBrains в целом и в команде Space. Любопытный доклад. В 2001 JetBrains начинал со среды разработки для Java, которую делал для себя и для всех остальных. C тех пор компания все продукты делает для себя и для остальных - трекер YouTrack, TeamCity, Kotlin... Наверное, поэтому они и взлетали.

И сейчас они решили сделать очередной шаг, сделать продукт Space, который создает комплексную среду жизни всех сотрудников компании в рабочем окружении. Со всеми социальными, а не только производственными аспектами. И это интересно, основная мысль - организовать это пространство вокруг людей. Заметим, что это принципиально отличается, в частности, от подхода Kanban, который говорит: "структурируйте поток работ, а люди сами соорганизуются вокруг него".

В докладе рассказ про культуру, ценности и практики тесно перекликался с рассказом о Space. На мой взгляд, Space было многовато, но проблем, культуры и практик самого JetBrains было довольно много.

Ценности компании

  • Плоская структура. Каждая команда - замкнута и все обеспечивает, подкоманды - редко, над командами - CEO
  • Самообслуживание - каждый может сам завести свой проект
  • Догфудинг
  • Распределенные команды
  • Открытость и прозрачность работы. Публичный трекер для всех пользователей!

2019 - 1300 сотрудников, 9 офисов, 1.8 клиентов по всему миру, 28 продуктов.

Ценности на 200 человек в 2011 поддерживались сами собой, а на 1300 - нужно принимать усилия. И Space - часть этих усилий.

Среда погружения: человек туда попадает и весь день работает. Чаты, Git, Задачи, планирование.

  • Space вокруг людей.
  • Глубокая синергия и нативная интеграция. Ролевая структура команд. Отпуска, планы и присутствие.
  • Командная работа собирает все роли в единый флот.
  • Платформа. Интеграция и расширяемость. Чтобы подключать внешние продукты.

Правда, сборка процесса оформления отпуска - слишком плюшевая, непонятно, чем это отличается от тикета в трекере...

Знания у них были в Confluence - исторически сложившаяся свалка, в которой нельзя найти ответы на вопросы. И в командах рядом прорастали другие инструменты - notion, github, googledocs и многое другое. Делают в space и хотят переехать. и немного об этом рассказали.

  • Разделение на то, как использоваться. Внутрипроектная, Книги компании, Тэги.
  • Совместная работа, трансформация документов.
  • А еще - структурный поиск и результаты обсуждений - в YouTrack у них очень много информации.
  • Slack - распространение между командами, Who-канал - чтобы начти адресата, которого ты не знаешь

Эволюционное распространение. Slack дал ощущение компании как единого пространства, доступность людей. правда повысился уровень шума для людей, которые нагружены. Они пытаются легкодоступностью информации в Space снизить уровень шума - пусть люди сами ищут.

Интересные практики: Внутренний найм, знакомство между офисами, OnlineTV в офисе.

Режим антивыгорания в Space. Смотрит нагрузку по митингам и делам и дает всякие советы.

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

Переход на английский язык во всех командах. Потому что много евангелистов и developer advokat - они в тесном сотрудничестве. И специалисты в европейских офисах. Поэтому только официальной коммуникации на английском недостаточно, надо и внутри тоже. Она рассказывала про опыт перехода на английский

  • Митинги проходят быстрее. StandUp тоже. Потому что люди готовятся и формулируют мысли
  • Уровень языка повышается очень быстро
  • Есть записи - на английском, можно шарить
  • Приватная переписка и частные обсуждения - на русском, но сразу переключаются, если подключается кто-то из не-русских. А иногда и начинают на русском - чтобы контекст сохранился для тех, кто придет позднее.

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

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

Анжелика Федько. 5 критериев неэффективной базы знаний и способы все исправить

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

Публичная БЗ, доступная клиентам. Проблемы

  • Однотипные вопросы
  • Выгорание сотрудников
  • Увеличение штата и рост расходов сотрудников
  • Затянутый онбординг

Используют KCS - Knowlede-Centred Service

Сотрудники прокачиваются, а время решения не сокращается - потому что заявки каждый раз новому инженеру.

Причина: люди не пишут статьи в БЗ, а ведут личные заметки. Почему не делают? Не хочу и НЕ могу. Не хочу: Не вижу выгоды или Не нравится.
Не вижу выгоды - проблема в корпоративной культуре. Инженеры набирают баллы KPI. Личные заметки дают преимущество. Это надо менять.
Статьи в KPI - нужно, но! надо аккуратно проработать. Просто число статей - нельзя, будут бесполезный дубли. Надо ставить, чтобы заявка кончалась статьей.
Мне не нравится - сложнее. Надо разобраться. Потому что реально не всем нравится, некоторые предпочитают решать вопросы.
Не могу - реально не все умеют, и надо обучить, дать шаблон и так далее. Он на другую приходил. Выработали шаблоны.
  • HowTo: Question - Answer
  • Problem: Symptoms, Cause, Resolution
Результат: Увеличили скорость на 16%, Закрытие с первого ответа - на 40% чаще.

База знаний растет, количество клиентов увеличивается, а вопросы - все те же, клиенты не находят

Причина - статьи языком сотрудника, а не языком клиента. Symptoms писали сотрудники, которые, например, упоминали про логи, о которых они знают - а клиент-то видел только выдачу сайта.
Изменили написание - 50% заявок начали решать на момент заведения - через выпадашку на сайте, которая всплывает по мере заполнения заявки! И клиенты пользуются, им интересно не ждать. И сотрудникам стало интереснее!

Крутой onboarding - а новенькие буксуют.

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

Только ограниченный круг людей пишет в БЗ.

Казалось бы - замечательно, пишут опытные. Но! оказалось что статьи тяжелые, не находит не только клиенты, но и сотрудники. Или посадили тех, у кого хороший язык - не хватает техники.
Плюс получается узкое горло - написать новые статьи, актуализировать существующие (11 тыс) - приоритеты и т.п. А еще те, кто пишет, но не использует - теряет техническую экспертизу.
Как решение - начали писать все.

Ни новые фичи ни фикс багов не улучшают NPS.

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

А самое главное было в конце, как шестой критерий, бонус. Который нулевой. Надо, чтобы сотрудники и топы не понимают, что нужна база знаний.

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

Tatiana Gavrilova. Вавилонская башня, или На каком языке делиться знаниями: проблема business vocabulary

Пост на FB Tatiana Gavrilova. Вавилонская башня, или На каком языке делиться знаниями: проблема business vocabulary. Как всегда, очень концентрированное и содержательное выступление о проблемах передачи знаний на глубоком уровне и со ссылками.

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

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

Есть потери информации при общении. Тут известная картина, что 24% осталось в памяти по пути Задумано - Приобретено словесную форму - Высказано - Выслушано - Понято - Осталось в памяти. Только со ссылкой - Мицич "Деловое общение". Штука в том, что с этим связаны разные когнитивные особенности. Есть говорители и пониматели. Пониматель - отдельная когнитивная характеристика.

При этом у слушателя всегда собственная субъективная картина мира. Интерпретация текста всегда идет в своей картине. Есть несколько моделей - Шенон, Стюарт-Холл. Аналитик или инженер по знаниям - толмач, который понимает разных экспертов. Но ему необходим контекст. В психологии чтобы выделить сухой остаток из статьи надо прочесть несколько монографий.

Извлечение знаний - из облака переводим в структурное поле знаний, ментальную модель. Из эксперта проще - можно переспросить. Из Базы знаний извлечь сложнее.

Психологические проблемы понимания и перевода.

  • Контактный слой: личность, пол, возраст
  • Процедурный слой: время, невербальные компоненты, темп
  • Когнитивный стиль: поленезависимость, ригидность, диапазон когнитивных эквивалент

Влияние гендера на понимание. Таблица различий по речевому поведению в устной и письменной речи.

  • Категоричность высказываний
  • Разная шкала оценки, мужчины негативнее
  • Мужчины говорят короче, их надо доспрашивать.

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

Аспекты когнитивного стиля. Когнитивная сложность: самопонимание, сложный или простой мир.

  • Самопонимание, рефлексия есть далеко не у всех.
  • Сложные модели, с полутонами тоже есть не у всех.

Надо встать на позицию другого.

Ригидность: есть собственная модель, и все новое укладываем только в нее. Против гибких, хороших понимателей. С возрастом ригидность нарастает, но статистически, есть молодые ригидные.

С возрастной ригидностью сложно. brain fitness натаскивает на задачи, а не ликвидирует. Надо читать книги.

Понимание: глубина, подробность и полнота.

  • Одним нужны подробности, а другим - нет.
  • Полнота - неразрешима.

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

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

Ошибки при передаче.

  • Легкие ошибки: Недоговариваем, синонимы, семантическая множественность
  • Критические ошибки: лакуны, неясные слова (часто, дорого), и самая сложная "элементарно, Ватсон" - когда эксперт сказал так, что слушатель начал домысливать за него неверно (или не начал).

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

Нужен лингвист. Структурная, семантическая, эмоциональная многозначность.

Картинки - помогают пониманию. Хотя картинки стоят дороже. Картинка - это мысль, а не иллюстрация, это важно. Новое поколение плохо воспринимает тексты, надо картинки... Или слушают - 15 минут.

В общем, смотрите запись, а главное - качайте презентацию, в ней ОЧЕНЬ много слайдов с материалом, Татьяна рассказала малую часть!

Евгений Викторов из Газпромнефти. Одна методика картирования знаний

Пост на FB Евгений Викторов из Газпромнефти. Одна методика картирования знаний. Методика показывает способ извлечения знаний из области, где много классных, но узких профессионалов, и невозможно найти эксперта, представляющего область целиком. Я отмечу, что в IT достаточно много таких областей, и чем дальше - тем будет больше, универсальных специалистов не найдешь.

Идея методики в том, что мы стартуем от опроса сотрудников, которые должны сами структурировать область. Опрос из двух частей. Во-первых, просто карта коммуникаций - к кому, по каким задачам и как часто обращаетесь.

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

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

Мотивация к опросу - зависит от культуры. От руководства, от экспертов и коллег, потенциальные возможности для респондента. Через опросы есть возможность получить статус эксперта, для многих она ценная.

И дальше Евгений показывал анализ результатов - через выгрузку в Excel и дальше инструмент Gephi, который рисует граф взаимодействия и кластеры. И анализ метрик

  • Базовые из теории графов. Степерь узла - активность. Диаметр сети - максимальное расстояние, компактность связей графа. Средняя длина - сколько надо прояти, чтобы связаться. И плотность.
  • Мера нагрузки: активный отвечатель и активный искатель.
  • Влияние. Центральность по посредничеству (центр мнений) и по близости (ретрансляторы).

Была короткая живая демонстрация анализа. Инструмент сам кластеризует и подсвечивает кластеры. Смесь ручной и автоматической работы.

Примеры интересных результатов анализа

  • Кластеры вокруг сотрудников с низкой позицией, который активно взаимодействует.
  • Эксперты, которых обнаружили в результатах, но не опрашивали - руководители о них не знают :)
  • Экспертное ядро, к которым обращаются все люди. И их надо хранить, даже если оценки не слишком...

А еще - соотносят карту коммуникаций с рассадкой в офисе. И оптимизируют.

Кроме графов - Excel. Самооценка компетенции, сравнение с коммуникационной картой. Подбирают визуальный формат, чтобы не Excel.

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

Картирование - периодически. И хотят еще сделать частью онбординга - чтобы был свежий взгляд. А еще он хорошо себя оценивает.

Помимо опросов можно делать выгрузки из почты и из АТС (правда они с безопасниками пока не договорились). Я отмечу, что в IT хорошую инфу даст таск-трекер.

Боли.

  • Сложность обработки. Около 1 часа на человека
  • Мотивация респондентов. Надо помогать - письма от руководителя и экспертов.
  • Осилить респонденту опросник - тяжело. Но у них обязательна только одна область.
  • У менеджеров и HR. Боли возникают при вскрытии ситуации: руководителей не считают экспертом, большое обучение не дало самооценку, обучают одному, а хотят другому.

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

Мария Мариничева. Как оценить эффективность Knowledge Manager и всей КМ-команды

Пост на FB Мария Мариничева (Maria K. Marinicheva). Как оценить эффективность Knowledge Manager и всей КМ-команды. Высокопрофессиональный рассказ про оценку на сложных кейсах. И замечательный формат - смесь рассказа и взаимодействия с участниками, включения их в дискуссии и упражнения.

Кейсы - интересные. Рассказан в кейсах был только кусочек про оценку, в соответствии с темой доклада, и это несколько обидно. Потому что первый кейс - о том, как в одной мебельной компании было административно внедрено сверху сообщество практик с понятным результатом: люди саботировали, а практики не работали. Марину позвали как консультанта и они прошли 5 месяцев до выяснения стратегических целей, причин саботажа, и далее - до вовлечения руководителей бизнес-направлений, создания из них совета по KM и подбора Knowledge manager внутри компании на 50% времени. Стратегическая задача KM - выявление лучших практик и создание условий для распространения и применения, для повышения компетенций на рынке увеличения доли рынка.

И через несколько месяцев ее позвали, чтобы оценить - насколько KM справляется со своей работой. Поскольку срок был маленький, то изменения в достижении бизнес-целей в оценку не входили. Оценка была устроена следующим образом.

  • Самооценка KM по ее активности
  • Оценка 360: руководители (внутренний совет по KM), внутренние клиенты, коллеги (T&D, HR)
  • Оценка по использованию ресурсов

4 направления

  • Обучение KM: введение новичков, обучение работы с ресурсами
  • Модерация ресурсов, помощь в размещении материалов
  • Помощь в поиске и использовании, соединение тех кто ищет и тех кто знает
  • продвижение идей обмена знаниями, поиск лучших авторов, поиск историй успеха

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

Результат: самооценка (62) ниже оценок остальных: 67 у клиентов, 72 у руководителей и 77 у коллег

Выводы: на роль KM годится, но времени - не хватает. Недостаточно фасилитации (коммуникация - хорошая), недостаточно знаний в предметке и кто что знает. А в работе - не хватает работы с историями успеха: процесс, шаблоны, пиар историй успеха.

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

А еще приняли решение, что БЗ не нужна, посмотрев на ее использование.

После рассказа было предложение участникам: напишите за 5 минут свою версию оценки KM. B потом обсуждение в интерактиве с несколькими из них.

Мой вариант. Оценка KM

  • Самооценка: Какие цели KM перед собой ставит и как двигается к целям KM
  • Руководители: Какие вопросы они возлагали бы на KM и как KM в компании с ними справляется, какова роль менеджера KM в этом. Как они оценивают распространение знаний между командами? Какие истории успеха, когда принесенные знания помогли они могут вспомнить? Какие проблемы? И как оценивают роль менеджера KM в каждой из них.
  • Команды: Есть ли истории успеха, когда знания были получены и помогли? Есть ли сложности получения информации от других команд? Есть ли проблемы коммуникации с командами, непонимание. Есть знание о ресурсах публикации. Читают ли, полезно ли (чем помогло прочитанное - вспомните истории), публикуют ли, ощутили ли авторы полезность, что мешает публикации? И аналогично про чаты. Знают ли менеджера KM, оказывает ли прямую помощь? B вопросах разделить клиентские истории и производство внутри.
  • Смежники (обучение, HR): Какие формы кооперации ожидаются, что бы хотели решить за счет KM, какие были истории успеха, и какие проблемы.
Комментарий от Марии: Максим, здорово, но в этом случае было рановато. Про истории успеха спрашивать. А так-то - согласна, отлично звучит, немного позже

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

Комментарий от Марии: думаю, это потому, что KPIs - можно очень сильно заформализовать, и тогда их выполнение просто связано с выполнением текущих задач. Например - провести 10 фасилитационных сессий. 100% - 50% - 150% не всегда они могут отразить сущность этих тонких процессов.

А дальше перешли к оценке команды. Интересно, что в версиях слушателей оценка самого KM - по личной активности, а вот оценка команды - уже по бизнес-результатам, например, сокращение времени поиска ответа на запрос клиента.

Про оценку команды Мария рассказывала кейс команды KM в Оргкомитете Сочи-2014. Задача KM - организовать и поток знаний и опыта от МОК и международного сообщества организаторов прошлых Олимпиад во все 64 бизнес-направления нашего оргкомитета. Потому что большинство сотрудников такого опыта не имеют.

Соответственно, оценка работы, которую делала сама команда, определяла, получают ли руководители необходимый опыт от международного сообщества, и распространяется ли он по сотрудникам. И качество фокусировки работы KM на актуальных вопросах.

Использовали опросник, интервью, статистику обращений к KM, cтатистикe участия в KM-мероприятиях.

  • Оценка уровня нужных знаний. Насколько есть, где находитесь, какие трудности
  • Взаимодействие с KM - результативность, сервис, взаимодействие, ожидаемая помощь
  • Идеи по развитию знаний

30% участвуют, 39% знают. Удовлетворены 50% Но при этом 60% имеют знания, 66% знают, что достаточно. Проблемный фокус - знания по проектному управлению. И взаимодействие сложно.

Результаты: команда хорошая, пиар и продвижение - плохое, вовлеченность - низкая.

Что делать: интранет, новостная лента бизнес-направлений, обучение проектному управлению и коммуникациям, координаторы знаний, карта знаний оргкомитета, начинают проактивно заказывать обучение в МОК, программа building knowledge capabilities, экстранет МОК, развитие сервиса анализ опыта игр.

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

Оценка повторялась и помогала. Розочка - как за год изменилась. Принципиальная форма не изменилась, но по всем векторам продвижение вдвое в низких точках (15-30, 30-70) и в полтора в высоких (60-90). 90 вышли в уровне знаний и KM компетентности: нужное знаю, а что не знаю - могу найти.

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

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

Anton Morev. Шаринг знаний через освобождающие структуры

Пост на FB Anton Morev. Шаринг знаний через освобождающие структуры. Супер-доклад про малоизвестную сборку техник групповой работы. Техники обеспечивают быстрый обмен информации и погружение от нуля до некоторого уровня, который Антон называет "кухонные знания" - когда ты можешь поддерживать беседу на кухне. Плюс возникает интерес к вопросы, так что дальнейшее погружение можно проводить самостоятельно. В докладе было несколько примеров, используемых для разных целей.

1-2-4-все: по 5 минут обсуждение вопроса в парах, потом в четверках, каждая выдает резюме для всех. Используется для выравнивания знаний, погружения в технологии, о которых кто-то слышал, выяснения, что нужно клиентам и выравнивания информации с ними, погружения новичков в технологии компании - и при этом мы транслируем свои знания и получаем знания от новичков. За короткое время.

Для экспресс-выяснения что нужно клиенту, они используют 4 техники: 1-2-4-все, тройка-консалтинг, толпотворение для порождения идей и 15% вклад для фокусировки.

Тройка-консалтинг. Пусть клиент - отдел продаж. Собираем тройку Продавец, Руководитель клиента, IT.

  • Кто играет клиента? пусть на первом шаге Sale. Он рассказывает о проблемах 2 минуты. Уточнение вопросов, еще 2-3 минуты.
  • Дальше оставшаяся пара генерит и обсуждает идеи - как помочь. Клиент - только слушает. 1-2 минуты
  • Клиент делится - что он думает про высказанные идеи 1-2 минуты
  • Дальше по кругу. Руководитель как клиент, сотрудник компании как клиент.

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

Толпотворение - на примере генерации идей для pet-проекта. Минимум 10 человек, у каждого хотя бы одна идея. Очень важно, что все участвуют. Наблюдатели - ухудшаю процессы.

  • Идея от каждого
  • Передай другим
  • Каждому получившему - оценить идею 1-5. Итого 10-25 баллов
  • Дальше итоги по идеям - их ранжируют, и идет обработка результатов.

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

Всего 33 формата. Придумали Henri Lipmanowicz и Keith McCandless, есть сайт http://www.liberatingstructures.com/ и их книга, и русский перевод энтузиастов http://liberating-structures.ru/ Но из сухого текстового описания вся эта коммуникативная механика - не понятна. А волшебство именно в ней, создается коммуникативная структура, которая обеспечивает стихийную работу со сознанием, такой управляемый хаос. Сам он услышал на конференции и понял ценность и механику только за счет того, что был практический мастер-класс, можно было попробовать. И потому решил сделать доклад, чтобы заинтересовать.

Роман Сентюрёв. Capture the flag, или Передача знаний в соревновательной форме

Пост на FB Роман Сентюрёв. Capture the flag, или Передача знаний в соревновательной форме. Их компания АвтоТрансИнфо ati.su занимается грузоперевозками, но это IT-компания, грузы она не возит. Он пришел в компанию с задачей заниматься безопасностью кода. И рассчитывал не только сам работать в этом направлении, но и поучиться от тех кто там есть. А оказалось, что там рассчитывают, что профессионалы-разработчики будут писать код без дырок. Что тоже самое, что не тестировать код, рассчитывая, что он без багов. Посмотрев код, он понял, что хорошо сделаны позитивные кейсы и работа с данных. Но на стыке технологий возникали проблемы, несанкционированный доступ к папкам и так далее. Он пробовал найти единомышленников, но разработчики говорили "тема интересная, но слишком большая для погружения", никого не заинтересовало.

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

Дальше шло много техники. Организация команд с выравниванием сил. Метод паровозов для вовлечения: индивидуальная продажа идеи лидером мнения ДО общего вовлечения. Но опасность, что паровоз приведет команду, не будет смешивания. Первый день - все вовлеклись и рабочий день насмарку. Ограничил время доступа к серверам.

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

Техника сложная, но люди дошли до конца, реально это win! Все дошедшие до конца взломали сервер. И они начали применять знания на проектах, это позволило выявить и закрыть уязвимости. И появился пул людей, которые начали развивать безопасность в проектах.

А CTF - продолжают запускать раз в 5 месяцев (у них такты по 2.5 месяца, чередуют хакатоны и CTF). Одна из CTF - поняли, что пришло много новичков. И они поделили участников, у одних было обучение, а у других - полноценный defence attack.

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

Евгения Ращупкина. Короткий доклад Пять правил курирования контента

Пост на FB Евгения Ращупкина. Короткий доклад Пять правил курирования контента. В общем-то основная мысль - проста и очевидна. Если просто кидать контент, то он часто превращается в свалку, поэтому полезно с ранних этапов начать курировать контент. Почему-то эта простая и очевидная для меня мысль оказывается вовсе не очевидной многим из тех, кто думает про организацию корпоративной информации. Они как-то убеждены, что стоит дать платформу - контент органично прорастет и будет структурирован. А это - заблуждение.

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

  • Релевантный источник информации. Почему ему можно доверять, почему это знания?
  • Соответствие целевой аудитории. Зачем людям в компании это знать?
  • Курирование = информация + дополненная ценность. Не просто вбрасываешь, а объясняешь, почему стоит смотреть. От себя отмечу, что о внесении дополнительной ценности забывают очень часто.
  • Смысл - в каждом сообщении и каждой теме. Почему это здесь и именно так. Внутренняя логика размещения.
  • Удобство создавать и использовать - добавлять новые кусочки знаний и ориентироваться в имеющемся, находить нужное.

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

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

Пост на FB Наталия Михайлова. Как с помощью одного проекта систематизировать корпоративную базу знаний, подружить коллег и увеличить лояльность клиентов: история создания онлайн-курса. Наталья - из компании Getintent, которая делает AI-платформу Programmatic для ведения рекламных компаний online. Сложная высокоспециализированная область, с большим количеством специальной терминологии и сложных технологий. Клиенты ей пользуются в двух режимах - заказывая им настройку рекламных компаний как аутсорсерам, или самостоятельно настраивая свои рекламные компании, и они заинтересованы, чтобы клиентов на самообслуживании было больше. Проект касался трех команд: Sales, Account и AdOps - команда поддержки клиентов, разработчиков не затрагивали. В каждой команде - свой язык, люди друг друга понимали, а коммуникация между командами была сложной.

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

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

B дальше был достаточно подробный рассказ про технику. Курс делала команда AdOps Люди собирали уроки, отправляли на техническую проверку. Дальше в маркетинг - стилизация текста под публицистический, язык клиентов. Очень много информации от технических специалистов, и при этом - специальный непонятный язык, поэтому убираем воду, но объясняем непонятное. И потом техническая проверка, что при стилизации не испортили.

Отдельная проблема, что разные люди по-разному описывали один инструмент. Они сводили воедино и проверяли понимание у авторов, добивались согласованного понимания. И появлялся словарь терминов.

  • Основной формат передачи - презентация, картинки и схемы.
  • Текстовые уроки тоже есть - там важно разбиение на части, заголовки по фрагментам. Чтобы можно было идти по мини-темам отдельно. И пропускать ненужное, уже известное - курс проходят люди с очень разным начальным уровнем.
  • Не инфинитивы, а побудительные глаголы - воспринимается легче и вспоминается легче. Короткие предложения, без воды.
  • Еще - скрин-каст инструкции и видеолекции.

Видеолекции - не так сложно. Можно использовать подручные материалы - iPhone очень хорошо снимает.

После создания курса его запустили. Прохождение теста обязательно, тест сложный, но есть несколько попыток - можно повторно посмотреть курс. Сделали номинации за лучшего прохождения курса. И это вызвало позитив. Тестирование до обучение. Через месяц - повторное тестирование. Рост ответов 20%. И видели прогресс, и пробелы. Пробелы тимлиды в проходят индивидуально. Сейчас тестирование включено в курс. После создания курса использовали его для онбординга новых сотрудников, получили очень крутой результат. И это сократило время тимлидов на их онбординг.

Запустили для клиентов, сделали 1 новость и рассылку - и за месяц было 300 студентов, они приходили сами. Раньше это было через личные встречи с клиентами. Они сократили это от 6 до 12 часов. А еще сократилось количество простых вопросов от клиентов. В начале марта открыли школу для всех - клиентов, партнеров, конкурентов. И люди приходят. Три агентства привели всех сотрудников на обучение. Сейчас они идут к сертификации агентств.

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

Курс создавали на платформе GetCource - она для них оказалась самой удобной. Потому что много возможностей для тех, кто умеет работать с кодом. Много кастомизации, совмещение разных форматов, чат с кураторами.

Евгений Селевич. Новые технологии для управления адаптацией и риском потери новых сотрудников

Пост на FB Евгений Селевич (Eugene Selevich). Новые технологии для управления адаптацией и риском потери новых сотрудников. Рассказ был не о технологиях, а о принципиально новом взгляде на процесс вхождения сотрудника в компанию. А именно, как на процесс получения сотрудником employee experience, благодаря которому он либо останется сотрудником компании, либо уйдет искать другое место. Именно такой взгляд становится уместным на дефицитном рынке сотрудников,погружение которых дорого, а конкуренция - велика в современных условиях, когда люди очень легко меняют работу.

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

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

Для мониторинга нужны метрики: retention, удержание сотрудников; выход в продуктивность; удовлетворенность сотрудника компанией, включая метрики инцидентов и их исправления.

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

А еще был рассказ о том, как это можно собрать на коленке, и как они работали у себя в компании до того как сделали инструмент. Интересно, что основа - Workplace by Facebook, у нее есть бесплатная версия, ограничения которой несущественны. Там все социальное общение, приветствия, доступ к предыдущим постам. Там же голосования и опросы. И он все это видит, включается в социальную жизнь. Остальное - понятно, таск-трекер, мессенджеры, митинги, средства обучения. Но это все - техника.

В заключении было очень интересное сообщение. Готовя свой продукт они, естественно, изучали рынок. При чем глобальный, рынок России слишком мал. И пришли к выводу, что тема комплексного онбординга, ориентированного на удержание персонала через employee experience выстрелит в 2021 году. Что значит "выстрелит"? Это значит, что отраслевые лидеры сочтут задачу актуальной для себя в конкуренции за персонал. А как только кто-то из отраслевых лидеров достигает вау-эффекта - это тут же становится стандартом отрасли, плюс влияет на смежные - многие сотрудники сейчас востребованы в разных отраслях и свободно переходят. И к этому надо готовиться. Это - изменение культуры и процессов, по сути, переход онбординга в digital-вариант с постоянными метриками и мониторингом от неспешного старого лампового варианта. Который не исключает личное общение в разных форматах, но в котором постоянно наблюдаем и оцениваем эффекты от этого общения.

Мария Белоглазова. Как построить процесс менторинга для сотрудников, и кому он действительно нужен

Пост на FB Мария Белоглазова. Как построить процесс менторинга для сотрудников, и кому он действительно нужен. Очень крутой рассказ про менторство, с хорошим разбором процесса и его целей, с отличием от других форм. Что интересно, на момент становления менторинга в компании уже был коучинг как регулярный процесс, 400 кейсов. Но был фидбек - экспертизы не хватает. А у коучей предметной экспертизы нет, они из HR и снаружи. Они начали искать форму и запустили менторинг как раз для того, чтобы дополнить коучинг другой формой.

Доклад Мария начала с различий менторинга от других форм. На шкале директивности: Наставник - Ментор - Коуч.

  • Наставник - знания, повторяй за мной 1-2-3
  • Ментор - навыки, углубление знаний, он и делится экспертизой и развивает людей.
  • Коучинг - работа с установками: ценности, выгорания, внутренние ограничения

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

Сначала собрали: кто хочет учить и у кого вы хотели бы учиться. Получили 15 человек, которых обучили. И запустили первую группу. Был супер-результат, 10/10, 94% успехов. Были факапы, отвалы менторов и менти. Двое менторов отвалились, и один менти у ментора, который отвалился сразу. Учли ошибки, процесс продолжается.

Ментор

  • есть экспертиза
  • внутренняя потребность делиться опытом
  • ставит вызовы и масштабные цели
  • верит, что менти способен достигнуть
  • взаимное доверие и открытость коммуникации внутри (но не публично)
  • умение передать то, что умеешь

Кейс. К ментору пришли за тайм-менеджмент "ничего не успеваю". Ментор посмотрел - увидел, что планирует и выполняет очень много. Разобрались - 17 прямых подчиненных. И они перестроили структуру отдела за три встречи, выстроив промежуточный уровень.

Запросы формулируют разные, и в 90% случаях начальный запрос - не то, что надо решать.

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

Надо отбирать и менторов и менти, и обучать обоих. Менти - не новичок, есть база и есть конкретный запрос. И еще - химия взаимодействия.

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

Процесс для сотрудника

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

Компетенции ментора

  • Слушать и слышать -- выявлять запрос, в 90% приходят с неправильным запросом
  • Разделять ответственность -- запрос "я хочу повышения" - за это не отвечаю, но могу помочь стать готовым, претендовать на повышения.
  • Задавать вопросы "на подумать". Не всегда надо давать решение, сначала самостоятельно, ментор дополнит
  • Создавать сильный контракт. Ментор челленджит человека, у менти есть интерес двигаться.
  • Наблюдать, подвергать сомнения взгляды ученика. Чтобы был выход за рамки парадигмы мышления, ограничения.
  • Закреплять успешный опыт, изученное. Ментор должен помогать фиксировать, что уже получилось, менти часто думают, что движение медленное.

Критерии успеха

  • менти становятся менторами
  • растет спрос среди сотрудников
  • растет ценность развития других

Был вопрос про мотивацию. Для нее развитие - естественная мотивация. Но для менторов у них менторы-профессионалы. При этом у них растет не только менторские скилы, но и скилы руководителя.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.