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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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