提高工时估计准确性,减少开发成本

估时不准是很正常的事情

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

软件项目延期和跳票是众所周知的事情,其中不乏知名项目。

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

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

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

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

工时估算的前提是质量

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

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

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

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

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

估算准确依赖工程能力

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

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

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

需求和任务分析

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

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

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

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

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

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

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

技术方案和团队能力

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

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

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

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

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

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

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

遗留系统和外部依赖

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

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

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

  • 前置条件不满足或者很困难。客户可能觉得只是添加一个小功能,但是涉及数据库变更、API 升级。软件项目往往牵一发而动全身。
  • 遗留系统代码难以理解,没有人说得清楚原委。这种系统往往伴随着重构,否则难以进行。
  • 数据迁移的成本。例如,需求只是简单要求对用户的某些数据加密,实际工作包括了对存量数据的迁移。
  • 临时代码的清理。遗留系统往往为三个状态,原始态-过渡态-最终态,很多人估算工时要么忘记了过渡态,就是忘记了最终态的时间成本。

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

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

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

  1. 需要等待别人提供服务,我们去集成。在估计工时的时候,一定要把对方的交付时间考虑进去,提前沟通,并建立契约。
  2. 提供给别人服务,被别人集成。这种情况估计工时,往往只是计算到 API 上线,实际上还需要考虑一定的支持、文档工作量。很少有一次到位的情况,大多要磨合一段时间。

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

总结

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

软件工程的估时更具有弹性,相对供应链管理的交付时间估算成本更低。做好估时,对减少项目运行成本和风险有巨大意义,工时估算的准确性也往往体现了一个 IT 团队工程能力。

评论已关闭