Рубрики
Самоорганизация

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

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

В том, что теги — намного более продуктивный способ сортировки информации, чем папки или категории, наверное, многие уже убедились. В этой заметке я хотел бы предложить принципы построения личной системы тегов на примере своего варианта такой системы для 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 ответов к “Личная система тегов для Google Docs”

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

Замечательно, — оказывается, в своем 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, #, + и т.д. будут меня в вашем контенте запутывать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий для Алексей Труфанов Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *