在从公司辞职出来的之前，我们对创业的期望是不降低大家的生活质量。我们对自己这么说，对我们拉入伙的兄弟们也这么说。这里的生活质量当然除开收入之外，很大的一方面就是不加班。

但是实际上的情况是：五一之前整个公司度过了一个非常特别的时期：产品团队不停地根据用户的输入，修改产品需求；服务器端和客户端两个开发组都疯狂加班，彻夜不眠；测试每天没有东西可以测试。

假期我回忆了一下自己参与过的所有的软件项目，大到 IBM 的存储或者 Ericsson 的基站，小到自己做着玩的一些 prototype，有跨时区的几个团队合作的，也有每天都可以互相抛媚眼的死党一起撸的，它们有一个共同的特点：居然没有一个是能够按照预估的时间交付的。

假期我和一个老一辈无产阶级革命家聊起了这个问题：每次一个项目出现这样那样的情况，不能按时交付，我们都反思、开会、总结，希望下一个项目能吸取所有的经验，不再犯同样的错误。为什么最后的结果还是一样？

他推荐了 Daniel Kahneman 的Thinking, Fast and Slow。这是一本心理学著作，探讨了人类认知的很多方面，其中有不少观点挺值得软件开发从业人员思考的，特别是想不明白为什么我们做的 estimation 永远不准的软件从业人员。

原因一：开发软件面向的问题域在你深入之前是不完全可知的

可以通过编写软件完美解决一个问题的前提是，我们对问题域了解得「足够深入」，以至于我们可以细致而精确地告诉计算机「如何」解决一个问题。

但是矛盾的地方在于，一般我们了解到这个程度的问题，都已经有现成的软件或者是库了。需要我们进行开发的总是来自一些新需求：引入不确定性的那些新需求。

新需求引入的不确定性是多方面的：第三方接口提供者不能按时提供可靠的接口，所以你要自己做适配；选定的数据库服务器之间不能互联互通需要 VPS 提供商开通 3306 端口互访。当然，不那么具体但是绝对会遇到的不确定性一般来自客户：产品 release 了，但是他们发现自己需要的并不他们最开始描述的这个东西，他们要这里那里做一些「小改动」…

这其实也是历史上钻出来那么多 specification 文档的原因：有一些管理层希望能通过在文档阶段对需求足够细化来避免不确定性对项目的影响。但结果大家都知道了，细化的文档被整个软件行业唾弃的原因是越来越多的证据说明，如果你掌握的细节足够多，你就该直接去写软件。如果你掌握的细节不够多，那么写文档也没足够细的可能。

有趣的地方在于，无论做工程师的时候大家对估开发时间多么的不屑，一旦到了管理层，你工作的核心就是估开发时间。而且有不少前一个月还在为没有按时 delivery 睡不着的苦逼工程师，一升到管理层就无比相信自己估的开发时间了。无论项目的实际情况如何，他们都会 push 整个团队苦干蛮干，这就是另外一个问题了。

原因二：过度自信和效率神话

这次雅安地震那位预测四川多少多少年不会有大地震的专家又成了笑柄。这当然不是专家第一次或者最后一次因为错误的预测成为笑柄。Kahneman 在书里面专门花了一些篇幅写「专家」的预测为什么在大多数情况下是毫无用处的，最核心的三点在于：

• 事实证明专家的预测常常会出错
• 但作出预测的专家会对自己有绝对的自信
• 即便后来发现自己的预测是错误的，专家对自己的自信不会减少

最后这一点特别有趣。即便事实证明预测是错误的，即便明白只是人类认知中必然可能出现的问题，专家仍然会对自己的预测继续充满自信。原因何在？

系统I/系统II以及我们是如何做预估的

在Thinking, Fast and Slow里面 Kahneman 的解释了人类其实有两套决策系统：系统 II 负责谨慎、理性、分析性的思考；系统 I 复杂快速、基于模式、基于直觉的思考。

重要的是，在进化的过程中，一个主要变化就是系统 II 慢慢少被使用了：耗时长的系统，仅仅在极其少的必须的情况下被唤醒。但是这里有个显而易见的矛盾是，如果没有经过思考，你怎么知道应该使用系统 I 还是系统 II 呢？

这就是做预估的时候总是估不准的根本原因。做预估的时候，因为你是要在没有仔细分析（甚至一般也没用仔细分析的输入）的情况下使用系统 I 来做出判断。所以你的预估「一个任务需要花多少时间」的时候，其实多半是在根据「这个任务你有多少自信」。

所以，一般来说我们报这个任务我需要 3 天的时候，其实是因为「这个东西看起来非常简单，而且我十分清楚如何做」。如果报这个任务我需要 3 个月，则是因为「这个东西看起来很难，我也不知道怎么做，但是我相信我能搞懂是怎么做」。

避免凭直觉做预估就能得到准确预估吗?

你看到这里肯定会觉得，为了避免这些虚幻的估计，我们应该通过各种手段使用系统 II 来通过仔细地分析得到准确的数据。

Bravo！恭喜你发明了「瀑布开发流程」。基本上来说”在开始编码之前我们先编写文档”就是为了让你切换到系统 II。但是为什么使用瀑布的项目也会失败？

说白了，还是软件开发在初始阶段即使使用系统 II 也不能做出精确的判断：知道的太少，变化的太多。那么究竟该怎么办？

什么样的预测是比较有效的？

Kahneman 和其他一些专家通过研究，得出了什么时候做预测是比较保险的：

「To know whether you can trust a particular intuitive judgment, there are two questions you should ask: Is the environment in which the judgment is made sufficiently regular to enable predictions from the available evidence? The answer is yes for diagnosticians, no for stock pickers. Do the professionals have an adequate opportunity to learn the cues and the regularities?」

这里的”adequate opportunity”意味着大量的实践经验用于可控的周期内的稳定环境中，并且具备了反馈机制可以随时修正准确度。以此为根据，0-12 个小时的 task，如果这些 task 一被建立就能立刻得到执行，那么：

• 在这么短的时间内，虽然仍然有可能会出现变化，基本环境应该是稳定的
• 你可以很快的得到结果并且知道自己估计的准确度

在这种情况下，你是尽可能的先利用系统 I 开始工作，并且通过迅速得到的反馈来修正自己的结果，达到目标。

打破效率神话

创业团队出现过于乐观的估计除开过度自信之外，还有很重要的一个原因是因为相信效率神话。Evernote，AnyDo，OmniFocus 等等 GTD 工具和各种关于同时做 n 件事情还每件都做好的江湖传说很容易把焦头烂额的创业团队坑进去。接受你不可能做出一个准确的预估然后向客户承诺的事实，转而思考如何在规定时间内最大化的输出对客户有用的价值时，关于效率需要牢记下面的事实：

• 一天只有 24 个小时，即使团队的沟通成本很低，仍然需要在使用你们选用的 agile 工具，开会，互相之间同步信息，迭代和对外汇报等等上花时间；
• 人的生活还有各种不确定性，如生病、怀孕、过劳、休假、结婚、家长会、禽流感等等；
• 你的系统会有一些非常难以找到 root cause 的 bug 需要花你估计的十倍以上的时间才能根除
• 你的客户会给你各种乱七八糟的输入并且提出各种来时已晚的需求
• 一周工作的超过40个小时之后的部分已经被认为是无效的
• 工作被打断后需要15到20分钟才能恢复
• 人们上班的时候花了非常多的时间干和工作无关的事情

接受现实，摒弃对效率神话的膜拜，用心思考在有限的时间内如何最大化的输出对用户有价值的东西，比任何流程、方法论、工具都要重要。这一方面在团队内部倡导了一种科学并且诚实的做事方式，一方面会让你更能分清工作任务和资源的优先级。它最大的好处是让你专心地根据实际的优先级做出判断，把精力放到最关键的事情上去。

这，是对整个团队最重要的事情。