软件工程师专属的时间预期指南

导语：你是否也觉得在开始工作前做时间预期反而是一种时间的浪费惜项目经理似乎永远和你思路相反，咄咄逼人。侯世达定律：做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。——道格拉斯·侯世达（Douglas Hofstadter）

Kat Busch曾经是Dropbox的项目领队，如今他的工作是一名软件工程师。听听作为程序员的他是如何理解“时间预期”的重要性的。

经常有软件工程师问我：“为什么要做时间预估那么麻烦的事还有人认为这简直又增加了工作成本。（当然，事实就是如此）他们抱怨：“不用预估时间的话我可能完成得更快呢

然而学习预估时间有两个重要理由：外界依赖和重点排序

外界依赖

要知道，历来没有任何要事是只靠一个人或者一个团队可以完成的。任何项目都会有或多或少的“外界依赖性”——比如要和非工程师团队协调（零售商品部、金融部、公关部、用户支持等等），再比如和其他的工程师团队，甚至是终端用户协调。对于公司的客户经理或者CEO，与外界协调是工作的重要一部分。而这就意味着，需要做出精确时间预期的人，即软件工程师，恰恰不是最需要知道预期时间的人。这一矛盾性在一定程度上解释了程序员不喜欢做时间预估的原因。

重点排序

预估时间可以让你轻易地找出工作的侧重点。在编写程序时，“物有所值”这四个字很重要。然而如果你不能做出正确的时间预期，你就无法获得相应价值的回报。即使你正在处理世界上最酷的软件特性，如果你可以预先匀出一点点精力做个时间预期，你就可能意识到就算再酷的软件特性也不值得你花费那么多时间。

做一个假设——用同等的时间，你可以提升一个网站50%的运行速度；或者你也可以同时分别提升两个网站40%的运行速度。如果你跳过了时间估计这一环节，你可能永远不会知道你的能力所及比你目前所完成的更厉害。

时间预估

既然现在大家都对时间预估的必要性有了一定的认识，那我们就来说说时间预估的方法。

程序员常常以为自己要写的程序很简单，所以导致低估了需要花费的时间。然而发布程序远没有那么容易。时间预估必须囊括编码、测试、调试以及最终完善等所有步骤。况且你还不能排除参加会议、访谈、代码评审、发送邮件这些零碎的时间。

程序员总是低估项目时间的另一大原因是在编码过程中，我们很可能遭遇一些目前无法预计的未知领域。当然，你不必指望自己可以预见这些未知领域——比如说你的IDE忽然更新打断了你的项目，然后你还需要花费一整天来修复项目。这些意料之外的情况当然不可能被事先预计到。

除此以外，尝试下面这些方法，你或许可以更好地做出时间预估。

第一步：制定一个技术方案

你要预计技术方案中每一步大概要用多少时间能够完成。当然在预估的时候你需要细化到各种细节的时间预估，比如“是否已经建立了数据库”等问题。如果仅仅靠以往的经验之谈，以为自己只需要建立一个简单的原型，在具体实施的过程中你会遭遇更多问题。

第三步：在预估时间上加一点宽裕时间

虽说项目发表之后还要回顾一遍听起来简直是痛苦的折磨。但是回顾一遍可以让你吸取经验，下一次才能做得更好。

想想在写代码的过程中，哪个环节比你预期的时间用时更长果最终的综合测试比你预期的时间长得多，那就记录下来，在下一次预估时预留更多时间——或者就索性改进一下你们的综合测试环节。

沟通交流永远是最重要的一步

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92039 人正在系统学习中

来源：硅谷精英程序员