Операционная система видеоблогера

Вера Пятибратова

Операционная система видеоблогера

Предисловие

«Совершенство достигается не

тогда, когда нечего добавить, а

тогда, когда нечего убрать.»

Антуан де Сент-Экзюпери

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

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

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

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

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

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

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

Важно понимать, что эта книга не является руководством по Obsidian. Мы не будем просто изучать возможности программы или знакомиться с ее функциями. Наша цель гораздо шире - спроектировать и построить собственную операционную систему видеоблогера, которая поможет организовать весь процесс создания контента от появления идеи до анализа результатов после публикации.

Если вы никогда раньше не работали с Obsidian, это не станет препятствием. Мы начнем с самых первых шагов: разберем, где скачать программу, как установить ее на компьютер и какие первоначальные настройки стоит выполнить. Затем, постепенно усложняя систему, будем создавать полноценную рабочую среду, объясняя не только последовательность действий, но и причины каждого принятого решения.

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

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

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

Главная цель этой книги - показать, как спроектировать операционную систему автора, в которой контент проходит весь путь от идеи до публикации благодаря продуманной архитектуре, связям между объектами и автоматизации процессов.

Часть I. Проектирование операционной системы

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

Глава 1. С чего начинается любая надежная система

Цель главы

Большинство книг, посвященных Obsidian, начинаются одинаково. Автор предлагает скачать программу, создать первое хранилище, установить несколько популярных плагинов и приступить к работе. Такой подход кажется логичным, однако именно он чаще всего становится причиной того, что через несколько месяцев тщательно выстроенная система перестает приносить пользу.

В этой главе мы не будем открывать Obsidian. Возможно, это покажется странным. Но прежде чем выбирать инструмент, необходимо понять, что именно мы собираемся построить.

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

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

С чего начинается хаос?

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

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

Именно с этого момента начинается история большинства систем управления контентом.

---

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

Со временем ситуация постепенно меняется. Контента становится больше, одновременно появляются несколько материалов, увеличивается количество площадок, а вместе с ними - описания, обложки, дополнительные публикации, статьи, короткие ролики и другие сопутствующие материалы. Объем информации растет почти незаметно, пока однажды не становится слишком большим, чтобы удерживать его в памяти.

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

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

Чем больше становится инструментов, тем больше времени начинает уходить на поддержание самой системы.

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

Одна и та же информация начинает существовать сразу в нескольких местах.

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

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

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

Информация или объект?

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

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

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

Идея. Исследование. Сценарий. Обложка. Материалы. Публикация. Аналитика.

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

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

---------------------------------------------------------------------------------------------------------------------------

Правило операционной системы:

Любая информация должна существовать только в одном месте.

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

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

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

---------------------------------------------------------------------------------------------------------------------------Почему мы не начинаем с Obsidian

На этом этапе вполне естественно задать вопрос: почему книга посвящена Obsidian, а программа до сих пор даже не открыта? Ответ очень прост.

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

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

Именно поэтому первые главы книги посвящены проектированию системы. Когда фундамент будет готов, настройка Obsidian станет не набором случайных действий, а логичным продолжением уже принятой архитектуры.

Практика

Не спешите что-либо менять в своей текущей системе. Пока наша задача состоит не в том, чтобы построить новую, а в том, чтобы увидеть существующую такой, какая она есть.

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

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

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

Типичные ошибки

Самая распространенная ошибка на этом этапе - начать искать «идеальную программу», надеясь, что именно она решит все проблемы организации работы. На практике такого инструмента не существует. Даже самая функциональная программа не сможет навести порядок, если сама система построена неправильно.

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

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

Проверьте себя

Прежде чем переходить к следующей главе, попробуйте ответить на несколько вопросов.

Понимаете ли вы, почему большое количество инструментов само по себе не является проблемой? Можете ли вы объяснить, почему дублирование информации постепенно разрушает любую систему? Удалось ли вам увидеть, что идея, сценарий, публикация и аналитика относятся не к разным документам, а к одному объекту?

Если хотя бы на один из этих вопросов вы затрудняетесь ответить, не торопитесь двигаться дальше. Именно эти мысли станут основой всей книги.

Итоги главы

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

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

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

Что дальше

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

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

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

Глава 2. Архитектура начинается не с папок

Цель главы

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

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

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

Почему большинство мыслит как файловый менеджер?

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

И почти каждый начинает одинаково. Сначала появляется папка «Идеи». Затем создаются «Сценарии», «Видео», «Статьи», «Обложки», «Публикации», «Шаблоны», «Архив». Через несколько минут кажется, что фундамент уже готов. Осталось лишь постепенно наполнить его информацией. На первый взгляд такое решение выглядит совершенно логичным. Мы привыкли хранить документы именно так. На компьютере есть папки с фотографиями, музыкой, рабочими файлами и документами. Кажется естественным перенести эту же логику в систему управления контентом.

Проблема заключается в том, что контент - это не набор файлов.

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

Возникает простой вопрос: Где должна храниться вся эта информация?

Если сценарий лежит в папке «Сценарии», а идея - в папке «Идеи», то где разместить исследование? В какой папке должна находиться аналитика? Куда положить текст публикации для разных площадок? Где хранить список задач, связанных с этим материалом?Очень скоро оказывается, что один и тот же проект одновременно относится сразу к нескольким папкам. Именно в этот момент архитектура начинает давать первые трещины.

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

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

Каждая отдельная папка кажется логичной. Однако вместе они начинают работать против автора. Возникает парадоксальная ситуация. Информация становится организованнее, а найти ее оказывается сложнее.

---------------------------------------------------------------------------------------------------------------------------«Порядок без системы - всего лишь хорошо организованный хаос.»---------------------------------------------------------------------------------------------------------------------------

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

Почему? Потому что папки никогда не были причиной беспорядка. Они лишь делают заметнее ошибку, которая была допущена значительно раньше.

Что на самом деле является объектом?

Чтобы понять, где возникает эта ошибка, попробуем посмотреть на привычный процесс создания материала с другой стороны.

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

Если внимательно посмотреть на весь этот процесс, можно заметить удивительную вещь. Хотя на протяжении работы создается множество разных документов, все они относятся к одному и тому же материалу. Мы просто привыкли воспринимать их как самостоятельные сущности. Идея кажется отдельной заметкой. Сценарий - отдельным документом. Чек-лист - отдельным списком задач. Описание - еще одним файлом.

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

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

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

Наша будущая система должна работать точно так же. Для нее не существует отдельных сценариев, отдельных описаний или отдельных чек-листов. Существует контент, вокруг которого постепенно собирается вся необходимая информация. Именно поэтому мы будем строить систему иначе. Мы перестанем думать категориями файлов и начнем мыслить категориями объектов. Это решение может показаться небольшим изменением терминологии. На самом деле именно с него начинается переход от набора заметок к настоящей операционной системе.

Учимся мыслить объектами

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