英文原文：The Software Engineer’s Essential Time Estimation Guide
编者按：《人月神话》里面提到，在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因。而进度安排的不合理大部分又出在时间测算不合理上面。事实上与实际进展一致的完美时间测算是不存在的，尽管如此，曾经在 Dropbox 负责过 Web 性能的软件工程师 Kat Busch 还是提出了他的时间测算方法指南，按照他提供的步骤不断实践，你的测算准确度一定会日臻改善。
霍夫斯塔特定律：实际时间总是比预期要长，即便你考虑到了霍夫斯塔特定律。
——道格拉斯·霍夫斯塔特
我的一位产品经理朋友最近告诉我她碰到的一个问题：“软件工程师永远都没办法估计自己的项目要花多长时间。我该怎么办？”有两位 CEO 最近也跟我说了同样的事情。
我们这些工程师对此早已司空见惯。我曾经见过一个预计 2 天完成的项目最后花了 4 个月。那种情况下哪怕“只需把时间翻倍”的经验法也还差了一个量级之多。我曾经见过整家公司倾尽全力想要推出一场发布活动结果却不得不推迟几个月的时间。
从高级层面来看，问题出在测算时间时工程师的说法跟 PM、经理以及所有其他人的说法不一样。大多数工程师在直觉上考虑的是，如果一切都按照计划进行的话，写出一个原型所需的最少时间。而那些受阻的下游想要知道的是项目什么时候可以为发布准备就绪——这个完全就是另一个故事了。
对于工程师来说，掌握测算技能是一段终身的历程。对此疏忽大意会让你以及直接或间接跟你打交道的人备受折磨。掌握测算能让你在同事当中鹤立鸡群，被后者视为专业、稳定和高质量的象征。
为什么要进行测算？
我先从回答听到工程师问得最多的问题开始：“为什么要估计时间？”许多工程师抱怨（也是有道理的）这属于额外开销。“如果我开足马力全心全意去写的话项目就可以早点结束了！”
原因主要有两点：一是存在外部依赖，二是要确定优先次序。
外部依赖
任何有效的事情都不会在真空中发生。项目通常都存在外部依赖，比如跟非工程团队（财务、PR、客户支持）、其他工程团队或者甚至跟最终用户自己的协调。跟这些外部依赖协调往往是经理、PM 或者 CEO 的工作。这意味着最有资格做出时间估算的人（工程师）并不是最需要这些测算的人。这种不对称导致了根本性的紧张。
优先次序
时间测算对确定跟踪优先级也很关键。“钱花得值”在工程领域是一项重要指标，没有一分钱不经过真正的估算。哪怕你在做的功能是全世界最出色的东西，如果你花时间进行充分测算的话，你也许也会意识到要完成需要花费你很长很长的时间。
比方说你正在做一个项目，做成之后可以让网站快 50%，但用同样的时间你本来可以完成 2 个项目，而且每个项目都可以让网站快 40%。如果你不花点时间进行初步测算的话，你永远都不会知道自己本来可以做出一个快得多的网站！
时间测算入门
现在我们都同意时间测算在绝大部分情况下都是必要的了，下面就应该讨论一下测算技巧了。
我们低估时间是因为我们想的是“写出一个基本版本需要花我多长时间？”
但是交付出去的东西要比基本版本大得多。你需要考虑编写、测试、调试以及优化程序花费的时间。还有，别忘了开会、访谈、代码评审、发送邮件等事情也要花费时间的。
我们低估的另一个原因，是我们在编码过程本身几乎总会遇到“未知的未知”问题。而这些是不可能充分考虑得到的。也许你的 IDE 要进行更新而中断了你的项目，然后你不得不花了一天的时间去弄好环境。你的估算是没有办法把这件事情也考虑到的。
但是我们依然能够做得比最初的直觉要好得多。以下是我的做法：
步骤1：制定技术计划
在开始任何一个重要项目之前，你应该已经有了一份技术计划或者设计文档了。你用这个来让其他人知道你在做什么并且获得反馈。技术计划是开始进行时间测算的理想场所。当你关注到那些技术细节时，你就已经在发现那些未知的未知时魔术般地改进你的测算了。也许你会意识到你可能要把某个要用到库更新到新版本，而这个可能要多花你 1 天的时间。你甚至可能会意识到自己打算要用的一个库根本就不存在，得自己写。
颗粒度在这里是很重要的。如果任何一部给人感觉不清楚或者含糊的话，要么你是在蒙蔽（且应该了解更多），要么得把它分解为更小一点的步骤。与此同时，如果某个步骤的颗粒度太细的话，可能会太脆弱导致整个计划都无效了。
想要知道你的技术计划里面应该要考虑哪些东西，可以看看 Alicia Chen 的这篇文章的指南。关键点之一是跟 PM 或者其他利益攸关者沟通清楚，消除任何有歧义的地方，这样最后才不会把东西做错而必须重新开始。
步骤2：给每一步增加时间估算
测算技术计划里面的每一步实现起来需要多长时间。这往往牵涉到对细节的研究（“这个是不是已经有库了？”）。视项目性质而言，先扔出一个简单的原型可以帮助揭示大量可能的未来痛点。
步骤3：追加大量额外时间
现在你已经进行了初步的时间测算，不过我们前面提到过还要考虑很多的其他东西。
随时调试：Bug 永远杀不完。调试很大程度上取决与你对特定代码库的经验以及该代码库的成熟度。
会议、访谈、假期等：在做这些事情的时候你基本上是不会在桌面敲代码的。你真正用于写代码的时间究竟有多少呢？在进行估算的时候你至少应该看看自己的日程表。
最终测试与错误大扫除：你通常应该一边编码一边写测试，但很多团队还需要额外进行润色的工作或者在发布前集成测试。要在测算中给这些留足预算。如果你是分阶段推出的话，前面那1% 可能会揭示出需要修正的那些 bug。你也得考虑这个。
代码评审。在这个代码库中你一般要进行几轮？通常要花多长的时间？确保要经过足够的评审人（可能还要留意一下他们的日程安排）的充分验证。如果项目是那种只有一位可能的评审人的项目，你应该事先征询一个备份的人，以防关键时刻此人出去度假或者太忙而误事。
一旦你把所有这些交付的时间开销也考虑进去，你就会看到自己的时间测算跟项目的实际发布的匹配情况要好很多。是，实际情况仍然会比测算更长。是的，你可能会受到压力要缩短工期。但当大家弄清楚自己可以依赖你时，他们会赏识你的测算的。
步骤4：在发布之后对测算进行回顾
是的，在项目完成之后再回过头来审视你的时间测算似乎是一种痛苦。但是你的学习就是通过这种回顾学到的，而下一次你会做得更好。
如果实际花费的时间跟预期不一样会发生什么事情？如果集成测试花费的时间 2 倍于你的估算，那你就记下来，下一次留出更多的时间。或者试图改进你的集成测试系统。
这样下去的话你绝对可以看到自己的事件测算会不断改善。你甚至可能还会得到另一些很好的洞察来帮助整个团队。
到头来一切都与沟通有关
尽早地、经常地与人沟通你的时间表和变更。如果你在发布前一个月让你的经理知道你正在使用的一个库出现了一个新的安全漏洞，你不得不重头开始的话，他们相应地也会通知 PR、财务或者用户说时间需要推延。
跟相关参与者进行沟通也会让他们为你提供可影响你测算的重要信息。一位设计师可能会说：“哦，如果那个梦幻动画需要整整一周才能做出来的话我们干脆砍掉不要算了。”PM 可能会补充说：“这只是一个原型，就是用来对用户研究进行实验的。这次迭代我们不需要做太多错误大扫除。”经理可能会说：“你有一半时间都用在了开会上？让我来搞定这件事！”
对于工程师来说，不要为了取悦上司而向不切实际的更短时间表妥协。对你的测算及其该变更方式开诚布公会显得更加专业。
对于牵涉到的任何其他人来说，尊重这一估算时间是很难的，这需要一个过程。你只有坐下来减少发布时不需要的功能或者阶段才能削减时间。光靠唠叨是不可能把时间减下来的。
我们永远也没有办法完美地估算出项目所需的时间。解决之道唯有开放沟通、有同理心以及毫不留情地确定优先次序。