Knowledge and bacon - Управление знаниями в IT

Google Docs упрощает работу с Markdown На той неделе Google Docs анонсировал поддержку импорта и экспорта Markdown формата. Причем это работает даже на обычной вставке! Чем это круто для тех, кто работает с техническим контентом? Если вы пишете черновики и обсуждаете их сначала в гуглодоке, но потом доку или статьи в базе знаний нужно публиковать в Markdown - это спасение. Также если нужно отдать статью на ревью, получить быстрые комментарии, но ревьюеры не полезут в соры - тоже спасение, заимпортил, обсудил, отредактировал, заэкспортил. Еще одна вещь, которую я узнала буквально недавно - в самих гуглодоках некоторые элементы Markdown тоже поддерживаются, это можно включить в настройках (Инструменты - Настройки).

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

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

Александр Клименко рассказал, как они создают и переиспользуют внутренние артефакты базы знаний в публичной документации Из доклада можно унести готовый чек-лист, как разобрать внутренние артефакты, какие методики применить, чтобы привести их в порядок, например: - Использовать постепенно раскрытие (progressive disclosure), описывая прямо в процессе разработки - Хранить историю изменений - Вести реестр фигур описаний - какие глаголы используем для действий, какие названия для элементов системы - Фиксировать источники

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

Продолжаю конспектировать для вас доклады #knowledgeconf снова про #базызнаний Николай Сенин рассказал о нескольких типичных архитектурах баз знаний и под какие задачи они лучше подходят. Важно помнить, что накопление информации в БЗ развивается по S-образной кривой и в какой-то момент наступает предел. Типичные подходы к структуре: - Списки - Дерево - Граф - Свойства/фасеты Решаемые задачи: - Совместное решение задач - функциональная организация в виде дерева - Обучение - структура от целей обучения или других параметров, например, задача, сложность, грейд - Синхронизация представлений - списки, словари, глоссарии, небольшие графы - Получение новых выводов - определить от каких свойств выстраивать структуру, чаще - два свойства

Анастасия Граф прямо сейчас рассказывает о том, как сформулировать требования к базе знаний и провести ее реинжиниринг. С чего начать? - А точно ли есть что-то ценное прямо сейчас? - Договоритесь о языке и сформируйте глоссарий - Делим все оставшееся на три категории: точно актуально, точно мусор, надо разобраться Внезапный совет: Мусор не удаляем, заводим отдельное пространство, помечаем как архив, что-то обязательно кому-то окажется ценным, то что вам таковым не показалось. Как страницы попадают в «архив, два варианта: - Если страница на протяжении квартала не использовалась, можно отправить ее в архив. - Выделить спринты на разбор и идти порциями в выделенное время Что фиксировать по ходу - Типы конвента - например, страница справочника, отвечающая на вопрос что это - Важно выбрать правильный оптимальный для вас триггер обновления - изменение статуса, изменение внешней среды (законодательства например), - Связи между материалами. Если настраивать их сразу, то меньше вероятность потерь Что проектировать по ходу - Статусы страниц - Кто будет владельцем контента, кто отвечает за триггер - Шаблоны - чем больше, тем проще потом людям вносить вклад. Снижаем тревожность. - Требования к оформлению - в идеале прямо в шаблоне - Порядок верификации - что будем делать, когда появляется новая страница, кто проверяет, описание внутреннего процесса - Порядок актуализации - кто и как обновляет, они используют отчеты/дашборды - Дерево страниц Пост дополняется 👩‍💻 #базызнаний #knowledgeconf

Квинтэссенция моего выступления на KnowledgeConf 2024 в Санкт-Петербурге Забирайте, распечатывайте, а если интересно подробнее - ждите запись, скоро будет!

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

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

Обнаружила, что гайдлайны Википедии могут быть очень классно применимы для компанейских и командых баз знаний, особенно рекомендации для computer science статей, конечно их надо адаптировать, но тем не менее 💪 Эти рекомендации помогают структурировать и проверять информацию, что особенно важно для эффективного распространения знаний внутри организации. Рассмотрим, как можно адаптировать эти принципы для корпоративной среды. Wikipedia предоставляет четкие руководства по написанию статей в области conputer science, например, как структурировать, как называть, как оформлять примеры кода, как ссылаться. 1. Вводный Раздел Каждая статья в вашей базе знаний должна начинаться с вводного раздела, который описывает основную тему в общих чертах. Это помогает сотрудникам быстро понять, о чем идет речь, и решить, нужно ли им читать дальше. Введение должно быть кратким и информативным, резюмируя ключевые моменты статьи. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#Length 2. Обзор или Предыстория Следующий раздел должен предоставлять неформальное введение в тему, которое будет понятно даже тем, кто не обладает техническими знаниями. Это может быть раздел "Background" или "Overview". Такой подход помогает дать контекст и базовое понимание темы. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Computer_science#Background_and_application 3. Структура Статей Статьи на разные темы могут быть структурированы по-разному. Важно учитывать специфику информации и целевую аудиторию. Например, технические статьи могут включать разделы с примерами кода, тогда как статьи по процессам могут содержать пошаговые инструкции и схемы. Используйте структуру, которая наилучшим образом передает содержание и помогает читателям усваивать информацию. По ссылке есть рекомендаци для разных типов: https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Computer_science#Structuring_different_kinds_of_articles 4. Примеры Кода Для статей, содержащих технические инструкции, очень полезно включать примеры кода. Они должны быть понятными, легко воспроизводимыми и хорошо прокомментированными. Примеры кода помогут сотрудникам лучше понять и применять теоретические знания на практике. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Computer_science#Code_samples 5. Включение Ссылок Очень важно, чтобы вся информация в вашей базе знаний была проверяема с помощью надежных источников. Включайте ссылки на литературу, внутренние документы и внешние ресурсы. Любая спорная информация должна быть подкреплена встроенной ссылкой на надежный вторичный источник. Это повышает доверие к вашей базе знаний и упрощает поиск дополнительной информации. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Computer_science#Including_references. и еще статья из общих гайдлайнов Вики https://en.wikipedia.org/wiki/Wikipedia:Verifiability Эти рекомендации - хорошее подспорье, чтобы не начинать придумывать с нуля. А вы какие хорошие гайдлайны про базы знаний видели?

Небольшой апдейт о нашем эксперименте по разметке знаний в мессенджере, вдруг вы тоже захотите что-то подобное Он пока не показал успеха и на это есть ряд причин: - Мы выбрали слишком generic эмоджи (совушку 🦉) и сделали на него алиас :useful-knowledge:, но отделить в результатах поиска с помощью алиаса теперь нельзя - Тестовой группе не вполне была понятна задача "размечать полезные знания, которые они затем хотят вновь найти в Слаке", потому что много информации имеет короткий срок жизни, но может быть полезной в моменте - Не ясно, как учитывать размеченное в приватных каналах - Нам не вполне понятно, а что делать с размеченными знаниями - переносить в базу знаний или же как-то индексировать и делать искабельными в корпоративном поиске или каком-то AI-боте Любые идеи, мысли приветствуются.

Давно хотела поделиться с вами трендами, которые пророчат для управления знаниями в 2024 году (да-да, полгода спустя очень актуально). APQC недавно выпустил отчет по результатам опроса о текущих тенденциях и приоритетах в управлении знаниями, проведенного в начале года. В отчете много интересного. Конечно, искусственный интеллект на переднем крае, но в первой пятерке задач остаются картирование знаний и перенос экспертизы. Задачи управления знаниями принципиально не изменились — фокус по-прежнему на сохранении и распространении знаний, поиске и доступности знаний. Однако ИИ постепенно трансформирует наши процессы. Управление знаниями как дисциплина никуда не уходит, наоборот актуализируется в связи с неоходимостью отдавать данные для дальнейших ответов ИИ, а хайповая технология становится еще одним инструментом в нашем арсенале. Ссылка на отчет: https://www.apqc.org/system/files/resource-file/2024-01/K013966_2024%20Knowledge%20Management%20Priorities%20and%20Predictions%20Survey%20Report.pdf

Знания идут к пользователю, а не наоборот Увидела просто поразившую меня вещь в языке Go — когда вы используете функцию из стандартной библиотеки, можно вот так навести, чтобы посмотреть на документацию к этой функции и там есть пример от разработчиков - в IDE на него можно кликнуть, чтобы открыть пример как отдельный файл с кодом, поредактировать и позапускать, чтобы посмотреть output. Локально у меня этих примеров и описаний не было, то есть это часть самого Go SDK и открывается в IDE как временный (scratch) файл. А вы встречали другие классные примеры, когда "документация идет к пользователю", в его контекст, а не наоборот?

Мы сейчас в компании экспериментируем с разметкой полезных знаний в мессенджере, пытаемся пока что только проверить гипотезу. В связи с чем наткнулась на интересную статью 2015 года: https://18f.gsa.gov/2015/12/08/using-emoji-for-knowledge-sharing/ Кратко, что делали в этой компании: - Взяли эмоджи вечнозеленого дерева и попросили сотрудников размечать им сообщения или треды, которые "стоит знать/видеть всем новичкам в компании". - Потом проходились по ним поиском (у Слака есть нотация has: эмоджи) и оценивали, что людям показалось важным и "вечнозеленым". Для упрощения использовали CLI тулзу, которая все такие сообщения выгружала в репорт: https://github.com/18F/emoji_search - В первые недели они получили больше 100 размеченных сообщений и обновили на их основе онбординг в компании. Поделитесь, пробовали что-то подобное у себя, как-то размечать знания в мессенджерах? Было ли это для целей онбординга или других?

Наткнулась на крутой кейс от Selectel - Елена Насыбуллина рассказывает о том, как они распаковывали знания экспертов, чтобы сэкономить их время, а затем выбирали подходящий формат упаковки, чтобы эта распаковка не прошла зря и люди не начали снова ходить с вопросами к тем же экспертам. Все это на примере создания внутреннего курса по архитектуре сетей. Читать тут: https://selectel.ru/blog/what-is-knowledge-management/ Несколько инсайтов лично для меня: - То, как они собирали потребности в знаниях через опросник при этом делая акцент, что речь о знаниях нужных для выполнения рабочих обязанностей == блокирующих - Делили всю информацию на ту, которую можно нагуглить (контекст, предусловные знания) и ту, которую качественно нагуглить не получится - собственно экспертиза - Определили периодичности актуализации (таймеры), причем для разных знаний она разная

KnowledgeConf возвращается, теперь в Петербурге KnowledgeConf вновь будет отдельным треком про управление знаниями в ИТ-командах и компаниях, в этот раз 24 и 25 июня в рамках питерской TeamLead Conf. CFP уже идет во всю, подробности тут: https://cfp.knowledgeconf.ru Особенно не хватает заявок по темам: - Онбординг, да, про него сказано уже много, но если вам удалось найти какой-то новый подход, убрать часть ручных операций, сохранить качество при бурном росте - поделитесь этим со слушателями. - AI-инструменты в управлении знаниями: если вы внедрили чат формата вопрос-ответ по корпоративным знаниям компании, сделали AI-ассистента, который помогает онбордиться новичкам, или же AI помогает вам в структурировании, рефакторинге и таксономии базы знаний - будем очень рады заявке. - Единая точка доступа к знаниям: внедрили единую точку доступа к знаниям, например, реестр архитектурных решений, систему корпоративного поиска или каталог сервисов? Расскажите про это. - Извлечение и упаковка знаний экспертов. Нам интересны доклады про работающие практики проведения интервью или фиксацию знаний экспертов, про создание локаторов экспертов и использования нейросетей для поиска пробелов, распаковки и оформления экспертных знаний в артефакты.

Notion поглотил Cron (и представил Notion Calendar) Я не пользовалась Cron до поглощения, поэтому не могу сравнить, но пока выглядит очень удобно и многообещающе. Что заметила из полезного: - Можно создать документ в Notion прямо из события и перейти в него. - Можно подключить несколько календарей и управлять ими оттуда, например, добавлять ивенты, передвигать, смотреть доступность коллег - Можно подключить Zoom/Google Meet и создавать звонки прямо из календаря - Если в базе данных/таблице/таймлайне проекта есть упоминание сроков/дедлайнов - из них можно сделать отдельный календарь Буду наблюдать. Я сейчас практикую тайм блокинг/батчинг, поэтому послеживаю за тулами, которые позволяют мне управлять несколькими календарями и заодно заметками/документами. Кто уже попробовал?

Фронтенд-разработчица Наталья Давыдова в офигенном твиттер-треде запостила гайд, как вести рабочие конспекты в Notion так, чтобы легко можно было найти нужное и освежить знания по определенному аспекту. Мне кажется этот опыт можно переложить не только на языки программирования и фреймворки, но и на другие области. Если кратко по советам: - Любой конспект базируется на четырех китах: структура, уникальность формулировок, цветовое выделение, подкрепляемость практикой - Одна тема на одной странице - Не более трех уровней вложенности заголовков - Каждый кусок текста записывать своими словами, копирование не работает - Самую важную канву материала выделять цветом, чтобы быстро пройтись и освежить знания - Отдельно выделять примеры кода и плохие/хорошие советы - При конспектировании стараться обогатить конспект скринами, схемами, кусочками кода с пояснениями или "песочницами" с кодом. Лайфхак - можно записать коротенькое видео с демонстрацией - Когда конспект готов, можно использовать три техники: саммаризацию, повторяемость и доосмысление. - Материал, который требует повторения, например, перед собесами можно добавить в нумерованный список, запускать рандомайзер и повторять 3 рандомных пункта Для тех, у кого нет аккаунта, положу скрины треда в комменты.