2019年终总结

2019 年因为一次又一次的冲击，不断更新了对“自我”的认知。年终来看，仍然是一个“幸运”的人


这一年，看了31部电影，读了7本书

旅行（工作）上，去了首尔、东京、马尔代夫、迪拜、圣保罗、萨尔瓦多、里约热内卢、孟买、昌迪加尔、加尔各答、新德里这些城市，国内经过或经历了烟台、上海、承德、广州。2019年这些城市本身，生活在这些城市的人，在这些城市里我的经历，这些经历对我的冲击，开始塑造我，和我的’ego’

2018 个人总结

2018年是我很多年来第一次没有制定个人计划的一年，一方面是因为工作占据了太多精力，17年的总结都拖到了7月底才写完，另外一方面是这一年的工作和生活的方方面面，都面对着巨大的改变，回到2018年年初，只猜想这一年会对我很重要，但绝未曾想到这一年我所经历了这么多。

在19年初写完上面这一段之后，再打开这段草稿，已经是7月末的飞机上了。挤在737局促的座位里，突然觉得应该补完这个个人总结。回顾2018年，工作上换了一条业务线，被动卷入了一场声势浩大的互联网战争的局部战场；生活上主动结婚建立了自己的家庭，开启了一个新的个人阶段。除了这两个最主要的改变外，于现实生活和自我认知中，方方面面都出现了非常多的改变，有一些是身不由己的适应和拧巴，有一些是主动选择的改变与进化。给这一年选择关键词的话，我认为是“被动”与“主动”

工作上，虽然这一年一直在同一家公司，但是4月份业务调整前后，有着截然不同的状态。在当时来这家公司的时候，希望的是能够选择一个已度过风口的业务，追求去解决一些更成熟期，更接近商业本质的问题。在18年却进入了被大潮推着走的状态，一边建立对行业、对职能方向，对一个又一个新国家的认知，一边全力追着业务的发展，避免跟不上增长速度导致掉队。这家公司本身也有着非常强的特色，每一个在这里工作的人都一定会受到公司强文化的影响，追求可衡量的指标目标，追求脱离感情之外的客观判断，追求激进的工作方式和强势的沟通。

健康上，在17年大运动量后体重下降的基础上，因为缺乏运动体重开始回升，并且由于频繁的出差和极限强度的加班，神经全年持续处于紧绷状态，持续弥漫着挥之不去的焦虑感。

生活上，这一年我组建了新的家庭，和相恋十年的她领了证。这一年收获了许多惊喜，也共同经历了很多，不足为外人道也。

2018年，看了29部电影，读完了5本书。

在这一年里，因为做国际化的业务加上旅行，海外先后去了曼谷、普吉岛，东京，香港，首尔，悉尼，洛杉矶等城市，国内去了上海和昆明转机。前几年一直在努力去不同的国家感受不同的文化，很巧地在今年对职业生涯有了一点点帮助。这一年的工作里也会有主动和被动地去投入在理解生活在不同国家的人之间的共性和差异，也算是幸运地工作和兴趣相辅相成了。

2017 个人总结

因为春节出行和换工作后的突然加速，拖到了7月底才写完上年度的总结。其实很多事情记忆已经没那么清楚了。回看 17 年计划中的三个核心目标，基本都达成了，从这个角度来看 17 年，还是可以给自己打一个不错的分数。

年度核心目标

  • 工作上可以负责起更广的业务和更大的团队，使产品取得领先地位
  • 身体素质恢复到「健康」的轨迹上，体态得到明显改善
  • 在金融知识上有系统的入门学习和实际经验的积累

工作

在 12 月即将结束的时候，离开了 FellowPlus，加入了字节跳动。这一年里在 FellowPlus 打造了自己满意的产品，却没能帮助团队找到 Product-Market Fit, 是遗憾，更是深刻的教训。

健身健康

本年度一共有60天里进行了运动锻炼，其中包含 42 节私教课和 10 节 CrossFit Workout。这一年里，体重降低了 10公斤，自认为是一年中达到的最重要也是最有成就感的目标。

阅读

本年度共读书 17 本，和年度计划所相符的，是完成了金融/投资主题的系列阅读，和意大利主题的系列阅读。
这一年里有很多书是在跑步时听的音频版，充分利用时间的同时，跑步也不会觉得那么枯燥了。

写作语言

今年发布了一篇翻译文章，前后也用了几个月的周末时间断断续续去翻译而成。
虽然因为话题并不热门，点击量一般，但是我一直很认可这篇文章的内容价值。
为了旅行，学习了最基本的意大利语。在回国之后，基本只能记得「你好」「再见」，「谢谢」「抱歉」了。

个人提升

通过9-11月连续几个周末的努力，成功达成了拿到驾照的年度目标，拓展了在城市里的活动半径。

消费理财

完成了香港银行户头的开户，在港美股做了投资尝试以真实了解市场。在 Amazon 和腾讯上获取了长期的超额回报，在 Google 获得了微小的短期回报，在微博和陌陌的短线操作上都有不同比例的亏损。
这一年评选买的最值的商品，应该是 Airpods 和 Nintendo Switch。其他购买了值得推荐的设备有Kindle Oasis 、小米扫地机器人、坚果 Pro 2。

娱乐/旅行

在这一年里，去了芽庄、香港、罗马、佛罗伦萨、米兰旅行。有趣的是，年底换工作时的几个 Offer，都跟国际化方向有关系。希望对世界的好奇心，可以成为我持续前进的重要动力。

​

2017 个人计划

今年又是在下半年才完成全年的计划，尽管比前两年发出来的日期还早了将近一个月。

从去年年底开始全力投入的大版本更新直到五月方才尘埃落定，无论是工作上还是个人事务上，在稳定了一个季度之后，也终于得以进入一个可预期的状态。

其实像过去几年这样上半年全力以赴，下半年兼顾周全的节奏对于我也是一个还不错的选择。这篇计划的大部分内容在新年前就已经确定，这几天回顾一下上半年的进展，做了一些修改和增补，希望下半年可以因此更有的放矢。

年度核心目标

  • 工作上可以负责起更广的业务和更大的团队，使产品取得领先地位
  • 身体素质恢复到「健康」的轨迹上，体态得到明显改善
  • 在金融知识上有系统的入门学习和实际经验的积累

工作

  • 在核心业务上取得突破，打造一个在商业价值上和过程上都优秀的产品
  • 能够管理更大的团队，保障团队效率和流程严谨
  • 增强判断决策能力和对外合作能力

健身健康

  • 每周至少一节课的速度，完成两个月的私教课。之后保持至少每周一次的锻炼频率
  • 体重控制在 75-80 kg，体脂控制在 15% 以下
  • 体态问题能得到明显的纠正

阅读

  • 制定金融、互联网、意大利方面的三个书单并且完成计划
  • 在工作需要的方向上保持可以解决问题的阅读量
  • 继续有意识地增加纯文学类书籍的阅读量

写作/语言

  • 以力所能及的频率翻译对我有巨大帮助的英文文章
  • 学习基本的意大利语对话和单词语法
  • 学习日语或提升英文口语

编程/计算机科学

  • 在数据挖掘、机器学习方向上完成入门级别的系统学习
  • 写一两个 python 的小项目

个人提升

  • 增加对一级市场的了解，对股权投资有全面且深入的了解，建立完整的知识体系
  • 今年内拿到驾照

消费理财

  • 将消费预算拆分到更细的粒度
  • 为额外支出提前预留预算
  • 开始了解二级市场的基本知识，开户入市并尝试获得正收益

社交感情

  • 加强亲密关系的维护，预留时间和预算，主动联系、主动付出

娱乐/旅行

  • 1-2 次常规的年度旅行
  • 为过年期间陪父母出游做好准备
  • 在主机游戏外，再培养一个兴趣或者有益身心的娱乐方式

【译】一个列表看懂所有认知偏差

我常常会用到维基百科上的「认知偏差列表」这个条目。每当我目睹了某一种认知偏差在现实中发生，却很难回忆起来这个认知偏差的名称或者详细的含义时，我就会打开这个页面去寻找答案。这个可以帮助我发掘我思维中的漏洞的宝贵的资源，是我看到的最为全面又最简洁易懂的一个关于认知偏差的列表。

但是坦率地说，这篇维基百科组织得有点乱，许多年来我一直希望能够梳理清楚这个页面中的信息脉络。在这个页面里查找某一个认知偏差非常困难，更别提我常常在找到之后扭头就忘了上次看到的位置。我觉得这应该是因为在过去的十多年里已经有近千人先后编辑过这个页面，这使得它变得愈发庞大和冗杂。时至今日，这个条目里共索引了 175 种认知偏差，散落在几个界限模糊的分类中（例如决策偏误、社会偏误、记忆错误与偏误，等等）。而每个分类中又是生硬地按照英文字母来排序所有的认知偏差。甚至，还有很多实际意义差不多，只是名字不一样的认知偏差重复出现在不同的分类中。

在过去的四周里，我（Buster Benson）一边休陪产假一边深入地分析了这个列表，才终于整理了出一份更简单、清晰的认知偏差分类树。要不是这段时间里可以思索这些认知偏差之间的区别，我在哄孩子睡觉的时候可能早就无聊致死了。

我把这 175 个认知偏差都放到了一个 Excel 表格中，去重之后，将类似的认知偏差（例如怪异效应和幽默效应）或者互补的认知偏差（例如乐观偏误和悲观偏误）归纳到一组之中。最后，我从所有的认知偏差中归纳出了 20 组不同的思维机制，正是这些思维机制导致了所有的认知偏差的产生。

在种种尝试后，我最终又根据这 20 组思维机制所产生的原因，把它们分成了四大类。每一个认知偏差的产生都是有原因的，一般来讲都是我们大脑为了节约其时间或者精力。这四大类也正是我们大脑最起初想要解决的四大问题。因此这样梳理了所有的认知偏差并进行归类之后，我们也就更容易理解为什么会出现这些认知偏差，它们起到了什么样的作用，又导致了什么样的问题。

导致认知偏差出现的四个问题：

信息过载，信息的意义不明确，大脑来不及认真作出反应，以及大脑存不下所有的记忆。

问题1：信息过载。

这是一个信息大爆炸的年代，我们必须主动过滤绝大多数的垃圾信息。所以我们的大脑也有一些简单的原则来选择性地接收最有价值的信息。

问题 2：信息的意义不明确。

我们只能看到大千世界中很小的一部分，但我们仍然需要从这一小部分世界之中建立起每个人的世界观。在过滤了过载的信息之后，我们的大脑就会将所有的信息连接起来，脑补出这些信息之间缺失的细节，并通过这些信息不断更新我们的世界观与心智模型。

问题3：大脑必须立即采取行动。

我们无法控制时间，也不可能无所不知，但这不是能使我们停止思考的原因。人类之所以能生存至今，正是因为具备了在未知的环境中快速反应的能力。每当了解到一个新的信息，我们都会首先评估我们影响事态的能力，所有的可选的应对方式，并推测不同的决定会导致的后果，从而作出判断，或者立刻开始行动。

问题 4：如何对浩瀚的记忆做出取舍？

吾生也有涯，而知也无涯。我们的大脑会遇到浩如烟海的信息，只能作出取舍，尽力记住将来可能用得上的信息。因此大脑总在不断地作出判断，哪些记忆应当永存，哪些记忆可以被舍弃。例如，我们更喜欢概括的信息，而不是具体的信息，因为概括的信息可以占用更少的脑容量。当大量信息都简化到极致时，我们就只能从中挑出一些存储下来，丢掉所有其他的信息。通常而言，我们大脑中的信息选择机制会与本文问题 1 中所提到的，解决信息过载的过滤机制有所关联；亦或者与问题 2 中所提到的，脑补信息的流程有所关联。这些机制所筛选出的信息又都会对筛选机制本身有所增益，如此反复，从而使这些机制不断自我增强。

太好了，那我怎么能记下来所有的这些认知偏差呢？

其实你并不需要记住所有的认知偏差，仅仅牢记下面的这四个问题就可以了，我们的大脑进化了数百万年就是为了解决这四大问题（以及你可以收藏这篇文章以备不时之需，万一你想找某一个特定的认知偏差时来这里搜就好了）：

  1. 信息过载让人很不舒服，所以我们主动对信息进行过滤。噪音成为了信号。
  2. 缺乏意义的零散信息会困扰着我们的大脑，所以我们自行脑补了信息中缺失的部分。信号连成了一个事件。
  3. 想要避免错失机遇，就需要迅速采取行动，因此我们会匆忙下定结论。事件变成了决定。
  4. 即使这样大脑还是不堪重负，所以我们只想记住最重要的信息。决策最终化为了我们的心智模型和世界观。

为了避免被信息过载淹没，我们的大脑需要对海量信息进行脱水和过滤，并且几乎不加思索地飞速判断出哪些重要信息值得关注。

为了从无数碎片信息中归纳出明确的意义，我们需要填补信息之间缺失的细节，并且将所有信息映射到我们已有的心智模型之中。同时我们也需要避免我们的心智模式因此有所动摇或模糊。

为了迅速采取行动 ，我们的大脑需要对可能波及我们的生存、安全以及成功机会的问题迅速做出决定，并且始终充满着自信。

为了更高效地完成上述的一切，我们的大脑需要记住新信息中最重要和最有用的部分并运用于大脑的其他机制，久而久之，这样大脑才可以不断适应新的环境以及不断自我改善，但是在这个过程中大脑会遗忘其他的「不重要或没用」的信息。

这些机制听起来很靠谱！所以为什么还会有「偏差」呢？

上述大脑机制依次解决了大脑的四个大问题，但分别有着不同的副作用，正是这些副作用导致了所有认知偏差的产生。因此，除了上面的四个问题，我们也最好记住下面这四个副作用导致的结果：

  1. 我们被遮蔽了双眼。大脑过滤掉的信息中有一些实际上是有用并且重要的。
  2. 我们为信息归纳意义的时候，实际在给自己植入幻觉。我们会根据我们的假设臆想出事情的细节，也会因此构造出错误的含义和情节。
  3. 快速作出的决定可能会导致严重的问题。我们在快速反应下作出的一些决定是不公正、自私自利的，会导致适得其反的结果。
  4. 我们的记忆会不断放大错误。我们记忆中的错误信息会导致上述的所有机制不断扩大偏差，对我们的思维造成更坏的影响。

只要记住了上面提到的四个问题，和我们大脑解决这四个问题的过程中导致的四个后果，根据「可得性捷思法」（更准确说，应该是「巴德尔-迈因霍夫现象」），我们就会更为频繁地注意到生活中认知偏差的发生。如果你还能每过一段时间都来复习一下这篇文章的话，「间隔效应」将帮助你记忆更多的认知偏差，从而不断自省是否陷入到「偏见盲点」和「素朴实在论」之中。

我们永远无法使上述的四大问题彻底消失（除非我们能够将大脑的计算能力和存储空间提升到天文数字）。但是，一旦当我们接受了自己永远受到认知偏差影响的现实，事情就已经开始了变化。「确认偏误」会一直帮助我们找到更多的证据来证明我们「永远生活在认知偏差之中」，这会使我们更加了解我们自己。

“自从了解了认知偏差，我发现它们无所不在！”

认知偏差是一把双刃剑，在正确的环境下会带来好的效果，而适用到错误的环境时就会对我们有害。这是唯一一个我们生来就拥有的思考机制，并且在它们本应解决的问题上也确实发挥了无可替代的作用。我们应当了解和熟悉它们，甚至应当感激我们神秘的大脑中，一直有这样一个处理天地万物的机制。

更新：这篇文章发布了几天之后， John Manoogian 问我是否可以引用这篇文章的内容来画一张信息图，我自然是没有任何意见。下面就是他的作品：

如果你有需要，可以在这里买一张上面这张图片的海报。我还把这篇文章里的信息整理成了一份 JSON 格式的数据放在了 Github 上，你可以点击这里下载 。

文章的最后，我将用狄金森的这首小诗的第一段作为结尾：

头脑，比天空辽阔——
因为，把他们放在一起——
一个能包含另一个
轻易，而且，还能容你——

译注：

原文链接：https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18
原创翻译，转载请注明出处

2016 个人总结

2016 年的关键词，我想应该是「改变」。

这一年来，大环境中的不确定性日益增强。我自己在这一年中换了工作，进入了陌生的领域，也搬了家，用了更多的时间去思考「我是谁」和「我想要做什么」。

工作

跟很多人聊起过年初选择加入 FellowPlus 的原因：金融与互联网类似，可能都是边际成本最低的行业之一，也是一个我认为应当尽早学习，深入了解的行业；一级市场又是我工作几年来接触最多，未来也可能有更多联系的金融领域。在这些大前提下，这家公司所在做的事情比较符合我的兴趣，商业逻辑链条成立而又富有挑战，与我的个人规划也是合拍的，于是在今年年初我就选择加入了这个团队，进入了对我来说全新的领域。

一年过去回过头来，无论是工作状态还是成果，都还是达到了我年初的期望。这一年来做产品的瘾被大大地满足了，团队管理的身份转变比较顺畅，在金融知识和行业认知上建立了基础的知识架构，开始在每个细分领域进一步下探。

而超出我预期的是，得益于小团队的氛围和打法，以及 ownership 的增强，我在工作事务的执行力、自我驱动和自律上有着可以明显感受得到的成长。

健身健康

虽然年初办了很贵的健身房，下班时间也有所提前，但是健身的次数反而下降了，体重也随之上升。这一年里共运动 38 天，且有 22 天是在 3、4、5 三个月里。体重和体脂也没能达到之前的目标。

回想一下这一年虽然忙，但是显然还是可以控制出运动的时间的，新的一年里，一方面还是需要把健身房换成定期上私教课 + 在家运动/跑步的形式，另外一方面恒定的健身时间是保持运动的必要的计划。

这一年逐渐培养了吃早餐的习惯，从很少吃早餐，到现在几乎每个工作日都吃完早餐再出门。加上年底肠胃不舒服，遵医嘱后整个饮食还是规范了很多。不过这一年偶尔还是会吃夜宵或者喝含糖的饮料，比起去年来说是退步了。

阅读写作

2016 年共读书 15 本，几乎只有往年的一半了。虽然说一直认为应该有一个比阅读数更好的读书评价标准，但是阅读量绝对值的腰斩仍然是一个很能反映现状的依据。

年初确定的「系列化」的阅读方式的目标，也没有能够执行。这两个目标其实是相辅相成的，系列化的阅读方式，可以提升阅读效率和阅读量；而更高的阅读量，也支撑了读完多个系列的可能性。而这两个目标背后的支持性要素，都是日常为读书留出固定的时间。

今年的一个全新的尝试，是在下半年把自己很认可的两篇长文章翻译成了中文，在知乎、微信公众号上，以及通过其他平台的转载，累计获得了几万的阅读量。

这个尝试所带来最大的收益，是我在阅读英文资讯上的速度有了很大的提升，以及不再像以前那么忌惮于阅读英文长文。要知道这可是我过去几年一直希望突破的难题，没想到年底就这么歪打正着地解决了一点点，这也是一个完全没有在意料之中的收获，希望能成为一件坚持做下去的事情。

年度计划中的学习日语和 Swift 都基本没有付诸行动，主要的原因一方面是对英语和 Python 的兴趣还是比日语和 Swift 要大，另一方面这几个月翻译这两篇万字长文花费了我下班后大部分时间和精力，实在没办法再顾及其他的计划了。

这么来看 100 天培养一个习惯可能会是比较好的一个节奏。

社交感情

年中的时候养了两只猫，虽然我自己更喜欢养狗，但是盘算了下实在很难有时间出门遛狗，于是就养了这两只名为「皮皮」和「呼噜」的中华田园猫和加菲猫。

消费/娱乐

这一年买的设备里，有这些是值得晒出来推荐的：Dyson V6 吸尘器，Sony a6000 微单，352 空气净化器，WiiU，HHKB，小蚁智能摄像机，飞利浦 HX9352 电动牙刷，Backbeat Fit 运动耳机，Marshall 音箱。

另外充值了这些苹果税：iPad Air，iPhone7 Plus，Apple Watch，Airport Express（用来给音箱做 AirPlay）。

这一年工作生活都完全切到了 iOS 平台，基本不再使用 Android 手机之后，感觉生活质量还是提升了很多，唯一不够好的就是 RescueTime 不能再记录我在手机上每个应用花费的时间了。

2016 年唯一一个进入了我首屏的应用是 Ulysses，这篇总结也是使用手机和电脑两个平台上的 Ulysses 写完的。另外还有三个没有进入首屏但是这一年使用非常频繁的新应用是「即刻」、「湾区日报」、「收趣云书签」。「湾区日报」是一个很不错的英文 IT 资讯推荐应用，「收趣云书签」是一个 Read it later 工具，提供了很好用的微信收藏助手。

「即刻」是我心中当之无愧的年度应用，在这一年里通过它在第一时间获取了很多有价值的信息。但是随着越发重度地使用，我也开始反思即刻是否还在提高我的效率。趁着春节，我重新梳理更新了下几年来订阅的 RSS 源，和在即刻等资讯平台所关注的主题。

这一年，去了两次日本（东京、仙台和关西），国内今年到过南昌、鹰潭、杭州和天津。就像这篇总结开头所说的，我用很多时间在想「我想要做什么」，在这个问题上，持续去看更大更不一样的世界一直对我意义重大。2017 有着更多的未知和不确定，也希望我能在已知的方向，正在思考的疑问和要探索的领域里，都能有更多的收获。

【译】产品文档撰写指南

Gaurav Oberoi 是 SurveyMonkey 的联合创始人（现已离任），曾于 Amazon、Xmarks 先后从事工程师、产品经理等职位，在西雅图和硅谷有十余年的工作经验。在这篇文章中他分享了他对于产品文档的看法以及撰写产品文档的常用流程。

产品文档撰写指南

很多人听到「产品文档」这四个字就像吞了苍蝇一样，人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累，怎么可能「敏捷」得起来，怎么可能高效地产出代码？

我在过去十几年创造了多个数百万人使用的软件产品之后，越发认为这种观点是完全错误的。根据我的经验：

高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成部分。

撰写产品文档可以强制所有人从项目初始就理性思考，频繁沟通，明确权责——所有的这些都会带来更好的软件质量，更低的进度风险，以及更少的时间浪费。

在这篇文章中，我会通过一个案例来分享一些普适的建议，这些建议会对大中型（超过二百人的）公司中的产品经理们非常有帮助。

首先，举个例子

假设你在这里工作：

一家从事在线旅游预订服务 （就像 Hotels 或者 Airbnb 但是规模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个季度大家打算尝试通过在支付环节加入在线客服的方案来提升转化。

你的工单/用户故事/路线图是：

通过在支付环节增加在线客服来尝试提高支付转化率。
支付转化率目前仅有 18％，而业内平均转化率有 30％。我们打算测试下在支付时展示在线客服聊天窗口是否可以提高这个转化率。用户运营团队已经同意了提供 1 人月的客服人力支持。

在你没有产品文档时，你会这样做：

比方说，你觉得行动起来总是最重要的，因此直接开始动手：

  1. 在迭代计划会上，你和团队讨论了这个需求。
  2. 然后你挑选了一个靠谱的第三方客服供应商（例如 SnapEngage ）。
  3. 提交一个工单来让工程师添加一些 Javascript 代码。
  4. 和支持团队开个会，确定他们都准备好了

搞定了！这么简单的事情怎么能要我们写产品文档呢？如果你是在一个小型创业团队，你也确实并不需要——因为产品改动相对小，涉及到的人也相对更少。

但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会陆续出现下列这些问题，并且相比写文档，这些问题会需要更多时间来处理。例如：

  • 工程师把工单标记完成了，但是一验收测试，就发现这个功能完全没有考虑移动端的适配。
    • 「唉呀！你忘了提醒大家手机端的使用才是核心场景。」
  • 用户运营经理打算开展一个漫长的评审流程，以确定最合适的聊天服务商。
    • 「啊……需要定一个会议，向大家解释下这次上线只是一个灰度测试。」
  • 发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。
    • 「啥？要追加一个紧急发布，把这个测试限定在英语用户中。」
  • 一个设计师花了几天，为聊天窗口滑入屏幕的交互绘制了一个完美的动画。
    • 「用户体验过度优化，你是否对整个团队统一了「这次只是一个测试」的预期？」
  • 一周的测试完成之后，数据分析师发现无法产出你要的报告，因为相关的必要指标并没有埋点。
    • 「史诗级的失败。从头再来吧。」

如果这是一个相对简单的项目，即使没有产品文档可能也不至于陷入这样的灾难之中。但是在简单的项目中你仍然有可能会因为没有文档浪费许多时间和机会成本。

如果你写了一篇文档：

为了便于说明，我准备了两个示例文档：一篇思路笔记，和一篇完整的产品文档示例——这样可以完整介绍产品文档的撰写流程。

请在继续阅读文章之前，花几分钟读一下这两篇示例文档吧。

  • 阅读示例思路笔记。 （阅读时间 2 分钟）
    这是一个根据你已知的信息和想要解答的问题所梳理成的列表。这会是你需要做的第一件事情，大约需要一个小时来完成这个文档。这个文档会成为你和团队中其他人的一个沟通基础。
  • 阅读示例文档。 （阅读时间 6 分钟）
    只有和团队一起评审了你的假设和创意之后（无论是在专门召集的会议上，喝咖啡时，或者桌上足球的休息时间），你才应该真正开始写产品文档。如果已经完成了沟通和评审，整个文档应该花费你 1-3 个小时的时间。啊哈！有了文档之后是不是就感觉踏实多了？写文档看起来是额外的工作成本，但是其实并不是，高效的文档可以帮助你和你的团队节约时间投入，并且在交付上线时会更有信心。

等等！——你已经读完示例文档了么？请务必先读完它再继续阅读下面的文章。

文档撰写指南

我通过示例文档诠释了这篇文章中所讲述的思考，在继续阅读全文之前，请务必确认你已经阅读了示例文档 。

为什么要写产品文档？

为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。

是的，就是这样。那么，产品文档将如何帮助你做到这一切呢？Ben Horowitz 分享了上图中这个看法，我的示例文档也是一个很好的例证。明确一下要点：

  1. 从一开始就理性思考
    在团队开始付出更高成本去设计软件架构、实施代码开发、完善界面设计、测试软件质量之前，写文档可以迫使你提前思考每一个细节。这将会提高你决策的质量，降低意外事件发生的概率。
  2. 高效沟通
    你常常需要和不同的利益相关方（支持团队，工程团队，设计团队，财务团队，管理层等等）沟通你的方案。产品文档可以帮助你事半功倍地完成沟通，避免口头沟通中产生的歧义，团队中的所有人可以更好地理解你的意图，并且更有的放矢地做出答复。
  3. 明确权责
    明确项目目标的评价标准，公开承诺奖惩激励机制：利益相关方可以知晓如果最后一刻变更需求会意味着什么，工程师们也会在预估工期时再三斟酌。

产品文档中应当包含哪些内容？

产品文档应该明确沟通要做一个「什么」产品，以及「为什么」要这么做。用来说明清楚一个产品的表达方式很多，但最核心的，一定要说清楚这五件事情：

  1. 问题
    描绘你此次打算解决的问题。更重要的是，解释为什么要去解决这个问题。描述要尽可能地具体，并且提供相关的数据指标。
  2. 可衡量的目标
    明确承诺交付和成果，明确哪些事情超出了此项目的范畴。每一个目标，都应该可以明确衡量「是否达到目标」。
  3. 需求背景
    提供你的观众理解当前问题以及接受你的提议所需的所有背景信息。包括但不限于假设、用例、数据指标等信息。
  4. 解决方案详情
    你的提议应该有充足的细节，易于团队成员消化理解及执行——可以把这部分内容想象成对人脑进行编程和执行。
  5. 时间轴
    列出你的团队共同认可的截止日期和其他重要时间点。这部分内容开始的时候可能会比较模糊，但是在最后一次文档评审之前应当完全敲定。

你可以使用我的示例文档做你的文档模板，按照你的想法增/删/改任何章节。只要你能够清晰并且条理清楚地表述上面提到的这五点信息，文档形式并不重要。

如何写产品文档？

接下来我会介绍我撰写和评审文档的常规流程。根据项目大小，利益相关方的数量不同等情况，流程细节可能会有所变化，但是大体的流程是确定的。

  1. 快速完成一个草稿（1-2 个小时）
    关闭电子邮件和聊天工具。泡杯茶，坐在椅子上开始思考，然后逐一把你所了解的信息列成清单（见上文中的思路笔记示例）。
  2. 安排几个 30 分钟的一对一会议 （1-4 个小时）
    这个步骤的目的是过一遍文档中的细节，优化你的方案，并且获得更多人的支持。尽可能控制这些会议的规模，人越少越好（理想状态下都应该是一对一会议）。在本文的示例中，我会和客服部门的负责人，一个财务人员和一个工程师分别安排一次会议。
  3. 撰写和编辑文档 （0.5-3 天）
    此时，你应该对能做，并且应该做什么有了一个明确的想法，但是大脑中塞满了大量的细节等待着梳理清楚。于是接下来需要将所有这些细节都整理出来，并且逐一梳理斟酌。在完成第一版文档之后，需要继续大篇幅编辑修改，通常最终的文档可以在你的第一版草稿的基础上压缩 30%-50% 的长度，简洁和清晰的文档就意味着更加容易阅读。大部分文档都可以在半天到一天的时间里完成，不过实际上也会有一些文档需要两三天才能写完。
  4. 群发文档并且安排一个 1 小时的评审会议（15 分钟）
    将文档群发给项目的所有利益相关方，并且抄送给其他可能对文档感兴趣的团队（例如你所在的产品团队，整个支持团队等）。跟进这些关键人员是否接受了会议邀请：将会执行这件事情的人，和所有对这件事情有通过/否决权力的人。
  5. 评审文档（1小时）
    在开始会议之前，询问是否有参会者没有详细阅读你的文档。通常都会有一两个人中枪，在这种情况下可以说：「没问题，我们先用 10 分钟一起来看一下文档。已经读过文档的人可以利用这个时间先放松休息一下」。这次会议上你需要获得利益相关方的同意，并且获得执行方（工程师、支持团队等）的知晓、认可以及人力支持。你可能需要开多次评审会议，并且根据评审会议上沟通的信息不断修改文档。
  6. 通过评审后，及时同步信息和建立工单 （1-2 小时）
    会后同步信息的电子邮件需要包含更新后的产品文档链接，和此项目相关的工单链接（例如「在页面上添加 JavaScript 代码」，「完成数据分析报告」，「测试 Staging 环境」，「和支持团队预演流程」，等等）。一般接下来将会有一位工程师完成技术文档，不过并不总是这样（文中的示例项目就不需要这一步）。

写出高效产品文档的进阶技巧

  1. 尽量简短
    没有比这更重要的文档写作建议了。简洁意味着清晰的思路和沟通，也意味着你的文档更加易于阅读和理解——这一点至关重要。
  2. 使用平白的语言和简单的格式
    使用简短而不是花哨的语句，使用列表和加粗强调可以使文章更一目了然，以放松有趣的方式写作而不是一板一眼，如果你有得体的幽默感就再好不过了。
  3. 为开发团队预留时间
    通过评审并且达成一致通过的文档才是完善的文档。如果你希望在未来的某一个迭代 Sprint 中开发此项目，就应该提前两到三周开始这个产品文档写作流程。
  4. 像工程师一样思考
    在项目得以进入开发之时，常常会发现大量未预料到的边缘情况——但这种情形其实可以避免。如果你认真考虑过项目进入开发的所有必要条件，你就可以提前发现这些问题（例如，是否在移动设备中可以使用在线聊天功能？）。
  5. 确保每一个人都跟上了你的节奏
    当我组织产品评审时，会议室里的大部分人都已经大致了解我要讲的内容——因为我已经提前在讨论会和日常聊天中沟通过这个事情了。既然大家都已经清楚了「做什么」和「为什么要做」的问题，文档评审会上我们只要关注实施细节就好了。
  6. 在图表中下功夫
    流程图、线框图等图表可以通过易于理解的方式提供很大的信息量，同时也需要消耗非常多的时间来制作这些图表。
  7. 在思考和写文档上花 0.5-3 天时间
    具体时间根据项目大小而定。花费在写文档上的时间越长，所带来的边际收益就会递减。特别需要指出的是，没有人能够读的下去超过 5-6 页的文档。
  8. 指明方向，明晰愿景
    你不仅仅是在定义一个功能，也是在解释「为什么我们要做这件事情」以及「我们的目标是什么」，在文档中指出这个项目将会对更高层面的规划造成什么影响，以及接下来会发生什么。
  9. 确保你的观众阅读了文档
    如果你的文档又臭又长，或者从来不分享给对应的人，那你还不如不写文档。务必确保你的文档被对应的人阅读了，我上面关于评审开始时留时间给大家读文档的建议值得大家参考。
  10. 获取真诚的反馈 
    你的文档是否是在赘述人尽皆知的事情？或者是文档缺乏足够的细节？是否在后续实施中发现了太多的边缘情况？又或者，是否在制定计划和文档评审上耗费了太多的时间？你应该和你的团队时刻保持沟通。

说好的敏捷开发（Agile/Scrum）呢？

我知道会有争议，但是产品文档和敏捷宣言的原则没有丝毫冲突，并且在类似于 Scrum 这样的敏捷方法上得到了充分发挥。

毕竟，用户故事（Story）许多时候需要详尽的描述，文档可以增加沟通中的清晰度和可传播性，为什么非要刻板地认为仅仅使用口头沟通和使用白板才算是敏捷开发呢？

「产品文档会导致发布变慢，过度规划，通常会浪费时间」的想法完全是无稽之谈。

我工作过的多个世界级团队遵循着一些敏捷原则（例如两周一个迭代周期），每天（甚至更频繁地）发布代码，并且以发布产品（而不是文档或者会议）作为衡量成功的标准——这些团队也都仍然认为文档是他们打造成功软件的一个关键部分。

你对技术文档怎么看？

我是一个技术文档的支持者。产品文档通常关注 做什么 ，而技术文档更多关注在如何做 。这两种文档为研发流程中的不同环节带来同样的清晰视角，并且都使得工程师（和他们的用户）身心愉悦。

未来如果大家有兴趣的话我可能会写一篇关于技术文档的文章。

总结

感谢你读到这里。如果你认为这篇文章有用，请分享给其他人——特别是你的产品/工程团队。

如果你想看更多的产品经理内容（例如：规划产品路线图），或者想了解其他人如何使用产品文档， 请用两分钟填写这个小调查（英文） 。我会在未来的文章中分享调查结果中有意思的信息。

以上，祝写文档愉快！

备注：

1. 感谢周思博（Joel Spolsky） （微软早期 PM，曾参与创办 Stack Overflow，Trello，FogBugz 等产品，《软件随想录》作者）的「文档是对人脑的编程」的比喻。早在2000年，他写了4 篇关于文档的系列文章（英文） ，这对我的 PM 道路产生了巨大的影响，强烈推荐。

2. 在顶部的引文中，贝索斯所说的笔记是指为高层管理会议使用的，介绍新业务/产品创意的备忘录。这实际上不算是产品文档，但是两者并不是完全不一样。贝索斯在会议开始的时候会组织所有人默读文件——这激发了我在文档评审时做同样的事情。来源

3. 感谢 iDoneThis 博客这篇关于写作的价值的文章（英文）。这是贝索斯和 Horowitz 的引言的来源。

感谢 Vikram Oberoi 。

原文链接：https://goberoi.com/on-writing-product-specs-5ca697b992fd

原创翻译，转载请注明出处

项目协作工具的不可能三角

因为 Tower 太长时间没有功能更新，九月份看了下 Trello、Asana 和国内的 Teambition、Worktile、明道等项目协作工具，也使用了最近内测中的 Ones.AI。

悲观点想，对于项目协作工具，或者广义来讲包括个人事务管理应用在内的一系列事项管理服务。以下三点可能永远是无法同时满足的：管理层的充沛视野，执行层的方便高效，使用流程及方法论简单易行。

明道选择了使管理者有更好的视野，牺牲了执行层面的效率；Trello 牺牲了全局视野（尤其是当多项目并行时），获得了执行时的简单高效。

如果大中型团队想通过类似于 Trello 的产品同时满足上述两个条件，就很难不去维护一套复杂的流程和额外人力投入来确保流程运转。

同样， Asana 等试图在全局视野和高效执行上有所兼顾的服务，也都不得不使用户付出同样的大量人力或时间成本投入。

个人事务管理应用也是一样：简单的 To-do list 应用无法在处理复杂事务的时候理清头绪；所谓「专业级」的工具又大多臃肿低效（还记得 Outlook 么）；而 OmniFocus 这样的应用可以兼顾视野与执行，却有着令人望而生畏的学习曲线。

是否有同时满足这三点的服务？我是没能见到

【译】如何设置更适合你的 OmniFocus

 

OmniFocus 的强大在于它的高度定制性，借助 OmniFocus 的「透视」功能，配合对每个动作设置的「项目」和「上下文」两个标签，可以非常方便地定制在工作流程中不同阶段使用的不同界面，从而心无旁骛地处理当下的事务。

Andrew 作为 OmniFocus 的资深用户，在这篇文章中分享了他是如何通过自定义的文件夹、上下文和命名规范来设置自己的 OmniFocus 的。此文英文原文在许多 OmniFocus 的经典中文教程中被引用，我自己的 OmniFocus 工作流也高度参考了文中所提到的文件夹及透视设置。所以我挑选了这篇文章进行翻译，希望能帮助更多的人根据自己的情况来设置 OmniFocus。

注：OmniFocus 中的「上下文」其实对应英文中的 context，日常用到时通常会译为「情境」。此文中将和 OmniFocus 应用中的官方翻译保持一致使用「上下文」。

omnifocus

如何设置更适合你的 OmniFocus

正如我之前文章中提到过的，我通过戴维·艾伦的 GTD （Getting Things Done ）方法论和 OmniFocus 来管理我的工作与生活。然而，OmniFocus 一直都算不上一个简单易用的产品，它陡峭的学习曲线使得很多人始终不知道如何才能发挥这个工具的最大功效。

从 OmniFocus 发布第一个内测版本开始，我就一直在使用 OmniFocus 来践行 GTD 理论。并且这些年，我一直在调优对 OmniFocus 的使用设置，如今终于有了下述的一套完整的设置方法。

每当我提到我在使用 OmniFocus 的时候，就经常会被询问应该如何设置和使用 OmniFocus 。可惜的是，这并不是闲聊中一两句话就可以讲清楚的。所以这次我将会分享我独有的一些 OmniFocus 设置方法，从而向大家说明我是怎么使用 OmniFocus 来提高效率的。

文件夹

folders

当 OmniFocus 中的项目列表越来越长的时候，最好把项目归到不同的文件夹之中。但是，应该如何分类呢？

我的做法是（按照 GTD 中所描述的 2 万英尺理论）为每一个「责任范围」都创建一个新文件夹，然后把每一个项目都整理到这些文件夹中。一般情况下，这些文件夹会按照对我的重要性来排序。

这个分类方法有以下优点：

  • 默认情况下，当你在上下文视图中查看任务，OmniFocus 会按照项目视图下的默认排序进行排序。这样如果你按照重要性来对项目进行排序，那么你在某个特定的上下文中看到的任务也会同样按照重要性来排序了。*
  • 在每周回顾的过程中，这么设置文件夹会提醒你做一些小而快速的头脑风暴，这样就可以发现在每一个责任范围中你可能忘记或者漏掉了的项目。
  • 对你的责任范围进行明确的分类和标记，可以帮助你想清楚你是否真的把每一寸光阴都花在了你真正想去做的那些事情上。

*当然，你始终应该根据个人当下情况来选择「下一步行动」，但是我认为任务列表默认按照重要性排序是非常有意义的。

上下文

使用 GTD 这么多年，挑选一系列正确有效的「上下文」仍然是我最为纠结的事情之一。

有一些上下文我从来一眼都没有看过，也有一些上下文中总有着太多太多的任务，还有一些上下文的任务我从来都做不完——和另外的上下文有冲突导致我不能对这个上下文中的任务作出正确的判断。

在不断的试错和优化后，我终于找到了正确设置所有「上下文」的方法。完美设置所有上下文之后，终于可以说使我的生活回到了正轨之上。下面是具体的设置方法：

设置「上下文」的最佳方法就是问自己一个问题：「通常在哪些情景下我才可以做事？」这个问题的答案正是我们所需要设置的「上下文」。

context

人员

我们通常会和一些人有着不同形式的定期会议。在工作中，这个会议可能是老板和你每周的单聊时间。和伴侣的定期会议，则可能是你们每周的约会之夜。

关于「人员」这一系列上下文最重要的原则是，你只应该为那些和你有定期会议的人设置「上下文」。

我平常会和非常多的人打交道，如果一个人我必须特意去找他才能和他沟通，那我就不应该为他单独建立一个「上下文」。对于这样的情况，我会把这一类任务放到我的「办公室」或者「家」的上下文中（或者其他我可能找到这个人的地方）。

如果为和我没有定期会议的人员设置「上下文」，那么我就会发现自己永远不会处于这个「上下文」之中，从而这些任务也就再也无法被我处理了。

地点

当我想到以地点命名的上下文时，基本上都是指那些需要外出跑腿的杂事。所以，我觉得最靠谱的办法就是建立一个叫做「外出」的上下文，并且为每一个我可能会需要去的地方建一个子上下文，例如「宜家」、「星巴克」、「7·11」。

在 OmniFocus 中，可以筛选仅显示「可用」的上下文（即至少有一个可用任务的上下文），这样你就可以在出门的时候快速获得一个所有需要去的地点列表。

电脑/书桌

对我来说，最棘手的上下文设置就是处理我在电脑上的所有任务。作为一个计算机工程师，我大部分的工作时间（以及许多消遣时间）都在使用计算机。那么我需要做的就是区分我在使用计算机时的不同的精神状态及使用的具体设备。

  • 计算机：全神贯注：必须在电脑上完成，并且需要我清醒有着充沛的创造力才可以完成的事情（例如写博客、编程等）
  • 计算机：离线：那些不需要互联网连接就可以做的事情
  • 计算机：笔记本电脑：必须在我的笔记本电脑上才可以做的事情（例如说不能在我的 iPad 上完成的工作）
  • 计算机：所有：既可以在普通电脑也可以在 iPad 上完成的事情
  • 工作：和我的专业工作相关的事情。我发现应该把所有和工作相关的事情放在同一个上下文中（即使有一些不是在电脑上完成）。因为工作是一个需要「仪式感」的事情，当我真正调整自己进入工作的状态中不再处理其他事务，我才可以高效地工作并且持续工作尽可能长的时间。

情景化上下文

除了这些人员和地点相关的上下文，我在日常使用中还会使用一些基于活动或者每天的特定时间的上下文。

例如，我的「工作时间」上下文中有着所有必须在正常上班时间做的事情，不论这事情和谁有关或者我在哪里。我的「阅读清单」上下文中则是所有我想要阅读的东西（例如文章、书籍等），不论我具体在哪里阅读这些内容。

另外一个例子是，我曾经有过一个名为「短时长」的上下文，用来放置那些不适合当下就做（按照 GTD 的原则，如果一件事情两分钟内可以完成，那就立即去做），但是也只需要不超过10-15分钟时间的事情。当我在一个大公司从事管理工作时，经常在会议之间有那么几分钟时间，这个列表就完美解决了我的需求。

特殊目的的上下文

最后，还有几个我用到的上下文事实上并不算是「上下文」，但是可以帮助我更加轻松地使用 OmniFocus 。例如我的「等待」和「将来」上下文。我会在下述的章节中讨论我试如何利用这些特殊目的的上下文的。

单个动作项目

single-action-project

在每一个文件夹中，我都使用了几个特殊目的的「单个动作」项目（single-icon）来扩充我的项目列表。

一般这些项目是为了整理那些事实上不属于任何项目的任务。换句话说，这些任务只要你完成了，就再没有任何后续任务需要跟进了。

例如，「买钉子」肯定是一个项目多个任务中的一步——你不太可能买钉子只是为了置之高阁——而「做午餐」可能就是一个独立的任务，不会再有后续任务了。

杂事

这是第一个特殊目的单个动作项目：将某个责任范围文件夹中的所有一次性任务收集到一起。

在上图中的例子里，我的「博客杂事」项目中放置了所有的写博客相关的一次性任务。这些任务不会需要长期跟进，做完了就做完了。例如，我曾经把「配置谷歌分析」这个任务放置到「博客杂事」这个项目中。我通常都把这种项目命名为“「文件夹名杂事」。

创意

第二个特殊目的项目是用来放置每个文件夹中的「将来/也许」列表。

「将来/也许」功能是 GTD 中的一个常见概念，但是在 OmniFocus 的快速输入功能里输入这个词比较麻烦，所以我就缩写成了「文件夹名创意」。这个项目在具体用法上和《搞定》这本书（即戴维·艾伦的 GTD 经典教程）中介绍的用法是一样的。

目标

最后，我把所有的目标也都放在了类似的特殊目的项目中。

实际操作中，我会将我的 1-2 年目标，3-5 年愿景，以及终生的宗旨和原则（即 GTD 中的 3 万英尺到 5 万英尺高度的比喻内容）整理到这个项目中。

这个项目中有三个部分：宗旨和原则、愿景和目标（即 5 万英尺、4 万英尺和 3 万英尺）。

在「宗旨和原则」中，我会简单描述为什么我要对这个文件夹所代表的责任范围负责，我又能从中获得什么。在「愿景」中，我希望用尽可能多的细节来清楚说明对我而言，在这个责任范围中取得成功指的是什么。实际上，我会想象自己在未来已经完成了我这个责任范围中的每一件事，然后写下来我所看到的未来的我身上发生了什么。最后，在「目标」这个项目中，我通常会一一列举我未来一年左右的时间里想去完成的具体事项。

在每周回顾中，我会通过浏览目标、愿景以及宗旨和原则，来头脑风暴出新的我应该执行的项目，或者来评估现有项目的进展。

下图中就是这些单个动作项目的实际效果。

blogger

等待和备忘录

戴维·艾伦在他的书中提议使用「等待」和「备忘录」的概念，但是在 OmniFocus 中并没有明确的功能来对应支持这两个概念。下面就是我常用的设置方法：

等待

我综合使用 OmniFocus 的多个功能来实现了「等待」列表。

每当我需要把一些事情放到「等待」列表中时，我都会在对应的项目中建立一个新的任务，并以「等待：」开头为这个任务命名。然后在任务名称中进一步描述这个任务具体是在等什么事情发生。接下来，我会把这个任务分配给一个特殊的叫做「等待」的上下文。最后，把这个任务的起始日期（「推迟至」日期）设置为我需要再跟进这个任务的日期。

在实践中，经常会有某些项目的下一步行动是交由其他人去执行了。「等待」清单就可以帮助我记录下一步动作是什么，谁在执行，并且给自己建立了一个跟进备忘。下图就是包含「等待」列表中任务的项目的一个例子：

waiting

备忘录

「备忘录」主要可以满足我三个需求：

首先，经常会有一些项目的下一步动作非常明确，但是我在特定的时间之前就是不能去执行；其二，有时我认为自己将来可能会做某件事情，但是我还没有确定要不要做，这种情况下会给自己设定一个提醒；其三，有时我遇到一些暂时拿不定主意的问题，那么我就会想提醒我自己几天或者几周后再做出决定。

为了满足上述的需求，我通常会建立一个任务，把起始日期（「推迟至」日期）定在未来的某个合适的时间。

对于第一种有明确行动的任务，我通常会分配到合适的上下文中，这样这个任务就会在对应的时间神奇般地出现在这个上下文中；对于第二种只是为了设一个提醒的任务，我就会在任务名称前加上「提醒：」或者其他类似的文字，然后分配到「等待」这个上下文里；对于最后那种我想要为未来的潜在行动做决定的提醒，我通常会在任务名称前加上「重新考虑：」的字，样并且也分配到「等待」上下文中。

透视

你是否会遇到这种情况： 在各种上下文列表之间翻来翻去，就是为了找到下一步你应该执行哪一个任务？ 或者有时只是想快速看一下哪些项目停滞不前了？ 又或者为了在 iPhone 的屏幕上更有效地浏览任务，恨不得删掉一些上下文？

OmniFocus 的「透视」功能，正是为了解决所有这些问题以及更多个性化需求的神级功能。

首先，可能有人会问：「我们既然已经有了上下文功能，为什么还会用到透视呢？难道这些不是一样的么？」这是一个非常好的问题，我也在用了很久 OmniFocus 才灵活使用到下述这些透视具体可以帮助我解决的情况：

  • 有时我发现我可以在多个上下文中任选其一，这个时候我需要透视来帮助我选择我究竟开始做哪一方面的事情（例如，我是应该坐下来开始用电脑，还是应该去车库里）。
  • 有时我发现我同时满足多个上下文的条件（例如我在工作时间里坐在家里的电脑前）。
  • 我的一些上下文可能在多个情形下都有效（例如我不管手边是笔记本还是 iPad，我的「计算机：所有」上下文都是有效的）。

透视通过对你的 OmniFocus 窗口的不同状态建立一系列的快照，来使得你可以轻松处理类似于上述的这些情况。

例如，当我用 OmniFocus 做我的每周回顾时，我都需要选择「项目」模式，展示所有「可用」状态的项目。我可以为这样的一系列选项做一个快照，这样每次我有同样需求的时候，可以一键就设置好所有选项，而不是每次都重复操作 N 下。

在使用过程中，我设置了这六个不同的透视模式：

perspective

每周回顾

这是我每周回顾中用到的透视。

这个透视会使用「项目」层级，过滤只剩下所有「剩余」的项目，按照「文件夹」进行分组，展示所有「剩余」的动作，并且所有的文件夹、项目、动作都完全展开。换句话说，我可以在一个视图中看到所有的未完成的文件夹、项目和动作。

停滞

我会每天都检查这个透视（有时一天看数次）来了解是否有任何项目中缺少了明确的下一步动作。

这个透视会使用「项目」层级，并且过滤只剩下所有「停滞」的项目

即将到期

这通常会是我每天查看的第一个透视。

这个透视会不使用「项目」层级，过滤只展示所有「剩余」的上下文，按照「到期」来分组和排序，并且设置状态过滤器为「截止或已标记」。这样我就可以看到我的 OmniFocus 中所有的有截止日期的项目，并且按照截止日期进行排序。

家&工作

因为我在家里工作，所以你可能会认为我的「家」和「工作」两个透视其实是没有区别的。但是我实际上会用这两个透视来区分别人付费让我做的事情，和我自己为我自己而做的事情。

这两个透视都会不使用「项目」层级，过滤只展示所有「剩余」的上下文，按照「到期」来分组，按照「项目」来排序，展示所有的「可用」的动作。这两个透视的差别在于，「家」透视中默认聚焦在「等待」、「工作时间」、「电话」、「瑞秋」、「家」、「计算机」和「阅读清单」这些上下文，而「工作」透视中则默认聚焦在「等待」、「工作时间」、「工作」这些上下文。这样我可以在工作的时候更加集中精神，而在其他的时间里也可以更加放松。

手机

当我在 iPhone 或者 iPad 上使用 OmniFocus 时，我会默认使用「手机」这个透视。

它的配置方式和我的「家」、「工作」透视类似，只不过聚焦了不同的上下文：「等待」、「工作时间」、「外出」、「计算机：全神贯注」、「计算机：离线」、「计算机：所有」。我的想法就是排除掉上面提到的两个透视中所有只有在家里才可以执行的上下文，然后再加上一些出门才能做的事情（例如「外出」）。

命名规范

在你使用 GTD 和 OmniFocus 是否也会遇到过这样的情况：回顾自己写下的任务时，完全不记得当时自己写的是什么鬼了。

当我最开始使用 OmniFocus 时，我就常常会遇到这样的问题。后来，我就开发了一套命名规范，既可以缓解这个问题，又可以使我更快地浏览屏幕上的所有信息。下列就是我在 OmniFocus 设置过程中会用到的一些规范：

动作

对于独立的动作，我会努力使每一个动作的名称都以动词开头，然后是宾语对象，（必要时）最后是一些详细信息。当选择动词时，我总会选择那些现实生活中实际看到的动作，而不是那些抽象的动词（例如使用「打电话」而不是「联系」，因为前者更加具体、动作导向）。因为我们看到一个动作的时候也会同时看到动作所属的项目信息，所以我只在一个动作在一个月后必须要提醒我自己某些细节的时候，才会在名称中增加详细信息。下面是我目前的动作列表中的一些例子：

  • 介绍我的 OF 命名规范（在「如何设置更适合你的 OMNIFOCUS 」项目中）
  • 发一封邮件给查德确定见面日期（在「和查德约一顿晚饭」项目中）
  • 读下一章（在「阅读《餐巾纸的背面》」项目中）
  • 等待：58 同城上的广告过期（在「卖掉钢琴」项目中）

我会尽可能统一使用常见的动词（例如我有许多「发一封邮件给……」，「读……」以及「等待……」类似的任务），这样就更容易一目了然看清楚任务列表。同理，所有动作的名称我都会尽量使用通用的结构。

项目

我对于项目的命名规范和我对于动作的命名规范类似，另外项目的名称应该可以描述清楚项目的最终目标。也就是说，项目名称是“ 做什么+对某某某+其他细节 ”的形式的话，就很容易看明白「嗯，这个项目的产出会是他对某某某做什么」。下列是一些例子：

  • 还清 Windows 的账单
  • 用掉日料店代金券
  • 组织整理所有的产品需求到 Lighthouse 中
  • 更换 MINI Cooper 的 前轮胎

一个好的项目标题，应该一目了然地说明白究竟什么意味着「完成」了此项目，哪怕是我自己过了几周后也应该非常容易看明白。

上下文

我会尽量选择一个独立的，可以清晰描述其所代表的情境，又和其他的上下文有足够区隔的名词（或者名词短语）来作为「上下文」的名称。或者，换一个角度想一下，这个情境下我可以做这些任务的条件究竟是什么？这里有一些例子：

  • 家
  • 计算机：笔记本（这是一个子上下文，「笔记本」嵌套在「计算机」里）
  • 沃尔玛
  • 工作时间

文件夹

我使用文件夹来展示我的责任范围（即 2 万英尺视角）。

对于每一个文件夹，我都努力找到一个独立的形容词来描述人的某一种社会角色。然而，我发现这个方法并不总能奏效（毕竟，2 万英尺视角同时包含着人所需要担当的社会角色和需要负责的责任范围）。所以当没办法找到一个合适的角色的时候，我就会尝试找到一个最能描述清楚这个领域的独立的名词。这里有一些例子：

  • 财政
  • 丈夫
  • 负责人
  • 朋友

因为我自己已经充分了解我内心的想法，并且每一个文件夹都会有一个名为「目标」的项目来帮助我更加具象地梳理这个责任范围的定义。所以这些文件夹名称还是越短越好。

 

所有这些命名规范的基本目标都还是为了让自己几周后甚至几个月后仍然可以清晰地了解自己曾经的想法。

每当我在 OmniFocus 中写一些东西的时候，我都会想象我其实是在为我的妻子或者密友写一个备忘。这个思路会帮助我避免写出任何的缩写、模糊不清或者残缺不全的文字。如果要让其他人理解我的备忘，我就必须要写得全面、直接和准确。这样，不管几周还是几个月之后，即使是整整一屏的任务，我仍然可以一目十行。

每周回顾

weeklyreview

GTD 理论中最关键的环节就是每周回顾，这也是最难有效执行的一个环节。

首先需要解决的就是日程规划上的挑战：你如何在每周总能保证 1-2 个小时的固定时间？其次就是更加现实的挑战：每周回顾的时候，究竟需要做些什么？

第一个问题我可帮不上忙，但是我这里打算分享一下我是如何解决第二个问题的。

回顾步骤

我把我的每周回顾分成了三个步骤：

  • 清理
  • 回顾我的日程
  • 头脑风暴出新的项目

有一些我需要明确不属于回顾环节的事情：

  • 清空收件箱（这是我日常基础工作的一部分，而不应该属于回顾环节）
  • 在任何议题上花费超过两分钟的时间（如果脑暴出了有意义的事情，我会为其建立新的任务，而不是在当下寻根究底）
  • 尝试去完成任何的任务

坚持这几点，可以避免我把每周回顾的时间拖长到数小时甚至整整一天。

清理

clean
每周回顾的第一阶段就是把一周来没有时间整理的细碎问题都清理干净。

首先，我会切换到我的每周回顾透视，然后点击我的第一个文件夹。对于每一个文件夹，我会依次进行下列这些快速检查：

  1. 这些项目是否是按照优先级排序？我通常会把「目标」项目放在第一位，然后是按照优先级排序的所有常规项目，然后是「杂事」项目，最后是「创意」项目。需要提醒的是，在 OmniFocus 的右侧主界面中拖拽项目是没有用的，必须在左侧边栏中对项目进行排序。
  2. 是否每个项目都有一个下一步行动？如果没有的话，我会评估这个项目是否已经完成了（那就标记完成）或者尚未完成（那就增加一个下一步行动）。
  3. 有没有哪些项目是我不想在未来一周中推进的？如果有，我就会把这些项目标记为「暂停」。
  4. 有没有哪些「暂停」的项目是我打算在未来一周中推进的？如果有，我就会把这些项目标记为「活跃」。
  5. 有没有已经「暂停」了相当长一段时间的项目？如果有，我会干脆直接丢弃这个项目，或者把它拖到「创意」项目中作为一个单独的动作存在。

看上去这是一个特别长的检查清单，但是实际执行中，你只需要挨个浏览文件夹中的每一个项目，很自然就会对每一个项目作出决策了。

在我完成了第一个文件夹的回顾之后，接下来我会按照同样的顺序对每一个文件夹进行回顾。如果我保持专注（即抵制一切诱惑，真正开始做事），我通常可以在 30-35 分钟内完成所有的步骤。

回顾我的日程

calendar
在第二个阶段中，我会打开我的日历（一个包含我所有的个人日程、工作日程以及家庭事项的日历）并且检查每一个日历项，问自己是否需要针对这个日程做些什么。

我一般会从一周前的日程开始，一直看到整整一周后的事项。这个步骤通常会需要 5-10 分钟的时间。

头脑风暴出新的项目

这是最为困难的环节。

在这个环节中，我会重新浏览每一个文件夹（此时要忽略外界的所有干扰），来用心审视这一部分的人生是否会有新的项目。

可以尝试重新阅读一下每个文件夹中所标明的目标和愿景；或者想一下这个领域中我最近做了些什么；再或者想一下这个领域是在向好的方向进行，还是在向坏的方向进行。

只有大约四分之一的情况下我会真的可以新增一些项目，但是每次做完头脑风暴，我都会充满了成就感。

 

原文：http://andrewminer.tumblr.com/omnifocus

原创翻译，转载请注明出处

2016 个人计划

虽然今年仍然是到8月份才发布年度计划，但是比去年早了10天 😛

与去年情况相似，其实下述的计划也大多在年初都已经确定，但是在年初至今一直没能稳定到一个可以完整规划全年的状态。

这半年里换了工作，搬了家，养了两只宠物，工作生活状态都有了很多改变，年中工作生活终又逐渐稳定。于是重新看一下年初拟订的计划，根据这半年的状况和新的思考做一些更新，也是一个合适的时候驱动自己下半年向一些既定的方向加速了。

年度目标

  • 工作中找回主动感和 ownership
  • 坚持锻炼习惯，缓解各种职业病/地域病
  • 掌控个人时间，学习语言、编程和设计

工作

  • 能够独立熟练 own 一个产品，每一个季度/月份均达到产品目标。
  • 能够管理小型产品团队。
  • 在效率工具产品上的综合能力得到保持并继续增长；横向发展金融产品和 social 产品的经验积累和产品能力。

健身健康

健身

  • 每周至少锻炼两次以上，兼顾有氧与力量
  • 体重稳定在 75-80KG
  • 体脂降低至 15% 及以下。

健康

  • 针对对颈椎脊椎不利的生活工作环境/习惯进行纠正。
  • 有意加强颈椎脊椎附近肌肉锻炼，有更加全面的康复保健知识。

阅读写作

阅读

  • 养成每天一小时读书的习惯
  • 在金融、团队/项目管理、设计上有系列化的阅读计划并且完成。
  • 在英语书籍、心智脑科学上保持力所能及的阅读量
  • 注意加强非功利纯文学经典书籍的阅读量，进一步锻炼阅读肌肉

博客

  • 将收藏的英文 GTD 资料每个月翻译一篇。
  • 考虑整理和分享我个人的效率工具使用方法论。

个人提升

  • 对个人事项及个人时间有规划、有执行，优化精力管理，不因为无计划而浪费个人时间。
  • 完成日语入门学习，可以进行基本的对话和阅读。
  • 学习 Swift，上架一个个人作品。
  • 已购买的 Sketch 教程至少要看完一个。

消费理财

  • 更严格遵守消费预算，为额外支出提前预留预算
  • 扩大积蓄规模

社交感情

  • 增强 social 能力与沟通能力，适应与陌生人/工作伙伴主动沟通。
  • 养成定期约好友聚会的习惯，预留时间和预算。
  • 注意维护亲密关系，预留时间和预算，主动付出。
  • 把两位喵主子照顾好，保证其心理生理健康。

娱乐

  • 年内出境游至少一次，期望两次。
  • 主动尝试新的美好的娱乐方式。