Личная система тегов для Google Docs

pic

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

Оптимизированная система тегов нужна потому, что при активном использовании тегов возникает несколько проблем:

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

Отказ от тегов в пользу поиска (search, don’t sort) не всегда годится, потому что для быстрого поиска по ключевым словам нужно вспомнить хотя бы одно ключевое слово, которое а) точно есть в документе и б) является достаточно редким (потому что документов много).

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

Я различаю 4 основных типа информации:

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

  2. Информация, связанная с личным видением. Этот тип материалов можно было бы назвать «сны о чем-то большем». Сюда относятся идеи, мечты, проблемы, вопросы, долгосрочные планы и так далее. В gtd к нему ближе всего maybe lists, которые Дэвид Аллен считает справочной информацией. Мне же кажется, что наши мечты — это ростки будущего, которое может осуществиться только через нас. Их важность в том, что они нас мотивируют и никуда не исчезают со временем. Идея может дремать годы, пока наконец не найдется способ ее осуществить. При этом есть идеи, которые важнее своей конкретной реализации — со временем такая идея может быть реализована еще раз, на более высоком уровне. Точно так же есть вопросы, которые важнее ответов — ответы устаревают, вопросы остаются. Точно так же проблемы могут быть больше решений — когда решения перестают работать, проблемы вновь переходят из латентной фазы в активную.

(В скобках. Не все замечают медленную эволюцию своего «мира возможного», поскольку не все имеют привычку фиксировать свои идеи и отслеживать их историю. А между тем именно здесь кроются наши реальные личные возможности — те, для осуществления которых у нас есть внутренняя мотивация. Например, я когда-то писал о том, как шестилетний Тейяр де Шарден ушел из дома в горы, чтоб узнать, что находится внутри потухшего вулкана, потому что камешки халцедона, которых было много в его краях, казались ему вечными. Фактически это те же поиски, которые впоследствии привели его к экспедициям по всему миру в поисках останков древнего человека и к его захватывающей теории о прошлом и будущем Вселенной.)

  1. Информация, связанная с проектами. Она может потребоваться при выполнении следующего похожего проекта, анализе работы, составлении отчетности, разборе полетов и т.д. Чтобы обеспечить к ней быстрый доступ, нужно иметь список всех своих проектов, помеченных уникальными идентификаторами. Это может быть просто таблица с полями «идентификатор», «название», «описание» и «дата выполнения». Идентификатор проекта и будет тегом, который присваивается всем документам, связанным с этим проектом. Его можно использовать не только в GDocs и других онлайновых системах для работы с документами, но на других сервисах (flickr, delicious), а также в именах папок на компьютере, наклейках физических папок, бланках документов и т.д.

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

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

Вот что получается:

  • @ — метка для документов, связанных с действиями.
  • * — мечты. После значка может идети название подтега, например *ideas.
  • # — проекты. После значка идет идентификтор проекта, например #7-001.
  • + — метка для обновляемых документов.

P.S. На уровне социума проблема тегов в том, насколько коррелируют между собой теги разных людей (даже если не брать проблему различных языков и ограничиться английским) и насколько в действительности тегам соответствует помеченная ими информация. С моей точки зрения, напрямую создать универсальную иерархическую систему описания данных (на что претендует, например, проект Semantic Web) практически невозможно, потому что сегодняшний мир очень быстро меняется, и структура, описывающая этот мир (онтология) должна за ним поспевать, а при этом еще скорость изменений неодинакова в различных культурах и социальных слоях. Но этой проблемой мы займемся как-нибудь в другой раз :)

Заметки по теме

Комментировать (уже 19)

  • Андрей К:

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

  • Замечательно, — оказывается, в своем del.icio.us я пришел к подобию описанной вами модели тэгов.

    Так, у меня есть тэги 2do, 2read, 2reply/2comment — нет только спецтэга для обновляющихся документов. Есть также тэг «myPosts» — им я отмечаю, как правило, собственные посты, а чаще — мои комментарии в чужих блогах (лелея древнюю мечту «собрать разрозненные записи в книгу»). Кстати, сначала для решения этой задачи я использовал сервис coComment, но потом понял, что «ручное» занесение собственных важных комментариев в букмарки приводит к более упорядоченному результату, заставляет делать это более дисциплинированно.

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

  • Я тоже пользовался кокомментом, но он сильно тормозил и пришлось отказаться.

    Теги 2read u 2reply для меня не работают — пришел к выводу, что лучше либо читать / комментировать сразу, либо не делать этого вообще :)

    На перепросмотр тегов я махнул рукой — слишком трудоемко. У меня 150 тегов и 500 документов в Google Docs, 300 тегов и 1500 закладок в delicious и 150 тегов + 500 фото во фликере, причем большинство тегов не пересекаются. Может быть (сейчас в голову пришло) проще новые теги помечать годом, например так: 7:tag.

  • Кроме всего прочего теги хороши тем, что другим пользователям сервиса будет проще (чем если-бы вы свой контент организовали в виде дерева) найти ваш контент. При этом надо учитывать что public теги — это просто набор слов ассоциаций и не более.

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

    Иначе все 7:tag, 2read, #, + и т.д. будут меня в вашем контенте запутывать.

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

  • Kosarev Andrey:

    Очень понравилась идея с идентификаторами проектов. Начал применять, как только прочитал статью. На данный момент, даже люди не знакомые с GTD, подхватили эти индентификаторы (я их использую как префикс в теме письма, касающегося определенного проекта, в рабочей переписке). Спасибо! :)

  • Wave:

    Коллега, а вот на компьютерре больше двух лет лежит статья с ценной критикой по делу всевозможной метаинформации. Взгляните. http://www.computerra.ru/think/37381/

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

  • […] = тип информации: @context = списки дел (action lists), например @computer, @call итд #7—001 = […]

  • Найс:

    Статья ваша очень пригодилась! Спасибо.

  • […] Идеальный выход — не просто в периодической уборке, а в создании своей системы организации информации. В частности, это означает, что нужно собирать всю поступающую информацию в одном месте и четко отделять информацию, связанную с действиями, от всей остальной. Подробнее об этом — в заметках Мой опыт GTD и личная система тегов. […]

  • Интересно. Но чего-то всё равно не хватает… :) Может быть настойчивости в применении? Нашёл программку http://www.tag2find.com/, предлагает присваивать тэги файлу при его сохранении.

  • […] В мою личную систему тегов входит тег @Action, которым я помечаю всю почту, с которой связано какое-либо действие, а также теги-идентификаторы проектов, которыми я помечаю всю почту, связанную с важными проектами, и теги для обозначения справочной информации. […]

  • Для меня информация по каждой сущности делится ПОКА на две: 1) вся (тэг «сущность») 2) активные действия (тэг «сущность/TODO»). Toread как отдельный тег не выделяется и считается подмножеством TODO.

    Программисты используют идентификаторы проектов (codename) испокон веков. Они всегда легко запоминаются и позволяют добавлять постфиксы, означающие подпроекты либо flavors.

  • Спасибо, Алексей, интересный подход. Я задачи не помечаю тегами вообще, т.к. по-моему чем больше их классифицируешь, тем больше вероятность, что они затеряются в недрах системы и останутся невыполненными :) плюс тратится время на это. Я вообще думаю, что идеальное состояние для каждого проекта — это одно определенное ближайшее действие и всё. Тогда весь список задач поместится на одной странице. К сожалению, это не всегда возможно, но думаю что стремиться к этому нужно. Вся штука в определении правильного следующего действия, а это связано с ответом на вопрос «Что сейчас главное?», и вот тут требуются серьезные навыки, а если их нет, получается или псевдодеятельность, или прокрастинация.

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

    Вы спросите: зачем так много? Да очень просто. Например, мне надо будет, когда приеду к родителям (а это может быть и через 2 недели), обновить софт, забрать какие-то документы и обсудить с отцом вопрос. Держать это в голове? Конечно нет, заносим в список, выставляем тэг @Славянск (родители живут в этом городе). Аналогично и другие тэги, больше всего у меня — в @Computer.

    Да, если всё это делать на бумаге — это сложновато. Но в Outlook это делается легко, за счёт быстрых клавиш и прочих удобств. Насчёт траты времени: внесение задачи, как только решил, что она нужна — несколько секунд; просмотр задач вечером (выбор дел на завтра) — 2 минуты; просмотр задач в воскресенье, выбор дел на неделю и ближайшие дни — 5 минут.

  • Вероятность того, что задачи «затеряются» мало зависят от применяемой системы. Блокнот или листочек с 3 задачами тоже можно потерять или внести задачи и «забить» :-)

    Насчёт «единственного» состояния проекта — не соглашусь. 1) если у меня всего один «следущий шаг», я не могу оценить, сколько работы ещё осталось, я не могу сказать заказчику, когда будет готова работа 2) бывают дни, когда планировал сделать большое дело, а проснулся и понимаешь: не получится, я при этом не теряю время, а просто выбираю задачи «попроще» (но их ведь всё равно надо делать) и проект движется дальше, а не стопорится на одной задаче 3) иногда по ходу выполнения проекта возникают новые задачи (например, небольшие правки, не входящие в ТЗ), и практически всегда, если не записать задачу — о ней потом забудешь

  • Сейчас (т.е. 2 года спустя после написания статьи) я использую RTM и группирую задачи по нескольким спискам. Но тегов все равно не ставлю, за исключением как раз тегов, связанных с местом или с конкретным человеком.

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

Добавить комментарий