Статья о том, как внедрить и как продуктивно использовать систему статусов в персональных проектах.
Гайд предназначен для пользователей Obsidian. Однако, если вы к таковым не причисляетесь, то можете ознакомиться только с описанием системы статусов. Возможно, что вам сам подход понравится и у вас впоследствии получится адаптировать его в своих инструментах.
Структура статьи (оглавление)
Введение
Алгоритм Зонке Аренса
Детализация этапов
Система статусов
Конкретизация этапов работы
Статусы в контексте проекта
Single-project
Небольшая вспомогательная структура
Быстрый способ вставить статус
Longform-project
Supercharged links и иконки в плагине Longform
Как возвращаться к статусам
Нелинейность как возможность
Дополнительный контекст для задач
Основная цель
Мелкие дополнения
Заключение
Введение
наверх
Изначально я хотел назвать эту статью "Для любителей Obsidian, проектов и emoji". Однако, не смотря на то, что это название прям максимально точно и ёмко описывает содержание всей статьи, всё же я решил выбрать более спокойное и сбалансированное название.
Вероятно вы уже догадались, что речь будет вестись о проектах и статусах, которые эти проекты будут помогать двигать вперёд. Однако прежде чем мы перейдем к конкретике, я вас сначала помучаю алгоритмом Зонке Аренса, а точнее своей критикой этого алгоритма. Потом я ещё вас помучаю и предложу в качестве альтернативы свой длиннющий алгоритм. И только после этого начнется развитие основной идеи этой статьи.
Стоит подчеркнуть, что статья является комплексным решением. Это значит, что почти все части статьи так или иначе взаимосвязаны друг с другом. В связи с этим я предлагаю вам такой план работы:
Вы поверхностно читаете всю статью целиком, чтобы уловить все основные идеи
Далее вы открываете оглавление статьи и на каждом пункте спрашиваете себя "Мне это нужно?"
Если вам это нужно, то открываете нужную главу, вчитываетесь в неё и внедряете в свою систему что-то новое
Если вы на этапе поверхностного чтения не понимаете зачем вам нужны те или иные предложенные в статье вещи или идеи, то простой забей на них. Возможно, мы просто с вами решаем разные проблемы
Важно отметить, что система статусов, которую я предложу, подойдет именно для персональной, творческой работы. Увы, но для коллаборации или для проектов с высокой ответственностью, предложенная система скорее всего не принесёт пользы – есть риск, что она даже навредит.
Также ещё добавлю, что показать свои боевые проекты я, увы, не могу. Поэтому примеры будут такие, которые вы так или иначе уже могли видеть. В общем не обессудьте за это.
Теперь перейдем к основному тексту.
Алгоритм Зонке Аренса
наверх
У Зонке Аренса есть алгоритм, который по его мнению может помочь в написании каких-то сложных текстов. Приведу алгоритм в оригинальном виде (Как делать полезные заметки. 2.1 Пишем шаг за шагом. Стр. 35):
Делайте повседневные заметки
Делайте записи о литературе
Создавайте постоянные заметки
Теперь добавьте новые постоянные заметки в свой ящик
Разрабатывайте свои темы и исследовательские проекты снизу вверх внутри системы
Через некоторое время у вас будет достаточно много идей, чтобы решить, на какую тему писать
Превратите свои заметки в черновик
Отредактируйте и вычитайте рукопись
Алгоритм хоть и отражает в какой-то степени действительность, однако в моём случае он всё равно не работает.
Основная проблема, на мой взгляд, заключается в том, что этот алгоритм слабо отражает нелинейность процесса написания, а также недостаточно точно объясняет, что нужно делать на каждом этапе.
Хотя чего это я тут лукавлю. Мне этот алгоритм в принципе не очень нравится. И я даже попытаюсь кратко объяснить почему.
Не открывать впечатлительным личностям
"Повседневные заметки" – это наивная идея, что в потоке быта можно бессистемно наловить множество хороших идей, из которых потом якобы получится развить что-то стоящее. Если эту мысль развернуть в контексте программирования, то есть у меня стойкое, кхм, ощущение, что работающий код всё же появляется в процессе написания этого кода, а не в процессе запечатления и накопления якобы ценных, случайных всплесков размышлений о том, какой код является работающим. Возможно, я очень превратно воспринял идею "fleeting notes", но в любом случае, как оказалось, я не большой фанат уж совсем бессистемных заметок.
Записи о литературе, конвертация их в постоянные заметки и добавление в "ящик" – это шаги, которые в рамках цифровых систем делаются как одно связанное действие. Причём такое, которое можно сделать в один присест. Если же вы пользователь аналоговых систем с реальным ящиком для заметок или вам в действительности нужно делать эти шаги как раздельные, то вы просто извращенец.
Мысль о разработке проектов снизу-вверх мне тоже не очень нравится. Ибо она подразумевает, что я как-будто бы всегда начинаю с нуля. Я как будто бы не знаю как могут развиваться проекты, я как будто бы не могу накидать заранее предварительную архитектуру своего исследования, я как будто бы не могу смоделировать логику развития своего проекта, я как будто бы не могу сделать парочку другую мысленных экспериментов, чтобы определиться с тем какие примерно шаги в действительности для меня будут полезными и эффективными. В общем по мнению Зонке Аренса я как будто бы изначально "немощный" и мне нужно в процессе "подкачаться". Если что я в курсе, что в книге есть глава про то, что никто никогда не начинает с нуля, Однако, увы, но она не раскрывает мысль, что я могу изначально иметь более-менее ясное видение того, к чему хочу прийти.
Мысль Зонке Аренса о том, что у меня через некоторое время будет достаточно много идей, чтобы решить, на какую тему писать тоже весьма кривая. Эта мысль предполагает, что я будто бы хожу, брожу и делаю заметки по тем или иным источникам, а потом в какой-то неожиданный момент на меня снисходит инсайт и я нахожу себе проблему, которую хочу решить. Также стоит отметить, что эта мысль будто бы исключает ситуации, когда я в рамках базы знаний делаю какое-то последовательное исследование, а потом на основе этого исследования делаю проект или исключает ситуации, когда я делаю проект, а потом под проект делаю исследования. В логике Зонке Аренса я сначала агрегирую заметки, а потом конвертирую их в проект (в конечный текст). Причём сам процесс агрегации ничем не ограничен и толком ничем не обоснован (это даже навевает мысль, что Зонке предлагает нам заняться коллекционированием и надеяться, что в какой-то момент нам повезёт и мы найдем то, что нас сильно зацепит). Я не хочу сказать, что Зонке не прав и в действительности такого не происходит. Просто сама мысль у него получилась кривая – т.е. я её не отрицаю, ибо у меня у самого так или иначе фоном постоянно происходит псевдослучайный процесс агрегации заметок, из которого потом появляется что-то связное и интересное.
С шагами про черновик, вычитку и редактуру всё так. Тут не придерёшься, хех.
Если что это не нападка на Зонке Аренса. Так-то я настоятельно рекомендую прочитать всем заметкоделам его книгу. Ибо сам-то я её внимательно прочёл и сделал по ней довольно большое количество полезных заметок.
В качестве промежуточного решения проблемы алгоритма Зонке Аренса, я решил написать свой, несколько более расширенный алгоритм.
Детализация этапов
наверх
Итак, начнём-с.
Написание небольшого количества первых заметок, которые нужны для формирования первоначального видения той или иной проблемы (мой алгоритм начинается с проблемы и формирования начального видения, а не с повседневных заметок)
Это можно производить в рамках предварительного исследования
Можно собрать в одном месте и поверхностно обработать схожие по теме источники из всевозможных "read later"
Можно пройтись по уже имеющимся источникам/заметкам и попытаться дать оценку тому, что есть ли вообще релевантный материал в системе. Если есть, то можно создать мета-заметку и накидать туда соответствующих ссылок
Постепенное формирование списка источников и заметок, которые в потенциале способны стать чем-то связанным и последовательным. И соответственно непосредственная обработка этих источников и заметок
На этом этапе можно сформировать полноценную мета-заметку или сразу создать проект
В рамках мета-заметки или проекта нужно последовательно выкачивать из найденных источников заметки
Логика для внешних источников
Если источник мелкий и при этом оказался не шибко значимым, то можно просто ограничиться комментарием к нему (сделать отступ и написать коммент под внешней ссылкой)
Если источник мелкий, но в нём есть полезные идеи, то создается обычная заметка, записывается в неё всё, что нужно, а сам источник указывается в качестве сноски
Если источник большой и его трудно разом обработать и при этом тут же обобщить в одну заметку, то создается log-заметка, в которой впоследствии выделяются и атомизируются наиболее значимые идеи
Если источник огромный и в нём нужно довольно много всего изучить, то создается заметка-источник, внутри которой происходит разбиение на ряд log-заметок
Логика для внутренних источников
Перейти на следующий этап, хех)
Создание из полученных заметок связанных кластеров (например, с помощью иерархического списка, mindmap или canvas) и последующее написание по ним небольших кусочков текста
В соответствии с поставленным задачами, гипотезами или проблемами ищутся наиболее подходящие заметки, которые сразу объединяются в кластеры
Далее на основе этих кластеров пишутся небольшие, необязательно напрямую связанные между собой, тексты
Формирование первого черновика – первая попытка написать связный текст
Написанные кусочки текста в нужных местах склеиваются или наоборот разбиваются на логические замкнутые блоки (например, с помощью заголовков), благодаря чему формируется 1-ый драфт
Если конечный текст предполагается очень большой, то возможно это будет просто 1-ый драфт какой-то определённой части
Проработка структуры / углубление в определённые части или главы текста (детализирование) / формирование дальнейшего плана действий при необходимости
На этом этапе мы по сути делаем основную работу – пишем плюс-минус конечный текст
Попеременно работаем то над текстом, то над его структурой. Попеременно значит раздельно, хех
Из не самого очевидного. Пытаемся каждый логически связанный блок текста (например, связанный на уровне заголовка) сделать достаточно автономным, чтобы при необходимости этот кусок можно было перенести в другое место. Этот пункт нужен для того, чтобы сохранялась гибкость (об этом будет немного дальше)
В процессе формализуем те или иные проблемы в виде задач и последовательно решаем их
Вычитка своей работы и проведение критического обзора
На этом этапе мы пытаемся оценить связность аргументов, а также логичность структуры отдельных частей или всего проекта
Попеременно включаем, то писателя, чтобы отполировать те или иные формулировки или структуры, то критика, чтобы найти те или иные несостыковки, неточности и прочие проблемы
За счёт неоднократной вычитки текста, пытаемся досвязать, доразвить, докомбинировать различные части нашего проекта
По-серьёзному задумываемся о том, что мы выбрали плодотворное направление, которое нас действительно волнует или, что мы действует уже из-за инерции, довольно жёсткой структуры или внешних нам неугодных требований
Если нам нравится то, что мы делаем и мы видим в этом потенциал, то переходим на следующий этап
Если мы чувствуем, что глобально движемся не туда куда хотим (нас раздирают сомнения или мы вообще не видим смысла в том, что делаем), то можно вернуться к самому первому этапу, чтобы поработать над какими-то другими, новыми проблемами. Или можно просто поработать над другими проектами. В общем делаем передышку, дабы немного охладеть к проекту и дабы подумать о том "нужен ли он нам или есть занятия повеселее и поинтереснее"
Не стоит забывать, что нам никто не запрещает забросить неугодные нам части проекта или создать новый проект и перенести в него только то, что у нас лучше всего получилось, дабы развивать только эти части
Также не стоит забывать, что творчество в большинстве своём итеративный процесс – мы сначала довольно упорно пытаемся что-то сделать, потом анализируем результаты и потом снова пытаемся что-то сделать
Мы старались сделать логически замкнутые блоки информации автономными для того, чтобы сохранить чувство контроля. Само же чувство контроля проистекает из нашей возможности сменить приоритеты и/или выбрать другой путь развития. Если мы не можем распараллелить наш проект или создать новый на основе кусков старого, то значит мы находимся в жёсткой системе, а это сулит тем, что рано или поздно мы можем потерять мотивацию
Модификация структуры и проработка с помощью драфтов
Переставляем части нашего проекта, если это необходимо
Драфтим те куски, которые плохо вписываются в общую канву или стиль
Дописываем все промежуточные, связывающие и вводные части, если это необходимости
Финализация, приведение проекта к конечному виду
Работа с редакторами или рецензентами, если они есть. Допиливание через драфты, если это нужно
Редактирование и исправление мелких ошибок
Формирование служебных структур
Доработка результатов под те или иные формальные требования
Создание конечного проекта (файла)
Публикация или просто донесение результатов своей работы до конечного потребителя
Алгоритм хоть и выглядит как обобщённый, однако он написан по мотивам одного, не самого простого моего проекта.
Наверное, вы сейчас подумали, что как-то уж чересчур детализировано получилось. На столько детализировано, что из-за большого количества деталей всё стало каким-то мутным. Однако не переживайте. Я написал этот алгоритм ни сколько для того, чтобы сделать его практичной альтернативой алгоритму Зонке Аренса, сколько для того, чтобы проиллюстрировать на сколько всё может быть сложнее и неоднороднее в действительности.
Практичности же мы будем достигать с помощью системы статусов. К ней, без лишних слов, и перейдем.
Система статусов
наверх
Система статусов выглядит вот так:
структура статусов
На интуитивном уровне вроде ничего сложного и удивительного, правда? Было бы даже странно, если система для проектов состояла из сюрпризов и неожиданностей. С другой стороны, не смотря на интуитивную понятность, именно эту систему я буду обсасывать с разных сторон на протяжении всей статьи.
структура статусов
- ⬛ abandoned
- Preparation Интересные статьи
Интересные статьи
