#GTD

Останнього тижня мені пощастило піти у коротку відпустку… та так вийшло, що я це зробив з абсолютно порожнім списком наступних дій. Це в мене безпрецедентно, та до того ж дуже приємно. Хочеться повторяти цей успіх, тому занотую спостереження.

Йдеться про список наступних дій; список проєктів, звісно, не залишився порожнім, бо там деякі справи тривають місяцями. Виходить, в цьому розділенні на два списки є додаткова користь — тільки один з них можна закінчити. По поверненню з відпустки я, звісно, пройшовся по проєктах та досипав ще дій — але визначним був той момент, коли дій не було. Хотілося б досягати такого щотижня.

Це моя перша роздільна система для роботи та дому. Раніше робота завжди була контекстом (текою, зоною) в спільній системі. Зараз в мене окремий компʼютер для роботи та я намагаюсь відокремити роботу від особистих справ, тому було логічно й системи задач зробити дві.

Виявилось, що розділення значно спрощує робочу систему: в ній лише один контекст, тобто єдиний список задач (дій.) Я просто відкриваю його та роблю дії по черзі; нові задачі додаються в кінець. Майже не доводиться думати, що робити далі. Зате тепер доводиться окремо робити щоденний та щотижневий огляд, що в цілому тільки перевага.

В домашній системі до такого успіху ще далеко, бо там все (поки?) вдесятеро складніше. Контекстів багато, проєктів багато, вони всі різні. А головне — потрібно вставати з-за компʼютера. Бо дійсно, зараз робота стала такою зоною комфорту, де все заздалегідь впорядковано — сиди та роби. Раніше так хіба з компʼютерними іграми було. Втім, такий успіх надихає влаштувати особисті справи так само.

Коли мене просять щось зробити, то воно йде або в кінець списку, або — якщо це терміново — то я роблю його невідкладно. Але головне, що є надійне місце для всього, що невідкладно не зробиш. Це звільнює від “режиму хомʼячка”, де бігаєш по колу та робиш останнє, що впало в очі.

До речі, майже всі нетермінові прохання я обробляю вранці під час щоденного огляду; протягом дня я їх записую в нотатки чи зберігаю в Slack, а вранці обробляю ці вхідні та перетворюю за GTD.

Чесно, поки писав пост про порядок виконання задач, тільки під кінець згадав про існування “системи” Final Version (Perfected). А я їй колись користувався в блокноті, з непоганими результатами. Цього разу вирішив адаптувати систему для власного домашнього застосунку для ведення справ. Далі більше про систему FVP та деталі реалізації.

Нащо воно потрібно? Бо чим довше список задач, тим важче обрати, що з нього робити наступним. Та найстрашніше те, що природна реакція на те — взагалі нічого не робити. Тому люди вигадують всякі системи, як я писав в попередньому пості, а також розставляють пріоритети, плани на сьогодні та таке інше.

FVP пропонує елегантне та просте рішення, яке все ж включає постійний перегляд всього списку — тому важливі задачі будуть виконані якнайшвидше. Це, якщо хочете, розвʼязок задачі динамічним програмуванням.

Для FVP тобі потрібний список, де можна відмічати задачі. (На папері — ідеально.) Відмічати будемо задачу, яку робити наступною.

1. Спочатку — відмічаємо першу задачу (як початковий стан).

2. Далі шукаємо в списку задачу, яку треба зробити до відміченої.

3. Знайшли — відмічаємо її, та продовжуємо порівнювати решту задач вже з нею.

4. Дійшли до кінця списку — тепер остання відмічена задача є найпріоритетнішою. Робимо її.

5. Повертаємося до попередньої відміченої задачі, та продовжуємо перебір вниз по списку.

Сила цього метода в тому, що доводиться тільки порівнювати по дві задачі, та лише N раз. Ніби нічого революційного, але дуже дієво. (Залишається ще чистити список від того, що там застрягає, але то окрема історія.)

В мене в застосунку для GTD є режим FVP для простого вибору наступної задачі. Він був трошки напівавтоматичний, а саме: переглядати задачі в послідовності, та не стрибати туди-сюди, доводилося вручну — за звичайним списком. Тобто все одно перед очима був повний список.

(Нагадаю, що весь сенс алгоритму FVP - це такий класичний пошук найпріоритетнішої задачі в масиві — запамʼятовуємо першу задачу, перебираємо всі інші та порівнюємо з нею, як найдемо більш приорітетну — запамʼятовуємо її та йдемо далі. Ну всі такий код писали. Але тут воно працює “на мʼясі”.)

👈 Сьогодні, щоб полегшити собі життя, впровадив спеціальний режим, де показуються тільки дві задачі - “найважливіша” та наступна з не перебраних, Залишається тільки обрати між ними (і так N разів). Такий собі “тіндер для задач” замість списку. 👉

Насправді колись я робив цілий сортувальник в такому стилі. Але для FVP потрібно тільки обрати одну задачу, та “мʼясна складність” алгоритму лише O(N).

🏄‍♂️ В колах самоменеджерів ходить така фраза, як “впасти з воза” (fall off the wagon): це коли ти припиняєш підтримувати систему. Далі на цей віз треба залізти та їхати далі. Проте мені більше подобається не віз, а човен чи навіть дошка для серфінгу: бо коли “впадаєш з човна”, вода — задачі — нікуди не зникає, а навпаки, тепер доведеться вигрібати поточні справи вручну, поки не залізеш назад.

Для мене головною проблемою із відновленням системи є — що робити з попереднім списком задач? Продовжувати як є — морально дуже важко. Викинути — ризиковано, бо завжди там сидітиме пара задач “з другого квадранту”, які потрібно зробити обовʼязково, навіть якщо час минув. Насправді навіть щось з нього викинути теж важко. Окрім утоплених витрат, взагалі важко (мені?) відмовлятися від задуманого.

Тут важливо згадати, що причиною падіння з човна саме й був поточний список задач. Ну тобто так, можна звинуватити обставини, але якби список був чітко з важливих речей, то не було б проблеми до нього повернутися. Але ні, список заріс бурʼяном. Тепер він відштовхує, та ми обираємо вигрібати вручну. Можна сказати, що повернутися в човен ще складніше, ніж почати.

Допоможе прорідити список система “мабуть/колись”. До “мабуть/колись” менше вимог, тому від неї значно менше стресу. Все зі старого списку, що не потребує невідкладного виконання, може йти в “мабуть/колись” та сидіти там… а хоч довічно. Головне, що ми й не забудемо нічого, і зобовʼязань не беремо зайвих. (А ще краще переносити задачі в “мабуть/колись” раніше, ще на тижневому огляді, як тільки ясно, що поки на них немає часу.)

Сьогодні шукав відповіді на те, коли ж все ж таки робити ті наступні дії, які назбиралися по GTD. Бо якщо не придивлятися, весь день без того чимсь зайнятий. Знайшов на реддіті відповідь, яка змусила замислитись.

Метою GTD є розум, спокійний, як вода: такий, що робить саме те, що потрібно, та не марнує зусилля на аби що. (Якщо замислитись, це дуже буддистська філософія.) Так от ця відповідь давала пораду від зворотного: там, де розум тривожний, і потрібно прикладати GTD.

Мені подобається, що такий підхід водночас і визначає межі системи продуктивності (бо записувати потрібно тільки те, що не виходить само), й створює тригер для уваги (відчуваєш тривогу — перевір списки.)

От в мене є таке, що коли раптово та терміново просять щось зробити, то стає тривожно… не від того, що я вже зайнятий, а від того, що я не знаю, чи буду зайнятий. Оце для мене саме та тривога, з якою можна боротися за допомогою GTD.

Прочитав нещодавно в пана Рожкова про бота для обліку пального. Та відразу згадалося, як я колись такого нагородив… аже поділитися захотілося, бо проєкт нікуди не пішов. Йдеться про бота для обліку власних задач за моделлю GTD.

Власне, ось навіть код виклав.Я писав його влітку 2017-го, але сьогодні легко завів. Бо це Go, а не React Native. У Go підтримка легасі — це одна з головних цінностей дизайну. Ще треба зазначити, що в Telegram дуже зручна модель розробки ботів, тож ти його можеш запустити в себе локально та створити власного бота. Поки програма запущена, бот буде доступний будь-звідки через інтерфейс Telegram.

Як бот влаштований. Фактично бесіда з ботом — це “вікно” в дані, яке фокусує нашу увагу на чомусь одному (наприклад, поточній дії.) Задача бота — просувати це вікно, а також пропонувати ефективні та вчасні операції в поточному контексті. Це досить особливий бот, можу порівняти його з людиною-тренером, або з інтерактивною літературою, тільки ще й з твоїми даними всередині.

Головна складність в тому, що він повинен памʼятати стан бесіди, причому навіть після довгої паузи. А бесіда має складну блок-схему (“обробка вхідних” в GTD вже складна!)

Я роздивлявся різні моделі та вирішив розбити спілкування на пари “питання-відповідь”. Кожне питання має: код-ідентифікатор, “шаблон інтерфейсу” - текст та кнопки, та обробник відповіді.

(До речі, оці кнопки - це лише “заготовлені відповіді”, тобто немає різниці, натиснути на кнопку чи ввести її текст вручну. А також тому можна обробляти кнопки та вільний ввід одночасно, в одному “питанні”.)

Обробник інтерпретує відповідь, робить належні зміни в базі, та надсилає повідомлення про результат. Результатом обробника завжди є нове питання, яке набуває чинності та отримує шанс побудувати вже власний “інтерфейс”. Наприклад, ось питання action_suggestion з ілюстрації.

Таким чином вдалося ізолювати логіку кожного кроку. Щоправда, я на той час не здогадався класти додатковий стан, як-от поточну дію, в поле JSONB, а записував прямо в спільні поля в моделі користувача. Це погано, бо в кожного питання може бути своє розуміння “поточної дії”.

Мені цей проєкт, з одного боку, подобався та досі подобається за його інтерфейс. Є щось особливе в тому, щоб працювати з даними в режимі діалогу (що на цей день стало тільки актуальніше.) А з іншого, діалог обмежує. Зокрема як тільки треба передивитися всі дані в базі, та ще й робити над ними зміни. Були в мене фантазії гібридного застосунку — тобто такого, де діалогова модель доповнює традиційну - але руки не дійшли.

Знаєте що? Червень — місяць, максимально віддалений від Нового року. А значить, це такий надир продуктивності, коли всі старі новорічні обіцянки вже вигоріли, а до нових ще так далеко. Я гадаю, найкраще часу для пояснення системи самоменеджменту не придумати. 🌚

Отже, GTD. Я багато разів згадував її, але тепер хочу систематично пройтися, бо гарного пояснення рідною мовою ще не бачив. На початку була книга. Українською її перекладають нудно “Як привести справи в порядок: мистецтво продуктивності без стресу”. Хіба це бренд? Я пропоную альтернативну назву: Беремося До Справ — БДС, а оскільки це моя авторська адаптація — то БДС Модифікована: БДС(М). 🐴

Центральна мета БДС — це, як не дивно, не виконувати справи, а зберігати спокій та робити саме те, чого потребує кожний поточний момент. Раніше я думав, що це потребує патологічного контролю над собою, але справжній зміст цієї мети в тому, що це неможливо, поки голова забита справами. Через систематичне спорожнення голови у зовнішню систему ти залишаєшся вільним бути в моменті — хай то важливий дзвінок, прибирання квартири, чи гра з дитиною.

Можна подумати, що “система” це структура даних, але, як я згодом зрозумів, тут головне — як ти думаєш про справи. Якщо бездумно виконувати вимоги структури (про яку я буду писати пізніше), ефект виходить мінімальний. А навпаки, з правильною філософією — багато структури не потрібно.

Також цікаво, що БДС охоплює всі сфери життя. Теоретично можна її впровадити тільки на роботі (бо в мене зараз взагалі дві окремі системи), але повний результат буде тільки від повного застосування. Бо голова ж зайнята всякими справами, що на роботі, що вдома. В БДС немає нічого специфічно “робочого”, та вона чудово допомагає впоратися з побутом.

Я з цією системою вже років 18, та хоч не завжди я її дотримуюсь, але принципи та поняття БДС так невідʼємно зі мною, як арифметика. Останній рік досліджував її поглиблено — шукав пояснень, бо хотілося дійсно розуміти, що мав на увазі автор. Спробую й вам розповісти.

GTD / БДС є системою звичок, а вже в другу чергу організації даних. Тому вона й вижила 24 років — бо книжка вийшла у 2001, ще коли не було ані смартфонів, ані інтернету в сучасному сенсі. Інструменти змінилися, але ми так само ходимо з повною головою та хочемо зробити більше, ніж можемо.

Сенс цих звичок в тому, щоб звільнити голову від всього, що нам не потрібно на цей момент. Та зробити це так, щоб ми були впевнені, що всі справи, обовʼязки, обіцянки десь записані, а не загубились. Сьогодні перерахуємо ці звички.

1. Збір. Це звичка завжди записувати все, що захоплює твою увагу та потребує дій в майбутньому. Багато чого приходить до нас вже записане — як-от повідомлення чи пошта. Але збирати варто все, за що чіпляється розум, від скрипучих дверей до ідей продуктів. Та, звісно, всі обіцянки та прохання теж.

2. Обробка. Вхідні — це ще не задачі; “вхідним” може бути все що завгодно, та першим чином їх треба розділити: що робити, що відкласти на потім, що зберегти для довідки, а що викинути. Цей крок дозволяє нам спокійно оцінювати задачі, замість того, щоб реагувати на них в моменті.

3. Систематизація. То, мабуть, найбільш знайома всім звичка про розкладання задач в різні списки. В БДС на диво списки дуже прості, тому влаштує буквально будь-яке сучасне рішення, від блокнота та текстового файлу. Вся магія не в списках, а в осмисленні, яке їм передує.

4. Перегляд. Звичка, яка все повʼязує. Щотижневий перегляд зберігає впевненість у повноті та актуальності системи. Без нього швидко втрачаєш довіру. Не лякайся, переглядаються тільки поточні справи, та ті, що можливо пора починати — тому перегляд виходить цілком осяжний. (І надзвичайно корисний!)

5. Виконання. Нарешті, те, заради чого ми все це робимо. За моїм досвідом, хоч БДС охоплює всі частини життя, але тільки невелику частину часу. Здебільшого це ті справи, що просто так не робляться: “важливе, але не термінове.” А більшість часу займає всіляка рутина та термінові несподіванки. Тому без звички виконання будеш щотижня сумно переглядати той самий список задач.

На мою думку, коли люди займаються типовим тайм-менеджментом, то обмежуються систематизацією та виконанням. Переглядом — хіба як щось епічне-новорічне.

А особливо сумно за збір, бо саме завдяки збору приходять гарні ідеї, а інколи — справжнє просвітлення. Про це — завтра.

Про збір можна дуже швидко сказати: записуй все.

Підкреслю, що збираються не задачі, а нотатки. В цьому й сенс збору як окремої практики: ми вільні записувати все, що завгодно. Поки - невідомо: може, то задача, а може, ідея на майбутнє, а може просто зайва думка. Зібрані нотатки називаються “вхідні” та обробляються наступним кроком тоді, коли це зручно (зазвичай щодня.)

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

Не всі вхідні доводиться збирати вручну. В нас багато місць, куди вони приходять самі: пошта, повідомлення, робочий стіл тощо. Такі місця достатньо перелічити та точно окреслити — тобто знати, коли там є що обробляти. Я відстежую понад 20 категорій вхідних, де є, наприклад, “відкриті вкладки браузера” та “речі не на місці”.

Власне, з пошуку таких місць можна й почати. А також, завести собі зручну записничку. Зараз це 100% телефон — то обрати програму, куди легко заносити нотатки. Для мене це Drafts, але зовсім на ходу надиктовую Siri в нагадування.

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

Завдяки регулярній обробці у вхідних нічого не залежується — а значить, ми впевнені, що звідки б не звалилися обовʼязки (та коли б не вистрілило натхнення!), все це не залишиться без уваги.

В GTD / БДС є центральна блок-схема для обробки — вона на ілюстрації. В ній є два ключових питання: чи потребує це дій? та коли? Обидва питання критично важливі, щоб не завалити себе незрозумілими “задачами”.

Частина вхідних або просто непотрібна, або записана для довідки. Такі ми викидаємо чи переносимо в нотатки та інші зручні місця. Тут все просто.

А далі залишається велика маса того, що можна “робити”. Це й прямі обовʼязки, нагадування, запитання. Та ще ідеї, навʼязливі думки, проблеми, плани, фантазії, афіші. “Задачі” приходять в широкому різноманітті.

На оригіналі схеми є питання: is it actionable? Довгий час я думав, що воно значить — чи можна взагалі щось по цьому зробити? Це неправильно! Робити можна майже все. Навіть мрія починається з маленької дії сьогодні. Проте справжній сенс цього питання в розгалуженні: беремося робити в найближчий тиждень, або почекає?

(Я для конкретики написав тиждень, бо це правильний проміжок між оглядами. А на огляді ми маємо шанс переглянути списки відкладеного та поповнити активні задачі. Взагалі в БДС багато чого відбувається в ритмі оглядів.)

Все, що чекає — йде у “беклог” під назвою “мабуть/колись”, про який я вже писав, але напишу ще в пості про систематизацію. Це наш великий довідник занять на майбутнє.

Нарешті, залишається те, що треба робити ось зараз чи найближчим часом. Я гадаю, найважливіша частина БДС — це те, як ми обробляємо поточні задачі. Тому її я виділю окремо.

(Організаційне питання: я подумав, що перейменовувати продукт із торговою маркою — погана ідея. Тому далі буде просто GTD, без вигадок.)

Задачі приходять до нас в різній формі: “додати фічу X”, “повісити москітні сітки”, “купити сорочку”, “купити хліб”. Всі їх можна виконати. Але центральний момент GTD в тому, що ми недостатньо плануємо наперед. Може здатися, що план — це зайвий, якщо й без нього можна все зробити. Але якщо звернути увагу, тоді виходить, що ми змушені “планувати” в момент вибору задачі, та виходить це кепсько.

Наприклад: “повісити москітні сітки” наче зрозуміло… але самі сітки лежать в гаражі, то туди ще треба сходити забрати. “Купити сорочку”… та яку саме ще не вирішили. З хлібом зрозуміло, але його потрібно купити не зараз, а коли будеш в крамниці. Таке мікропланування ми робимо щоразу, коли читаємо список задач, та саме через нього список переростає у незрозумілу купу.

GTD пропонує додумати кожну задачу заздалегідь, на етапі обробки. Це не так нудно, як звучить. Всього лише потрібно від тієї початкової “задачі” піти: вгору, щоб визначити очікуваний результат, та вниз, щоб визначити справжню наступну дію.

Наприклад: з сорочками може результат бути “мати свіжий одяг на літо” (бо сорочки ж не самоціль?) А наступна дія - “спитати в друга, де він купував сорочку.” А ні, то не мій друг, а чоловік подруги дружини. Ну тоді спочатку “спитати контакт в дружини.” Ми розкручуємо задачу, поки не дійдемо до дії, яка не має передумов (окрім контексту, про нього буде окремо пізніше).

(До речі: для GTD нас цікавить тільки наступна дія, а не повний план. План можна зберегти за бажанням, але все одно кожний крок будемо розкручувати так само — виходячи з обставин.)

А “купити хліб” - це взагалі не задача, а пункт списку покупок! Немає сенсу такі рутинні дії тримати в GTD. Та це ще один нюанс: знати, де пора зупинитися. GTD це точно не система “для всіх задач в житті”.

Для складних проєктів варто завести нотатку та обробляти формально. Прості можна й в голові. Хоча по правді кажучи, в голові погано виходить, легко себе надурити. Ще є магічні дії “подумати” та “розпланувати” - це ми фактично відкладаємо осмислення на потім. Головне, щоб в нас був час, коли це осмислення відбудеться, бо часто така дія сидить аж до наступного огляду, коли доводиться приділити їй увагу.

Та так, думати — важко. Допомагає ставитися до цього як до творчої задачі. Ну як наче ти пишеш квести для гри. Чіткий список наступних дій — задоволення само по собі, про що ми будемо говорити, коли доберемося до виконання.

Вчора зачепив тему проєктів, але вона варта окремого поста, бо “проєктом” можна називати зовсім різні речі. Ось я вже писав про проєкти.

Зокрема, це зовсім не те що проєкт в керуванні проєктами. Наприклад, в мене проєктами в GTD стають задачі чи епіки з Jira. На мою думку, “проєкт” на цей день надто перевантажене слово, але маємо те що маємо.

Вчора ми розкручували задачі в наступні дії. З одного боку, тепер їх легше почати — та закінчити. З іншого, також мусимо памʼятати, до чого ми хочемо дійти. В GTD проєкт — це результат, до якого спрямовані наступні дії. Тож окрім списку наступних дій, ми ведемо список проєктів. Не просто “задач” незрозумілого рівня, а саме бажаних результатів.

Наприклад: “Зробити пошук в каналі”, “Приготувати карбонару на вечерю”, чи “Підготуватися до відпустки” - це все проєкти.

Список проєктів нам потрібний для контролю. Ми не звертаємося до нього для вибору задачі — на те є список дій. Але ми передивляємося список проєктів, щоб помітити застряглі справи та оцінити навантаження. Дивно, але за GTD цей список достатньо переглядати раз на тиждень. Це, певно, за тих умов, що після виконання дії ми додаємо наступну, бо інакше робитимемо по одній дії на проєкт щотижня (це якщо встигнеш!)

Проєкт — це великий чи малий результат? Я гадаю, в ідеалі від тижня до місяця роботи. Тиждень — бо це інтервал огляду; менші проєкти змушуватимуть звертатися до планування частіше. Місяць — бо надто великі проєкти втрачають чіткість та розтягуються. Такі краще розбити на кроки. Для мотивації важливо, щоб ми могли закрити проєкт та рухатися до наступного, а не жувати місяцями один й той самий.

Існує ціла школа правильної постановки цілей, як-от SMART тощо. Це, мабуть, гарно і для проєктів, але система працює і без того, завдяки оглядам.

Є ще питання надто маленьких проєктів, коли здається, що одна дія — це й все. Тут офіційних порад не бачив, але я схиляюся що проєкт краще знайти навіть “на одну дію”. Ніякі дії не існують в вакуумі. Тож варто визначити, звідки ця “одна” дія взялася, та для чого. Також краще мати віху для контролю, що справа зроблена, бо після виконання “однієї дії” часто зʼявляються продовження.

Давайте головне: хоч GTD пропонує охопити всі сфери твого життя, але 100% немає мети охопити всі діяльності. Немає ніяких просвітлених монахів GTD, які з ранку до ночі роблять все життя по системі.

За моїм досвідом, у дні є трішечки часу, коли ти звернеш увагу на систему GTD. Спочатку — все рутинні справи, календарні події, відпочинок в решті решт. І от, між всім цим, є моменти, коли можна встигнути зробити щось неординарне. GTD нас готує до цих моментів, щоб ми не загубилися та влипли в телефон, а мали чіткий список дій, над яким більше не треба думати — час діяти!

Але з усіх дій ще треба обрати одну. Якщо їх мало, можна просто перебрати. (Або використати FVP чи інший алгоритм.) Втім, зазвичай дій багато — кілька десятків — та це обтяжує. Тому ми розбиваємо список дій на менші списки — за контекстами. Контекст задає обставини, в яких ми хочемо бачити ту чи іншу дію.

(Наприклад: в моїй системі для роботи контекстів немає, бо поточних дій не більше 20, та я дійсно можу взятися за будь-яку - “робота” це вже достатній контекст.)

В книжці про контексти написано якось абстрактно, та вони виходять надуманими: “вдома” чи “місто”, чи “комп”. На мою думку, тобі варто подивитися на своє життя, та на доступні в ньому ситуації та базувати контексти на них.

Коли контексти надумані: “Місто” велике, та ти не буваєш регулярно в усьому “місті”. Більшість поїздок треба планувати заздалегідь — то може краще мати контекст “планування справ”? А “комп” - поганий контекст, бо й так весь день за компом і це ні про що не каже. Може, краще “швидкі справи рано вранці” чи “поки чекаю дитину з тренування”. Або “дослідження”, теж зручно.

А от контекст “дзвінки”, чи в мене - “комунікація” - дуже мені подобається: я до нього звертаюся в понеділок зранку, та послідовно закриваю всі стресові дії. Та це інший підхід до контекстів: збирати схожі дії в пачку. Тільки все одно треба розуміти, коли ти ними займешся; контекст, в якому ти не буваєш — поганий контекст.

Нарешті я трохи підготований перелічити, з чого складається система GTD, а також де ці частини розташовані в мене. За моїм досвідом, немає ідеального застосунку для GTD просто через різноманіття потреб та функцій. І це нормально.

Серце системи — Списки наступних дій за контекстами та список проєктів — про ці я детально розповідав в останні дні. Я на те зробив собі застосунок CoreGTD, яким досі (вже майже рік!) користуюся.

Список очікування — сюди пишемо все, чого пасивно чекаємо, щоб 1) не забути та 2) відстежувати, що проєкт заблокований. В мене це просто ще один контекст, який я переглядаю щодня.

Календар — в ньому залишаються всі справи з конкретним часом. Календар — це святе. В мене календар в Apple Calendar.

Календар нагадувань Йдеться про нагадування на далекі дати. Наприклад, “купити подарунки на Різдво”, “фестиваль”, чи “перевірити систему опалення на зиму”. Англійською називається tickler file - я завжди думав що це вигадка GTD, але насправді така картотека існує ще з перших нотаріусів. В мене такі в Apple Reminders, де зручно налаштувати повторення.

Мабуть/колись — це величезне сховище ідей та планів на майбутнє. В мене воно все на канвах в Obsidian, за посиланням детально написано.

Плани проєктів — бо планування точно не закінчується на меті та наступній дії! План — це не тільки перелік дій, а ще й нотатки, довідки, ідеї, ілюстрації — все це обовʼязково варто збирати до купи. Це теж я тримаю в Obsidian, по канві на проєкт (якщо потрібно.)

База знань — без неї теж голову не спустошити, хоч до задач база знань не має відношення (майже за означенням). Тут можна залучити будь-яку систему, яка подобається (або ніякої.) І тут в мене теж Obsidian.

Вхідні — це теж частина GTD, бо повинно бути місце, куди легко записати на ходу. Для мене це передусім Drafts.

Всю систему GTD можна розділити на дві частини:

“Активна” частина — це списки наступних дій та вхідні. Вона потребує щоденного перегляду. Дії ми просто робимо (сподіваюся), а вхідні обробляються за схемою. Це все, що потрібно робити постійно, щоб залишатися з робочою системою. (Ну й, звісно, користуватися календарем.)

Решту системи ми переглядаємо щотижня. Це називається, очікувано, тижневий огляд.

По-перше, під час тижневого огляду переглядаються всі проєкти; якщо є такі, що не мають наступної дії, чи застрягли без прогресу, то виправляються. Часто розумієш, що проєкт чи дія поставлені невірно та переформулюєш. Або — видаляєш / пересуваєш до “мабуть/колись”! Бо зайвих проєктів повинно не бути.

По-друге, ми додаємо нові проєкти. Вони можуть братися з календаря нагадувань, з “мабуть/колись”, або просто з навколишніх обставин. В офіційних посібниках для того є довжелезний перелік питань-тригерів, але можна зібрати й власний — з усіх сфер життя, де можуть виникнути проєкти.

Чому тижневий? Можна було б й рідше. Але краще стежити за обсягом системи та не брати більше справ, ніж можна переглянути за годину кожного тижня.

Що я не роблю щотижня, так це перегляд всіх “мабуть/колись” - їх просто надто багато. Натомість переглядаю тільки по одній категорії. Гадаю, це в моїй системі слабке місце, але з тим “мабуть/колись” - найменш термінова категорія, та зазвичай готова чекати.

Без регулярного огляду система розвалюється. Але, як бачите, саме завдяки систематизації нам вже не потрібно робити якийсь епічний огляд всього життя в абстракції, а достатньо переглянути кілька списків. Та, дуже приємно щотижня знати, що ти все переглянув та задачам більше немає де приховатися.

(Поки закінчую писати про GTD. Я наче пройшовся по основах, а також зрозумів, що краще писати, коли є натхнення з конкретної теми. Не кидаю надій зробити колись красивий посібник українською.)

Хотілося замість всього цього сухого поговорити про відчуття. Що я відчуваю без GTD та тоді, коли система працює.

Ось сцена, яка мені знайома як рідна. В ній герой хоче замінити лампочку, але натомість занурюється в яму послідовних задач: закріпити полку з лампами, змастити ящик з інструментом, купити мастило, і фінал — полагодити машину, на що в нього йде весь день. В серіалі це виглядає комічно — хіба не можна було закінчити першу справу, а потім братися за наступну? Але саме так я відчуваю себе без системи, в яку можна записати вхідні — я хапаюся за крайню справу, що здається важливою, бо без системи єдиний шанс зробити справу — це натрапити на неї та вхопитися негайно. Я називаю це “режим хомʼячка”.

Тобто звісно, якби всього в житті було пʼять задач, то нескладно розставити їх за порядком. А коли їх сто?

Напевно, все залежить від характеру (та від нейродивергенції.) Моя голова є нескінченним фонтаном ідей буквально для всього, тому в мене завжди більше незробленого, ніж часу. Частина цих ідей — чудові та розвʼязують справжні проблеми. Але інші — нереальні або тільки створюють додаткові проєкти та додаткове навантаження.

Без системи я заходжу на кухню та бачу мільйон задач — від законних “прибрати посуд” до наче важливих, але не зараз “повісити гачки для каструль” до зовсім казкових “зробити вертикальну грядку для зелені”. Виходжу з кухні та бачу ще мільйон задач… Річ не у тім, що всі їх треба зробити, та навіть не в тому, що треба виділити пріоритетні. Система GTD дозволяє мені зібрати всі задачі в єдину купу, та в спокійних обставинах приділити їм належну увагу.

З системою я оглядаю кухню та бачу — все як вчора, про все це я вже подумав. Можна спокійно прибрати посуд. О, і ще оце посилка нова лежить — запишу, щоб з нею розібратися. (Нарешті проєкт з гачками розблокований!)

Тобто, GTD існує (всупереч назві?) не заради того, щоб зробити всі справи, а щоб можна було спокійно взаємодіяти з життям та вже на ґрунті цього спокою будувати все інше. Та щоб я не захотів будувати - GTD допомагає рухатися до мети. Як кажуть, в GTD будь-що стає проєктом — значить, будь-що можна зробити - задачі, ідеї, мрії, турботи, тривоги. Ось заради цього спокою та впевненості я завжди повертаюся до GTD, скільки б не кидав.

В GTD є модель горизонтів фокуса. Це шість перспектив, з яких можна дивитися на своє життя: починаючи з нульового рівня наступних дій, та закінчуючи пʼятим рівнем мети життя та життєвих принципів.

Та, коли сформулюєш твердження для кожного горизонту, кажуть, то стане легше відрізняти потрібне від зайвого. В мене з цим хронічні проблеми, тож нарешті намагався визначити свої горизонти, а насамперед оті самі “життєві принципи”. Ось кілька спостережень.

Мені було важко почати, бо не хотілося писати зовсім загальні речі штибу “бути чесним”. Справа зрушилася, коли я пройшовся по списку проєктів з питанням “навіщо я це роблю?” Так набирався список тверджень як-от “допомагати близьким” чи “підтримувати форму”. Головне, щоб таке твердження вже давало відгук: так, це воно! Бо, власне, вправа не на вигадування, а на пошук в собі.

Інший спосіб — це спостерігати, в які моменти ти відчуваєш, що реалізувався. Або вчиняєш “правильно”. Такі моменти можна довго збирати, але в цілому ми нікуди не поспішаємо.

Я також зрозумів, що немає ніякої оцінки, що принципи записані правильно або вичерпно. Краще ставитися до цього як до поточного розуміння, та виправляти, коли це потрібно. Та головне — сформульовані принципи негайно починають впливати на ставлення до життя та на прийняття рішень. Це якась психологічна магія.

Найцікавіший ефект: поки принципи не усвідомлені, ти можеш почувати себе жертвою обставин. Раціональність за браком фактів тут готова робити нам кривду. Наприклад, я чимало зусиль витратив на розробку плану електрики для квартири, та весь цей час вважав, що це така неприємна праця, яку я мушу робити. Складно — факт. А чому мушу? Можна ж фахівцю віддати? Неясно… А от тільки зараз зрозумів, що мені ж взагалі-то подобається, коли я сам все дослідив та продумав подробиці під себе! Тож тепер така саме робота буде в задоволення, а не в тягар.

Але поки я тільки почав з цим працювати, було б цікаво почути, в кого такий досвід вже оформився. В теорії можна було б ще з дитинства починати, але краще пізно ніж наколи.

В мене довгий час була проблема (я про неї навіть писав), що я починаю надто багато проєктів, а потім не встигаю їх робити та як результат система розвалюється.

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

Є проєкти, які очевидно належать цілі: наприклад, “обрати фарби” до цілі “закінчити ремонт”. Для таких проєктів я отримую додаткову мотивацію від розуміння, задля чого воно робиться.

Є такі, де ціль народжується в процесі. Я так знайшов у себе ціль “вибудувати режим” з наче неповʼязаних спочатку проєктів-спроб щось потрохи покращити. Тут наявність цілі відкриває творчий потенціал та можливість вичерпати всі напрямки.

Ну й нарешті багато з чим стає питання “щоб що?” Завжди є справи заради інтересу чи задоволення - то нормально. Проте це коли вони рухаються та не створюють проблем. А коли застрягли та висять - вдається спокійно скасувати без відчуття втрати.

Ставити собі цілі не так страшно, якщо прийняти, що вони в тебе вже є - залишилося тільки їх знайти.

Одна з цікавих ідей GTD: будь-яка справа ділиться на два етапи: думати та робити. Робити, коли все ясно — достатньо просто (може, не легко.) Мабуть, кожний може згадати час, коли нехай важка, але абсолютно визначена робота була навіть в задоволення. Але в нормі не все ясно. Та ми, замість того, щоб подумати та прояснити, думаємо про справи, та ухиляємося від невизначеності.

Щоб полегшити собі життя, можна продумати справи, а не думати про справи. Це значить — поставити та знайти відповіді на всі запитання потрібні… уважно: для того, щоб зробити наступну дію. Продумати все до кінця під час не те що непрактично, а взагалі неможливо.

Питань виникає багато, деякі очевидні, деякі несподівані. Наприклад: щоб “шукати нові шини” треба хоча б знайти потрібний розмір. А може поговорити з дружиною про бюджет. А може взагалі вони ще не потрібні? Як це перевірити? А який виробник гарний? І так далі. Поки не будеш точно знати — що далі робити.

(До речі, це відчуття оманливе, та його в собі ще потрібно виплекати. Як легкий показник — якщо щось не робиться певний час — спитай себе: чи є обʼєктивні причини відкладати, або “руки не доходять”? В другому разі шукай невизначеність.)

(Ще один гарний критерій - чи можу я доручити цю дію комусь іншому? Якщо ні - значить, не все ще вирішено.)

Звісно, щоб не ходити по колу, всі ці відповіді варто записувати хоч кудись. Тоді буде зʼявлятися визначеність та впевненість. Навіть без всякого GTD можна завести звичку брати аркуш (чи текстовий документ) та проводити інтервʼю сам з собою. А ще й заготувати список питань заздалегідь.

В програмуванні такий підхід особливо потрібний, бо в нас “думати” та “робити” тісно повʼязані. Можна сказати, що на кожному рядку доводиться щось вирішувати. Але в таких дрібних рішеннях немає проблеми. Зате варто продумати: спочатку перелік вимог, потім з нього — загальну архітектуру, потім — план виконання. І на кожному з цих етапів будуть виникати питання, які здатні повністю загальмувати наївну розробку в лоб без продумування. Без цього сидиш тиждень, дивишся в порожній екран та не можеш написати ані рядка. Проблема не в натхненні — а в невизначеності на одному з рівнів. Знайомо?

Продумати справи до кінця звучить красиво, але як це зробити? На практиці часто опиняєшся в стані, коли в голову нічого не йде. Особливо із тими проєктами, які вже застрягли та не рухаються. Але і з новими теж буває що думці нема за що зачепитися. Власне, так потім і опиняєшся з задачами, які наче потрібні, але навідсіч непідступні.

Отже, я для себе збираю потроху список питань, які освітлюють той чи інший аспект справи. Це не анкета — не потрібно відповідати на всі з них. Достатньо знайти ту відповідь, яка зсуне справу з місця. Ну або переконає відмовитися чи пересунути на пізніше — це теж гарний результат.

Ось поточний список. Ставиш перед очима назву наступної справи та медитуєш на нього. Сподіваюся, можна не казати, що всі відповіді треба записувати, щоб наступного разу не починати все наново.

• який очікуваний результат?
• чому я це роблю?
• яка тут більша мета?
• чому я роблю це зараз?
• чи є кращий час для цього?
• чи потрібно зробити це якнайшвидше?
• чи можна поділити проект на декілька частин?
• чого в мене немає?
• чого я не знаю?
• чого я не вмію?
• кого треба спитати?
• чого треба дочекатися?
• що треба вирішити?
• що треба виміряти, перевірити, знайти?
• чи є тут декілька наступних дій?
• чи можна щось перекласти на іншу людину?