Об ведение базы знаний
(копия моего поста в одном из чатов)
При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):
- Поиск внешний
- Сбор и учет материала, фиксация ссылок, выгрузка контента
- Осмысление материала, фиксация мыслей
- Анализ взаимосвязей между темами
- Корректировка и переработка материала
- Поиск материала в своей БЗ
- Обмен материалами с другими людьми / встраивание материалов в повседневную работу
Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.
Ты лично должен их осуществлять — за тебя никакой инструмент не запишет твои мысли после прочтения статьи.
Но может помочь с этим (предоставив удобную локацию для записи и удобный интерфейс), или помешать (заставив тебя задумываться куда именно записывать).
Ну и инструменты обычно помогают только с какими-то небольшим набором сценариев.
К примеру, OneNote хорошо помогает фиксировать ссылки ко встречам в аутлуке, выгружать с них контент (мой основной юзкейс для него), но не помогает со всем остальным.
А Obsidian/Logseq из коробки с этим никак не помогают и здесь у нас разрыв в деятельности (если кто-то может рассказать как быстро и просто из календаря в аутлуке попадать в страницу в obsidian, и из нее обратно в календарь — я буду очень благодарен).
Хорошие инструменты помогают с большим количеством сценариев — по сути удобны для всех этих сценариев кроме разве что поиска внешнего (и поиск это отдельная большая важная тема) и обмена материалами с другими.
Часто возникает и куча смежных задач для инструмента, типа работы с задачами, рисования и т.д. — это часто реализуется через плагины, здесь Obsidian на высоте.
А с поиском внешним (в интернете, в корпоративном поиске или других системах) никак не помогают.
И вернусь к основной мысли — ключевое не в инструменте, а в подходах к работе, в обмене ими я вижу максимальную ценность
Я могу описать несколько принципов, которым стараюсь следовать:
- Не держу миллион вкладок в броузере, ссылки сохраняю в БЗ и в двух словах пишу что это и зачем (например, «Сравнение инсталляторов Kubernetes https:///ссылка»)
- Если прочитал статью и нашел ее интересной — выгружаю ее снимок в Zotero, т.к. через год-другой ее в интернете уже не найдешь. Кстати, можно попробовать вести таким образом библиотеку контента из интернета расшаренную на компанию. Плюс линкую в БЗ в виде отдельной страницы (происходит автоматом в виде плагина)
- Если нужно письменно о чем-то порассуждать — делаю это в БЗ, и сразу проставляю [[ссылки]] на другие страницы, чтобы через полгода при поиске информации можно было найти свои старые мысли через обратные ссылки/backlinks. Конкретно в этом пункте в Obsidian будет некоторое ограничение, т.к. в нем (в отличие от Logseq) по-моему нет ленты/журнала в который я пишу мысли не задумываясь «в какое место их положить», и обратных ссылок в Obsidian тоже по-моему нормальных не было
- Предыдущий пункт мне позволяет «автоматически» создавать страницы про концепты и делать связи между не связанными на первый взгляд темами. Пример в скрине ниже — я не писал ничего про Engineering, но в 5 страницах ссылался на термин, плюс Logseq мне нашел еще 117 страниц, где слово встречается в тексте
- Если где-то написал что-то что захочу сохранить (например, этот пост) — копирую к себе в БЗ.
- Ну и все вообще записи (кроме проектных) веду в Logseq — поэтому он останется приватным
- Вся проектная активность — вокруг корпоративного стека MS Office (Outlook, OneNote) и проектных Gitlab/Wiki/и т.п.
Вот по сути вся моя методология ведения базы знаний. Поделитесь своей?
(копия моего поста в одном из чатов)
При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):
- Поиск внешний
- Сбор и учет материала, фиксация ссылок, выгрузка контента
- Осмысление материала, фиксация мыслей
- Анализ взаимосвязей между темами
- Корректировка и переработка материала
- Поиск материала в своей БЗ
- Обмен материалами с другими людьми / встраивание материалов в повседневную работу
Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.
Ты лично должен их осуществлять — за тебя никакой инструмент не запишет твои мысли после прочтения статьи.
Но может помочь с этим (предоставив удобную локацию для записи и удобный интерфейс), или помешать (заставив тебя задумываться куда именно записывать).
Ну и инструменты обычно помогают только с какими-то небольшим набором сценариев.
К примеру, OneNote хорошо помогает фиксировать ссылки ко встречам в аутлуке, выгружать с них контент (мой основной юзкейс для него), но не помогает со всем остальным.
А Obsidian/Logseq из коробки с этим никак не помогают и здесь у нас разрыв в деятельности (если кто-то может рассказать как быстро и просто из календаря в аутлуке попадать в страницу в obsidian, и из нее обратно в календарь — я буду очень благодарен).
Хорошие инструменты помогают с большим количеством сценариев — по сути удобны для всех этих сценариев кроме разве что поиска внешнего (и поиск это отдельная большая важная тема) и обмена материалами с другими.
Часто возникает и куча смежных задач для инструмента, типа работы с задачами, рисования и т.д. — это часто реализуется через плагины, здесь Obsidian на высоте.
А с поиском внешним (в интернете, в корпоративном поиске или других системах) никак не помогают.
И вернусь к основной мысли — ключевое не в инструменте, а в подходах к работе, в обмене ими я вижу максимальную ценность
Я могу описать несколько принципов, которым стараюсь следовать:
- Не держу миллион вкладок в броузере, ссылки сохраняю в БЗ и в двух словах пишу что это и зачем (например, «Сравнение инсталляторов Kubernetes https:///ссылка»)
- Если прочитал статью и нашел ее интересной — выгружаю ее снимок в Zotero, т.к. через год-другой ее в интернете уже не найдешь. Кстати, можно попробовать вести таким образом библиотеку контента из интернета расшаренную на компанию. Плюс линкую в БЗ в виде отдельной страницы (происходит автоматом в виде плагина)
- Если нужно письменно о чем-то порассуждать — делаю это в БЗ, и сразу проставляю [[ссылки]] на другие страницы, чтобы через полгода при поиске информации можно было найти свои старые мысли через обратные ссылки/backlinks. Конкретно в этом пункте в Obsidian будет некоторое ограничение, т.к. в нем (в отличие от Logseq) по-моему нет ленты/журнала в который я пишу мысли не задумываясь «в какое место их положить», и обратных ссылок в Obsidian тоже по-моему нормальных не было
- Предыдущий пункт мне позволяет «автоматически» создавать страницы про концепты и делать связи между не связанными на первый взгляд темами. Пример в скрине ниже — я не писал ничего про Engineering, но в 5 страницах ссылался на термин, плюс Logseq мне нашел еще 117 страниц, где слово встречается в тексте
- Если где-то написал что-то что захочу сохранить (например, этот пост) — копирую к себе в БЗ.
- Ну и все вообще записи (кроме проектных) веду в Logseq — поэтому он останется приватным
- Вся проектная активность — вокруг корпоративного стека MS Office (Outlook, OneNote) и проектных Gitlab/Wiki/и т.п.
Вот по сути вся моя методология ведения базы знаний. Поделитесь своей?
👍1
Об весенние конференции 2025
В апреле 2025 я делал два доклада на конференциях примерно на одну и ту же тему.
1. «Компетенции и уровни развития инженера инфраструктуры. Системный взгляд» на конференции DevOpsConf 2025.
Я рассказывал про то, как расти инженеру – во многом на базе материалов, которые я публиковал здесь на канале.
Я сам недоволен тем какой доклад получился, поэтому видео не выкладываю. При должном желании вы его найдете, или увидите его когда доклад опубликуют организаторы конференции.
2. «Бизнес-ориентированные модели компетенций: инженерный подход к построению» на конференции MergeConf 2025.
Доклад на базе той же модели, но без адаптации под конкретный профиль сотрудника, и чуть расширенная для того чтобы захватить не только направление devops.
В докладе я разбираю как деятельность любой организации разворачивается в проекты, в наборы компетенций проектных команд (более точное название – capability), знание предметных областей, и наконец, в набор элементарных навыков.
Модель может задать систему координат в построении моделей компетенций конкретно под вашу компанию.
Слайды доклада: https://mergeconf2025.timurb.ru/
Видео: https://youtu.be/iJl4kQq1YcY
Краткое содержание:
- Попытаемся рассмотреть модель компетенций как продукт, опишем сценарии ее использования, и через нее построим ее содержательно
- 5 основных сценариев, в которых пытаются использовать модель компетенций
- Уровень в организации определяется ответственностью за результат
- Декомпозиция результатов на составляющие и во времени
- Предметные области и шкала владения ей
- Жизненный цикл системы задает набор навыков необходимых команде
- Middle-минус работают не по результатам, а по задачам
- Типовая задача devops-инженера, которая встретится на любом проекте
- Построение карьерных путей — навигация по пространству ответственности
- Построение обучения внутри уровня — описание предметной области
В апреле 2025 я делал два доклада на конференциях примерно на одну и ту же тему.
1. «Компетенции и уровни развития инженера инфраструктуры. Системный взгляд» на конференции DevOpsConf 2025.
Я рассказывал про то, как расти инженеру – во многом на базе материалов, которые я публиковал здесь на канале.
Я сам недоволен тем какой доклад получился, поэтому видео не выкладываю. При должном желании вы его найдете, или увидите его когда доклад опубликуют организаторы конференции.
2. «Бизнес-ориентированные модели компетенций: инженерный подход к построению» на конференции MergeConf 2025.
Доклад на базе той же модели, но без адаптации под конкретный профиль сотрудника, и чуть расширенная для того чтобы захватить не только направление devops.
В докладе я разбираю как деятельность любой организации разворачивается в проекты, в наборы компетенций проектных команд (более точное название – capability), знание предметных областей, и наконец, в набор элементарных навыков.
Модель может задать систему координат в построении моделей компетенций конкретно под вашу компанию.
Слайды доклада: https://mergeconf2025.timurb.ru/
Видео: https://youtu.be/iJl4kQq1YcY
Краткое содержание:
- Попытаемся рассмотреть модель компетенций как продукт, опишем сценарии ее использования, и через нее построим ее содержательно
- 5 основных сценариев, в которых пытаются использовать модель компетенций
- Уровень в организации определяется ответственностью за результат
- Декомпозиция результатов на составляющие и во времени
- Предметные области и шкала владения ей
- Жизненный цикл системы задает набор навыков необходимых команде
- Middle-минус работают не по результатам, а по задачам
- Типовая задача devops-инженера, которая встретится на любом проекте
- Построение карьерных путей — навигация по пространству ответственности
- Построение обучения внутри уровня — описание предметной области
🔥1
Я последний месяц слишком часто в обсуждениях кидаю скрин этого слайда, выложу и сюда. Он на самом деле ключевой во всей теме.
Уровень ответственности в абсолютно любой организации, и уровень сложности задач растет как показано слева (но далеко не во всех организациях есть предсказуемые переходы на следующий уровень).
Навыки которые нужны для этого уровня ответственности — справа. Обратите внимание на то, что это за навыки содержательно, что именно мы получаем при их применении.
Пример: Если ты знаешь не одну вендорскую коробку, а а две или три — это кажется и не рост вовсе. (Например, если ты помимо ELK изучил еще fluentbit, loki, vector и otel).
Если при этом научился делать аргументированный выбор между ними — вырос.
Если не просто выбрал и реализовал решение, но и научился и начал этим решать чьи-то чужие проблемы (проблема — это то, что не решается в лоб стандартными способами) или разобрался как это приносит постоянную пользу кому-то другому и начал это применять — вырос еще
Уровень ответственности в абсолютно любой организации, и уровень сложности задач растет как показано слева (но далеко не во всех организациях есть предсказуемые переходы на следующий уровень).
Навыки которые нужны для этого уровня ответственности — справа. Обратите внимание на то, что это за навыки содержательно, что именно мы получаем при их применении.
Пример: Если ты знаешь не одну вендорскую коробку, а а две или три — это кажется и не рост вовсе. (Например, если ты помимо ELK изучил еще fluentbit, loki, vector и otel).
Если при этом научился делать аргументированный выбор между ними — вырос.
Если не просто выбрал и реализовал решение, но и научился и начал этим решать чьи-то чужие проблемы (проблема — это то, что не решается в лоб стандартными способами) или разобрался как это приносит постоянную пользу кому-то другому и начал это применять — вырос еще
Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture:
https://eaonapage.com/
4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):
Из изменений:
- Добавилась модель зрелости EA
- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации
- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)
- Уточнены формулировке на карте артефактов
Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:
- Lifecycle объектов уровня солюшена и масштабнее
- Опермодель архитектурной функции и взаимодействие между отделами и проектами
- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)
https://eaonapage.com/
4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):
Из изменений:
- Добавилась модель зрелости EA
- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации
- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)
- Уточнены формулировке на карте артефактов
Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:
- Lifecycle объектов уровня солюшена и масштабнее
- Опермодель архитектурной функции и взаимодействие между отделами и проектами
- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)
👍1