Под катом находится перевод нового варианта реализации 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
Оригинальный пост
—
источники:
