← 返回目录


零收件箱原则很有必要吗?

学校≠教育≠技能;文凭溢价=80%信号传递+20%人力资本

37 👍 / 0 💬

问题描述

浏览过一些知乎上提到的邮件管理经验分享,很多人都提到了邮件要归档且保持收件箱为空。
我试着归档,把邮件放在不同类别的文件夹中,但感觉查找和搜索邮件时还是主要依靠邮件中的关键字,而归档文件夹貌似没有起什么作用。
既然客户端在全体归档文件夹中搜索邮件的速度和在一个大收件箱里搜索邮件的速度差不多,那收件箱还有必要保持0状态么?
谢谢解答!

必要,但不足够。

收件箱需要可靠的清空流程才有效

可靠的收件箱是强大的,因为它让我们闭合开环[1]并专注于工作本身,而无须注意元工作。

但有个故事似乎循环往复地出现:

  1. 你设立了新的待办事项清单。局势一片大好!
  2. 你添加新的待办事项,把完成的勾掉。一天天过去了。
  3. 有件事需要处理。把这件事添加到待办事项清单之前,你犹豫了一番:这件事可能会迷失在待办列表中找不到,而你必须把这件事办完。
  4. 因此,你为这件特别的待办事项写了张便条,没放在待办事项清单里。
  5. 便条越来越多。现在你又有了一个待办事项清单!
  6. 重复上述过程。

只有足够可靠的收件箱才能让我们闭合开环[1]——也就是说,往收件箱里面添加任务后,能够相信这些任务在其中停留合理的一段时间即能得到「处理」。「处理」是模糊的:你只需要觉得这些任务的处置大致反映了你的真实偏好即可。如果收件箱中 90%的任务都放弃了,但那 10%才是你真正关心的,那么这样的收件箱系统是值得信赖的;如果收件箱中 90% 的任务最终完成了,但那没有完成的 10% 却是你真正关心的,那么这样的收件箱系统不值一提。

在高效的收件箱中,保持这种信心可能很容易,因为完成率自然超过收集率。但大多数知识工作者的收件箱并不是这样的。这两个速率时常流变,这就造成了瓶颈。并非每项任务都需要处理,但很容易对处理能力过于乐观,所以任务逐渐积压。

有时我们可以降低收集率;例如谨防自动导入阅读收件箱[2]。通常完成率还必须提高,但很难;例如,见收件箱维护的分流策略(如「收件箱归零」)往往不够稳健[3]

参考文献

Matuschak, A. (2019, December). Taking knowledge work seriously. Presented at the Stripe Convergence, San Francisco.

链接至本文(已汉化)

本节摘自 @Thoughts Memo 的译文《收件箱需要可靠的清空流程才有效

收件箱维护的分流策略(如「收件箱归零」)往往不够稳健

收件箱需要可靠的清空流程才有效[4],而收件箱归零是确保流程发挥作用的一种方法。它通过积极提高流出率来,降低项目排队等候处理的时间(理论上为一天)。

Getting Things Done (GTD) 中,大卫-艾伦建议,你可以通过策略性延后、委托或放弃任务来提高代办队列的流出率。「收件箱归零」是 Merlin Mann 对这个建议的一个实现。它通过每天归零整个收件箱的方式,来确保队列的流出率得到充分提高。这个方法简单粗暴,但确实能保证流出率恒大于流入。

挑战

你必须对收件箱中每一个项目做处理,判断去留。成本上既巨大,也没有支付意义(除非收件箱比较小)

明确地点击「推迟任务」会带来不必要的情绪压力:只有在流入大于流出的情况下,「收件箱归零」才是必要的。如果流入率是波动的,时常低于流出率,你仍然可以在合理的时间范围内处理所有的事情,而不需要每日都归零。

明确地点击「放弃」很难,因为软件界面经常将破坏性操作作为最终决定,而不是视情况而定的选择[5]

而考虑方法的落地,「收件箱归零」通常会导致对推迟麻木:我们太容易把一个任务一次又一次地推掉。艾伦建议,人们应该定期进行自我反思性的审查,重新考虑那些被反复推迟的任务,但这些审查需要做更多的决定。长期使用可能很难坚持。

最后,以这种方式处理收件箱时,会有压力鼓励你简单地多这些任务,这可能不是你真正想要的。

机会

一个更理想的机制将确保等待时间保持在可容忍的范围内,但周期不一定非得是 1 天。我们还必须考虑要做的决定的数量。我宁愿做更少的决定,但容忍更长的平均等待时间。

一个可能的实例:间隔重复可以降低破坏性收件箱维护操作的风险[6]

参考文献

Allen, D. (2015). Getting Things Done: The Art of Stress-Free Productivity.

43 Folders Series: Inbox Zero | 43 Folders

Matuschak, A. (2019, December). Taking knowledge work seriously. Presented at the Stripe Convergence, San Francisco.

链接至本文(已汉化)

本节摘自 @Thoughts Memo 的译文《收件箱维护的分流策略(如「收件箱归零」)往往不够稳健

不应该设置多处收件箱

收件箱需要可靠的清空流程才有效[7],但做到这点很难。如果对应单一概念的收件箱(如「要读的东西」),在实体上却分散在许多不同的地方,可靠地清空收件箱更是难上加难。

可靠的收件箱要求流出率>=流入率,但如果一个收件箱分布在许多地方,就很难看到和管理这些速率(例如,通过放弃或推迟项目)。

一个解决方案可能是创建虚拟收件箱,为该概念收件箱的项目所在的几个「地方」提供一个统一的界面;见我的阅读收件箱实现[8]

链接至本文(已汉化)

本节摘自 @Thoughts Memo 的译文《不应该设置多处收件箱

声明

此内容发布由 Andy Matuschak 许可。未经允许,不得转载或修改。保留所有权利。


参考

1. 闭合开环 ./441969379.html
2. 谨防自动导入阅读收件箱 ./504979464.html
3. 收件箱维护的分流策略(如「收件箱归零」)往往不够稳健 ./438419831.html
4. 收件箱需要可靠的清空流程才有效 ./434717044.html
5. 软件界面经常将破坏性操作作为最终决定,而不是视情况而定的选择 ./439652714.html
6. 间隔重复可以降低对收件箱进行维护中破坏性操作风险 ./438631838.html
7. 收件箱需要可靠的清空流程才有效 ./434717044.html
8. 我的阅读收件箱实践 ./501627735.html

← 返回目录