【译】产品文档撰写指南

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

娱乐

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

2015 个人总结

2015年,是完全离开校园,进入工作环境后的第一年。
相比2014年,2015年的工作生活状态都更稳定了一些,这一年中最得意的应当是终于养成了健身的习惯并取得了一些成效。
另外这一年在工作上的成长速度达到了年初设立的目标,也着实更加用心去维护了和家人朋友的关系。

工作

这一年豌豆荚发生了许多事情,我认识了许多新朋友,也告别了许多旧同事。
回首这一年,还是应该感谢豌豆荚所给予我的充分的成长空间。

2015 新年伊始,突然接手了应用内容库的新项目。这个项目本身的产品逻辑并不复杂,但是因为应用内容库历史久远牵涉广泛,所以投入了大量精力在旧有逻辑的梳理,新策略试错与运营流程固化之上。
下半年工作重心转移到客户端产品设计上来,两个季度的时间里做了豌豆荚内部诸多不同方向的一些 features,在年末工作内容慢慢收敛,专注在了两个工具卫星产品上。
总的来说下半年的成长、工作量和产出都是完全超出了计划的。相对于技能的提升,我更大的收获是在自我驱动上有了更大的自信。通俗点讲,相对于上半年多数时间处于给定的 deadline 压力下的情形,下半年我更多是在自己的目标驱使之下达到了远超自己所想象的效率和努力程度。

得益于数任 manager 的照顾,这一年里的工作方向转换大多是为了我自己更全面的成长路线。虽然工作节奏越来越快、在舒适区停留的时间也越来越短,但这一年的工作状态还算称得上令自己满意。然后在年末的时候,我也开始慢慢开始更多考虑如何控制自己的焦虑感,找到合适的「焦虑度」。

健身

2015 年最大的成就感来自于规划多年的健身事业终于得到了践行。
在这一年里共有55天在健身房锻炼或者在户外跑步,平均每周一次。频率上虽然仍然没能达到理想中的目标,但是这对我的健身事业仍然是非常好的一个开局。在年末,体重也成功达到了之前的目标区间之内。
上半年自己去了很多次健身房但是感觉收效不如预期,感觉长此以往健身大业又要无疾而终,于是在夏天下定了决心要投入更大的精力和成本去打开新的局面。七八月份开始和同事一起跑奥森5公里,接下来的六七个月中还在私教工作室一共上了二十节健身课。
系统地接受私教课的训练来作为新一阶段健身的助力,是非常明智的一个决定,在教练指导了一个动作之后,我就顿悟了自己去健身房看教程训练没有成效的原因。对于缺乏经验的健身初学者,认知身体各个部位,感受肌肉发力情况犹如瞎子摸象。而一个好的教练可以通过规范动作、详细讲解,避免不必要的协同发力,使目标肌肉获得最大化的锻炼,同时避免劳损和受伤。
今年另外一个触动很深的感悟是,很多以为难以坚持下来的事情其实并没有那么艰难。在整个夏天过去都没有再吃夜宵之后,在习惯了每天午餐用南瓜红薯来替换米饭面食以降低碳水化合物摄入量之后,在一年基本只喝水不喝任何含糖的饮料之后,这些曾经看起来会逼疯我的事情现在反而让我感觉更棒了。

总结一下,我非常享受运动时可以感知自己的身体,了解自己的身体,控制自己的身体,充满力量和愉悦感的感觉,我想这会是我接下来每一年把这个目标继续下去的最大的动力。

阅读

2015年共读书25本
比去年略多但是仍然离目标很远。当然工作和健身占用了比之前更多的时间,这一年里基本上只在睡前有固定的阅读习惯,其他时候只能在一些碎片时间进行阅读。
各项阅读目标基本都没有达到,新的一年会尝试一下更主题化序列化的读书方式,当然更重要的还是多留一些时间,多留一些精力给读书。

在这一年里 reeder、豌豆荚一览等阅读应用填补了我的许多碎片时间,并且我也在刻意减少了社交网络的使用度。基本也固化了我的互联网碎片信息解决方案:时效性的互联网碎片信息获取:微博、豌豆荚一览;非时效性的互联网碎片信息获取:Reeder、Pocket。

另外我在考虑对于我个人来说,是否虚构类的兴趣阅读并没有比优质的电影、电视剧更有营养。

应用

这一年有三个新应用进入我的首屏:Surge、Inbox、Dailycost ,另外有两个应用虽然没有进入首屏但是在今年养成了每天使用的习惯:豌豆荚一览和 Spotify
另外,Uber 、滴滴和神州专车这一年中极大地扩充了我探索北京以及其他每一个城市的范围和效率,更是提升了我在这些城市中生活的幸福指数。

消费

这一年陆续买了 New 3DS XL、小米 note、Bose QC20i 降噪耳机、小蚁运动相机、PICOOC 体脂称、Netgear R7000路由器等数码产品。在年末的时候,忽然意识到 2015 年是可能近几年来唯一一年没有给自己购买任何苹果数码产品 : )

2015年,在巴黎、布鲁塞尔和列日玩了一周(感谢火柴的友情赞助和二迪的留宿),在天津、武汉、成都、稻城、西安等国内城市留下了足迹。
因为年内几次旅行和私教课花掉了许多积蓄,所以并没有按照年度计划去台湾或者日本跨年。
但正如一年前所期望的那样,这一年,我看到了更大的世界,也看到了更美好的天空,看到了更厉害的自己,2016,希望这一切能够继续

从 Linode 迁移到 MediaTemple

在前两天把博客从 Linode 迁移到了 MediaTemple 上,并且关闭了 Linode 上所有的服务,写点东西纪念下这台 Linode53546吧。

Linode VPS 是在五年前和几个朋友一起开始租用的,当时的目的有这么几个:

  • 有个地方放博客,可以自由地写东西不被任何人干预
  • 学习一下 Linux Server 的维护
  • 搭建科学上网的隧道

五年多来,这个 Linode VPS 为数十位朋友提供了博客 hosting 的服务,也启蒙了包括我在内的许多人的服务器维护基础,但在 2014 年末的时候,我忽然想着也许要跟它说再见了。

主要的原因是我工作之后越来越难以有精力去保证这台服务器的日常维护工作,学习 Linux Server 的目的早已达到,工作性质的改变使得各种各样的 spam 和爬虫带来的负载问题不再是我愿意花许多精力去解决的问题;同时自己在海外 VPS 搭建科学上网服务的投入产出比也早已比不上购买成熟的付费服务。

于是在2015年中我确认了迁移到虚拟主机而不再维护独立 VPS 的方案,经过对比后选择了公认满意度较高的 MediaTemple 主机。为了进一步降低我的维护成本,我参加了「」的合租计划,在上周末完成了全部的迁移工作。

中文互联网上可以搜到很多从 MediaTemple 迁移到 Linode 的文章,像我这样反向迁移的情况很少,主要原因是从虚拟主机「升级」到 VPS 几乎是每一个博主的必经之路,但从 VPS 降级至虚拟主机丧失了太多自由度,若非是像我一样的原因,「降级」并不多见。

简单横评一下,在使用 Linode 的过程中,Linode 无论是速度、服务还是稳定性上都从未让我失望过,目前为止 Linode 被人吐槽最多的也只是 Tokyo, Fremont 等机房涌入了太多国人导致高峰期 Ping 值上升以及被 Block IP 段的风险加剧而已。被 GoDaddy 收购了的 MediaTemple 据称是不超售的虚拟主机,虽然网络不如 Linode 并且价格高昂,但是好在省时省心,稳定性有保障(相对于个人空闲时间维护 VPS 的情况而言)。

BTW,NoSpamNX 是个很不错的插件,配合 Askimet 可以解救许多饱受 WordPress Spam 困扰的人。

2015 个人年度计划

题记

在8月末制定年度计划这样一件非常诡异的事情并不是因为犯了八个月的拖延症。

其实在年初就已经打完了下文的底稿,但在最终定稿之前,就被突如其来的工作安排推上了高速跑道,在过去的半年暂停了所有其他计划,以保证工作的完成。

现在终于是一个合适的时间,重新看一下今年对自己的计划。有一些已经提前完成,有一些则已经落后太多,略作整理还是决定发出来,以作自勉。

年度目标

  • 工作上可以独立执行和完成项目,思路清晰完善
  • 坚持锻炼,明确锻炼目标并且达成,保持身体健康
  • 注意亲密关系的维护,加强 social,开拓眼界

工作
融入,承担,成长

  • 掌握日常工作中的设计方法,可独立地完成一个需求的分析与设计。
  • 对每个项目有计划地 handle,对开发流程、项目管理的方法论有清楚的认识。
  • 自我驱动,在每个工作上都去尝试突破自我,在部分工作上取得突破。
  • 数据分析能力、沟通能力、团队合作能力上保持进步。

健身健康
坚持锻炼,降低体重及体脂,保持健康

  • 制定一个更科学系统的锻炼目标,并且逐步接近目标直至达成
  • 每周至少锻炼2次以上,掌握基本健身方法和动作
  • 控制饮食,改正在生活上对健康不利的不良习惯

阅读
保证个人提升所需阅读的前提下提升非功利阅读量

  • 在产品设计、项目管理和心智脑科学上保证阅读量(每月2本)
  • 增大非功利纯文学经典书籍的阅读量,锻炼阅读肌肉,可以有沉下来连续两小时以上的深度阅读能力
  • 在互联网等快消阅读领域保持在 up to date 的频率(每月1-2本之内)
  • 寻找更高效的碎片阅读解决方案,降低碎片阅读的时间精力投入

个人提升
行事更主动,思维更自律

  • 对拖延的战胜不再依靠阶段性重复的战拖攻关,有成熟的从拖延习惯中快速走出的流程
  • 锻炼意志力肌肉,每两个月坚持培养一个好习惯
  • 个人 Productive Workflow 建立完整的回顾流程

消费理财

  • 财务归正,有积蓄
  • 消费有规划,有预算

社交感情

  • 注重亲密关系的维护
  • 保证友谊的维持
  • 加强 social 和交流技能

娱乐

  • 出境游至少一次
  • 年底去台湾或日本跨年
  • 有意识地接触一些经典游戏

2014 个人总结

2014 ,关键词是“适应”

在2013做了那么多的“选择”之后,2014年的365天里我不断在适应着这些选择所带来的改变。

Moments

1-2月度过了一个近四五年陪伴家人时间最长的假期,过年前溜回北京参加了下豌豆尾牙。年后即将返校时接到通知开始准备 Duke-UNC CLS 的各种申请材料,在天津办了护照,去上海申美国签证顺便见了许多朋友,虽然磕磕绊绊得幸最终成行,在北卡和华盛顿度过了充满乐趣的一周。

回到学校最后的半年里,推动了自强的架构调整,完成站长和总监团交接,参与了一场不留遗憾的十大。熬了许多通宵完成了毕设(写下了第一个 Android 程序),最终没有发生毕不了业的窘况。和室友去了重庆四川顿顿都吃火锅,毕业前喝了许多场酒,大醉两场之后再也不夸耀自己的不醉之身了。

毕业度过短暂假期之后回到北京,发现在学校的半年里贵荚又来了好多好多新豌豆,原先的办公室已经很难盛得下了。下半年就搬了更大的办公室,来到了北五环外一个心旷神怡的园区,只有每次进城吃饭的车费让人心痛。

豌豆荚工作

上半年远程工作其实只保证了自己的参与感,对团队贡献并没达到期望;下半年入职后花了一段时间来 warm up ,找回团队工作的节奏和基本的产品方法论。真正融入工作状态的过渡并没有想象的那么顺利,其间还是有几次比较痛苦的阶段的。

选择创业型公司有利的一面在于有着足够快的节奏逼迫新人成长,不利的一面则在于经验的积累只能自己把握节奏适时总结。直观感受上,下半年总是不断地被从自己刚达到的舒适区中踢出,去面对自己不足的地方。客观现实中是否因此得以成长,因为缺乏纵向比较对象,就不是自己能那么轻易归纳清楚的了。

自强网工作

漫长的交流和选举后终于交棒,除了效率工具和数据分析的推进上留给自己的时间太少,其他计划的完成度自评都很满意。我相信这个团队在被一群有动力,有意愿使它变得更好的人所管理着。纵然感受到了校方对这种改变的阻力或者说并不科学的引导方向,但还是怀着美好的希望相信它可以越来越好,帮助更多热爱互联网的学生发现、了解、培养自己的价值。

阅读学习

过去的一年只读了23本书 ,这个历史最低值着实吓到了自己。但是再看到这一年我一共看了65部电影或美剧的历史巅峰,时间都去了哪里也就一目了然。

好玩的是,在2013年到2014年中常常有“影视领域还有太多的经典好片好剧没看过,要多看一些”的想法。但是等真正花了很多时间在看视频上之后,很容易就发现看了更多的好 or 坏的电影美剧并不能带给我足够的满足感。

相反,当年底总结时,或者每过个把月发现自己读书读很少时,总会有种恐慌感,似乎“一步慢,步步慢”的警钟就在耳边敲响了。每当觉得知识或者智商不足以满足自己的需求时,也都会怪在最近读书不够多上。虽然更多是自我解脱的慰藉,但这种恐慌能致使自己放下手机拿起书应当不是坏事。另外越发感觉到,制定更清晰的阅读计划可以帮助人从“买书如山倒,读书如抽丝”导致的松鼠症和焦躁感中解脱出来(为什么不早几年这么做呢)。

毕业设计选择了 Android 开发的课题,也借这个契机把  Java&Android 的基础教程过了一遍。工作上也不断借各种机会尝试小的 python 和 shell 脚本,虽然一直没能把 Codeacademy 的教程看完,但是学以致用的日积月累自己还是挺满意的。

年初买相机现在看是一个投入产出比非常高的选择,上半年在拍/修出更好看的照片的激励下,学习许多构图/色彩/PS 方面的教程。下半年很少有机会带着相机出门,但在 instagram 上还是发了不少手机拍的照片。快门按得多了也有自己还挺得意的作品,尽管一年下来最受欢迎的照片永远是公司的萌猫们 LOL

产品设计上有了一些很基础的经验,但是年初经验中“更加清晰的学习路线”并没有梳理清楚,要被 delay 到2015年的 plan 中了。

个人提升

这一年 Daily workflow 已经很稳定了,拖延症在流程和工具以及 peer pressure 的帮助下得到了遏制。Omnifocus 仍然是这个星球上最好的 GTD 工具,可惜的是中文互联网里关于它的讨论太少了,英文讨论分散在广袤的互联网中,发现和筛选成本都偏高。虽然 daily 的流程已经很明晰,但是我在更长时间更高层次上的 organize 和 review 依然是非常初级的状态,因此而导致的问题也逐日逐月积累下来,甄待进一步的学习和优化去解决。

个人提升的阅读量也受了整体阅读量下降的影响,整年几乎没有建树。另外受和菜头老师启发,接下来一年如果在阅读社会科学书籍的同时能够间插读一些百年以上的经典纯文学著作,可以更加体会到阅读的乐趣,避免为了个人提升功利的阅读所带来的偏食感。

情绪能力上能感受到自己的适应和变化,但是从感受到的反馈来看应该还是远远不够的。上半年一直持续在毕业所带来的强烈的情绪震荡中,虽然这并不算得上一件坏事,但是好情绪其实更容易让人松懈放弃对情绪的控制。下半年身体情况不佳使我的情绪常常出于周期性的正负交替之中,特别是当处于需要团队合作的日常工作之中时,情绪肌肉的紧绷会消耗许多本应属于其他事务的意志力。“身体是革命的本钱”从未如此真切过。

健身健康

正如前文所提到的,2014年身体长期积攒的一些问题开始集中爆发。乐观去想,自己早发现早重视总比无可挽回要好,不然刚进入工作环境很容易就会更加肆意地透支身体。因而,年初计划中“重点保护”这条也因此达成了,后半年确实持续在运动护具和居住环境上加大了重视和投入。

上半年和来北京之后断续游了十多次泳,天气冷之后就以篮球和跑步为主了。一年下来体重勉强保持住了,“目测可见的体型变化”并没有发生。好在公司一直都提供比较方便的健身环境,也还常能找到伙伴同行。

消费

除了例行更换到了 Nexus 5 和 iPhone6 plus 之外,在数码设备上这一年并没有太多大宗投入。一个 bong 手环,一个小米空气净化器,一个电动牙刷,一个 LG 蓝牙耳机,都挺好地提高了生活质量;和室友合资添置了 PS4 和电视,进一步侵占了大量读书时间 : P

在数码设备上节省下来的开支,大多都扔到了机票和旅行费用上,这一年去了上海、美国、川渝、福建、香港,希望这只是一个更大的世界的开始。

利用 IPtables 屏蔽来自于福建莆田的 IP

近期我的 Linode 被大量 spam 撑爆了 SQL 和 Disk IO,检查Nginx log,发现大部分 IP 都属于福建莆田。随手一搜,原来莆田是闻国内外的垃圾评论和垃圾邮件发送者聚集地,许多 blog 和论坛都深受其害。

解决这个问题,一个简单粗暴的方法就是禁止所有福建莆田的访问,这个做法虽然会带来一些误杀,但是也是目前看投入产出比最高的解决方案了。

继续阅读利用 IPtables 屏蔽来自于福建莆田的 IP

不悔过往,不惧将来

在武大的最后一天,在宿舍收拾东西时,翻出来高中转学时同学的留言。当时的我就一直是一个跟大家不太一样的人,总是花心思花时间在各种奇奇怪怪的事情上,以至于作为一个高三学生,都没有多少人提到我的学习,都在感慨我是一个“非一般”的人。

四年过去了,再看看现在的自己,依然希望自己做一个不一样的人,不愿意从随于大众,不愿意隐没于生活。相比于四年前如果说有什么进步,也许可以算是多了一些稳重,多了一些努力。

武大四年,给予了我一个去探寻自己的空间。无论怎么抱怨武大对学生的所作所为,武大的风骨一直给予了每一个学生去探寻自己所想成为的人的空间,这即是武大的“自由”。从进入武大,加入自强,到去向的彷徨,到求职的选择,无不是在努力发现自己想要的是什么,在遇见和了解自己可以成为什么。这是我将永远怀念武大的。

自强,给了我太多的机会,去了解什么叫做责任,怎么样成为一个其他人眼中靠谱的人。让我知道怎么样去获得其他人的信任,也学会怎么样去信任身边的人。给了我又一个家让我去爱这么一群人,也收获了太多太多的感情。最后,帮助我找寻了自己最想要成为的是什么样的人,帮助我去选择每一天应该过怎么样的生活。

不知道是怎么样的幸运,让我度过了这样的四年,也许不务正业,也许不够努力,但是站在这个时间关口上回望,仍然充满了感激,充满了喜悦。

不悔过往,不惧将来,这是武大所给予我的四年。何其幸运

 

我知道 那些夏天
就像青春一样回不来
所以你好
再见