The Know All - Управление знаниями в IT
814 subscribers
6 photos
2 files
149 links
Канал об управлении знаниями в айти-командах для тимлидов и всех, кого интересует тема knowledge sharing в технологических компаниях.

Писать по вопросам сотрудничества или общения на тему @Lananovikova
Download Telegram
to view and join the conversation
Управление знаниями в ClubHouse

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

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

Во-вторых, у CH есть база знаний ClubHouse KnowledgeCenter, они сделали её в Notion в формате ответов на основные вопросы: как создать комнату, как ее модерировать, как подать заявку на создание клуба, как отправить инвайт и так далее: https://www.notion.so/Clubhouse-Knowledge-Center-342989cefea148ec98b66455a4b6073b

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

В-четвертых, люди уже начали создавать неофициальные внешние базы знаний, где освещают более тонкие вопросы: что писать в биографии, как избежать блокировки, как не выгореть от бесконечного числа дискуссий. Она также организована в Notion (как и оригинальная от создателей) и в ней есть интересные статьи по этике и тонким настройкам, алгоритмам CH, а также список терминов https://www.notion.so/Clubhouse-a4c67555f60e41f3a29564124fe1249c Это невероятный эффект, и я даже полностью не могу его объяснить, вероятно, люди очень мотивированы обмениваться любыми знаниями и находками в новой для себя ситуации.

И еще наблюдение про нетворкинг — появился жанр «молчаливых комнат », где люди сидят с выключенными микрофонами, стучат по клавишам, читают био друг друга, добавляются в контакты.
​​Мотивация к обмену знаниями

В конце прошлого года я проходила курс PsyvIT Психология для руководителей (кстати неистово рекомендую пройти). Там был большой блок про выявление мотивации сотрудников, какие основные и ведущие мотивы, какие триггеры, чтобы их определить. Всего мы разбирали 5 основных типов мотивации: деньги, власть, карьера, признание, работа над значимым продуктом (вера в продукт) и причастность/принадлежность.

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

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

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

Какой бы ни была структура мотивации, нужна система поощрения к обмену знаниями и выражение kudos всем, кто этим активно занимается. Но это тема для отдельного поста.
Результаты опроса: Что мотивирует к обмену знаниями

Из результатов опроса видно, что материальные стимулы побеждают, но в целом распределение остальных довольно ровное, и совсем мало кого интересуют ачивки и бейджики на корпоративном портале. В сухом остатке, нужно делать все в комплексе:
- постоянно проговаривать на уровне компании, что у нас ценится обмен знаниями;
- работать с тимлидами, чтобы они поощряли такое поведение;
- ставить сотрудникам цели/OKR или прописывать в контракте, синхронизировать обмен знаниями с другими критическими процессами;
- публично благодарить, рассказывать на встречах, в рассылках и во внутренних каналах коммуникации;
- стимулировать участие в сообществах.
И все это в конечном счете влияет на visibility и материальное поощрение (выполнение целей, признание, включенность в процессы).

Какого характера это могут быть цели?
- Внести вклад в общую библиотеку и написать для нее ридми
- Возглавить/поучаствовать в работе community of practice
- Поделиться или переиспользовать лучшую практику
- Описать выученный урок
- Выступить экспертом для новичков или выступить с техтоком

А у вас в целях на квартал/полгода/год когда-либо было что-то об обмене знаниями? Поделитесь примерами в комментариях.
Вебинар про лучшие практики управления знаниями в проектной деятельности

Завтра, 17 марта Владимир Лещенко и Екатерина Скрыпник на бесплатном вебинаре расскажут о практиках применения управления знаниями в проектной деятельности и рассмотрят, какие практики УЗ можно найти в стандартах PMBOK и ISO 30401:2018. Будет полезно менеджерам проектов и проектных офисов, RnD проектов, отделов обучения и развития сотрудников.

Зарегистрироваться
​​Исследование NAUMEN и Tadviser про корпоративный поиск

Послушала вебинар NAUMEN про поиск корпоративной информации. Они представили результаты исследования практик работы с информацией в российских компаниях.

Выводы по проблемам получения информации довольно ожидаемые: чаще всего сотрудники попросту не знают, в какой именно системе искать информацию (это отметили 92 процента), во-вторых, ищут и не могут найти (62 процента), а в-третьих, когда сотрудники хранят знания локально, а до увольнения забывают положить в публичное место (42 процента).

Актуальна проблема не только поиска, но и сохранения и передачи внутренней часто не формализованной ифнформации. Ее не фиксируют или хранят локально.

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

Три самые актуальные:
- Затягивание сроков решения задач
- Увеличение операционных расходов
- Недополучение выручки

Кроме того, одни из выводов, что серьезность проблем передачи информации зависит от роли сотрудника. Рядовые сотрудники могут терять до 30% времени в день на поиск ответов на вопросы, которые уже давно зафиксированы, они попросту не понимают, где именно нужно искать.

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

Также у корпоративного поиска ограничены источники информации (они подключаются как интеграции) и важно учитывать права доступа, они наследуются от системы, по которой идет поиск.
​​Техника Root Cause анализа

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

И кажется её можно применить и к управлению знаниями, например, если вам нужно понять пробелы в знаниях или вы взялись за стратегию.

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

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

Пример довольно абстрактный, в реальности у вас будут стрелки не линейные, а много ответвлений и несколько «root cause», например, разрастающийся скоуп, неправильная приоритизация, добавление фич в релиз на ходу, сложный процесс самого релиза и прочее . Для построения таких цепочек полезно использовать Root Cause фреймворк.

Идея в том, что наша проблема - это не проблема, а симптом, мы не чиним ее саму по себе, а we need to go deeper.

Пишете по центру проблему, от нее рисуете стрелки: вверх последствия, вниз - причины. Итерируем по такому дереву несколько раз, добавляем-убираем. Причин обычно будет несколько, можно сосредоточиться на тех, которые ведут к наибольшему числу последствий. Далее придумываем контрмеру на один root causes и пробуем её. Если добились небольшого улучшения — чиним дальше.

Исходя из найденного в ходе такого исследования можно дальше строить метрики эффективности.

Есть еще хак, а как понять, что это root cause?
Визуально верный признак — если много стрелок идут вверх и ничего вниз.

У Хенрика Книберга есть отличная статья про эту технику, там в том числе есть советы, как делать такой анализ в группе, как избежать проблем излишней персонализации, упрощения и кейса «слишком много стрелочек и квадратиков». На картинке как раз пример из статьи.

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

⚡️ Полезное и бесплатное от хороших знакомых: Otus проводит два бесплатных занятия для начинающих тимлидов и минимум одно из них обещает охватить темы, связанные с передачей и фиксацией знаний в командах разработки.

Занятие Первые шаги тимлида на новом месте пройдёт уже завтра, 16 апреля в 20:00 и будет посвящено тому, как быстро «заонбордиться снизу» — быстро собрать нужные знания о продукте и команде и добиться быстрых побед, а также, какие компетенции нужно развивать тимлиду, а занятие Организация процесса разработки программного обеспечения состоится 26 апреля в 20:00 и расскажет о том, какие есть подходы и модели к организации процесса разработки.

👉 Для участия пройдите регистрацию по ссылке.

В качестве PS хочу добавить, что ещё со времен KnowledgeConf 2020 вдохновлена процессом подготовки и онбординга преподавателей в Otus, там он выстроен очень круто и зрело, об этом в своем докладе рассказывала Дарья Вьюнова. Дождитесь, когда запись выложат в общий доступ и обязательно посмотрите! А пока можете посмотреть интервью с Дарьей на канале MoreView.
100 компаний, которые будут иметь значение на рынке KM

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

Помимо гигантов, вроде Google, Microsoft, IBM, AWS, Deloitte, Accenture, из интересных мне туда попали:
Keeeb — компания, которая разрабатывает решения в сфере корпоративного поиска и цифровых рабочих мест. Они делают продукт, который позволяет собрать фрагментированные источники информации в единое пространство. https://www.keeeb.com/
Ontotext — компания делает продукт по преобразованию структуры знаний компании в графовую базу данных с возможностью визуализации, построения таксономий и словарей, что, например, позволяет находить новые связи и эффективнее рекомендовать контент. https://www.ontotext.com/
Clarabridge — они делают интересный сервис по анализу текста и речи на базе AI, вы скармливаете сервису записи разговоров и логи чатов службы поддержки, а он анализирует тональность дискуссии и другие маркеры и предлагает вам инсайты и пространство для улучшения коммуникации. https://www.clarabridge.com/
Synaptica — система управления бизнес-таксономией и тезаурусом, которая позволяет анализировать корпоративный контент, индексировать сущности, строить связи, искать по ним, описывать сущности стандартизированным языком. https://www.synaptica.com/
Capaсity — ещё одна система для помощи команде саппорта: встроенный AI умеет распознавать вопросы и ответы в разговорах и автоматически добавлять их в базу знаний, его можно подключить к множеству корпоративных каналов коммуникации и хранилищ. Ещё одна киллер фича: это расширенная аналитика и сбор данных, это позволяет понять, какие именно знания уже приносят вам наибольшую ценность, какие ещё являются «белыми пятнами», кто вносит самый большой вклад в наполнение ответов, какие знания требуют обновления и так далее. По словам разработчиков, модель обучится на вашем контенте всего за пару недель. https://capacity.com/

На самом деле интересных систем и платформ в списке еще много, но я выбрала топ наиболее заинтересовавших именно меня. Пишите ваших фаворитов в комментариях.
​​Как формулировать вопросы, чтобы оценивать глубину знания?

В пятницу послушала доклад Наталии Савастюк Как формулировать вопросы, чтобы оценивать глубину знания на SQA Days. Он был посвящен тому, как на основе таксономии Блума строить вопросы на собеседованиях.

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

⁃ Есть два подхода к обучению: Higher-Order Thinking Skills и Low-Order Thinking Skills. Первые — это навыки мышления высшего порядка, такие как анализ, синтез, оценка и критическое мышление. Считается, что учащиеся должны овладеть навыками более низкого уровня, прежде чем они смогут заниматься навыками более высокого порядка.
⁃ В основе подхода лежит таксономия Блума. Он разбил все знания на уровни глубины освоения.
⁃ На первом уровне есть только фактические знания. На втором понимание, на третьем превращение в практический опыт, применение, далее идёт анализ, когда знание распадается на составляющие, и на самом высоком уровне идут анализ, оценка и создание нового.

Как применить это при собеседовании в тестирование? Любой вопрос можно углубить в зависимости от целей.
Например, есть уровни:
⁃ Могу рассказать, что это;
⁃ Могу рассказать своими словами и привести пример;
⁃ Могу спроектировать и выполнить, использовать на практике в новых условиях;
⁃ Понимаю причинно-следственные связи, как связаны одно действие и другое, могу систематизировать проблемы;
⁃ Могу комбинировать знания между собой и придумывать автоматические проверки;
⁃ Могу обучать других.

Далее в докладе разбирались конкретные вопросы с собеседований и как можно их перевести на другой уровень.

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

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

Ссылка на слайды
Бот Валера теперь в open source

Чат-боты в последние годы стали неплохим подспорьем в налаживании процессов управления знаниями и автоматизации разного рода рутины. Многие видели, а кто не видел – посмотрите доклад Татьяны Бунто из HFLabs про бота Валеру с SECR-2019, который взял на себя часть рутинных задач в переписке, например, если кто-то делится ссылкой на документ из базы знаний: отображает его название и проект, если кто-то делится ссылкой на задачу из Jira — кратко отображает её описание, если кто-то отвечает на эту задачу в чате — публикует комментарий и в задачу тоже, а ещё помогает искать по тикет-трекеру и базе знаний прямо из чата. Кстати, там в комментариях под видео Ольга Павлова рассказала о том, что делает похожий чат-бот в «Собаке Павловой».

Но сейчас не об этом, а о том, что разработчик Валеры выложил в открытый доступ код бота: https://github.com/mehanizm/valera Форкайтесь, улучшайте, дополняйте, пользуйтесь!
Friendly Asked Questions #2 — про документацию

Я инженер в девопс команде и каждый раз когда дают задачи на незнакомый проект — это боль. Хочу, чтобы команда начала писать документацию, но тимлид пожимает плечами, а техдир начинает открыто троллить и идти на конфликт в ответ на такие разговоры. Как быть?

Ответы дали авторы каналов Уютный Адочек, DocOps и The Know All
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

@the_know_all — Лана Новикова

Документация — один из способов организовать коммуникацию по какому-то каналу. Это решение, а давайте вернемся к проблеме. Зачем документация и какую вашу проблему и проблему бизнеса она решит?
Проблема — неосведомленность сотрудников о том, что делается в другом проекте. Эту проблему может решить не только документация, но и, например, периодические демо, сессии обмена знаниями, shadowing (когда периодически специалисты из одного проекта переключают контекст и работают в паре с коллегами из другого в формате «тени»). Техническому директору это надо «продавать» в его терминах: ускорение разработки, снижение эскалаций, снижение рисков инцидентов.
В тему организации обмена знаниями между отделами есть хороший доклад Марии Палагиной


@docops — Ник Волынкин

Давай тут разделим проблему на три части.
1. Команда не пишет. Стань первым, кто начнёт это делать. Когда будешь в чем-то разбираться — делай заметки. Так у команды будет хороший пример. Постарайся рассказывать команде о том почему и как это делаешь, и замечать, как твоя работа реально будет помогать коллегам.
2. Тимлид не поддерживает идею документирования. Вы, наверное, сейчас теряете время на погружение в задачу и на изобретение велосипедов, теряете мотивацию людей, плохо учитесь на ошибках (и будете их повторять). Всё это напрямую мешает работе тимлида и ставит его задницу под удар начальства. Не предлагай тимлиду писать доки — предлагай ему помощь в его работе.
3. Техдир идёт на конфликт. Лучше приходить к техдиру с тем, что уже работает хоть на небольшом масштабе. И ещё, техдиру нужен запрос, который можно решить только на его уровне. Плохо: "Сделай так чтобы мой тимлид заставил нас писать доки". Хорошо: "Мы начали писать анализ инцидентов, это помогает, давай это распространим на всю компанию".

@lovely_it_hellЦупко Игорь

Можете ли вы писать документацию самостоятельно, подавая пример коллегам? Если в компании не выделяют время на изменения и инициативы — возможно пора поменять компанию.
Описанные реакции — странные. Троллинг и агрессия руководителя в ответ на инициативу подчинённого — звучит не здорово.
Если я правильно понимаю, вы хотите вдохновить коллег, побудить их к действиям. Попробуйте покидать им хороших примеров (возможно вы просто сейчас более "насмотрены" на хорошую доку, чем они), докладов, пописать короткие посты в чатики команды — но без нажима и требований. Вода камень точит и со временем какие-то идеи осядут в головах.
Несколько кейсов про онбординг

Онбординг новичков в ИТ-командах — тема, не теряющая актуальность последние лет 5. Все хотят ускорить time to first production code, сделать путь новичка максимально комфортным и даже сделать онбординг конкурентным преимуществом при найме.

Вот еще пара кейсов за последнее время.

- В Miro шаблонизировали процесс онбординга, сопроводили его описаниями основных процессов и даже ввели должность онбординг-ментора. Читать на Habr.
- Руководитель нескольких успешных стартапов Дон Неуфельд предлагает относиться к онбордингу, как к вашей системе сборки, просто собираете и релизите вы — разработчика. В этом случае процесс будет масштабируемым, не зависящим от коннкретных людей и с возможностью контроля исходника (отслеживание изменений и версионирование). Ну и мой любимый принцип — каждый новых сотрудник должен обновить онбординг. Читать на Medium.
Вебинар для тех, кто хочет войти в тему управления личными знаниями

8 июля (это четверг) Виктория Олешко, евангелист управления знаниями в Украине проводит вебинар для тех, кто только планирует начать управлять личными знаниями. Это вообще о чем? Это про вашу личную базу знаний, интересные статьи, изыскания, курсы, ~которые вы проходите и забываете~, книги, которые читаете, ~но не фиксируете важные мысли~, плюс связка всего этого с целями и задачами, а затем и с личным планом развития.

Методик миллионы, и Second Brain, и практики Тиаго Форте, и Zettelcasten, но в них бывает тяжело разобраться самому Если вы хоть раз находили старые записи по теме и радовались, как ребенок, что оказываетс вы это все уже записывали — это для вас.

Записаться в ФБ
Конкуренты Notion. Часть первая: Coda

На рынке появляется все больше записных «убийц Notion» — схожих по функциям и даже по дизайну облачным продуктам для организации баз знаний и процессов планирования.

Решила рассказать в серии постов о некоторых из них, которые удалось попробовать.

Итак, первая на очереди — Coda https://coda.io/welcome

Набирающий популярность облачный инструмент, его основали два бывших сотрудника Google и YouTube. У нее приятный чистый интерфейс, удобный интуитивный редактор, который также поддерживает и Markdown.

Основной строительный элемент — это документ.

Также, как и в Notion документ по умолчанию находится в режиме редактирования, не всем это нравится, кажется, что всегда есть шанс что-то сломать. Документы легко копируются из Google Docs без поломки верстки, есть удобная миграция из Notion.

Плюсы

В Coda удобно работать со сложными таблицами, делать разные представления и выборки из них, настраивать условное форматирование. Строить из них диаграммы Ганта, календари, Канбан-доски.

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

Есть:
⁃ Шаблоны
⁃ Поддержка Markdown
⁃ Интеграции с Google Docs, Mail, Miro, облачной версией Jira и множеством других сервисов
⁃ Офлайн режим
⁃ Приложение для работы/чтения с мобильного

Еще из плюсов — хорошая документация, коммьюнити и блог с идеями организации вашей базы знаний.

Особенности и минусы

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

Навигация не совсем привычна для тех, кто пользовался древовидными БЗ: сначала идут корневые папки, далее – документы, в которых может быть неограниченное количество страниц и подстраниц. Но чтобы просмотреть ветку иерархии целиком, нужно зайти в документ.

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

И ещё неприятный нюанс — если аккаунт докмейкера деактивирован, документ перейдет в режим read only, вернуть его в редактирование можно будет только через поддержку.

Документы можно публиковать наружу прямо из Coda, функция работает также, как у Notion, администратор может включить шаринг только по email или отключить его совсем, но все ранее расшаренные документы не перестанут торчать наружу. Это важное ограничение по безопасности.

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

Вердикт: для enterprise целей слишком много нюансов, но для личной базы знаний подойдет неплохо.
​​Самые популярные инструменты для шаринга знаний: исследование Jetbrains

Прочитала для вас результаты опроса Jetbrains Best Collaboration Tools in 2021 — Лучшие инструменты для совместной работы 2021.

В нем приняли участие 47 тысяч человек из 183 стран и регионов, из них более 31 тысячи — разработчики или инженеры.

В опросе явно выделили отдельную подкатегорию инструментов — Knowledge Sharing Tools, тут оказалось без сюрпризов. До сих пор шаринг знаний и шаринг файлов неразрывно связаны между собой, а Atlassian правит бал.

Чаще всего опрошенные называли Confluence (34%), GitLab (23%), Google Docs (21%), Google Drive (15%). Все еще не сдает позиций старичок Sharepoint (11%), но по процентам его уже догнала GitHub Wiki. Confluence кстати называли чаще всего и в категории Инструменты для командной работы.

8 процентов используют самописный внутренний тул для обмена знаниями. Их используют чаще, чем Notion (6%). Еще из интересных вариантов называли OneNote, Azure devops server, Redmine Wiki.

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

Ссылка на результаты
Онбординг в распределённой команде: кейс СберЗдоровья

Нашла для вас интересный кейс онбординга от СберЗдоровья, их опыт актуален для распределённых или удалённых команд. В докладе спикер, Руслан Остропольский, рассмотрел 3 подхода к онбордингу и их плюсы и минусы для разных ситуаций.

Из интересных идей:
- Структурировать путь новичка в виде roadmap
- Присваивать каждому пункту Definition of done, что является результатом каждого шага или как проверить его выполнение.

Запись выступления с CodeFest
Презентация
Статья на VC
​​Исследование Future of Work Research: 90 процентов сотрудников хотели бы чаще делиться знаниями, а у 65 процентов есть знания, о которых компания не в курсе

Наткнулась тут на результаты исследования Starmind под названием Future of Work Research: Connecting the Know-How, Skills and Expertise Within Your Organization и там оказалось немало интересного для нас, любителей управления знаниями.

Они опросили более 1000 так называемых knowledge workers в США и Великобритании, чтобы понять, как на продуктивность и успех организации влияет обмен инновациями, ноу-хау и экспертизой.

- В результате оказалось, что сотрудники тратят огромное количество времени на поиск информации, экспертизы и ноу-хау, которые им нужны для выполнения обязанностей.
- В то же самое время средний сотрудник использует всего 38 процентов своих знаний и опыта на работе.
- 90 процентов сотрудников хотели бы чаще делиться знаниями, 65 процентов считают, что у них есть знания, о которых компания не знает или не капитализирует, а 75 процентов признались, что могли бы получить и принести больше пользы, если бы имели доступ к знаниям.
- 61 процент опрошенных считают, что могли бы вносить больший вклад в корпоративные знания, но не знают, как.
- Самые большие сложности возникают в поиске эксперта в каком-либо вопросе. Сотрудники проводят в среднем 26 рабочих дней в поисках информаци, знаний и экспертизы.
- 62 процента отмечают, что информацию и ответы получить нелегко и более половины опрошенных избегают задавать вопросы, поскольку не знают, кого спросить или как получить нужный ответ.

От себя добавлю: Задавание вопросов — один из ключевых навыков и активностей в процессе шаринга знаний.

Также в исследовании есть интересная секция про роль AI в процессе сохранения и поиска знаний.

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

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

Ссылка на опрос
Душевный митап про внутренние митапы и сообщества от KnowledgeConf

14 октября в 14 часов по Москве будет онлайн-митап про организацию внутренних митапов и сообществ вокруг них: что, зачем, как и надо ли?

Два классных спикера: Иван Преснов из Купибилет и Алексей Долгушев из @devrel_ru расскажут об опыте постановки на рельсы внутренних митапов в компаниях — изнутри и извне. Где брать темы и спикеров? Какую задачу они вообще решают? Как не допустить затухания этой практики? Приходите, если у вас уже есть свой опыт и если только планируете запускать что-то подобное.

Регистрация по ссылке: https://knowledgeconf.timepad.ru/event/1778819/