Обсидиан. От простой структуры к сложной и обратно. Часть 2

Краткий итог первой части

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

Закончилось это всё не очень хорошо, так заполнение «ежедневной рутины» усложнилось настолько, что заполнять её уже не хотелось. Поэтому критической задачей стало упрощение (идём обратно) в местах где сложность излишняя и автоматизация в местах, где есть лишние 2-3 клика.

Если что, структура папок у меня такая:

base/
life/
	p1/
	p2/
	index
periodic/
setup/
homepage.md

Внутри папок файлы просто копятся в соответствующих папках. Всё связывается через ссылки.

Чтобы быстро создавать файлы в нужных папках через новые ссылки, включите: Настройки -> Файлы и ссылки -> Место для новых заметок по умолчанию = В той же папке, где расположен файл

• Это удобно так как при работе с базой знаний файлы копятся в папке base/, а при работе с проектами в папке соответсвующего проекта

Этап 1. Выбрасываем всё лишнее

Выбросить лишнее — это не про dataview и буковки, а про вашу внутренную систему ориентиров и ценностей.

Соответсвенно в первую очередь нужно понять что действительно важно. Эти вещи я и рекомендую использовать как фундамент для ежедневной/недельной/месячной заметок. Можно долго размышлять на эту тему, использовать разные способы «настраивания жизни»: Метод АБВГД (узнал про него в книге «Мастер Времени«), колесо баланса и тд. Тут кому как нравится.

В моём случае всё решил фокус. Из всех своих проектов (на тот момент их было 5) я выбрал два, которые имеют для меня самое большое значение. Остальные загнал в рутину. (Не в обсидиане, а в голове).

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

Это может показаться сомнительным решением, но за ним скрывается довольно простой и логичный аргумент: Важен факт выполнения задач проекта, а не процесс. Поэтому мне совсем не нужно знать сколько часов я уделил в день на на ту или иную задачу. Важно её сделать.

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

Этап 2. Распределяем рутину

Возьмём для примера три типовых рутинных занятия

• Спорт

• Разовые, повторяющиеуся дела

• Чтение и тд

Спорт

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

Например я для отслеживания зала использую приватный тг канал (сам себе сделал своеобразный категоризированный Saved Messages ещё до того, как такое ввёл тг). В нём я пишу выполненные упражнения + подходы. Если мне нужно, я всегда могу скопировать результаты в лог. Делаю я это не чаще раза в неделю.

В этой статье есть пример настройки бота, для закидывания сообщений из ТГ в обсидиан.

Чтение, просмотр видео

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

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

```dataview  
LIST 
FROM !"Periodic"
WHERE file.cday = this.file.day  
WHERE type = "book" OR "video" OR "article"
SORT file.name asc  
```

Но лично я не использую такое 🙂

Рутинные дела

Тут я пробовал два вариант (Используется плагин Tasks)

1. Писать рутинные дела в отдельном проекте. Выводить самые важные в ежедневную заметк.

   • Сами рутинные дела создаются внутри категорий в проекте «Рутина»

2. Создавать рутинные дела внутри заметок по дню и агрегировать их внутри проекта «Рутина»

Сразу скажу — остановился я на варианте 2. Пример приведу для обоих

Вариант 1
Плюсы:

• Самые горящие дела всегда не виду Минусы:

• Создавать дела неудобн.

  • Приходится переходить в проект -> категорию -> добавлять таск

• Не всегда что-то из рутины нужно выполнять сегодн.

  • А место занимают зараза

При таком подходе у меня лежало два скрипта в шаблоне Daily Note

1. Самые горящие запланированные:

```tasks
not done  
path includes Life/Рутина  
limit to 3 tasks  
sort by priority  
```

2. Выполненные за сегодня рутинные дела:

```tasks
done on {{date:YYYY-MM-DD}}  
short mode  
path includes Life/Рутина  
```

{{date:YYYY-MM-DD}} — специальный формат записи даты для плагинов Calendar Plugin и Periodic Notes Plugin. При создании заметки автоматически проставится корректная дата. Потичать можно здесь

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

Вариант 2
Плюсы:

• Удобно создавать рутинные задачи, описывая лог дн.

  • Потом удобно воспроизводить контекст создания Минусы:

• Не всегда на вид.

  • Я компенсировал это за счёт вывода 3 самых горящих на Homepage

    • Или можно почитать тут

Создаём рутинные задачи так:

- Ходил с собакой на улицу. У неё заболела лапа
	- [ ] #r Свозить собаку к врачу
- [ ] #r Заказать что-то там

Собираем так:

```tasks
not done
tags includes #r
sort by priority
```

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

На дашборде вывожу так:

```tasks
not done
tags includes #r
limit to 3 tasks
sort by priority
```

Скрипты +- похожи на Вариант 1. Изменилось только первичное расположение и агрегация

Итог: Распределили повторяющиеся либо процессные дела без потребности в ежедневных отчётов. Сделали их либо создающимися органично, либо вспомогательными.

Можно, конечно, совместить два подхода: писать заметки в днях, собирать в рутине + показывать по приориету в день. Там же выводить и выполненные. Но это уже как-нибудь сами хехе

Этап 3. Наводим порядок в ключевых проектах

К этому этапу у нас уже +- чистый планер. Лишнего ничего нет, всё средней/малой важности распределенно по рутине или является лишь подходом для решения других задач

Остаётся разобраться с основными проектами. Их также можно реализовать через связку плагинов Projects + Tasks, но я это не делал.
Есть пример тут.

Что подошло лично мне? Простые текстовые задачи

Для меня в больших проектах есть две составляющие — стратегия и тактика 🙂

• Стратегия — долгосрочное планирование

• Тактика — решение конкретных проблем в в конкретный момент

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

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

С тактическими целями же наоборот — меняются они довольно часто. Точнее каждый раз, когда поступают новые данные. Например после 3-4 разговоров с пользователями проекта какие-то фичи уже можно убирать или существенно модернизировать :). Поэтому для меня было важно оставить их простыми для изменения.

В целом алгоритм выглядит следующим образом:

1. Формируются цели внутри проекта

2. Формируются квартальные цели с конркетными метриками.

   • Число платных подписок на сервисе, LTV и тд.

3. Формируются месячные цели

4. Недельные и дневные

1 и 2 пункты — 100% относятся к стратегии. 3-й пункт — что-то около того, так как иногда всё же меняются

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

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

Скажем мы отработали месяц по такой системе. В конце мы сверяем достигнутый результат с квартальными планами и на основе остаточной работы, делённой на 2 (так как впереди два месяца), планируем новый месяц. Лично для меня такая система максимально эффективна, но требует дисциплины в анализе дней/недель/месяцев. Если писать отсебятину, то толку от неё будет 0.

Кода какого-то супер полезного предоставить не могу, так как всё довольно просто, но какие-то микрокуски постараюсь зацепить

[[2024-Q1|Квартал]] | [[2024-M03|Месяц]] | [[2024-W10|Неделя]]

`$=dv.pages('"Periodic/Daily"').where(p => p.file.name < dv.current().file.name).sort(p => p.file.name, 'desc').limit(1).file.link` (Назад)| `$=dv.pages('"Periodic/Daily"').where(p => p.file.name > dv.current().file.name).sort(p => p.file.name, 'asc').limit(1).file.link` (Вперёд)

#### Три цели на день
1. [ ] 
2. [ ] 
3. [ ]

...

В самом верху каждой дневной заметки располагается такой скрипт. В нём реализована быстрая навигация по вышеупомянутыми временным периодом, а так же активные кнопки для быстрого перемещения вперёд/назад по дням. В неделе тоже самое, только нет кнопни на текущую неделю + в скрипте навигация по другой папке dv.pages('"Periodic/Weekly"').

Для сбора быстрого (предварительного отчета по дням недели использую такой скрипт)

[[2024-Q1|Квартал]] | [[2024-M02|Месяц]]
`$=dv.pages('"Periodic/Weekly"').where(p => p.file.name < dv.current().file.name).sort(p => p.file.name, 'desc').limit(1).file.link` (Назад)| `$=dv.pages('"Periodic/Weekly"').where(p => p.file.name > dv.current().file.name).sort(p => p.file.name, 'asc').limit(1).file.link` (Вперёд)

#### Цели на неделю
1. [ ] 
2. [ ] 
3. [ ]

---

#### Результаты недели  
```dataview TABLE WITHOUT ID file.link AS "День", summary AS "Кратко день"  
WHERE summary OR mistake  
WHERE date(file.link) >= date({{date+6d:YYYY-MM-DD}}) - dur(6 day) AND date(file.link) <= date({{date+6d:YYYY-MM-DD}})  
SORT date(file.link)  
```

#### 🧠 Выводы недели  
```dataview 
TABLE WITHOUT ID file.link AS "День", infer AS "Вывод"
FROM "Periodic/Daily"  
WHERE infer OR idea  
WHERE date(file.link) >= date({{date+6d:YYYY-MM-DD}}) - dur(6 day) AND date(file.link) <= date({{date+6d:YYYY-MM-DD}})  
SORT date(file.link)  
```
###### Какие общие выводы недели?  
infer::

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

Выводы по недели - более точечные выжимки из выводов за день. Обычно из 10-15 дневных получается 3-4 цельных недельных

Ну и пример месяца:

[[2024-Q1|Квартал]]  
`$=dv.pages('"Periodic/Monthly"').where(p => p.file.name < dv.current().file.name).sort(p => p.file.name, 'desc').limit(1).file.link` (Назад)| `$=dv.pages('"Periodic/Monthly"').where(p => p.file.name > dv.current().file.name).sort(p => p.file.name, 'asc').limit(1).file.link` (Вперёд)  
  
#### Цели на месяц  

1. [ ]
2. [ ]
3. [ ]

#### Обзор месяца  
  
### Итог по целям  
```ad-summary  
title: Итоги недель  
  
- [[2024-W05#Краткое описание недели|Неделя 1]]  
- [[2024-W06#Краткое описание недели|Неделя 2]]  
- [[2024-W07#Краткое описание недели|Неделя 3]]  
- [[2024-W08#Краткое описание недели|Неделя 4]]  
  
##### Общий  
  
___  
#### Выводы месяца  
```dataview 
TABLE WITHOUT ID file.link AS "Неделя", infer AS "Вывод" FROM "Periodic/Weekly"  
WHERE infer WHERE file.name = "2024-W01" OR file.name = "2024-W02" OR file.name = "2024-W03" OR file.name = "2024-W04"  
SORT date(file.link)  
``` 

###### Выводы по итогу месяца  
infer::   

Для красивого показа ссылок на выводы по неделям я использую плагин Admotion. Рекомендую!

Dataview делаю немоного туповато, но других адевкватных способов я не нашёл. Можно как в примере недели сделать по датам, но чёта и так ок

С выводами месяца всё так же, как и с неделями. На основе 16-20 недельных выводов формирует 3-4 месчных, а их уже смотрим в квартале

Как вы можете заметить - конечный вариант системы довольно просто составлен. Нет никаких замороченных агрегаторов и тд. и тп.

Но как раз за счёт того, что он так прост - он и хорош! Нет постоянных погрязаний внутри метрик, систем, сложных запросов... Есть только задачи и результат. Всё. Текущий вариант я использую уже полтора месяца и максимально им доволен

Контринтуитивным оказался следующий вывод: чем проще система, тем дальше она пойдет. Но чтобы к этому прийти, мне понадобилось 10 месяцев... Да и тяжело на такое согласиться, когда такой конь (обсидиан) заряженный у тебя под клавиатурой. Как то так 🙂

Вместо эпилога

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

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

В прошлой статье некоторым комментаторам не зашли краткие рекомендации по настраиванию своего ежедневного планирования. Хотелось больше конкретных примеров

Я же считаю что это просто великолепная рекомендация, во многом понятная именно тем, кто уже прошёл часть такого пути. Верятность того, что взяв чей-то сетап, вы не закинете его через месяц стремится к 0 (ну может к 5%). Всё дело в том что у всех абсолютно разные предпочтения/цели/мотиваторы/смысла.

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

Поэтому самый эффективный вариант сделать свою систему продуктивности - ПРОБОВАТЬ. Дорогу осилит идущия, а обсидиан - пишущий...

Что дальше?

В комментариях к первой статье посоветовали попробовать LogSeq. Собственно я и решил попробовать 🙂 Хотя около года воротил нос от всех альтернатив обсидиан.

Думаю после недель 3-4 мне уже будет что о нём сказать и я постараюсь написать детальное сравнение его и обсидиан

Если говорить по впечатлению за 3 дня: Куда проще настроить и вести проекты, списки дел нативно. Плюс какие-то трекеры на них навесить (если они конечно нужны).
Однако внутренне я всё еще за Obsidian И НИЧЕГО КРОМЕ ОБСИДИАН. Посмотрим что будет через месяц...

P.S. Как у любого новоиспечённого автора, у меня после написания первой статьи появился тг-канал. Милости прошу. Там пишу чаще, проще и более свободно. Формат статьи всё-таки сдерживает в каких-то рамках повествования.

Источник