两年前，在经历了几个月的拖延之后，终于看完 《Getting Things Done》这本书，还写了一篇总结：《GTD 入门笔记》。
经过两年实践的今天，再看这篇总结的时候，感觉十分啰嗦而且没有点到要害，加上这段时间以来有了一些新思考，精简优化了流程，感觉是时候重新聊聊 GTD 这件事情了。
有必要「GTD」吗？
要谈及时间管理，那么 GTD 肯定是绕不过去的方法论，大量的教程、工具、事例解读，使得 GTD 有被神话的嫌疑。但是，是否真的有人想过：「有必要在自己的生活中引入 GTD 吗？」
其实，GTD 的实践过程中需要养成大量习惯，任何一环的缺失都会导致系统崩溃，是一种非常重的管理手段，对于大部人来说，GTD 太重了。
在大部分情况下，如果只是目前手头有点忙，需要找个地方记一下，那么记事本就够用了，每天写写要做的事情用来提醒自己，「清单」足以应对一时忙碌。
如果只是突然有一个比较大的 Project，担心不能思考周全，或者怕做事情有遗漏，那么脑图就够解决问题了，梳理现状、划分关键路径、计划执行方向，并形成一个相对系统的可行方案。
如果发现每天要做的事情都有十几条，而且还需要多线开战并发推进，每天都感觉有永远做不完的任务追着自己，甚至 Deadline 悄然来临，时常加班救火，那么这时候才需要考虑把 GTD 用起来了。
当然😂，如果事情完不成只是因为拖延症的话，试试番茄时钟吧，GTD 真没必要。
GTD 的局限性
很多尝试 GTD 的人都有一种幻想，仿佛自己用了 GTD 之后一天就变成了 28 个小时，任务完成顺畅如长江水一样滔滔不绝。
GTD 不是魔法，既不会使你的时间变多，更不会使得的完成任务时效率变高。而是恰恰相反，GTD 系统本身的运作也会消耗一些时间，消耗部分精力。
“get things done” 这件事有着无数的影响因素：当前做的任务是否艰巨、自己的状态是否充沛、有没有同事突然拉你去开个会。 GTD 系统本身在这些因素中是最无关紧要的一环。
类比的话，GTD 类似于操作系统中的进程调度器，调度器通过各种调度算法来判断当前应该由哪个进程享有 CPU 的执行权。调度器本身既不能提高 CPU 的性能，也不能降低进程的计算量，甚至调度器自己还会占用 CPU 资源，但可以通过合理分配执行顺序，却提高整体吞吐。
我的 GTD 实践
一个完整的 GTD 流程由收集、处理、组织、回顾、执行五个步骤组成。其中前四个是 GTD 系统主要的维护成本。
虽然很多地方会把这五个阶段按顺序串起来展示，但是在实践过程中，这几个步骤是并行进行的，下面来说下我是怎么实践这几个步骤。
收集阶段
收集阶段正如其名，就是将所有想做的事情扔到一个收件箱中。收集的事情先不着急去完成，在实践中，只要不是需要我「do it right now」的事项，我都只是把他们扔到收件箱不管了。
有几个原因，首先，既然不是着急的事情，那么拖到下一个流程再考虑也无所谓，而且目前过多思考新的任务，肯定会打断当前做的事情，不要考虑太多，记一下上下文截止日期等，扔进收件箱不要再关心了，大脑作为一种湿件（Wetware）上下文切换是很昂贵的。
其次，因为事情已经进入系统了，只要系统还在正常运行，不会出现任务被遗忘的情况，既然整个系统都在掌控中，为啥还要急于一时呢，会有下一个阶段来处理这些事项。
当然，突然被打断也是很常见的场景，进来了一个优先级非常高的事情，如果目测是一个长时任务，除了会立马切换状态来应对这件事之外，一般我也会在收件箱新建这个任务，立马「组织」并扔到当日列表中，这样做的考量是让任务可以被追溯，如果这个紧急事项在处理过程中再度升级（比如发现需要很多前置依赖卡住了，或者意识到这件事一两天都不一定解决的掉），便可以利用这个任务进行后续跟踪和推进。
对于我来说，因为我的 GTD 系统是我非常信任的一个体系，我知道任何记录在内的东西我会时常回顾跟踪，因此我不仅会记一些「任务」事项，只要是觉得有必要得到一个结果的事情，我都会及时扔到收件箱里。比如突然间的灵感，听大佬们聊天 get 到的不了解的名词，一些不成气候的小想法等。
处理 & 组织阶段
在收集阶段会在收件箱中收集了大量的信息，而处理阶段做的事情就是避免信息在收件箱中堆积。这点非常重要，虽然收件箱是所有事情的入口，但是如果大量的事情堆积在收件箱中，会让事情失去优先级，更难挑选下一步要做的事情。因此处理阶段要做的就是把收件箱里所有的事情进行梳理。
在我的实践中，处理阶段和组织阶段进行了合并，除了将收件箱清空之外，还顺带这将任务组织归纳。这个阶段我会每天进行一次，一般是到公司之后做的第一件事。
处理时从收件箱开始，一件一件的处理，判断这件事是否可执行，是否需要分成多个阶段执行，是否存在外部依赖，是否作为未来打算，而不着急近期执行。
「是否可执行」这个标准虽然看起来很滑稽，不可执行在 TODO 里干啥，但是事实上有些任务的完成标准非常模糊，比如「了解 GTD」这个任务真的可执行吗？那怎么算完成呢。因此需要确定是否可执行，完成的标准是什么。并对一些信息、描述进行补偿。
有的任务看起来一两句话就可以描述，比如「使用 Gitlab 实现 Blog 的 CICD」，但是要做的事情很多，需要对任务进行细分：
- 看一下 gitlab-ci 文档
- 完成 Blog 的 Dockerfile
- 尝试使用 Gitlab 构建 Blog Image
- 编写发布脚本并配置在 gitlab-ci.yaml 中
因此需要创建一个 Project 来跟踪这件事情，把大任务细分为小任务算是门艺术了，我一般是以关键路径的节点进行细分，在细分的过程中即是对这个任务的初步思考，又是形成一个初步的执行方案，算是对事情的推进迈出第一步。
当然，细分成小任务还有一个额外的好处，就是可被调度的粒度小了，虽然近期没有大块的时间挤出来搞「使用 Gitlab 实现 Blog 的 CICD」，但是「看一下 gitlab-ci 文档」这种任务的时间还是比较容易挤出来的。
如果有的任务有外部依赖，或者短期内不会考虑，仅作为中长期考量，我一般是按项目进行组织归类之后，打上相关标签，等到「回顾阶段」再次评估。最近的工作中遇到的外部依赖越来越多，我也会定期的去催一催外部依赖的进展 ╮(╯▽╰)╭。
另外，在处理阶段「两分钟原则」非常重要，如果收件箱里的事项两分钟内就能完成，那么就立马去做，不要再走后续的流程了，因为这个任务的后续维护耗时说不定都不止两分钟。
回顾阶段
回顾是一件非常容易被忽视但却非常重要的阶段，很多任务堆在 GTD 系统中，随着时间的推移，可能一些当初不是很成熟的想法现在已经有推进的机会，有些仿佛可以做的事情，现在已经没有必要做了。
回顾是给了一个审视堆积任务的机会，也是一个兜底的阶段。发现当下可以投入精力的任务，准备排出精力来去完成，清扫已经没有必要再执行的任务，清出系统，没有必要在去想这件事情。
回顾的周期一般以一周为单位，我一般会在周五写周报的同时拿出几分钟来做这件事情，如果用 OmniFocus 这种本身就支持回顾的软件，便可以更灵活的设置回顾。
执行阶段
执行阶段是最容易产生疑惑的地方，早期接触 GTD 的时候，除了看《搞定》之外也看了大量别人的实践总结，但是得到的主观感觉是大家都在讲保持系统运转，而没有讲事情是怎么执行的。
对于一个时间管理系统，执行是最重要的事情。《搞定》中有一个「下一步清单」，来记录当下应该做的事项，每次执行的时候都从这个清单中读取下一项就可以了。在我的实践中也是参考了这个清单，不过我叫「本日清单」，里面列了我今天要做的事情。
GTD 的各个阶段的目标和行动都非常明确，我觉得最大的艺术就在于「下一步清单」怎么创建和维护，我们已经在任务执行前做了很多工作，这个清单就是临门一脚。明确了今天要做什么，是保持专注和分配精力的基础。
日常实践
已经按照 GTD 的要素分别讲解了每步要做的事情，现在来说明一下我是怎么实践的。我的实践不一定规范，但是对我自己却十分受用，仅供参考。
首先是我组织任务的方式，我基本是按照一个二层目录的结构来组织，总怀疑层级太深会容易找不到任务。
第一层是任务的大类，第二层就是具体的 Project。
GTD 理论分了很多阶段，不同的阶段要做不同的事情，期间要养成大量习惯，早期为了偷懒，索性就建立了 CronJobs 这个分类，把需要维持系统运行的任务以周期任务的形式放在里面。这样我只需要养成一个习惯就好了：到公司之后先过一下 CronJobs。
后来发现这种安排十分好用，以至于只要是周期性的任务，我都会扔到 CronJobs 里，现在已经有了很多分类，而且已经不止是 GTD 系统维护任务了。
在 Morning Review 中，清空 OF 收件箱就完成了「处理 & 组织阶段」。分别从 「本周」、「近期」里挑选今天要做的事情，便完成了「本日清单」的创建工作。最后梳理一下「本日清单」配合今天的精力情况分一下轻重缓急，剩下的就是从「本日清单」中拿任务开干了。
在 Weekly Review 中，回顾上周完成的任务，并根据完成的任务记录周报，一般工作中的周报也可以从「已完成」列表中整理出来。「任务检查 & 畅想下周」便是一次「回顾」的好时机，简单浏览下系统中遗留的事项，想一想是不是要提上日程。
每个月初我还会进行一次回顾，挑选一下这个月应该完成的事情，打上「本月」的标签，而每个周天都会来回顾这个标签的内容，确保能正常推进。当有一些非工作但是很重要的事情需要进行时，这是一个很有效的办法，毕竟非工作的事情没人催你进度。我一般通过这个来催着自己把某个专栏或者某本书赶紧看完。
最后还有两个非常常见的疑问，一个是这套系统非常的「自嗨」，如果中间有人打断你，比如突然把你拉进去一个会议中，一个下午就过去了，该怎么办？
前一段时间看到一篇文章（《SET 法则：过好每一天的时间管理之道》）其中讲到了如何面对现实的干扰与变化，简单来说，就是不用对「本日清单」抱着必须完成的决心，要知道一天中的时间是有限的，如果遇到外来因素的障碍导致花费了很多时间，那么需要对「本日清单」再次评估，把做不完的事情移出去，或者推迟到明天。当然如果真的很紧急，那就只能加加班了。
如果经常遇到 “只能加加班了” 的情况，自己也应该去反思给任务提前预留的时间是否充足，比如在开发中，需求总是来的很匆忙，是不是自己去了解需求时不够主动，是否能更早的了解场景，提前预判。
第二个问题是 GTD 系统会额外耗时多少，大部分讲 GTD 的文章冗长的吓人（包括本篇文章），其实只是细节比较多而已，但是这些都不重要，很多细节还是靠自己打磨一遍才清晰。早期的耗时可能比较多，而多的原因并不是 GTD 本身，而是任务划分不合理，经常发生 Project 的结构性变化，我倒是更认为是项目管理做得很差，无法合理的划分子任务导致一团混乱。
到了对任务管理有比较清晰的认识之后，基本没有什么时间消耗，目前我每天基本五分钟以内就能完成所有 Morning Review，甚至还遵守「两分钟法则」迅速 close 了部分任务。
GTD 系统的信任危机
GTD 系统的信任问题可能是前期最大的障碍，也是导致系统崩溃的最大原因。所谓的信任就是我们知道所有要做的任务都已经被托管了，不会去反思 “我还有啥事没做来着？”。
但是自己是很难欺骗自己的，如果遇到几次紧急的任务 GTD 系统中没有记录，或者记录了但不小心忽视了，那么你就很难相信 GTD 系统，会经常问自己除了「本日清单」里，还有什么事情没有做。这时候信任危机就产生了。
如果对 GTD 系统产生了不信任，那么系统崩溃也就是时间问题，越来越多的事情不会被托管，越来越多的事情又回到了靠「记忆力」来维持的情况。而让大脑保持太多的缓存，只会产生焦虑和惶惶不安。
应该怎么保持对 GTD 系统的信任？首先是收集阶段，要确保所有的事情都被记录，甚至可以和我一样，直接把 GTD 收件箱当临时笔记本，需要让大脑记忆的东西都扔进去好了，而且现在很多软件都有手机 App，做到及时记录已经很简单了。
其次是做好回顾阶段，回顾是对系统的兜底，不然 GTD 系统就是一个大的任务冰箱，成了一个储物间而不是辅助任务不漏的工具。
最后
最后，有两件事情要强调。第一，GTD 的实践过程中需要养成大量习惯，并要消耗精力经营系统以保持良好运行，如果疏忽中断便很容易导致整个系统的崩溃。不过，虽然崩溃很容易，但如果想重新捡起来也很容易，重新做一次收集，将所有的事情托管其中，整个系统便又恢复了。虽然我现在已经好久没有出现系统崩溃的情况，但实践早期，崩溃还是时有发生，只要不放弃，终会趋于平稳。
第二，GTD 虽然是一个自带光环的方法论，但我并不推荐唯教条是从，是否真的需要 GTD，是否需要对方法论进行剪枝，我认为可以灵活一些，想清楚最终的目的是什么，只要能辅助事情有序向前推进，任务不漏不误，不要太在意够不够 「GTD」，或者这套另类实践有没有炫酷的字母缩写。
