对于 GTD 的进一步思考

2020/04/30 21:31 PM posted in  坏笔记不如好记性

两年前,在经历了几个月的拖延之后,终于看完 《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」,但是要做的事情很多,需要对任务进行细分:

  1. 看一下 gitlab-ci 文档
  2. 完成 Blog 的 Dockerfile
  3. 尝试使用 Gitlab 构建 Blog Image
  4. 编写发布脚本并配置在 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」,或者这套另类实践有没有炫酷的字母缩写。