如何提高工时估计准确性？

文章来自：ThoughtWorks，世界经理人经授权转载。

“如果一个程序员告诉你他已经完成了 90% 的工作量，那么他还需要同样的时间完成剩下的 10%。”

软件项目容易延期和跳票是屡见不鲜的事情，其中不乏知名项目。

刚毕业的时候，我在一家做系统集成的公司工作，我们定制了一套售票软件，为景区接入互联网售票方案。供应该软件的软件公司非常自信的说，这东西非常简单，最多 2 个月就能搞出来。这家公司小有名气，我老板对 2 个月交付深信不疑，于是张罗了接入的客户、市场的物料等。

不难猜到，最终还是没能逃过 90% 定律，2 个月交付的东西只能算作一个 Demo。于是花了另外一个月测试，修复问题和完善业务逻辑，又花了另外几个月时间响应对接客户的要求，才逐渐稳定下来。

行百里者半九十，软件开发也大体如此。开发者估不准工时常有，估准了才奇怪呢。

后来自己也做了软件工程师，参与 IT 项目开发，项目延期也是非常常见的事情。

工时估算的前提是质量

IT 团队能准时交付是一项非常有价值的能力，哪怕交付时间长一点。计划两周交付，最后能准时完成，比承诺 一周时间，但是花了三周才交付重要得多。

越是大项目，越是重要。大项目的各个组件可能会发生相互依赖。如果不能准时交付，就会付出团队等待的成本，那可是真金白银。

做过项目管理的都知道甘特图，甘特图的每个泳道表达了项目各项资源的进展和计划。然而，软件项目不确定性非常多，存在各种突发事件。如果能提高准时按质量交付，各个单位的等待成本会小很多。

关键的是，衡量准时交付的关键是质量，其次才是交付。先给一个 demo，然后再慢慢改 bug。这种 “准时” 的交付，还不如有一个明确的延期时间，本质上还是 “猛糙快”。

谈项目工时估算，应该是在满足质量要求的前提下，否则估时没有意义。

提高估算准确性的方法

那么能不能提高软件工程工时的估算的准确性呢？其实是可以的，刚到 Thoughtworks 的时候，参与了一个交付项目。在一个项目开始前就计划了项目结束的时间，以及下一个项目的计划和安排。结果让我非常吃惊，那个项目的结束时间，和预期相差两周左右。并且这两周是逐步减少开发人员，最后只有 1-2 个人负责最后一周的交接期。

这就是专业软件团队和小作坊的差别，在专业项目经理带领下能把 3 个月的项目估算，精确到 20 - 30 个人天。能把项目工时估算到这种程度，体现了 PM 的内功。

在一个敏捷团队，需要把工时估准，不在于 “估” ， 而在于团队执行项目的稳定性。一般来说，准确估算工时需要考虑需求分析程度、任务拆分的合理性、技术方案的可靠性、团队成员的能力、外部依赖和环境，如果这个项目不是新项目，还需要考虑遗留系统改造的成本和数据迁移的成本。

需求和任务分析

只有把需求分析做的非常彻底，才能保证估算的输入条件。非专业的业务分析师，只能看到需求冰山水面上的部分 —— 软件的特性、功能的复杂性等。

专业的业务分析师，不仅需要考虑功能需求，并对功能需求的逻辑性考虑完备。比如用户需要一个 APP，他实际上还需要一个后台，对应这个后台会有不同的用户、角色等。

根据这些业务输出、拆分出任务，敏捷开发中我们叫做用户故事，一个用户故事代表一个合理拆分的业务逻辑。能被评估工作量，然后根据这个工作量来评估工时。

除了这些功能需求之外，还有非功能需求。客户不仅仅需要一个 APP，还可能需要的是一个安全的、高性能的、国际化的 APP，而这些往往被客户当做默认选项。

一些性能优化的指标需要分析，并考虑性能优化的任务工时；安全需求可能有 HTTPS 配置，防病毒扫描等，都需要考虑；国际化也是额外的工作量。

挖掘用户真实需求的目的是定义怎么才算完成（Definition of Done），如果没人说得清楚满足什么条件这个项目才算完，那么估算工时根本无从谈起。

彻底挖掘客户的真实需求是评估项目工时的首要条件。

技术方案和团队能力

技术方案、团队能力和项目时间估算有很大关系。很多项目的时间估算都是由技术经理或者 Tech lead 来完成，往往是他们按照自己的经验和能力进行计算的。光是这样，很难算的准。

团队有多少人？对这套技术方案的熟悉程度如何？方案是否会发生较大的调整。人一多，人员水平差距就为工时估计带来了不确定性。经验多的人来做方案，如果是他做过的相似方案，自然会估的稍准一点。但大多数情况下没有这么理想的场景。

要做好工时估算，需要结合技术方案和团队成员能力，而不是自己能干多少活儿，多快干完来算。

一方面，技术负责人需要安排相应的技术预研，走在实际编码的开发人员前面，探探路，验证方案的可行性、实施难度、风险。就像作战的侦查人员一样，我们把预研叫做 spike。spike 需要输出一些结论、demo，支持项目的时间估算。

另外一方面，考察团队真实运作效率很好的方式是根据迭代做工时统计。按照两周为例，10 个人的团队是 100 个工时。如果按照之前的估算，2 周内需要完成的 100 个工时的任务，实际上只完成了 50 个工时。也就是进度只有 50%。

我这个算法比较粗糙，敏捷项目管理中还有更准确的速率计算方式。通过速率，就能对下一阶段的工时估算做出调整，并在工作量、人员上做出调整。

通过方案预研和速率计算是提高项目工时估算准确率的良好方法。

把控遗留系统和外部依赖

我常常花了一下午时间完成了某个特性升级的编码，但是花了一个月的时间才完成了线上平滑升级、数据迁移。

真正有经验的工程师都知道，方案设计的难点往往不在设计一个新东西，而在于演进一个老系统。遗留系统演进是不可避免的，这种历史包袱是造成工时估算不准的一个重要因素。

遗留系统演进带来的估算困难来源下面几个方面：

● 前置条件不满足或者很困难。客户可能觉得只是添加一个小功能，但是涉及数据库变更、API 升级。软件项目往往牵一发而动全身。

● 遗留系统代码难以理解，没有人说得清楚原委。这种系统往往伴随着重构，否则难以进行。

● 数据迁移的成本。例如，需求只是简单要求对用户的某些数据加密，实际工作包括了对存量数据的迁移。

● 临时代码的清理。遗留系统往往为三个状态，原始态-过渡态-最终态，很多人估算工时要么忘记了过渡态，就是忘记了最终态的时间成本。

不负责的猜想，有一些客户就是遗留系统演进不下去了，然后招标做新功能，实际意图是想乙方顺便消化重构的成本。总之基于遗留系统的二次开发都是一件困难的事情，能不接就不接吧。

另外，社会分工意味着一个人干不完所有的事情，IT 项目往往一个项目也不是独立的。大多数情况下需要和外部条件进行集成，这部分时间超出我们的掌控。

集成这件事的成本需要视主动集成还是被动集成来说：

1. 需要等待别人提供服务，我们去集成。在估计工时的时候，一定要把对方的交付时间考虑进去，提前沟通，并建立契约。

2. 提供给别人服务，被别人集成。这种情况估计工时，往往只是计算到 API 上线，实际上还需要考虑一定的支持、文档工作量。很少有一次到位的情况，大多要磨合一段时间。

集成充满了不确定性，估算工时时需要预留足够的集成空间，才能让工时估算更准确。

总结

项目工时估算是一个系统性工作，基本上很难有一个万能的方法。因此大多数情况下都是玄学，但是毕竟是 “估” ，也不能要求 100% 精确。软件工程的估时更具有弹性，相对供应链管理的交付时间估算成本更低。做好估时，对减少项目运行成本和风险有巨大意义，工时估算的准确性也往往体现了一个 IT 团队工程能力。