GTD之我见

    GTD对我来说是一个比较新鲜的词汇。这个词汇到底应该怎么理解，还是比较难得描述的。这个词汇的来源，是一本书的名字，《Get Things Done》。作者Allen在这本书中介绍了一种时间管理的思路。通过这几天的学习研究，我发现世界上有好多GTD Fans。在Google或者百度上搜索GTD，有大量的文章和帖子在介绍，我就不重复了。这书名有几个常见的中译名：《无压工作》等等。

    这些都不是关键，关键是GTD到底是什么意思？下面就说一说本人对GTD的理解。

    简单地说，GTD就是一种思想，一种关于时间管理的思想。

    我们每个人在日常工作和生活中，会随时产生各种想法，会被别人要求/邀请/命令/委托去做某件事情。这些东西，在GTD中通通被成为“Stuff”。Stuff一词，我想翻译成“材料”是最妥当的，因为“材料”一词在中文里面就有“精神”、“非物质”层面的含义，最典型的就是“文字材料”。每当有新的Stuff出现时，人们应该做的事情就是把这个Stuff放入到In Box中。

    In Box的标准翻译是“收件箱”，但是此处的in box和我们平时说的Email系统中的收件箱还不是一个意思。这里的in box其实就是用来“装”stuff的容器，在不同的时间管理系统中，in box的外在形式也不同。例如，我们可以用一个文本文件将stuff都记录下来，那么这个文本文件就是in box。又例如，在非IT的传统办公环境中，装文件的多层文件托盘就是in box。如果有人走进你的办公室，交给你一份材料说需要你的签字，你自然会将这份材料快速浏览一遍（或者听来人简要介绍材料的主题），然后最通常的做法是将材料放入办公桌上的文件托盘中。当然，我看到很多人的显示器上贴满了五颜六色的便签纸，仿佛是那显示器挣扎着从纸堆中把脸露出来一般。其实，那显示器也就充当了in box的作用。

    故事还是从in box开始的。在in box中的stuff是需要我们进行的处理的。要处理它，我们首先要进行一个判断：这个stuff是一件可以采取行动的（actionable）东西吗？如果是，那么我们当然需要策划一下具体的动作（action）；如果不是，那么这个stuff仅仅只是一个想法而已。花开两朵，各表一枝。我们先说后者。一个不能采取某种动作的stuff，只有三种可能：① 这完全是一个垃圾，不值得保留；例如Email系统所未能帮我们拦截下来的垃圾邮件。② 这是一个值得保留的想法，但是它要么是因为目前条件不成熟而无法采取行动，要么是因为我们主观上还没有“想得很清楚”而无法采取行动；例如，很多男人经常会出现的想法－－“最好还是能够把烟戒掉”。③ 这是一个很成熟的想法，但是它本身并不会引发/触发某种行动；例如，女人们从报纸上剪下来的介绍如何保持皮肤水分的豆腐块文章。

    现在回过头来，我们看看另外一枝花。如果stuff是可以引发一个/一系列具体action的想法/命令/委托，那么我们又需要来做一个判断：我们需要做的事情，一步够不够？如果一步还不够，需要很多步行动才能够完成，那么我们就不再GTD中关注它了，它已经变成了一个Project（项目）了。我们需要做的事情就是立项，然后按照项目管理的套路去处理它。如果一步就够了，我们也就自然想好了：我们的action是什么？然后，我们要看一看，这个action是不是能够在两分钟之内完成的？如果是，就废话少说，先去把它做完再说。如果两分钟之内搞不定，那就先不着急，看看谁去做最合适。是我本人吗？还是别的某个人？如果某个同事、某个同学、某个战友、某个合作伙伴、甚至某个邻居做起来比我更合适，那么就委托/命令这个更合适的人去做。当然，你把这件事情委托/命令他去做，你也应该有一个时效预期。你希望/要求他在什么时间之前帮你搞定。

    如果事情还必须是我本人去做，两分钟之内又搞不定，那么我们就只有自己干，但注意不是立刻就干！如果这个事情现在还不能开始，其前提条件还不具备，或者必须在某个日期之后才能够启动，那么我们就把事情记录在日历上备忘。如果条件已经具备，随时都可以开工了，那么我们就把这个事情记录在List of things to do中。

    说起来，还真有些绕口。不过，看一看一张图表，就非常容易搞懂了。

    这张图是本人按照自己的理解所绘制。与传统的GTD流程图有些区别。

    区别一，除了“Which type？”判断之外，其他的判断都只有两个选项：Yes或No。这样，思路就更加清晰。例如，当明确了only one step enough之后，接下来就评估这个action是否应该有“我”来做会更合适（Shall I？）。如果有比自己更合适的人选的话，流程就直接转向了Delegate（委托）。如果的确更适合自己来做，那么还要看action是否现在就可以开工（Can start now）。如果必须要特定的日期/时间才能够开工，那么就把这个action放到日历中去，设置提醒即可。如果现在就可以开工，那么还不能急着卷起袖子就干。只有在两分钟之内就能够干完的action，才适合立刻去做，否则就先记录到待办事项清单（List of things to do）中。在传统的GTD流程图中，一个“what's the next action”判断之后，就有四个分支，而且四个分支的条件关系并不并列。这样，不太利于理解。

    区别二，我总结了按照GTD流程处理之后，stuff的八种“归宿”。这八种归宿是：1 形成project；2 形成delegation；3 形成things to do；4 形成calendar； 5 do it；6 作为垃圾扔掉；7 形成someday/maybe；8 形成reference，放到知识管理系统中去备查。其中，“do it”和“作为垃圾扔掉”两个终极项没有后续步骤之外，其他的6个都有后续步骤。

    接下来，我介绍一下我对这个“后续步骤”的思考。

1. 形成project。当stuff流到了project那里去了之后，我们该怎么办呢？难道就不需要日历了吗？在认真考虑之后，我认为这个时候就需要另外一套思路/系统来帮助我们了，那就是大家耳熟能详的“项目管理”（Project Management）。传统的项目管理，当然也会涉及到时间的安排。我想，这里所说的项目管理，应该是剥离了时间管理的剩余部分。这剩余部分，直白地说，主要也只有“任务的分解”了。把任务分解成若干个single step action，然后再把最上面的一个action回流到GTD流程中来，我称之为“Review For Next Action”。
2. 形成delegation。当stuff流到了delegation之后，委托方和被委托方都应该明确一个共同的时限，“什么时候要交活”。作为委托方，到了这个时限也是应该去Check/Review这个delegation是否完成的。所以，当形成delegation之时，我们就应该把这个时限放到自己的日历中去，我称之为“mark the check date/time”。所以，“形成delegation”这个归宿说到底还是流到了“形成calendar”了。
3. 形成calendar。calendar最大的特点就是有提醒，到了时间就会提醒我们应该做什么。现在的calendar都是电子的/软件的，所以这个无需多言，只是要记得要把提醒功能打开，并最好能够确保自己届时能够收到提醒消息（例如把calendar item灌到自己的手机中，或者自动发送到QQ/MSN或者Email in box中）。
4. 形成things to do。我最初认为这个things to do是多余的，与其专门设置一个list of things to do，不如直接把这些item放到calendar中。后来再思考，发现并非如此。我们观察一下things to do的形成就知道，这些item都是“自己做”、“可以立刻开始”，但是所需时间要“超过2分钟”的。这个时候，把这些item排到calendar中，反而是多余的。只要手头没有事情（两分钟之内可以搞定的事情已经没有了），就应该立刻处理things to do，从list的第一项到最后一项，一项项地去做。在GTD的原文中，这些事情有一个共同的属性，叫作ASAP（As Soon As Possible）。这里的possible，只是专门讲“手头有没有在两分钟内可以做完的事情”，并不涉及其他的前提条件。如果其他的前提条件还不具备，那么这个item就不应该放的List of Things to do，而是应该放到calendar中。所以，只要当我们自己觉得“无聊”、“没事可干”的时候，我们就应该去按照List of Things to do去做，把这里的Item变成Do it。
5. 形成Someday/Maybe。这些item的共性是，本身并不需要采取什么动作，或者只是一个很初步的想法，还很不成熟。说到底，这些item和stuff本身没有什么太大的区别。我最初认为，当stuff成为了item of someday/maybe之时，我们需要为它设定一个review date，提醒我们把这些item当作stuff再回炉走一遍流程。声望颇佳的ThinkingRock软件就是这样设计的，它把这个概念叫作tickle date。再细想，这个tickle date虽然没有什么坏处，但是操作性不强。因为位于someday/maybe的item本身就有很大的不确定因素，所以这个date也很难确定，或者很不准，从而使其意义不强。更有现实指导意义的是，定期review一下这些item。Review之后，这些item（实际上就是stuff）的归宿依然无非是上述的八种。这个定期，可以是天、可以是周、可以是月，可以是季，可以是年。但是我个人认为周、月是比较恰当的周期。
6. 形成reference。Reference其实和someday/maybe很类似，区别无非是前者的想法已经很成熟了，但是现在用不着，放入知识管理系统中备查备考。如果说，someday/maybe强调的是定期清理，那么reference则强调检索。当然，定期review一下也没有什么坏处，温故而知新嘛。只是知识库中的item只进不出，越积累越多，review一遍也可能会耗费太多时间，不太现实。所以，检索重于回顾。

    至此，stuff的8种归宿都介绍完了，特别介绍了6种非终极的情况。归纳如下。

    一，当有了想法或者接受到委托之后，立刻将它放入In box，这个事情不要拖延。如果担心占用时间的话，可以利用一些更“时髦”的手段，例如录音或者照相。

    二，当自己觉得无聊的时候，无所事事的时候，也不要发呆。首先检查List of things to do中是否还有item。如果有，则do it；如果无，则清理in box。如果list of things to do和in box都是空的，那么就犒劳一下自己，看碟片、打游戏都可以，甚至睡觉或者开车出去兜风。

    三，有些事情是需要定期回顾的。每到周末或者月底，我们需要一个不漏地review。这些Item分布在someday/maybe、reference、project management中。

    四，对于in box而言，是要做到每日清理的，日清日毕。这个原则不坚持，一切都是白说。有些说教者在那里宣称“每天的事情每天做完”、“不要把工作留到明天”。这些说法未免太大了，不现实，但是每天把in box清理完毕，是完全可以做到的，具有很强的操作性。

    最后，我还想谈一谈GTD的局限性。网上很多的文章和帖子都在赞扬讴歌GTD，鲜有批判的。但是任何事情都有利有弊，GTD也不例外。GTD作为一种时间管理的思路，和传统的时间管理思路最大不同是，GTD不再谈什么事务的轻重缓急。传统的时间管理思路认为，事务要按照紧急程度和重要程度进行划分，划分为四个象限。重要且紧急的，当然优先处理。不要重又不紧急的，当然是最后处理。在“重要不紧急”和“紧急不重要”的两个象限中，传统的时间管理思路更提倡前者。这一套理论，在GTD中统统都被抛弃了。GTD的原则是“两分钟”，只要是两分钟之内可以搞定的single step action，那么现在就开始做，否则就放到List of things to do 中去。我们当然不能否则轻重缓急理论。当然，如果我们认为GTD的两分钟原则更好的话，我们也可以把两分钟原则放在轻重缓急原则之上。也就是说，两分钟能够搞定的马上就去搞定，回过头来处理things to do的时候，我们还是可以遵从轻重缓急原则的。如果你认为轻重缓急原则比两分钟原则更重要，那么你就自己看着干吧。