霍夫斯塔特定律：做事所花费的时间总是比你预期的要长，即使你的预期中考虑了霍夫斯塔特定律 — 道格拉斯-霍夫斯塔特
我的一个产品经理朋友，最近和我说她遇到的一个问题：『软件工程师们总是，无法准确的估算项目所需的时间，我该怎么办？』，还有两个CEO最近也和我说过同样的问题。
我们的工程师都见证了这一点。我曾经看到过一个项目，估算时间是两天，到最后用了四个月的时间做完。在这种情况下，即使花双倍的估算数据，依然和实际的时间不在一个数量级上，这可是会对公司业务产生很大影响的。
在一个较高的层面上讲，问题其实工程师和，产品经理、项目经理对应项目时间估算的理解是不同的。大部分工程师本能的去设想是，如果按照计划最好的情况下做出原型的最小工作时间，而产品经理们想要的估算时间是项目能够发布的时间点，这是两个完全不一样的概念。
对应工程师来说，掌握项目时间估算是一项长期的，贯穿你整个这样生涯的旅程，忽略项目时间估算，将会给你自己和与你一起工作的人带来很大意想不到的麻烦。掌握时间估计会让你脱颖而出，你的同事会将你作为专家看待。
我们为什么需要估算时间
让我来先回答这个问题，我经常听到工程师们说『有什么好担心的』很大工程师抱怨说，如果我一开始就全力投入开发，就可以很快的完成工作，何必要花时间在这在估算时间上面呢。
这里有两个主要的原因：外部依赖和优先级
外部依赖
『没有项目是在真空中运作的』，意思就是项目总会设计到与其他非开发部门或者其他的开发部门进行协调工作的。这也是项目经理和产品经理的主要工作。这意味着，最应该估算时间的人，不是最需要估算时间的人。这种不对称性导致了两者之间，先天就有所冲突。
优先级
时间估算同样是工作优先级的关键，功能开发的收益如果没有时间估算的话是很难保证的。即使你在开发的功能是非常酷炫的任务，如果你花时间做完整的估算的话，你也许会意识到这个功能需要花费很长的时间才能完成。
譬如说你在做功能，它可以让网站的速度快上50%，但是同样的时间下，你也可以做两个其他的功能，它们分别可以让网站快40%，如果你不在开工前对工作进行时间估算你就不知道，可以在相同的时间内让网站变得更快。
时间估算101
现在我们都知道了时间估算是非常有必要的，那么我们就来看一下几个技巧。
我们总是低估时间，这是因为，我们想的是：多久可以做出一个基本可用的版本。但是你的工作可不仅仅是写出一个可用的版本，你还需要估算你在，编写测试、调试、还有改进，这还没有包括你需要参加会议讨论，做code review、邮件沟通这些时间。
另外一个原因就是我们总是在开发期间遇到一些意想不到的情况，并且这些情况几乎不可能被预先计算在时间计划当中，就比如你的开发环境或者是IDE需要更新，正好弄坏了你的项目，你还需要花上一天的时间去修复这些问题，这根本就不可能在预先包括在时间估算到中。
当然了，尽管有很多的不确定性，我们依然可以尽最大的可能让项目时间的估算尽可能的靠谱。
第一步：制定技术计划
你应该已经在项目开始的时间，制定了技术计划或者已经通过绘图工具设计的项目的系统结构，这些可以让此相关的同事，了解的你的工作并且可以获得反馈，技术计划是一个作为开始估算时间，非常理想的地方。在你计划项目的具体实现使用哪些技术的时候，你就会看到有哪些是不可预知的情况，有哪些技术，是你还没有掌握的需要花时间去学习，还有哪些第三方库的轮子没有人造，需要你自己去写。这都是在是技术计划的时候去考虑，加入到时间估算当中去的。
步骤分解的粒度，是非常重要的，如果你觉得在某一步骤上的功能，实现起来有些困难的话，要么就将步骤再次分解，或者跳过这个部分。同时你还有注意不要将步骤分解的太细了，不然的话整个计划执行起来就没有可操作性了。
第二步：在每一步骤中添加时间估算
在技术计划中的每一项实现起来，需要花费的时间都是需要进行估算的，通常包括一些技术实现上的细节问题（是否存在第三方库可以用），可以通过制作一个原型去发现未来潜在可能出现的技术难度。
第三步：加入一些额外的时间
现在你已经对时间估算有了初步的了解。下面是我们在之前提到的关于估算时间需要注意的地方。
- 调试：bug 总是有的，至于会有多少，这就取决于你对项目的了解和项目本身的成熟度了。
- 会议、面试、假期等：你不可能无时无刻都在编程，所以估算时间的时候也要考虑上你自己个人的时间计划。
- 测试：通常情况向项目的开发都是需要伴随着测试进行的，为项目的最后阶段的测试预留一下时间，当然同时也需要为你在最后阶段被测试出来的bug预估时间。
- Code Review：通常需要花多长的时间再code review上?，项目会有多少人参与code review，这些时间你都要去添加到估算当中去。
一旦你开始，使用上面的跪着到你的估算当中，就会发现你估算的时间和项目最后的交付日期越来越接近了。当然这些是需要长时间积累的，你可能在执行期间感到有压力，不过只要过了瓶颈期，你就会发现你的团体会非常依赖你对项目的时间把控的能力。
第四步：在发布后回顾你的估计
是的，这个计划是在你的项目完成开发的时候，回顾整个项目的时间估算，看看在这次项目开发的估算当中有什么可以在下一次中做的更好的。
你一定会看到你时间估算会随着时间的推移越来越准确。你甚至可能会产生一些对时间估算的自己的见解。
沟通
尽早的暴露问题和积极的沟通反馈，是非常重要的，如果你在项目上线前一个月就告诉项目经理，『我们使用的第三方库（或者服务）出现了安全问题，现在需要重新实现部分的功能』而不是到最后项目要发布了才说，那么他就有时间去让相关的同事进行准备。
积极的与有关同事进行沟通，还能从他们那得到可能影响你项目时间估算的重要信息。比如设计师可能说『如果动画效果的实现，需要一个星期的话，那我们就砍掉它算了』，或者产品经理会说『我们现在做的只是一个产品的原型，用于实验，没有必要在这次迭代中，做到完美』。对于工程师来说，不要迫于上级的压力，去缩短你估算的时间，坦诚的说出你真实估算的时间，并且让他们有准备，这才是更专业的做法。
我们永远也不可能完美无误的项目时间估算，我们唯一能做到的就是，开诚布公的交流，并且严格按照优先级计划开展工作。
