有效提高估计项目工时准确性的办法

什么是项目工时？

项目工时估算是一个系统性工作，基本上很难有一个万能的方法。因此大多数情况下都是玄学，但是毕竟是 “估” ，也不能要求 100% 精确。

工时估算的前提是质量：IT 团队能准时交付是一项非常有价值的能力，哪怕交付时间长一点。计划两周交付，最后能准时完成，比承诺一周时间，但是花了三周才交付重要得多。越是大项目，越是重要。大项目的各个组件可能会发生相互依赖。如果不能准时交付，就会付出团队等待的成本，那可是真金白银。想必做过项目管理的都知道甘特图，甘特图的每个泳道表达了项目各项资源的进展和计划。然而，软件项目不确定性非常多，存在各种突发事件。如果能提高准时按质量交付，各个单位的等待成本会小很多。关键的是，衡量准时交付的关键是质量，其次才是交付。先给一个 demo，然后再慢慢改 bug。这种 “准时” 的交付，还不如有一个明确的延期时间，本质上还是 “猛糙快”。谈项目工时估算，应该是在满足质量要求的前提下，否则估时没有意义。

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

需求和任务分析：只有把需求分析做的非常彻底，才能保证估算的输入条件。非专业的业务分析师，只能看到需求冰山水面上的部分 —— 软件的特性、功能的复杂性等。专业的业务分析师，不仅需要考虑功能需求，并对功能需求的逻辑性考虑完备。比如用户需要一个 APP，他实际上还需要一个后台，对应这个后台会有不同的用户、角色等。根据这些业务输出、拆分出任务，敏捷开发中我们叫做用户故事，一个用户故事代表一个合理拆分的业务逻辑。能被评估工作量，然后根据这个工作量来评估工时。除了这些功能需求之外，还有非功能需求。客户不仅仅需要一个 APP，还可能需要的是一个安全的、高性能的、国际化的 APP，而这些往往被客户当做默认选项。一些性能优化的指标需要分析，并考虑性能优化的任务工时；安全需求可能有 HTTPS 配置，防病毒扫描等，都需要考虑；国际化也是额外的工作量。挖掘用户真实需求的目的是定义怎么才算完成（Definition of Done），如果没人说得清楚满足什么条件这个项目才算完，那么估算工时根本无从谈起。彻底挖掘客户的真实需求是评估项目工时的首要条件。

技术方案和团队能力：技术方案、团队能力和项目时间估算有很大关系。很多项目的时间估算都是由技术经理或者 Tech lead 来完成，往往是他们按照自己的经验和能力进行计算的。光是这样，很难算的准。团队有多少人？对这套技术方案的熟悉程度如何？方案是否会发生较大的调整。人一多，人员水平差距就为工时估计带来了不确定性。经验多的人来做方案，如果是他做过的相似方案，自然会估的稍准一点。但大多数情况下没有这么理想的场景。要做好工时估算，需要结合技术方案和团队成员能力，而不是自己能干多少活儿，多快干完来算一方面，技术负责人需要安排相应的技术预研，走在实际编码的开发人员前面，探探路，验证方案的可行性、实施难度、风险。就像作战的侦查人员一样，我们把预研叫做 spike。spike 需要输出一些结论、demo，支持项目的时间估算。敏捷项目管理中还有更准确的速率计算方式。通过速率，就能对下一阶段的工时估算做出调整，并在工作量、人员上做出调整。通过方案预研和速率计算是提高项目工时估算准确率的良好方法。

把控遗留系统和外部依赖：真正有经验的工程师都知道，方案设计的难点往往不在设计一个新东西，而在于演进一个老系统。遗留系统演进是不可避免的，这种历史包袱是造成工时估算不准的一个重要因素。遗留系统演进带来的估算困难来源下面几个方面：前置条件不满足或者很困难。客户可能觉得只是添加一个小功能，但是涉及数据库变更、API 升级。软件项目往往牵一发而动全身。

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

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

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

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