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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
  • Часть 1

    • Для тех кто не хочет читать первую часть

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

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

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

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

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

  • Что дальше?


И первую и вторую части я пишу внутри Обсидиан. В этом мне очень хорошо помогают следующие плагины

  • Focus Mode - Просто добавляет в левое меню кнопку для закрытия всех елементов UI. Остаётся голая заметка.

  • Danger Zone Writing - Довольно забавный плагин, когда нужно заставить себя писать

    • Если за заданное время вы перестаните писать - удалит всё написаное

    • Использую его редко, но чтобы перескочить какую-то иннерцию "думания", вполне подходит

  • Linter - Помогает убрать стилистические неточности

  • Table of Contents - Плагин для генерации содержания

    • Но на Хабре оно не заработало. Пришлось настраивать вручную


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

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

Закончилось это всё не очень хорошо, так заполнение "ежедневной рутины" усложнилось настолько, что заполнять её уже не хотелось. Поэтому критической задачей стало упрощение (идём обратно) в местах где сложность излишняя и автоматизация в местах, где есть лишние 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  
```
  1. Выполненные за сегодня рутинные дела:

```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)  
```

#### 						
Источник: https://habr.com/ru/articles/798309/


Интересные статьи

Интересные статьи

Это третья часть цикла из 9-ти статей, посвящённых сравнительному анализу архитектурных стилей. Данная статья посвящена стилю архитектурному стилю «модульный монолит». 1/9 базовая статья с подробным о...
В этой статье я покажу, как организовать простейший автодеплой на сервере. Для автодеплоя через Bitbucket Webhooks и PHP не нужно использовать какие-то сложные решения.Для начала можно подумать, что g...
В прошлый раз мы рассмотрели, что такое синхронное программирование, и с какими проблемами с ним сталкивается разработчик. На примере простого сервера с блокирующими сокетами мы увидели, что в синхрон...
Содержание Часть 1 — Задача двух тел Часть 2 — Полу-решение задачи двух тел Часть 3 — Ужепочти-решение задачи двух тел Второй закон Кеплера Всем привет! В прошлый раз мы остановилис...
Как и обещали, продолжаем рассказывать про освоение процессоров Эльбрус. Данная статья является технической. Информация, приведенная в статье, не является официальной документацией, ведь получена...