Shares

Під катом знаходиться переклад нового варіанту реалізації 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 дозволяє створювати необмежену кількість смарт-списків, це дуже зручно. Найбільша проблема з звичайними списками полягає в тому, що завдання не може перебувати більше ніж в одному такому списку. До того ж прості списки неможливо швидко створювати (тільки через Налаштування → Списки → Додати список), а переміщати задачі можна тільки з допомогою величезного (тобто більше одного) кількості кліків.

У моїй системі існує кілька типів смарт-списків, які відрізняються по першому символу в назві.
Символ «+» перед назвою позначає смарт-список конкретного проекту, «.» — смарт-список завдань, пов’язаних з самою Системою, «@» позначаються контекстні списки, а «!» позначає список Таких дій. Завдяки цим символам всі списки відображаються групами і виглядають акуратно.

  • Список таких дій називається „!NextActions“. Це НАЙВАЖЛИВІШИЙ СПИСОК в Системі. Він заслуговує докладного опису, що піде в наступному розділі статті. Пошуковий запит:

tag:.na AND NOT tag:.maybe AND (dueBefore:«2 days of today» due OR 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:.OR maybe (list:Projects AND priority:3)

    ПРИМІТКА: якщо ви будете слідувати принципам розстановки пріоритетів, описаних мною вище, ви легко зможете виділяти формулювання цілей, зазначені пріоритетом, серед звичайних завдань. Якщо ви використовуєте функцію пріоритету по-іншому, тоді вам, можливо, знадобиться завести два списку «Maybe» (один для проектів, другий для задач). Пошукові запити в цьому випадку будуть виглядати так:

    tag:.maybe AND list:Tasks

    і

    tag:.maybe AND list:Projects

  • Список очікування називається «.Waiting_for». Пошуковий запит:

    tag:.waiting_for

  • Контекстні списки за необхідності (я їх рідко використовую). Називаються відповідно „@home“, „@побігеньках“, „@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» due OR 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
Оригінальний пост

джерела:

http://betteri.ru

Схоже

Share on Facebook Share
1
Share on TwitterTweet
0
Share on Google Plus Share
Share on Pinterest Share
0
Share on LinkedIn Share
Share on Digg Share
1
Total Shares
comments powered by HyperComments!