（给
伯乐在线
加星标，看经典文章
）
编译：伯乐在线/李大萌
霍夫斯塔特定律：实际花费的时间总是比预期的要长，即便你考虑到了本条定律。——Douglas Hofstadter
有位 PM 最近告诉我她面临的一个难题：“软件工程师永远不能估算出他们的项目需要多长时间。我该怎么办？”还有两位 CEO 最近也告诉我同样的事情。
《为什么程序员总是不能准确估测项目时间？》（http://blog.jobbole.com/24924/），我们都深有体会。我曾经遇到过一个项目，预计需要两天完成，结果做了四个月。在这种情况下，即使用“时间翻倍”的经验估算，也依然差出了一个数量级之多。这样真的非常影响业务。我曾见过整个公司为了举办一个发布活动费尽心力，结果却不得不推迟数月。
从高级层面上讲，这个问题在于在时间估算的时候，工程师、PM、经理、公关以及其他所有人的看法存在不同。大多数工程师本能考虑的是，如果一切都按照计划进行，写出一个可用的原型需要的最短时间。但下游的人想知道的是项目何时准备发布——这完全是另外一回事了。
对于工程师而言，把握估算项目所需时间是一段终身的旅程。忽视这个问题，会给你以及与你直接或间接接触的每个人带来困扰。精准把握估算项目所需时间会让你脱颖而出，同事们将会把这些和你的专业精神，稳定性和工作质量相关联。
为什么我们要时间估算
首先我来回答一下工程师经常问到的问题：“为什么要估算时间？”许多工程师抱怨（有一定道理）这是一份间接成本。“如果我开足马力去做，会更快地完成项目！”
主要有两个原因：外部依赖和优先次序。
外部依赖
没有任何有效活动会在真空中运作。项目通常有外部依赖，例如与非工程团队（通讯，金融，公关，客服）、其他工程团队甚至最终用户本身的协作。协调这些外部依赖关系通常是经理、PM或CEO的职责。这意味着最有资格做时间估算的人（工程师）不是最需要估算时间信息的人。这种不对称导致了根本的矛盾。
优先次序
时间估算也是确定工作优先级的关键。“钱花的值不值”是项目中的重要指标，没有真正的估算，也就无法确定钱花的值不值。即使你正在做的功能是世界上最棒的，如果花时间做一个全面的估计，你可能会意识到这将需要花费很长时间才能完成。
假设你正在做一个项目，这将使网站的速度提升50％，但在相同的时间内，可以完成两个项目，每个项目将使网站快40％。如果没有花时间做一个初步的估计，你永远不会知道你可以做出一个访问速度更快的网站！
时间估算入门
现在大家都同意绝大多数时候都需要时间估算，我们来谈谈技巧。
我们低估时间是因为我们考虑的是“我需要多长时间才能写出这个基本版本？”
但交付的东西不仅仅是基础版。还需要考虑到编写，测试，调试和润色所需的时间。不要忘了开会、访谈、做代码审查以及发送电子邮件等事情也需要时间。
低估时间的另一个原因是我们几乎总是在编码过程中遇到“未知数”，这些未知数是不可能完全预测和考虑周全的。也许IDE会更新，中断了项目，你花费一天的时间去修复它。在时间估算中无法考虑到这一点。
但是，我们仍然可以比最初的直觉做的更好。以下是我的做法：
第一步：制定技术计划
在着手开始工作前，你应该已经有了一份技术规划或设计文件，可以为任何重要的项目提供帮助。可以用这个让别人知道你在做什么，并获得反馈。制定技术计划是启动时间估算的理想阶段。当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间。也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间。甚至可能意识到计划使用的库实际上并不存在，需要自己写。
颗粒度在这里很重要。如果任何一步感到模糊或者不清楚，或许你会跳过这个步骤（应该学习更多），或者需要将其分解成更小的步骤。同时如果某个步骤粒度太细，那么在实践中可能会不堪一击使整个计划无效。
有关技术计划里应该考虑哪些方面，请参阅 Alicia Chen 的这篇文章《What do you mean ‘we need more time’?》。其中一个关键点是消除与 PM 或其他利益相关方之间的任何潜在歧义，这样最终你就不会因做错了某些事而不得不重新开始。
第二步：为每个步骤增加时间预算
估算一下技术方案中的每一步将执行多长时间。这通常会涉及对细节的研究（“有没有已经有人实现了这个库的功能？”）。根据项目的性质，罗列一个简单原型，可能会有助于暴露出许多未来潜在的痛点。
