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

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

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

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

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

Авторское наблюдение

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

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

Это наблюдение оказалось для меня очень важным. Оно изменило не только структуру заметок, но и сам способ мышления. С этого момента стало понятно: система должна не разрывать контент на куски, а собирать его в единое целое.

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

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

Система строится вокруг объектов, а не вокруг папок.

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

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

---------------------------------------------------------------------------------------------------------------------------Почему именно так будет устроен Obsidian?

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

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

Практика

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

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

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

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

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

После прочтения этой части главы попробуйте ответить на несколько вопросов.

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

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

Итоги главы

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

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

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

Что дальше

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

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

Глава 3. Невидимый фундамент: метаданные

Цель главы

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

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

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

Почему объекту нужен паспорт?

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

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

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

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

Что такое метаданные на практике?

Само слово «метаданные» часто звучит слишком сложно. На деле все гораздо проще. Это просто данные о данных. Если говорить совсем по-человечески, метаданные отвечают на вопрос: что именно перед нами и как с этим работать?

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

Это очень важный сдвиг в мышлении.

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

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

Метаданные выполняют роль паспорта объекта. Они позволяют системе понять, что именно перед ней и как с этим работать.

Почему метаданные важнее, чем кажется?

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

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

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

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

Авторское наблюдение

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

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

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

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

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

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

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

Метаданные должны отвечать на практические вопросы. Что это за материал? К какой серии он относится? На какой стадии находится? Когда должен выйти? Для каких площадок предназначен? Нужны ли дополнительные материалы? Если свойство не помогает ответить ни на один из этих вопросов, скорее всего, оно лишнее.

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

---------------------------------------------------------------------------------------------------------------------------Практика

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

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

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

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

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

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

Не менее опасна и обратная крайность - вообще не использовать метаданные. Тогда материал остается красивым текстом, но перестает быть управляемым объектом. В такой системе нельзя нормально строить календарь, аналитику и представления по неделям.

Поэтому нам нужен баланс: только те свойства, которые действительно нужны.

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

После прочтения этой главы попробуйте ответить на несколько вопросов.

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

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

Итоги главы

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

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

Что дальше

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

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

Глава 4. Карта будущей системы

Цель главы

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

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

Зачем системе карта?

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

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

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

Как выглядят связи между объектами?

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

Все это - связи.

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

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

Почему связи важнее, чем кажется?

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

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

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

Карта - это не папка и не список

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

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

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