从 2014 年 10 月正式购买 doit.im 服务开始，到现在已经续了两次年费了。 正好今天是 2016 年最后一天，坐在家里没什么事情，趁机回顾一下这两年实践 GTD 的心得，总结经验吸取教训，希望 2017 年能够完成更多事情，实现更多目标。
向着自由。
Goals, Projects, and Tasks
在开始长期的 GTD 实践之前，远至大学期间，我就学习过 GTD 的基本理念和方法， 也有过几次不太成功的尝试。 这些尝试不太成功的原因，除了我自身的懒惰散漫和缺少自律之外，最重要的， 我觉得是长久以来自己没有什么清晰的目标。
GTD 的字面含义虽然是完成任务，但完成任务的最终目的还是实现目标， 因此设计合适自己的 GTD 工作方式需要遵循的第一个原则，就是结果导向。 在整个大学期间，我的状态都是自由散漫、得过且过的，可能跟所学的专业并非心中所愿有关， 我感觉很长时间里自己都不知道要学习什么东西，将来要以什么作为自己的事业。 读研期间其实也是如此， 只是好在有导师指点方向和下发任务，才算是做成了一些事情，顺利离开了学校。
找目标本身花费了我很长的时间摸索和妥协，中间曲折就不多说了， 总之现在我终于有了一些大目标和一些小目标（并没有一个亿）， 可以在它们的指点下安排自己的日常。
在 GTD 实践中，像是人生目标这种远大的计划， 是不太适合直接作为 GTD 系统里的 Goals 的，毕竟什么时候才能在这样的 Goal 上点完成呢？ 想要通过 GTD 来实现的目标，要是尽可能清晰的，在一定时间内可完成的。 比如，"学会意大利语"就不太合适作为一个 Goal，因为"学会"是不太好度量的， 我不太好确定在什么情况下可以认为自己完成了这个目标， 而"通过 CILS A2 考试"就是一个清晰可度量的目标。 不过，很多时候目标也确实是没有什么清晰的度量标准的，我一般都会将一个目标分成几个级别， 比如"机器学习入门"，"Golang 进阶"等，大致到了什么程度认为自己完成了这个目标， 除了靠自己心里的评判标准，还可以看在这个目标下我可以安排什么级别的 Projects 了。 比如当我为"学习 ESLII"建立 Project 的时候，应该就可以标记"机器学习入门"为完成， 添加一个"机器学习进阶"的 Goal 了。
在一个 Goal 之下，会安排一个一个的 Projects。 到了 Projects 这个层次，每一个 Project 除了必须是清晰可完成的之外， 还要独立成单元。 比如，在"机器学习入门"这个目标之下，我安排了"西瓜书"这个 Project， 以及一些目前工作上相关的阶段性任务。 "西瓜书"这个 Project 就是通读这本书，看懂书中所讲机器学习工具的基本原理， 了解推导过程。 因为是第一遍通读，我要求自己不在看不懂的推导上太纠缠， 现在看不懂的内容记下来以后再安排，以此来保证进度。 工作中的阶段性任务就更清晰了，一个功能模块就是一个 Project， 上线稳定运行就是 Project 完成。
每一个 Project 都会分解成 Tasks，Tasks 是实践 GTD 最基本的执行单元， 是要每天来推进的一点点进度，它必须是短时间可完成的。 一般来说我安排的每一个 Task 时长都不超过 2 小时， 不过也有例外，比如今天下午我计划专注开发某一个功能，那么可能我会安排一个 5 小时的 Task，中途按照自己的专注情况自行休息， 甚至插入一些临时来的小需求（虽然极度不喜欢这种被强行打扰的情形）； 或者某个周六我打算搞定一个公开课的 Assignment，那就直接安排一个 All day 的 Task。 为了保证可执行，一个 Task 的时长一定不能长于一天， 否则你就应该考虑把它拆解成多个 Tasks，甚至一个单独的 Project 了。
从时间跨度上看，一般我安排的 Goals 大概都是以年为单位来完成的，至少也是半年左右， Projects 一般在几个月、几星期或几天，而 Tasks 则是小时级别。
上述完整的任务结构，也对应了按照长期、中期和短期拆分目标的工作方式， 可以帮助我理清思路，减少焦虑，从小处着手一步一步完成大目标。 然而并不是每天我们需要做的所有事情都需要组织成一个 Project， 也并不是每一件事情都对应了一个长远目标。 以前，我只把工作和学习相关的任务加入 GTD 系统，都可以按照上述三个层级来管理。 前段时间我把生活中的琐事也加了进来，这些生活琐事一般都是一个单独的 Task， 比如"去车管局换领新驾照"这类事情，没有相关的 Goals 和 Projects。
熟悉 GTD 方法的同学可能会看出来，我基本没有提到 Contexts 这个功能。 我觉得这可能跟我的工作有关。 作为一个程序员，我的工作生活情境非常简单， 大部分工作、学习都在电脑前完成，Online 几乎是一个必备条件，而不是一个特殊情境。 此外我会把工作带回家，也会在公司闲时学习自己的东西， 因此 Office 和 Home 主要是区分这个任务是工作任务还是学习任务的， 起不到按照情境过滤 Tasks 的作用。 也就是在我把生活琐事加入 GTD 系统之后，我才开始使用 Errands 这个情境标签， 但也仅限于标记一下任务属性而已。 Contexts 这个功能，我觉得可能适合于商务、销售、行政等方面工作的同学吧， 对此我并没有太多经验。
Today, Scheduled, Next, Someday, and Waiting
Tasks 规划好之后，就可以安排到具体的时间来执行了。
一般我喜欢在创建 Tasks 的时候就尽量把它安排到固定的时间， 也就是 Today 和 Scheduled（包括 doit.im 提供的 Tomorrow）这些 Boxes 里面。 Next 也是我常用的 Box，没空做详细安排的时候，我就先把一件事放在 Next 里， 一般没事儿可做的时候，或者每周做 Review 的时候，我都会浏览 Next Box， 要么搞点事情出来，要么把这些事情安排个时间。
不过，虽然时间安排的很好，我却经常估计错一件事情所花费的时间。 程序员们想必都懂，这个事儿看起来好像十分钟就能搞定，实际干下来却折腾了一下午。 所以我需要经常调整具体 Tasks 的时间安排， 比如把因为前一个 Task 延期而没能开始的 Task 丢进 Next Box 之类的。 看起来有点费时费事，不过我对我的强迫症已经弃疗了， 还是让我继续享受每件事都安排到小时，一切看起来井井有条的快感吧。
目前看来，Someday Box 完美解决了我好奇心强，对什么都感兴趣，啥都想试试的毛病。 之所以说这是个毛病，是因为单纯凭借一时好奇而开始的事情，容易被我半途而废， 从而并不能在这个事情上达成可观的成就。 这也就是我们常说的三分钟热度，因为短暂的好奇心，我"接触"过很多新奇的技术、技能， 但都因为失去热情、忙忘了等原因，停留在"接触过"的层面，而不能作为我技能树的一枝。 人的精力是有限的，因此现在我设定一个 Goal，开启一个 Project 的时候， 都会考虑自己的精力安排。 不过我总归还是好奇星人，日常接触到的很多新的、好玩儿的技术、技能， 还是免不了感兴趣，这时我就会把它们安排到 Someday Box 里面 （当然，一般都是先加入 Inbox 里，每周 Plan 的时候把这类事情丢进 Someday）。 这样，到了 Review 的时候，一些 Someday Box 里的东西可能就会直接被删掉了， 就像 JVM 的 GC 一样， 长期留在 Someday Box 的事情也可以在适当的时候建立 Project 来完成。
最后是 Waiting Box，一般需要等别人配合、等待某个条件成熟的 Tasks， 我会放进 Waiting Box，设置 Reminder 回来检查，或者每周 Review 时候检查。 这个 Box 的功能是比较显而易见的，也就不多说了。
Inbox, Plan and Review
一般来说，我的日常就是打开 doit.im，一一完成 Today 里的 Tasks。 每完成一个 Task，我会在相应的 Project 底下添加下一步的 Task， 并且安排到将来的某个时间，或者丢进 Next Box。 例如，假设我刚刚完成了 "The American Accent Course DVD2"， 那么我会立刻添加 "The American Accent Course DVD3" 这个 Task，并且安排时间。
Inbox 则是一些临时想到的主意、突然接到的任务（不需要立刻完成的）等。 Inbox 在 GTD 系统中的中文名叫做收集器，顾名思义，有什么想法都可以随时加入 Inbox。我在电脑前的话就会使用 doit.im 的 Mac APP， 不在电脑前的话使用手机版 APP 也很方便。
有了详细的安排之后，除了一往无前的执行，还需要经常性的回顾和校正，才能准确实现目标。 Plan 和 Review 是 GTD 系统里面重要的一环，并且在我这里，Review 大于 Plan。 我在 doit.im 里设置了两个周期任务，Weekly Review 和 Monthly Review， 分别在每周五下午和每个月最后一个周五下午来进行，如图。
Weekly Review 中的这些内容是我按照网上一个 GTD 文章中的建议设置的， 实践中，一个 Task 小于两分钟的时候很少，一般这种事情我都不加入 GTD 系统里， 或者加入当时就搞定了。
Monthly Review 时，则需要检查一下目前的 Projects 完成度，Goals 是否还合理， 并且再次检查 Someday Box。 这些 Review 都不会花很长时间，我一般会在 Weekly Review 的时候做一下下周的 Plan， 尽量满足自己的强迫症需求。
至于 doit.im 自带的 Daily Plan/Review，我反而觉得作用不太大， 我一般都是在 Review 的框里写下类似今日总结的一句话，不过 doit.im 并没有一个类似于 Timeline 的功能，如果有的话， 偶尔看一下自己的每日总结应该也是挺有意思的。
总结
虽然也遇到过不少问题，但总体上我认为我这两年多的 GTD 实践是有效的：
- 首先，GTD 系统极大的减少了任务繁杂时的焦虑感。
之前在数据平台工作的时候，作为 Issues 接口人，经接到大量的待处理 Issues。 当一堆事情向你涌过来的时候，如果没有合理的安排，焦虑感是难免的。 然而事情再多，一个人一个时间也只能做好一件事情，这方面，并行是低效的。 因此，按照优先级将这些 Issues 列入 GTD 系统之后， 我在一个时间只需要专注于一个 Issue，这极大的减轻了我的焦虑感。
- 然后，GTD 系统帮助我完成了一些事情，锻炼了持之以恒这个技能点。
在 2016 年里，我把 Scala 和 Golang 加入了我的语言技能树； 学习了 Docker 的前前后后，搞了几个 on Docker 的项目，并且开始深入源码； Spark 方面因为工作调动没有深入源码，不过使用起来也比较自信； 机器学习技能也正在逐步学习，这也是我 2017 年上半年的主要目标。 对照我 2016 年初在 FutureMe.org 上写下的年度目标， 完成度大概有 62.5% 吧。 此外，我维持了每天在乐词上复习英语单词，以及在 Duolingo 上打卡意大利语的进度。 2016 年我还没有把英语和意大利语的学习加入 GTD 系统里来， 今年我计划为它们都包含进来，特别是意大利语，学习完 Duolingo 的课程之后， 后面可能需要系统性的学习才能进一步提高水平，我认为 GTD 系统在这方面是能够帮助我的。 不过像是乐词、Duolingo 上面的学习，因为是要利用碎片时间，我觉得还是不用 GTD 系统管理为好。
以上一段写到这里，作为顺便离题的一个 2016 年的小结吧。
我的 GTD 系统基本上是围绕 doit.im 来实现的，我很喜欢这个软件， 简洁且完整，功能强大并且易用。 此外，早期我还用过纸上的 GTD 系统，中间也了解过八页小书这样的东西， 这类小型的 GTD 系统多少都能够满足我的需求。 当然，这可能跟我目前的位置有关，作为一个基层程序员，工作情境比较简单， 一个简单有效的 GTD 系统帮助我理清思路、完成任务就可以了。 当处在在一个更高的职位上时，比如技术管理岗位， 可能就需要处理更多沟通、协调之类的事情，这样简单的 GTD 系统也许就无法满足需求了吧。 这方面我也没有经验，不过磊叔就在使用传说中的 OmniFocus，相关的体验可以问他。 虽然工具并不是最重要的，但是趁手的工具确实能够让人更加专注和高效。 新的一年来了，开搞吧。
