Originally published at: Корпоративная база знаний, размышление о том как это можно организовать на Obsidian — Рустам Агамалиев
Для настройки управления знанием внутри корпоративного или, по крайней мере, коммерческого сегмента, недостаточно одного желания. Что маленькая компания, что крупная корпорация, обе требуют для запуска системы управления знанием и информацией определенной культуры. До сегодняшнего дня мне казалось, что это сделать без долгой и тяжелой работы с кадрами, воспитания определенной культуры ценностей, невозможно. Но что, если я не прав? Что если есть решение, которое позволит культивировать не культуру, а необходимость использовать общую информационную систему? Предположим, перед нами имеются следующие два кейса с вполне конкретными критериями успеха.
[!NOTE] Кейс 1: Составление документации по итогам проекта
Составление документации играет ключевую роль в завершении проекта. Это не просто формальность, но и важный шаг в управлении проектом. Как правило, начинается это с создания стандартного оглавления.Аналитик, на основе своего опыта и задач, вставляет раздел о функциональности. Архитектор, со своей стороны, дополняет документацию разделом об архитектуре, подключениях и интеграциях, включая соответствующие изображения. Проектные менеджеры вносят информацию о договорных условиях, которые были согласованы между сторонами, в то время как IT-отдел добавляет лицензионные данные. По мере того как каждая роль вносит свой вклад, оглавление документа уточняется и дорабатывается.
Итоговый документ, после того как все разделы будут наполнены и проверены, должен быть приемлемого качества. Если качество документа оценивается как промежуточное, он может быть сохранен в форматах PDF или Word и храниться в соответствующем месте для дальнейшего использования. Важно отметить, что такой документ по архитектурному дизайну будет обновляться, когда появляются новые интеграции, поддержка от другого поставщика, обновления версии сервера или изменения в лицензиях.
[!NOTE] Критерий успеха для Кейса 1:
На минимальном уровне успеха, один ответственный собирает все разделы документа. Каждый участник проекта предоставляет необходимую информацию из различных источников: электронной почты, договоров или чатов. Идеально, если в документе содержится ссылка на исходный договор или техническое задание, чтобы был доступ к дополнительной информации.
[!NOTE] Кейс 2: Система аналитики
Сбор требований – сложная задача, особенно когда участвуют разные отделы. Аналитики, как основные участники, начинают с определения основных «болей» бизнеса и запросов. Далее, команда аналитиков анализирует доступные данные: какие из них у нас уже есть и каких нет. При этом важно взаимодействие с тимлидами, product owner’ами и разработчиками.После определения необходимых данных, их можно декомпозировать на задачи для спринта. Сейчас используется система Azure DevOps, но есть проблемы с сохранением контекста истории после ее выполнения. Важно понимать, какая часть данных действительно важна для пользователей и как она может принести максимальный результат.
Если для выполнения задачи отсутствуют необходимые данные, исследуется возможность их покупки или интеграции. Product owner может провести интервью с другими отделами, чтобы получить нужную информацию.
[!NOTE] Критерий успеха для Кейса 2:
На минимальном уровне успеха, product owner собирает все запросы на данные, понимает их связь с бизнес-целями и определяет их итоговое значение. Важно понимать, как данные между собой связаны, например, как продукты и точки продаж связаны с каналами продаж.
По факту, два кейса связаны друг с другом; более того, они местами взаимозависимы. Можно представить все это в виде схемы, что значительно упрощает чтение и понимание направления движения информационных потоков: кто, кому, при каких обстоятельствах что должен предоставить. Сейчас мы не берем в расчет сроки и формат предоставления данных. Вместо этого попробуем решить архитектурную задачу: как сделать так, чтобы некоторое множество людей работало над своим участком проекта.
Если бы меня спросили год назад, можно ли что-то подобное организовать, мой ответ был бы «нет». Но сейчас у меня есть иное представление о том, что и как необходимо организовать. Идея решения, которое сейчас буду расписывать, находится в плоскости создания одной общей базы для рабочих и личных проектов. Как-то в сообществе, в очередной раз, задали вопрос о скрещивании слона и носорога, и я сказал: почему бы не попробовать?
Мне это может быть и не нужно, но что если в этом есть практический смысл? Немного поразмыслив, решил предложить следующее решение с универсальной логикой. Первое условие: мы используем приложение Obsidian, которое работает на движке Electron, хранит файлы локально или на облачном хранилище и записывает информацию в markdown разметке внутри простого файла. Чтобы создать базу знаний, состоящую из заметок, Obsidian требует от пользователя определить местоположение, в котором будет храниться хранилище, и указать его как «vault» в настройках программы. После этого, в этой папке сохраняются все новые заметки и файлы, которые мы можем к ним прикрепить.
В такой системе сложным звеном при разделении контекстов является необходимость переключения между хранилищами. Но самое неудобное, на мой взгляд, это то, что заметки и идеи из рабочего контекста иногда могут потребоваться в личном и наоборот. Как быть? Перетаскивать вручную? Копировать автоматически? Оказывается, ни то, ни другое не подходит. Рабочий и личный контексты, рассматриваемые по отдельности, помогают сфокусироваться на том, что вы делаете. У меня это решается через workspace, где под каждую задачу открываются закладки и настройка вида Obsidian. Для этого, правда, нужен большой монитор. Задача понятная, но решение – не очень.
А оно, тем не менее, простое. Для реализации ничего, кроме простоты, в лучших традициях ТРИЗ, не нужно. Мы создаем два отдельных хранилища заметок: например, «Работа» и «Дом», внутри которых большей категории, например «ЗАМЕТКИ». Получаем следующую структуру:
- ЗАМЕТКИ
- Работа
- Дом
После этого создаем три разных хранилища: Первое – «Работа», второе – «Дом», а третье – метахранилище «ЗАМЕТКИ». То есть, когда нам нужно оставаться в контексте только рабочих проектов и дел, мы открываем хранилище «РАБОТА»; когда личный – открываем хранилище «ДОМ»; а когда хотим работать с двумя сразу – открываем «ЗАМЕТКИ». Все теги и структура будут уникальными для каждой сущности, но при этом соединяются вместе в мета папке. Простое и оригинальное решение, когда не создаем новые сущности. Идеальный объект Альтшуллера. Именно это решение можно применить к задаче, с которой мы начинали.
Принцип, который разделяет контексты, вполне прост. Теперь нужно понять, как это внедрить в систему, где есть множество исполнителей, задач, проектов и масса документации. Обращаемся к схеме и смотрим, кто и что у нас есть:
- Аналитик.
- Архитектор.
- Проектный менеджер.
- ИТ-менеджер (или как его еще можно называть).
- Тимлид.
- Продакт-оунер.
- Разработчик.
- Заказчик.
Смею предположить, что каждое звено имеет доступ и, возможно, желает увидеть исключительно свой участок, но только одному необходимо видеть всю картину: аналитику. Соответственно, можно попробовать организовать их работу следующим образом:
- Аналитик:
- Метапапка (все документы).
- Архитектор:
- Архитектура.
- Подключения.
- Интеграции.
- Проектный менеджер:
- Условия и договора.
- ИТ-менеджеры:
- Лицензионные данные.
Скорее всего, это далеко не полный список категорий и папок, и возможно, даже не все роли представлены. Но я расцениваю это как некоторое упражнение.
Теперь, когда у нас есть простая архитектура, можно подумать о системе. Часто можно услышать о учении некоторого Святого Лумана: Zettelkasten. Говорят, что он так делал, и что можно делать исключительно так, как завещалось. Однако технологическая база, которой располагали заметковеды прошлого, и та, которая есть сейчас, существенно отличаются.
У меня есть некоторое представление о том, как это может функционировать. Первое, что необходимо сделать – это задать теги. Как бы я не относился к ним, в них есть польза. Тегов не должно быть много, и они должны выполнять свою функцию. Единственное, что можно им доверить, это классификацию. В нашем случае это класс документа и роль.
ТЕГИ: условия, договора, лицензия, архитектура, подключения, интеграция.
Стоит отметить, что Obsidian позволяет делать вложенные теги. То есть, если к тегу «архитектура» через слеш дописать «архитектура/блупринт», то станет понятно, о каком документе идет речь. Единственное, что нужно учесть — они не должны пересекаться, например, чтобы не было «блупринта» в «условиях». Это приведет к лишнему шуму в системе.
После тегов на класс документа имеет смысл прописать тег на роль.
ТЕГИ: аналитик, архитектор, PMенеджер, POунер, ИТ-инженер, тимлид, разработчик.
Теперь, когда заложена основа из папок и тегов, нужно приступить к наполнению. Следует избегать хаотичного наполнения, иначе все обрастет пылью и превратится в кладбище интересных идей. Наполнение зависит от процесса: чем он проще, тем лучше.
Для каждой роли и категории необходимо разработать шаблон документа, который будет наполнять ответственный. У нас уже есть ответственный — это прекрасно. Таким образом, помимо документов, нам нужно создать эти сущности. Достаточно создать карточку ответственного в виде заметки, где указаны роль, имя, контактные данные и проекты, в которых он принимал участие.
Название файла: по имени человека, в двойных скобках. Можно создать один исходный файл со всеми именами и ролями — карту сотрудников компании. В каждом файле стоит разбить информацию на категории, вплоть до подробного описания.
Для каждой роли и каждой категории необходимо разработать шаблон документ, который будет наполняться ответственным лицом и с которым производится работа. У нас уже появился ответственный. И это прекрасно. Значит что помимо документов, нам нужно создать эти сущности. Достаточно карточку ответственного, в виде заметки. Где прописывается роль, имя, контактные данные, проекты в которых принимал участие.
Название файла: по имени человека, в двойных скобках. Можно сделать один исходный файл со всеми именами и ролями, некоторую карту лиц работающих в компании. Внутри каждого файла сделать категории, вплоть до описания всего и вся.
[!NOTE] РОЛЬ_ИМЯ (Файл роли)
Имя: Батарейкин Иван Иванович.
Роль: архитектор
Адрес офиса: улица контейнерная д.2
Телефон: 002, его там все знают.
Проекты: через двойные скобки проекты в которых принимал участие.
Текущие проекты: через такие же двойные скобки проекты, на которых сейчас задействован.Идеи: тут все идеи, который так или иначе выражал, в виде заметок в тех же двойных скобках.
Каждая из ролей работает в своей папке, взаимодействует со своим участком, можно посмотреть, кто чем занят. Наполнять документы вместе НЕЛЬЗЯ. У Obsidian нет функции параллельной работы с одним документом. Это, все-таки, не облако. Поэтому тут можно немного поэкспериментировать с процессами. Но, как правило, если архитектор работает над одним проектом, редко можно найти двух архитекторов, работающих над одним и тем же проектом. С ИТ и разработчиками сложнее. Хотя и у разработчиков все решаемо: у них своя среда, им нужно рассказывать и архивировать проект после завершения, а также вести регулярные записи о ходе процесса. Я бы попросил записывать исключительно сложные решения, которые они используют, или простые, на поиск которых было потрачено дополнительные ресурсы, прежде всего, интеллектуальные.
Мне кажется, стоит повторить основную логику:
- Каждая из ролей видит только свою папку.
- Метапапка доступна только аналитикам.
- Система основана на тегах.
- Каждая роль и человек в ней прописаны.
- Над файлом работает исключительно один человек.
В таком формате это может сработать. Кстати, у Маргулана Сейсембая что-то похожее. У него две платформы: одна на Notion, вторая на Obsidian. Как именно устроено – не знаю, не спрашивал, но очевидно, что это может работать. В любом случае, стоит пробовать, анализировать, что эффективно, что нет. Исправлять, дорабатывать, модифицировать и снова запускать.
Reference:
