Возвращаюсь к обещанию: вот конкретный кусок системы
В первой статье на этом сайте я обещал рассказывать об устройстве личной системы управления знаниями по частям, без обобщённых слов про «второй мозг» и «потоки информации». Начну с того, с чем я сталкиваюсь каждый день, с хранения и обработки решений по проектам. Не про задачи, не про документы, не про переписку, а именно про решения: потому что это самое ценное, что производит проектная работа, и именно они теряются быстрее всего.
Картина, которая многим наверняка знакома: прошло полгода с начала проекта, кто-то задаёт вопрос «а что мы решили по бюджету на третий квартал и почему?». И начинается археология: почта, мессенджер, папки на диске, протоколы в корпоративной системе, которые нужно сначала найти, потом открыть, потом понять, тот ли это файл. Час работы — чтобы восстановить пятиминутное решение.
Я устал от этой археологии. И выстроил схему, которая сводит её к одному запросу.
Где решения теряются и почему это не проблема инструмента
Решения редко принимаются внутри проекта в том смысле, в котором проект существует в системе управления. Они принимаются вокруг него: на управляющем комитете, на рабочей встрече со спонсором, в переписке, где кто-то написал «ок, делаем так». Протокол подписали, разослали по участникам — и он растворился. У каждого участника своя копия файла, в своей папке, с немного разными именами.
Через полгода проект живёт, люди сменились, контекст размылся. Вопрос «что мы решали и почему» требует не поиска по ключевому слову, а восстановления цепочки: когда был комитет, кто был на встрече, что стояло на повестке, что в итоге зафиксировали.
Проблема не в том, что решения хранятся в плохом инструменте. Проблема в том, что они хранятся отдельно от проекта. Протокол комитета живёт сам по себе, карточка проекта живёт сама по себе, связи между ними нет. Когда ты открываешь проект — ты не видишь его историю решений. Когда ты ищешь решение — ты не знаешь, с каким проектом его соотносить.
Это структурная проблема, и она не решается переездом в другой инструмент. Она решается архитектурой связей.
Три элемента, которые держат систему вместе
Моя схема держится на трёх типах заметок. Они простые по структуре — сила в том, как они связаны между собой.
Карточка-хаб — это якорь проекта в базе знаний. Почти пустая заметка: тип проекта, короткий алиас для удобной ссылки (внутренний шифр и короткое название), два раздела («основная информация» и «заметки»). Никакой дублированной информации из корпоративной системы, никаких скопированных описаний. Это не документ — это точка сборки. Всё, что связано с проектом, будет ссылаться на неё.
Заметка-протокол — рабочая лошадка. У неё три структурных поля в шапке:
project— к какому проекту относится (ссылка на карточку-хаб);request— с каким запросом пришли на комитет или встречу;decision— что в итоге решили.
Ниже — свободный текст: ход обсуждения, аргументы, кто был против и почему. Поля держат структуру, свободный текст держит контекст.
Оговорка, которую стоит сделать сразу: я физически не могу присутствовать на всех встречах по проектам портфеля, одних только управляющих комитетов за год проходят сотни. Но через моё согласование проходят все важные протоколы, и именно поэтому схема с тремя полями (project / request / decision) позволяет мне фиксировать ключевые решения по всему портфелю, даже если на самой встрече меня не было. Три якоря — это способ удерживать контроль над портфелем при ограниченном личном присутствии.
Заметка-встреча устроена похожим образом: то же поле project, плюс повестка, список участников, ход обсуждения, чек-лист задач по итогам. Встреча привязана к проекту так же, как протокол.
Три типа — и больше ничего специального не нужно.
Главный принцип: связывать, а не дублировать
Когда заметки ведутся месяцами, накапливается их много. Сотни протоколов, сотни заметок по встречам. Каждая несёт поле project с ссылкой на нужную карточку-хаб.
Сама карточка остаётся почти пустой. Но в любой системе с поддержкой обратных ссылок — а в Obsidian она есть по умолчанию — панель обратных ссылок карточки показывает всё, что на неё когда-либо ссылалось. Все протоколы, все заметки по встречам, все материалы, где упоминался этот проект.
Это ключевой сдвиг в логике. Не «где мне хранить информацию о проекте», а «как сделать так, чтобы информация о проекте собиралась сама». Ответ: создай якорь и требуй, чтобы всё связанное ссылалось на него. Тогда якорь становится живым агрегатором.
История решений по проекту в этой схеме — один запрос. Таблица по всем заметкам-протоколам, отфильтрованная по полю project = текущая карточка, с колонками «запрос» и «решение». Открываешь проект — видишь, что на каком комитете решали, в хронологическом порядке, с доступом к полному тексту каждого протокола по клику.
Это не магия. Это просто структура, которая работает на тебя, а не против тебя.
Почему не корпоративная система, а личная база
Очевидный вопрос: зачем всё это, если есть корпоративная система управления проектами?
Ответ в четырёх пунктах.
Первый: корпоративная система управляет проектами организации, а не твоими знаниями о них. Это разные задачи. В системе есть статус проекта, план-факт по срокам и бюджету. Нет — контекста твоих решений, хода твоих обсуждений, аргументов, которые звучали на комитете.
Второй: личная база работает офлайн, не требует лицензий и не зависит от того, где ты работаешь.
Третий: личная схема масштабируется под твой стиль мышления, а не под чужие требования к форме протокола.
Четвёртый: мгновенный доступ в нужный момент. На работе у меня всегда открыт Obsidian, у него очень быстрая локальная индексация. Я могу за пару секунд найти карточку проекта по шифру, провалиться в неё и увидеть всю хронологию решений — какие вопросы выносились, что решили на управляющем комитете, как менялась позиция. Это критично на встречах с руководством: вопрос задают здесь и сейчас, и ответ «я подниму протокол и вернусь» не работает. Корпоративные системы с веб-интерфейсом и тяжёлым поиском такой скорости не дают. Личная база, лежащая локально и заточенная под мой способ навигации, — даёт.
Честная цена этого выбора — дисциплина. Заполнять два-три поля при создании каждой заметки. Пропустил поле project — заметка выпала из всех запросов, связь разорвана, её как будто не существует. PPM-системы дают структуру принудительно: система не даст закрыть протокол без заполнения нужных полей. В личной базе знаний за структуру отвечаешь только ты.
Это честное ограничение, и его стоит называть прямо: если дисциплина ненадёжна, лучше корпоративная система с обязательными полями.
Как я оптимизирую рутину: шаблоны и кнопки на дашборде
Для самых частых документов, которые проходят через меня — протокол управляющего комитета (УК), протокол инвестиционного подкомитета (ИПК), прочие типовые документы — и для рабочих встреч у меня заведены шаблоны заметок. Создание заметки по шаблону вызывается одной кнопкой прямо с дашборда, заметка создается сразу в нужной папке.
Кнопки реализованы через плагин MetaBind. Сам дашборд — это стартовая страница моего Obsidian, с которой я перехожу в нужные разделы базы знаний.
Пример сценария: нажимаю кнопку «Новый УК» — автоматически создаётся заметка с названием по шаблону (включая текущую дату), с заранее заданной структурой разделов и нужными полями метаданных. Дальше мне остаётся только вписать шифр проекта в специальное поле, вставить текст протокола в соответствующий раздел и сохранить заметку. Реестр всех УК при этом собирается автоматически в отдельной сводной заметке через плагин Dataview — я в любой момент вижу полный список и могу отфильтровать по проекту, дате или решению.
Именно эта связка - шаблон + кнопка MetaBind + сводка Dataview - превращает дисциплину ведения базы из «надо заставить себя» в «нажал кнопку - и всё уже почти готово».
Переносимый принцип: решение — это объект с полями
Obsidian — это просто конкретная реализация, которая идеально подошла под мой запрос. Принцип, который здесь работает, переносится в любую базу знаний, которая умеет выстраивать связи между заметками, работать в заметках со структурированными полями и делать запросы по ним.
Принцип такой: решение — это объект. У него есть поля: к какому проекту относится, с каким запросом пришли, что решили. Не просто текст протокола в папке, а объект с атрибутами, по которым можно фильтровать, группировать и строить сводки.
Следствие: не дублируй информацию о проекте в каждую заметку — создавай связь. Карточка-хаб существует в единственном экземпляре. Всё остальное ссылается на неё. Если ты напишешь название проекта текстом в сотне заметок — при переименовании проекта у тебя сто мест для исправления. Если ты создашь ссылку — у тебя одно.
Если брать из этой статьи одну идею, то вот она: решения по проекту не должны жить в папке. Они должны жить как объекты, привязанные к проекту, и быть доступны за один запрос. Всё остальное — детали реализации.