Простой и бесполезный bottom-up способ ведения заметок

Один из самых активных участников форума Obsidian и чата в Дискорде предложил следующий путь для организации заметок:1

  1. Написать 1 заметку
  2. Если она получилась запутанной – разделить заголовками
  3. Если в заметке много информации – разбить на отдельные заметки
  4. Когда заметок из одной темы накопится много – сгруппировать в папку

Проблема

Это не способ организации заметок – это способ начать их хоть как-то писать.

Почему это не работает в долгосрочной перспективе

Задача любой заметочной системы – при минимальных когнитивных и временных усилиях на организацию, по запросу получать максимум нужной и важной информации. 2 3 Чистый Bottom-up, который предложил юзер, этого не гарантирует: структура, выросшая снизу, отражает историю накопления, а не логику использования.

Другой симптом той же болезни bottom-up подхода – отсутствие целеполагания.4 Такой подход не привязан ни к хорошо масштабируемому методу, ни к цели.

Если человек не понимает, зачем он делает заметки, простые советы по организации не помогут. Юзер неизбежно придёт к фрустрации – но не потому что его заметки некачественные, непривлекательные или он плохо разбил их на заголовки, а потому что изначально он занимается сомнительной по смыслу деятельностью.

Что работает

Вместо чистого bottom-up-подхода можно встать на плечи гигантов и начать с того, что уже имеет в себе проработанные механики или где цель вшита в стандарт.

Абстрактная архитектура5 – нейтральная по отношению к доменным областям, объясняющая, как база устроена, а не что в ней находится. Структура существует на уровне механик и абстрактных соглашений (теги, свойства, связи, типы, статусы, роли, нумерация). Человек в такой архитектуре пишет и структурирует, используя конкретные механики.

Примеры:

  • Система Лумана6
    • Ссылки и специфические ID как основные механики
    • Это одинаково работает для философии, права, социологии и прочих гуманитарных наук
  • PARA (Тьяго Форте)
    • Проекты / Области / Ресурсы / Архив
    • Универсальный подход, не зависящий от среды реализации
    • Описывает назначение информации, а не её содержание
  • Johnny.Decimal7
    • Даёт унифицированную ID-логику упорядочивания, которая не выходит за границы возможностей файловой системы
  • Мой подход
    • Категории → мета-заметки → проблемы → иерархии

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

Доменно-специфичная8 – каждый элемент архитектуры соответствует стандартам или требованиям конкретной области. Такая архитектура в первую очередь отвечает на вопрос о чём система, а не как она устроена.

Примеры:

  • Core Design Pillars
    • Классический подход в геймдизайне
    • Это стандарт описания игры, который поймет любой геймдизайнер вне зависимости от того, как вы упакуете их в структурные элементы
  • SOAP-заметки9
    • Subjective / Objective / Assessment / Plan
    • Врач не строит свои записи о пациенте в стиле bottom-up – структуру сразу диктует профессия

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

Оба подхода долгосрочны, потому что опираются на что-то внешнее: либо на единую абстрактную логику, охватывающую любые доменные области, либо на дисциплинарные конвенции. В отличие от bottom-up, они слабо зависят от того, как стихийно накапливается контент у юзера.

Хорошая архитектура всегда якорится снаружи – в методе (например, как научный метод) или в профессии. Bottom-up якорится изнутри – в том, как случайно накапливался контент.

Структура мышления != Программа

Программа – мощный инструмент расширения и фиксации мышления.10 Но именно её мощность создаёт ловушку: чем богаче набор возможностей, тем сильнее запрограммированные аффордансы тянут юзера подчиниться архитектуре программы, а не наоборот.11

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

Неопытные пользователи сильно заземляют свою архитектуру до топорных возможностей самого приложения: Obsidian умеет делать папки – значит, нужны папки; Notion умеет делать базы данных – значит, нужны базы данных; появился плагин, который может связать внешние файлы с хранилищем – срочно нужно нажать install.

Несомненно полезно научиться стандартизировать информацию, чтобы можно было её укладывать в базу данных, но куда более продуктивным будет выйти за пределы интерфейса и спросить: что на самом деле требует мой рабочий процесс?

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

  • Позволяет ли система развивать темы нелинейно, разветвлять исследования и проекты?
  • Каждая новая заметка ведет к инкрементальному росту или становится очередной безвестной частью моей огромной кучи мусора?
  • Моя деятельность нуждается в жестком следовании алгоритмам или она построена на инсайтах и серендипности?
  • От какого процесса моя деятельность зависит сильнее: от присвоения информации (насмотренности) или от её поиска и изъятия в нужный момент (использования)?

Ответы на эти вопросы определят архитектуру и уровень её вмешательства в повседневный рабочий процесс.

Контринтуитивно, но чем более хаотична деятельность12 – тем нужнее жёсткая точка притяжения в виде доменно-специфичной архитектуры (стандарты, группирование, категоризация). Чем жёстче уже сложилась иерархия – тем нужнее её разомкнуть и перейти к абстрактной (сетевидность, мета-структуры, абстрактные соглашения).13

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

Footnotes

  1. Simple approach to organizing notes ↩

  2. Rosch, E. (1978). Principles of categorization, публикация в E. Rosch & B. B. Lloyd (Eds.), Cognition and categorization (p. 27–48). Hillsdale, NJ: Lawrence Erlbaum Associates. | Важно упомянуть, что Rosch изучала когнитивную категоризацию (как мозг естественным образом формирует структуры и прототипы), а не проектирование информационных систем. Я по сути дерзнул сделать перенос этого знания. ↩

  3. The Strategy of Note Taking: Folders, Tags, Links, and Redundancy ↩

  4. Jones, W. (2007). Keeping Found Things Found: The Study and Practice of Personal Information Management. Morgan Kaufmann. | В этой работе William Jones хорошо показал, что если база знаний (в оригинале “личная система управления информацией”) не будет согласована с собственной деятельностью и целями, то всякая база (метод) будет деградировать. Из этого можно рискнуть сделать обратный вывод, что система, которая не находится в узде какого-то метода или фреймворка, на длинных дистанциях будет постоянно рассинхронизироваться с личными целями. 💎 Метод служит целям; цели питают метод. ↩

  5. Точным академическим примером такого подхода является фасетная архитектура классификации. ↩

  6. Niklas Luhmann-Archiv. Именно так выглядит система Лумана, а не так как её описывают в популярных статьях. Важно отметить, что у Лумана была гибридная система. Это значит, что если вы, будучи новичком, начнёте строить аналогичную сеть, то без внутренней карты глубоко сложившихся интересов (доменов) такая сеть на длинных дистанциях скорее всего будет бесплодной (как если бы у яблони были только ветви без ствола). ↩

  7. A system to organise your life. Несмотря на то, что я плохо переношу папочный подход в контексте PKM, все же не буду отрицать, что это лучшая архитектура для папочных адептов. ↩

  8. Такая архитектура обычно определяется через специфический тезаурус или онтологию, диктуемые доменной областью. ↩

  9. Weed, L.L. (1968). "Medical records that guide and teach." NEJM, 278(11), 593–600. | Weed, L.L. (1969). Medical Records, Medical Education, and Patient Care. Press of Case Western Reserve University. | Два связанных источника. Первый про наиболее общий подход, второй, где конкретно появился метод SOAP. ↩

  10. Clark, A. & Chalmers, D. (1998). "The Extended Mind." Analysis, 58(1), 7–19. ↩

  11. Norman, D.A. (2013). The Design of Everyday Things. Basic Books. | С одной стороны, аффордансы полезны, ведь они подсказывают, как пользоваться вещами, но в контексте программ они способны увести новичка от его изначальных желаний в другую возможно абсолютно непродуктивную стезю (в изощренную прокрастинацию). ↩

  12. Важно отметить, что под хаотичностью я имею в виду деятельность с высокой неопределённостью, где паттерны эмерджентны. Если деятельность в истинном смысле хаотична, то тут стоит начать именно с устранения этого хаоса (выбрать точный вектор развития, начать действовать). ↩

  13. Для меня был удивительный инсайт, что PKM-сообщество сделало практическим образом открытие, что PARA + Zettelkasten – это эффективная структура. Эффективная потому что, если бы эти два подхода использовались раздельно, то это противоречило бы анализу O'Reilly & Tushman (2013), о том, что эффективны те формы организации, которые имеют структурную амбидекстрию – жёсткая структура + гибкость. Это ещё к вопросу о том, стоит ли делать разные хранилища – нет, не стоит. ↩