共计 3036 个字符，预计需要花费 8 分钟才能阅读完成。
| 导读 | 有位 PM 最近告诉我她面临的一个难题：“软件工程师永远不能估算出他们的项目需要多长时间。我该怎么办？”还有两位 CEO 最近也告诉我同样的事情。从高级层面上讲，这个问题在于在时间估算的时候，工程师、PM、经理、公关以及其他所有人的看法存在不同。大多数工程师本能考虑的是，如果一切都按照计划进行，写出一个可用的原型需要的最短时间。但下游的人想知道的是项目何时准备发布——这完全是另外一回事了。 |
有位 PM 最近告诉我她面临的一个难题：“软件工程师永远不能估算出他们的项目需要多长时间。我该怎么办？”还有两位 CEO 最近也告诉我同样的事情。
《为什么程序员总是不能准确估测项目时间？》（http://blog.jobbole.com/24924/），我们都深有体会。我曾经遇到过一个项目，预计需要两天完成，结果做了四个月。在这种情况下，即使用“时间翻倍”的经验估算，也依然差出了一个数量级之多。这样真的非常影响业务。我曾见过整个公司为了举办一个发布活动费尽心力，结果却不得不推迟数月。
从高级层面上讲，这个问题在于在时间估算的时候，工程师、PM、经理、公关以及其他所有人的看法存在不同。大多数工程师本能考虑的是，如果一切都按照计划进行，写出一个可用的原型需要的最短时间。但下游的人想知道的是项目何时准备发布——这完全是另外一回事了。
对于工程师而言，把握估算项目所需时间是一段终身的旅程。忽视这个问题，会给你以及与你直接或间接接触的每个人带来困扰。精准把握估算项目所需时间会让你脱颖而出，同事们将会把这些和你的专业精神，稳定性和工作质量相关联。
首先我来回答一下工程师经常问到的问题：“为什么要估算时间？”许多工程师抱怨（有一定道理）这是一份间接成本。“如果我开足马力去做，会更快地完成项目！”
主要有两个原因：外部依赖和优先次序。
外部依赖
没有任何有效活动会在真空中运作。项目通常有外部依赖，例如与非工程团队（通讯，金融，公关，客服）、其他工程团队甚至最终用户本身的协作。协调这些外部依赖关系通常是经理、PM 或 CEO 的职责。这意味着最有资格做时间估算的人（工程师）不是最需要估算时间信息的人。这种不对称导致了根本的矛盾。
优先次序
时间估算也是确定工作优先级的关键。“钱花的值不值”是项目中的重要指标，没有真正的估算，也就无法确定钱花的值不值。即使你正在做的功能是世界上最棒的，如果花时间做一个全面的估计，你可能会意识到这将需要花费很长时间才能完成。
假设你正在做一个项目，这将使网站的速度提升 50%，但在相同的时间内，可以完成两个项目，每个项目将使网站快 40%。如果没有花时间做一个初步的估计，你永远不会知道你可以做出一个访问速度更快的网站！
现在大家都同意绝大多数时候都需要时间估算，我们来谈谈技巧。
我们低估时间是因为我们考虑的是“我需要多长时间才能写出这个基本版本？”
但交付的东西不仅仅是基础版。还需要考虑到编写，测试，调试和润色所需的时间。不要忘了开会、访谈、做代码审查以及发送电子邮件等事情也需要时间。
低估时间的另一个原因是我们几乎总是在编码过程中遇到“未知数”，这些未知数是不可能完全预测和考虑周全的。也许 IDE 会更新，中断了项目，你花费一天的时间去修复它。在时间估算中无法考虑到这一点。
但是，我们仍然可以比最初的直觉做的更好。以下是我的做法：
在着手开始工作前，你应该已经有了一份技术规划或设计文件，可以为任何重要的项目提供帮助。可以用这个让别人知道你在做什么，并获得反馈。制定技术计划是启动时间估算的理想阶段。当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间。也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间。甚至可能意识到计划使用的库实际上并不存在，需要自己写。
颗粒度在这里很重要。如果任何一步感到模糊或者不清楚，或许你会跳过这个步骤（应该学习更多），或者需要将其分解成更小的步骤。同时如果某个步骤粒度太细，那么在实践中可能会不堪一击使整个计划无效。
有关技术计划里应该考虑哪些方面，请参阅 Alicia Chen 的这篇文章《What do you mean‘we need more time’?》。其中一个关键点是消除与 PM 或其他利益相关方之间的任何潜在歧义，这样最终你就不会因做错了某些事而不得不重新开始。
估算一下技术方案中的每一步将执行多长时间。这通常会涉及对细节的研究（“有没有已经有人实现了这个库的功能？”）。根据项目的性质，罗列一个简单原型，可能会有助于暴露出许多未来潜在的痛点。
现在你已经有一个初步的估计，但是我们之前提到的所有的点还需要考虑。
- 随时调试：总是会有 Bug。调试很大程度上取决于你对特定代码库的经验和代码库的成熟度。
- 会议、访谈、假期等：可能你不会在工位一直编码。你真正会有多少个小时进行编码？估算时应该至少看看你的日历。
- 最终测试和 bug 清理：通常你在编码的同时应该也在写测试，但是很多团队在发布前，需要进行一轮润色工作或集成测试。在估算中要给予这些工作足够的预算。如果分阶段进行推出，最初推出的 1%内容，可能会暴露需要修复的 bug，需要考虑到这一点。
- 代码审查：项目需要做几轮代码审查？通常需要多长时间？一定要确保有充足的评审人员（也可以确认一下他们的日程安排）。如果这是只有一个评审人员的项目，应该提前征求他们同意，要求他们安排一名候补人员，以防评审人员会休假或者在关键节点太忙。
一旦开始将所有这些时间开销添加到项目中，就会开始看到自己的时间估算值与项目实际启动时匹配地多了。是的，实际情况可能会比估计的更长，你可能会倍感压力去缩短工期。但是当大家知道他们可以依靠你时，他们会欣赏你的估算。
在项目完成之后回顾一下所做的工作，这听起来很痛苦。但是这种审查回顾会让你从中学到很多，下次做的更好。
哪个过程结果与预期的时间不同？如果集成测试花费了比预期两倍的时间，记下来，下次给测试留下更多的时间。或者尝试改进集成测试系统。
你一定会看到自己的估算随着时间的推移而不断改善。甚至可以在这个过程中提出一些很好的见解，来帮助整个团队。
你的时间表和其他变动事宜，应该提前告知其他人。如果在发布前一个月让经理知道你正在使用的库中存在新的安全漏洞，不得不从头开始，他们会有时间相应的通知公关，财务或用户，需要推迟发布。
和其他协作方沟通得来的重要反馈，有助于调整时间估算。设计师可能会说：“哦，如果这个花哨的动画将要花一整周的时间，我们可以完全剪掉它。”PM 可能会补充说：“这只是用户研究中的一个原型实验。我们不需要为这个迭代做太多的 bug 清理。”经理可能会说，“你把一半的时间用在了开会？我来解决这个事情！”
对于工程师来说，不要为了取悦上级，向不切实际的时间表妥协。坦诚地说出你的估算时间和变更方式，这样更专业。
对于其他所有人来说，尊重估算的时间是很难的，而且这需要一个过程。你只能坐下来砍掉实际上不需要发布的功能或阶段，来缩短预计的时间，而不是通过唠叨把时间缩短。
我们永远无法完美估算项目所需的时间。唯一的办法就是保持开放、多沟通、有同理心，并果断地确定优先次序。
