Свежий опыт использования Remember The Milk для GTD
Под катом находится перевод нового варианта реализации GTD средствами Remember The Milk. На наш взгляд, это одна из лучших, если не лучшая, методика из написанных.
Наконец-то кто-то придумал и четко изложил, как грамотно задействовать весь потенциал RTM, сохранив при этом общую стройность и правильный баланс системы!
Легкого чтива не обещаем, обещаем хороший ROI вложенного времени.
Автор: Petr Kopáček
Ниже будет описана моя система реализации G/ZTD в RTM, в основном основанная на использовании тегов и смарт-списков. Статья предполагает, что вы довольно хорошо знакомы с терминологией и фукционалом GTD и RTM. В противном случае вам будет очень трудно за всем уследить, лучше сначала почитать ознакомительные статьи про RTM и GTD.
Эта система в значительной степени основана на использовании тегов и смарт-списков (т.е. сохраненных поисковых запросов). Все задачи хранятся в едином списке, откуда попадают в смарт-списки благодаря соответствующим поисковым запросам. Это обеспечивает гибкость и относительно быструю обработку.
Необходимость Системы
Я просмотрел некоторые руководства о том, как реализовать GTD/ZTD, или в общем увеличить свою продуктивность при помощи RTM, ни одно из них само по себе не решило мои проблемы. Все они либо неэффективно используют возможности RTM, либо слишком упрощают G/ZTD, что для кого-то конечно может сработать…
Не поймите меня неправильно, большинство советов на форумах вполне разумны и полезны, но в части из них нет нужды, если вы хорошо понимаете GTD, а другие ведут к созданию слишком сложных систем тегов, что только вредит продуктивности, по крайней мере, моей. Объединив несколько идей из разных источников, я разработал систему, которая удовлетворяет моим требованиям.
Так вот, изначально идея была следующей: максимально использовать потенциал RTM в соответствии с концепциями G/ZTD.
Все просто. Теория в том, чтобы помечать тегами абсолютно все задачи в едином списке, откуда они будут «изыматься» в определенные смарт-списки с помощью соответствующих поисковых запросов.
Сама система
В этом разделе я перечислю все базовые списки, которые необходимы для функционирования Системы. Заметьте, я предполагаю, что вы понимаете разницу между простым списком и смарт-списком.
Списки: Инбокс (по умолчанию), Отправленные, Задачи, Проекты
Я использую только эти четыре списка. Единственным просматриваемым регулярно является Инбокс (подробнее ниже в подразделе “Рабочий процесс“).
- Инбокс это неудаляемый список, поэтому его приходиться использовать. Он является списком по умолчанию. Это значит, что в него поступают новые задачи, и он выполняет роль GTD-шной «Корзины для входящих».
- Отправленные это еще один неудаляемый список. Им я не пользуюсь, потому что у меня нет друзей, использующих RTM.
- Задачи — список всех задач в одном месте. В нем содержатся ВСЕ мои задачи, как активные, так и потенциальные. Здесь очень важно правильно расставить теги (см. раздел «Рабочий процесс») — ВСЕ ЗАДАЧИ ДОЛЖНЫ БЫТЬ ПОМЕЧЕНЫ ТЕГАМИ. Этот список я просматриваю не очень часто.
- Проекты — список, в котором я храню формулировки целей каждого проекта.
Согласно G/ZTD, на старте каждого проекта следует сформулировать его окончательную цель.
Пример (быстрый набор):
.Убедить Боба, что я должен выиграть годовой PRO-аккаунт #+rtmgtd #goal #Projects
Точка в начале предложения гарантирует, что формулировка цели окажется в самом начале смарт-списка будущего проекта.
Я использую приоритеты только в этом списке. Средним приоритетом отмечаются цели активных проектов, низшим — потенциальных (которые к тому же отмечаются тегом «возможно»).
Приоритет дополнительно обеспечивает отображение целей в начале списка.
ПРИМЕЧАНИЕ: я использую высший приоритет для отметки задач, связанных с самой Системой, например “Сделать ежедневный обзор”.
Смарт-списки: Проекты, Возможно, Ожидание, Контексты и Обзоры, Следующие действия
RTM позволяет создавать неограниченное количество смарт-списков, это очень удобно. Самая большая проблема с обычными списками состоит в том, что задача не может находиться больше чем в одном таком списке. К тому же простые списки невозможно быстро создавать (только через Настройки → Списки → Добавить список), а перемещать задачи можно только с помощью огромного (т.е. более чем одного) количества кликов.
В моей системе существует несколько типов cмарт-списков, которые отличаются по первому символу в названии.
Символ «+» перед названием обозначает смарт-список конкретного проекта, «.» — смарт-список задач, связанных с самой Системой, «@» помечаются контекстные списки, а «!» обозначает список Следующих действий. Благодаря этим символам все списки отображаются группами и выглядят аккуратно.
- Список следующих действий называется „!NextActions“. Это САМЫЙ ВАЖНЫЙ СПИСОК в Системе. Он заслуживает подробного описания, которое последует в следующем подразделе статьи. Поисковый запрос:
tag:.na AND NOT tag:.maybe AND (dueBefore:«2 days of today» OR due:never) AND NOT ((isRepeating:true AND tag:routine) AND NOT dueBefore:tomorrow)
- Списки проектов называются «+Имя_проекта», где «имя_проекта» это название или акроним конкретного проекта. Оно должно в некоторой степени соответствовать тегу проекта. Поисковый запрос:
tag:+имя_проекта
ПРИМЕР: я хочу написать пост про применение GTD в RTM. Я рассматриваю несколько вариантов названия: «+Getting Things Done в Remember the milk» слишком длинное. Как насчет „+GTD в RTM“? Все еще что-то не так. А вот „+GTDвRTM“ мне нравится. И я присвою этому проекту тег «+gtdrtm“. Таким образом, сохраненным поисковым запросом для этого смарт-списка будет:
tag:+gtdrtm
- Список возможных заданий называется „.Maybe“ и содержит потенциальные дела (задачи и проекты). Поисковый запрос:
tag:.maybe OR (list:Projects AND priority:3)
ПРИМЕЧАНИЕ: если вы будете следовать принципам расстановки приоритетов, описанным мною выше, вы легко сможете выделять формулировки целей, отмеченные приоритетом, среди обычных задач. Если вы используете функцию приоритета по-другому, тогда вам, возможно, понадобится завести два списка «Maybe» (один для проектов, второй для задач). Поисковые запросы в этом случае будут выглядеть так:
tag:.maybe AND list:Tasks
и
tag:.maybe AND list:Projects
- Список ожидания называется «.Waiting_for». Поисковый запрос:
tag:.waiting_for
- Контекстные списки по необходимости (я их редко использую). Называются соответствующе „@home“, „@errands“, „@to_read“ и т.д. Поисковые запросы:
location:Home AND tag:.na
tag:@errands AND tag:.na
tag:@to_read AND tag:.na
и т.п. ПРИМЕЧАНИЕ: Эти списки объединяют Теги и Места. (Некоторые контексты не зависят от местоположения — например, поручения, покупки — или могут включать два или более мест или их комбинацию). Это может привести к путанице. Если это произошло, я рекомендую решение Monk To Done. В нем описывается, как использовать в качестве контекстов исключительно Места, без тегов.
- Списки обзора сделанного: для ежедневного („.Dailyrev“) и еженедельного обзора („.Weekrev“). Поисковые запросы:
completed:today
и
completedWithin:1 week of today
соответственно.
Список следующих действий
Самым важным списком является смарт-список „!NextActions“. Поисковый запрос:
tag:.na AND NOT tag:.maybe AND (dueBefore:«2 days of today» OR due:never) AND NOT ((isRepeating:true AND tag:routine) AND NOT dueBefore:tomorrow)
объясняется в таблице ниже.
Грубо говоря: показывать следующие действия, которые можно выполнить в любое время или за день до их дедлайна, но не показывать потенциальные и рутинные задачи, если рутинные задачи не назначены на сегодня или просрочены.
У меня существует несколько проектов, содержащих ежедневно повторяющиеся задачи — рутину, вроде
Exercise ^today *daily #+healthproject #routine #.na #Tasks
,
Do a daily review ^today *daily !1 #+gtd.core #routine #.na #Tasks
или
Take out trash ^tomorrow *every 3 days #+negentropy #routine #.na #Tasks
и т.п. Но как только одна повторяющаяся задача выполнена, автоматически создается и показывается еще одна, что делает список переполненным (а значит демотивирующим).
В этом случае мой запрос действует как импликация, «если рутинная задача отображается, то только в день, когда она должна быть выполнена». Таким образом рутинные задачи показываются только когда наступает их срок, не раньше.
Использование „dueBefore:tomorrow“ вместо очевидного „due:today“ необходимо, потому что иначе просроченные задачи отображаться не будут.
Рабочий процесс
Делаем дела
В течение рабочего дня почти все время я работаю только со списком Следующих действий. Из него мне понятно, какие задачи назначены на сегодня (самые важные задачи согласно ZTD), какие можно выполнить в свободное время (все остальные задачи) и в каком контексте.
Опустошаем Инбокс: назначение тегов
В течение дня задания поступают в мой Инбокс. Статьи и веб-страницы для чтения, заметки, идеи, задачи. В определенный момент наступает время очистить Входящие: часть сохранить в личной вики, удалить множество ненужных или устаревших материалов, и назначить теги всем задачам. Процесс расстановки тегов состоит из двух шагов: самой расстановки и перемещения задач.
Очень важно выставить теги для всех задач. Как минимум тег соответствующего проекта или тег «возможно». Если это одиночная раздача, я сразу же присваиваю ей тег „.na“ (следующее действие *прим. betteri.ru) и назначаю срок исполнения, если это необходимо. Если это похоже на новый проект, я ставлю тег «возможно» и «цель». После этого я перемещаю все эти задачи в списки Задачи или Проекты. И наслаждаюсь пустотой моего Инбокса.
Ежедневный обзор: СВЗ
Во время ежедневного обзора я просматриваю список «.Dailyrev», чтобы увидеть, чего мне удалось достичь за день. Выполнение одних задач порождает (не всегда это происходит автоматически) новые задания. В это время я определяю самые важные задачи (СВЗ) на следующий день (подробнее об этом читайте в статье про ZTD). Я выбираю задачи, соответствующие моим планам и ближайшим приоритетам, и выставляю для них срок завершения на завтра. Срок задачи это единственный индикатор СВЗ, благодаря нему они визуально выделяются и отображаются перед всеми остальными задачами в списке «!NextActions». Теперь я ввожу в поисковую строку „isTagged:false», чтобы проверить, для всех ли задач расставлены теги, и на этом ежедневный обзор заканчивается, можно идти спать.
Еженедельный обзор и другие стандартные практики
Следует заметить, что я не буду описывать их настолько детально, насколько они того заслуживают. Еженедельный обзор и планирование проектов уже давно замечательно описаны другими. Просто отмечу, что я просматриваю свой список возможного «.Maybe», выставляю формулировки целей для новых проектов и приоритеты активных/возможных проектов. Если я хочу посмотреть, что ждет меня в будущем, я открываю список Задач, отсортированных по сроку завершения (или для более точного отображения ввожу в поиск „dueWithin:“one week of today“).
Заключение
Моей целью было реализовать методику GTD с помощью инструментов RTM.
Я понимаю, что описанная здесь система субъективна и настроена под меня, однако она объединяет несколько идей, которые я счел полезными, и содержит несколько свежих подходов (свежих по крайней мере для меня), которые способны упростить работу.
Список следующих действий, как и все другие значимые для GTD списки, формируется из всех задач, хранящихся в едином Списке.
Плюсами моей системы являются гибкость списков, последовательная работа с тегами. Минусами — относительная сложность настройки и переход на работу с ней.
Автор: Petr Kopáček
Оригинальный пост
—
источники:
comments powered by HyperComments