别让错估的时间，谋杀你的职业生涯！
最近听说前东家的一个大领导被开除，因为项目一延再延。我又亲自目睹了隔壁组信誓旦旦说项目能按时做出来，到期之后多拖了一个月，才在加班加点中做完。
我又给我们组下面的一个重要的项目做了一个初步的规划。所有的事情到一起，让我想到一个问题，我们每个程序员都需要估计项目完成时间，又都在错误的估计时间。
1
人月神话这本写在几十年前的软件工程的书籍，今天来看依然值得我们每个人在职业的不同生涯反复阅读。因为虽然计算机的技术在进步，但是愚蠢的人类依旧踏步不前，该犯的错误，几十年之后还在犯。
在程序员的日常里面，有一项就是对自己工作时间的估计。这在码农的各个层面，上到各个部门主管，中层领导，下到每个天天搬砖的程序员，不管是以前的瀑布开发模型，还是现在天天叫嚣的 Agile，每个人都免不了要对自己做的活估计一个需要的时间。
然而该不准确的依然不准确，该延期的继续延期，我们有多少时候，可以说做到了准确的估计了自己干活需要的时间，项目准时的上线。又有多少时候是通过码农日以继夜不停的加班为代价去赶时间和进度呢？
我们先辈们犯的错，我们一直在继续。但是最不应该的是，我们大部分人没有把这项技能当回事情。在我周围罕有人去考虑如何提高估计的准确性。这无疑是说，愚蠢的人类们，先辈的错误，我们都在继续重复，而毫无作为和进步。
page
2
能否正确估计一个项目、一个功能到底需要多少时间，是很重要的一项技能。重要性我其实不需要多列举了。
最低底线，它可以大幅度降低程序狗加班加点还希望一天最好有 48 小时的那些天。往大了说，能否按时交出东西来，在每个领导层面上都是种本事。而正确预估时间则是其中很重要的一项技能。所以今天我们聊聊时间的估计，从一个故事开始。
4 倍哥的故事
4 倍哥是个经验丰富的程序员，对自己负责的那块的程序都很熟悉。4 倍哥有一个问题，就是非常的乐观，每次估计时间的时候，都特别的乐观。
而且更重要的，自己显得非常的自信。所以用他估计的时间去做项目，没有一次不延迟的。
4 倍哥深受各级程序员爱戴。因为大家发现只要把 4 倍哥估计的时间乘以 4，那么就是一个非常精准的估计值，上下波动不会超过 10%。
这个神奇的发现，让这位资深码农获得了 4 倍哥的名声，也让大家在想，为什么他的估计乘以 4 就很准确呢？
page
3
我这个好事者对 4 倍哥进行了长达半年的观察和研究。这个研究揭示了一些很有意思的事情。
研究最开始，我拿着我要做的东西请教 4 倍哥，对方一如既往的说出一个数字来。和以往不同的是，我和 4 倍哥深入聊了一下为什么他认为需要这么多时间。
对方就开始和我详细讲整个项目的体系构架，以及在这个构架里面大致需要怎么样去添加什么功能。添加了这些功能之后需要改一些其他的什么接口之类。每个功能实现又大致需要多少时间。
可以说 4 倍哥是真的懂这个程序，说的话都言之有物。
拿着那些细节，我当时想的是，如果说有些东西被高估了或有些被低估了，那么最后出来的应该是高低抵消，差不多就是正确的。可是当我一个一个功能做下来，却发现其实每个估值都需要乘以 4。
于是这就有了飞总估时第一定律：人性的偏差不随机。
通俗一点来说，一个人在估计时间这种事情上，要么都往高处估计要么都往低处估计。这和人的秉性是乐观派还是悲观派也许有千丝万缕的联系。但是你很难看到一个人在一个功能上非常的乐观而到另外一个功能的时候则变得非常的悲观。
这条定律教育我们人贵有自知之明。我们如果希望学会估时准确首先要知道自己的那个误差比例是多少，能够纠正自己人性里面的偏差，是一种能力，而且是一种非常不容易的能力，这需要长期的锻炼。
page
4
拿着 4 倍哥身上学到的定律，我做了很长时间自己估计的时间和实际完成的时间的对比，这个对比里面确实显示了一个几乎恒定的比率。
我自以为发现了宇宙真理。然而这个梦想很快破灭了。当我换到另外一个项目的时候，突然之间我发现我的估时再也不能呈现出那种规律性，有的功能我估计的时间长了，但是大部分的功能我估计的时间偏短。
作为严谨实践的博士，我拿 4 倍哥的情况、我过去的情况和我现在的情况进行了一个对比。估时不准取决于我们对要做的项目了解多少。
这就有了飞总估时第二定律：估时的偏差和我们对事物的了解成反比。
这个反比和个人的偏差无关，但是和我们对要做的项目的了解和熟悉程度有关。那么怎么样才能提高了解和熟悉的程度呢？
熟能生巧是最基本的办法，自己做的相关项目久了肯定更熟悉。但是如果没有做得够久，我个人的经验最重要的有两条：
Talk，问更有经验的人，但是要怎么问是学问。
一步一步来，自己先 prototype 一下走走看。
有一个最实际的教训就是我们在填 backlog 的时候，对每个功能的分解，如果我们花费的时间越少，那么这种误差肯定越大。
我是坚决不相信要写两周的 feature，花两个小时就能够很好的估计出来的。如果我要写两周的 feature，那估计准确怎么样也得一天。
磨刀不误砍柴工，心急吃不了热豆腐，说得都是同一个道理。
page
5
如果你读到这里，心里有戚戚然，觉得自己也是个老司机了，那么多半你还会骂一句娘希匹。因为老司机肯定会发现只有这两点，我们在估计时间的时候，依然会出错。这是为什么呢？
这就要介绍飞总估时第三定律了，这是著名的墨菲定律：凡是可能要出错的地方必定要出错。
什么地方可能要出错，很多很多。举例说简单的，比如你的编译系统，跑测试的系统。你觉得用的好好的，在关键时候肯定来打你的脸。
比如说各种各样的飞来横祸，突然之间来的重要的 bug，没有能够想到的突发事件。
再比如说，因为 test coverage 不够，所以程序改着改着出问题了，但是一直到很后面才发现，前任欠下来的债，今天要还之类的。
并非在每个项目里面所有的地方可能都会错，对于做一两天的功能来说也许没那么倒霉，但是你一旦做到要领导一个半年的项目，去做计划，那么相信我，墨菲定律，从来没有错过。
所以我们需要什么：冗余。说白了，一切都估计的对，那也是最顺利的情况，正常情况下，根据这个组织本身的噪音程度，还需要加上预留的余量。至于组织的噪音怎么判断，这是技术活，只能修炼，没有什么捷径。
作者：飞总
编辑：陶家龙、孙淑娟
本文转载自飞总聊 IT 微信公众号
精彩文章推荐：