如何提高工时估计准确性?
“如果一个程序员告诉你他已经完成了 90% 的工作量,那么他还需要同样的时间完成剩下的 10%。”
软件项目容易延期和跳票是屡见不鲜的事情,其中不乏知名项目。
刚毕业的时候,我在一家做系统集成的公司工作,我们定制了一套售票软件,为景区接入互联网售票方案。供应该软件的软件公司非常自信的说,这东西非常简单,最多 2 个月就能搞出来。这家公司小有名气,我老板对 2 个月交付深信不疑,于是张罗了接入的客户、市场的物料等。
不难猜到,最终还是没能逃过 90% 定律,2 个月交付的东西只能算作一个 Demo。于是花了另外一个月测试,修复问题和完善业务逻辑,又花了另外几个月时间响应对接客户的要求,才逐渐稳定下来。
行百里者半九十,软件开发也大体如此。开发者估不准工时常有,估准了才奇怪呢。后来自己也做了软件工程师,参与 IT 项目开发,项目延期也是非常常见的事情。
1 工时估算的前提是质量
IT 团队能准时交付是一项非常有价值的能力,哪怕交付时间长一点。计划两周交付,最后能准时完成,比承诺一周时间,但是花了三周才交付重要得多。
越是大项目,越是重要。大项目的各个组件可能会发生相互依赖。如果不能准时交付,就会付出团队等待的成本,那可是真金白银。
做过项目管理的都知道甘特图,甘特图的每个泳道表达了项目各项资源的进展和计划。然而,软件项目不确定性非常多,存在各种突发事件。如果能提高准时按质量交付,各个单位的等待成本会小很多。
关键的是,衡量准时交付的关键是质量,其次才是交付。先给一个 demo,然后再慢慢改 bug。这种 “准时” 的交付,还不如有一个明确的延期时间,本质上还是 “猛糙快”。
谈项目工时估算,应该是在满足质量要求的前提下,否则估时没有意义。
2 提高估算准确性的方法
那么能不能提高软件工程工时的估算的准确性呢?其实是可以的,刚到 Thoughtworks 的时候,参与了一个交付项目。在一个项目开始前就计划了项目结束的时间,以及下一个项目的计划和安排。结果让我非常吃惊,那个项目的结束时间,和预期相差两周左右。并且这两周是逐步减少开发人员,最后只有 1-2 个人负责最后一周的交接期。
这就是专业软件团队和小作坊的差别,在专业项目经理带领下能把 3 个月的项目估算,精确到 20 - 30 个人天。能把项目工时估算到这种程度,体现了 PM 的内功。
在一个敏捷团队,需要把工时估准,不在于 “估” , 而在于团队执行项目的稳定性。一般来说,准确估算工时需要考虑需求分析程度、任务拆分的合理性、技术方案的可靠性、团队成员的能力、外部依赖和环境,如果这个项目不是新项目,还需要考虑遗留系统改造的成本和数据迁移的成本。
2.1 需求和任务分析
只有把需求分析做的非常彻底,才能保证估算的输入条件。非专业的业务分析师,只能看到需求冰山水面上的部分 —— 软件的特性、功能的复杂性等。
专业的业务分析师,不仅需要考虑功能需求,并对功能需求的逻辑性考虑完备。比如用户需要一个 APP,他实际上还需要一个后台,对应这个后台会有不同的用户、角色等。
根据这些业务输出、拆分出任务,敏捷开发中我们叫做用户故事,一个用户故事代表一个合理拆分的业务逻辑。能被评估工作量,然后根据这个工作量来评估工时。
除了这些功能需求之外,还有非功能需求。客户不仅仅需要一个 APP,还可能需要的是一个安全的、高性能的、国际化的 APP,而这些往往被客户当做默认选项。
一些性能优化的指标需要分析,并考虑性能优化的任务工时;安全需求可能有 HTTPS 配置,防病毒扫描等,都需要考虑;国际化也是额外的工作量。
挖掘用户真实需求的目的是定义怎么才算完成(Definition of Done),如果没人说得清楚满足什么条件这个项目才算完,那么估算工时根本无从谈起。
彻底挖掘客户的真实需求是评估项目工时的首要条件。
2.2 技术方案和团队能力
技术方案、团队能力和项目时间估算有很大关系。很多项目的时间估算都是由技术经理或者 Tech lead 来完成,往往是他们按照自己的经验和能力进行计算的。光是这样,很难算的准。
团队有多少人?对这套技术方案的熟悉程度如何?方案是否会发生较大的调整。人一多,人员水平差距就为工时估计带来了不确定性。经验多的人来做方案,如果是他做过的相似方案,自然会估的稍准一点。但大多数情况下没有这么理想的场景。
要做好工时估算,需要结合技术方案和团队成员能力,而不是自己能干多少活儿,多快干完来算。
一方面,技术负责人需要安排相应的技术预研,走在实际编码的开发人员前面,探探路,验证方案的可行性、实施难度、风险。就像作战的侦查人员一样,我们把预研叫做 spike。spike 需要输出一些结论、demo,支持项目的时间估算。
另外一方面,考察团队真实运作效率很好的方式是根据迭代做工时统计。按照两周为例,10 个人的团队是 100 个工时。如果按照之前的估算,2 周内需要完成的 100 个工时的任务,实际上只完成了 50 个工时。也就是进度只有 50%。
我这个算法比较粗糙,敏捷项目管理中还有更准确的速率计算方式。通过速率,就能对下一阶段的工时估算做出调整,并在工作量、人员上做出调整。
通过方案预研和速率计算是提高项目工时估算准确率的良好方法。
2.3 把控遗留系统和外部依赖
我常常花了一下午时间完成了某个特性升级的编码,但是花了一个月的时间才完成了线上平滑升级、数据迁移。
真正有经验的工程师都知道,方案设计的难点往往不在设计一个新东西,而在于演进一个老系统。遗留系统演进是不可避免的,这种历史包袱是造成工时估算不准的一个重要因素。
遗留系统演进带来的估算困难来源下面几个方面:
- 前置条件不满足或者很困难。客户可能觉得只是添加一个小功能,但是涉及数据库变更、API 升级。软件项目往往牵一发而动全身。
- 遗留系统代码难以理解,没有人说得清楚原委。这种系统往往伴随着重构,否则难以进行。
- 数据迁移的成本。例如,需求只是简单要求对用户的某些数据加密,实际工作包括了对存量数据的迁移。
- 临时代码的清理。遗留系统往往为三个状态,原始态-过渡态-最终态,很多人估算工时要么忘记了过渡态,就是忘记了最终态的时间成本。
不负责的猜想,有一些客户就是遗留系统演进不下去了,然后招标做新功能,实际意图是想乙方顺便消化重构的成本。总之基于遗留系统的二次开发都是一件困难的事情,能不接就不接吧。
另外,社会分工意味着一个人干不完所有的事情,IT 项目往往一个项目也不是独立的。大多数情况下需要和外部条件进行集成,这部分时间超出我们的掌控。
集成这件事的成本需要视主动集成还是被动集成来说:
- 需要等待别人提供服务,我们去集成。在估计工时的时候,一定要把对方的交付时间考虑进去,提前沟通,并建立契约。
- 提供给别人服务,被别人集成。这种情况估计工时,往往只是计算到 API 上线,实际上还需要考虑一定的支持、文档工作量。很少有一次到位的情况,大多要磨合一段时间。
集成充满了不确定性,估算工时时需要预留足够的集成空间,才能让工时估算更准确。
3 总结
项目工时估算是一个系统性工作,基本上很难有一个万能的方法。因此大多数情况下都是玄学,但是毕竟是 “估” ,也不能要求 100% 精确。软件工程的估时更具有弹性,相对供应链管理的交付时间估算成本更低。
做好估时,对减少项目运行成本和风险有巨大意义,工时估算的准确性也往往体现了一个 IT 团队工程能力。