前面我们探讨”项目管理工具常见问题“，假如公司已经开始使用项目管理软件，收集度量数据 ，就可以开始探讨如何做好项目估算，因没有度量便没有管理。估算解决什么管理问题，先看看以下故事：

项目估算 - 与一副总对话

案例背景： 公司希望部门结算，要采集真正的项目成本数据

公司副总：公司如果只是靠手工收集肯定做不出来，现在我们有项目管理系统，再配合财务制度就可以收集到项目的实际成本。本来财务以为工时表数据收集是越细越好，前面谢谢你和他们加上PMO经理沟通，知道没有需要做到这么细，按每周已经是挺好。项目实际成本这块，我们已经了解，会立马执行。

其实更头痛的是另一问题，我们有些分公司，为了争夺市场报价，我们后面发现项目确实是亏，但是碍于报价的时候，没有一个可靠的依据，只是凭感觉。如何能解决这个问题？

我答：有些做内部IT的公司，比如银行、金融、保险等，这些IT部门都是服务于事业部，他们要建什么IT系统，都要付成本给开发的内部团队，但往往没有一个准则，就很难定付多少钱，开发人员都会比较保守，给出一个比较安全、工作量比较多的报价。事业部就会觉得太贵。报价往往很难定，越来越多公司采纳国际功能点的方式，依据需求，可以客观定项目的规模，有了这个数以后，报价便可直接用功能点乘以一个生产率系数，变成一个标准报价。不需要每次讨价还价。

副总问：你这案例我很希望多了解。我刚说的例子，例如，报200万，他们以为软件成本占70%，但实际上开发成本300万，这肯定亏，但分公司副总会说会，是否因开发团队不熟悉，对客户要求不理解，能力低，才会用上这么多成本，所以应是要求开发把效率提高，而不是让分公司买单。所以场景和你讲的银行案例类似。功能点我很早以前就听过，但是国内同行真正用的很少，为什么呢？

我答：功能点其实从70年代从美国出现后，一直有很多软件公司采用，好处是不局限在什么开发语言，而是需求定好后就有估算，而不是代码行数开发完才知道，但是很多人认为它太复杂，没使用。因为以前是大型的瀑布性开发，人手和功能都多，要准确估算，必须要把每个功能依照它的复杂度，输入输出多少才比较准确，怎么判断也要用很多培训配合。比如有些金融/银行类公司做功能点，就直接招一位专职老师在公司教几个月，很多公司花不起这个时间和成本，但是随着敏捷开发，现在有个简化功能点的方式可以用。

简化功能点的思路和功能点一致，比如它也是以交易的行为来数有多少功能，但是不再分功能的复杂度，把计算的过程，算功能点的时间缩短很多，也不需要项目经理学得很深入来学，当然不好的地方是有20-30%的偏差。

副总问：我觉得这个可以接受，以刚才分公司这例子，偏差可能是50-60%，甚至100%，如果我们用简化功能点，起码可以把这种风险降低，如果有需要才优化，采用更准确的功能点，一步步来做。

答：很赞同。特别我们在敏捷开发，每两周迭代一次，需求变化多，变化后也要重估，所以不用每次估算很准确，还是比较可用。以前很多敏捷项目，都是用故事点的方式。但故事点只是相对，没有一个标准，变成A项目组的故事点和B的不同，限制了开发的项目团队形成一个公司级的基线准则来考核，因为都不同。但如用功能点就可以解决，因为大家都是用一个客观的方式来算规模。

项目规模大小

前面这故事让我们了解到，规模估算很重要，如果没有规模，便没有分母，让项目间可比。但是我看到很少公司度量规模，很多都是直接估项目的工时/成本。

如没有规模，便很难判断项目的真正成绩，比如质量，不能单是看每个项目的缺陷是多少，因项目大小不一，但如果用项目总费用来做项目大小的度量也不合适。

反过来，如公司利用功能点，便可计算每项目组和公司的生产率基线（标杆）。

为什么你不按模型估算？

我们做CMMI高成熟度培训时, 要求客户利用预测模型来做估算。 客户方通常会有数据分析师,分析公司历史数据，建立预测模型。

项目经理利用模型，做好项目估算。

我自己也是读理科数学。 以前觉得数学预测模型都应类似物理学中牛顿的万有引力引力理论一样。 用方程式算出来的对不会错。

后面随着管理软件开发项目越来越多， 越觉得影响项目的进度的因素实在太多，而且大部分是人的因素。

估算：靠模型，还是靠专家？(Model-based Vs Expert-based estimation)

以上的场景我经常碰到。一直困扰软件开发的基本问题 - 依赖专家估算还是利用预测模型来做估算。

什么是专家估算？最典型的例子，就是WBS估算，我们先把所有的任务，系统地分解出来，召集团队和专家估计工作量和工期；
模型就是反过来，利用一些参数模型，如利用功能点数来做其中的一个输入，也包括其他因素，如复杂度、人员能力、平台等，这个模型就会预计出总的，或者每个阶段的工作量或工期；

后者一般比较客观、可重复性，不像第一种那样主要依赖人的主管判断，但倾向于专家估算的人，会批评模型那派，40多年这么多研究，为什么模型估算还不准确，甚至不如用WBS估算。反过来，那些倾向于模型的，就会说如果没有模型，整个估算就像个黑盒，无法帮你知道规模、工作量、进度之间的关系，永远靠专家，尤其是在开发的初期，这种模型特别有用，因为当时你无法很准确估算整个WBS的工作量。
我最近看一个2009的IEEE杂志的文章，两位专家讨论两者的好坏：

左边：北欧学者 Magne JORGENSEN 过去十多年集中研究软件估算，发现专家估算法虽然很常用，但相关研究却不多
右边：Barry BOEHM 81年出版 Software Engineering Economics, 后面又推出 COCOMO 预测模型， 是模型估算的经典人物

看完之后，我更了解为什么不能单靠模型预测。其实模型与专家估算，两者各有好处，没有对错，应该两者都参照才是一个好的估算方法，比如模型的话，可以更好地在早期判断一些方案书，整个项目的成本估计，还可以帮我们比较成本与进度之间的各种取舍。

用专家估算更好帮助我们持续改进，提高生产率，也方便实际与计划对比。

为什么估算开发工作量/工期这么困难？

因除了规模， 还有其他重要的影响因子，例如，项目类型，团队成员等因素。
软件开发很依赖人，主要靠人来做，导致影响生产率的因素很多，如积极性，经验，工具，团队合作等等。用数据挖掘，机器学习，很适合研究一些科学的问题 （物理/化学/生物，如药品的化学成分），因素，效用都好衡量，但是人的因素就没有这么简单。所以过去虽然有几十年的关于工作量的估算模型建立，但准确度一直不太理想。反过来，也不能单靠专家估算，它非常依赖专家的选择，因为人是主观的。虽然主观有可能能帮助做好判断，但也正因为人的主观性，导致估算的偏差。

先把概念理清

很多人以为软件项目估算与其他项目（如土木）类似。我在香港理工教项目管理时，针对一些常见的误解，我们要求学生做估算实验，从亲身体验学习。
学生常见的误解有以下几点:

1. 以为软件估算可以精确到正负几个百分点

2. 以为在项目时间不够的时候，增加人员对项目的进度会有帮助

3. 以为团队人越多，工期就按比例缩短，像建筑工程一样

4. 以为估算是可以单靠一些预测模型简单地估出一个数值。
   

学生都没有软件项目的经验，我们也不可能在上课的时候做软件项目，于是用乐高积木，让他们做估算，比如我们让他们依据一个结果图，估算要多少人时来完成积木，也要看人的乐高经验，首先第一步是他们单独做估算。我们在课程中用了Wideband Delphi 估算法，每个人多轮估算，并真实地建乐高，看看实际用了多少时间。
然后我们在课程中加了一些估算模型，用一些历史数据给他们进行参考，下面就是我们的一些发现：很多人在没有经验的时候都会高估，用了Wideband delphi 的方式会确实比较准确。 后面有了实际数据，要求学生利用软件项目估算模型方式来估，他们就发现这不容易，很多时候，有学生直接改用简单方程式做估算。
学生自己动手来估算，才会有感觉，真正了解软件估算的各种困难。

如需求不清晰，怎么办

估算完全依赖于对项目需求的理解，当需求不明确时，就应该采用迭代或敏捷的方式。看下图左下角，如果需求非常明确，就可以完整的估算整个项目的规模与工作量与进度，但如果需求的变化很频繁，开始的时候很多需求只是大概，就应采取敏捷精益的概念，用迭代，每迭代2-4周左右，只对本迭代冲刺可确定的功能，做估算与监控。每一轮的估算跟前面的方法一样，可以采用专家估算，按WBS或每个模块多少，加起来的工作量多少。也可以用预测或者以往的数据做基础，估算工作量。冲刺或迭代完成后，立马就可以与实际比较，如需要可调整后面的估算。因每个迭代都有反馈，所以我们估算准确度会越来越高，有一个闭环的作用。因每次迭代估算完之后，会依据实际调整，就如我前面所说，就不需要估算的很准确。
但管理者首先要理解当需求不明确时不能采用传统的估算思维，不要在开始时问项目经理这个项目总共要多少时间，多少个月完成，成本多少？因敏捷与传统项目不同，范围(Scope)是不定。
因需求不明确，我们只可以粗略做大概的总体估算，但这个准确性就很粗。
CMMI的估算包含生命周期选择，意味不同的项目、团队、客户，最佳的估算方法都不同，要依据项目特性，选择传统瀑布性开发还是敏捷。

总结

• 如果要估算在项目之间可比,成为标杆，便不应直接估算人天，最好还是依据功能点，作为客观评价，然后利用功能点做从上而下的客观总体估算

• 估算本身有很多变数，不要误信用预测模型可以很准确地估算,每个估算除了一个单点外，必须有个范围

• 所以也要从下而上，做工作任务分解专家估算，与从上而下对比

• 估算需要不断纠正，不应只做一次，开始的时候，会比较粗，但当项目一直开展，就可以从实际的数据调整估算，越来越准

• 因很多人都对项目估算有误解，大家要先了解估算的概念

• 当需求不确定时，我们就应该走迭代或敏捷的开发模式，估算概念类似；只是每一轮(2-4周)可以更快速收集到实际的项目数据，修正估算

要做好项目估算没有金科玉律, 但必须要有可靠的项目管理工具， 收集正确的项目数据。 也要配合培训，公司才有可能把项目估算做好。

虽然功能点估算规模有很多好处 - 国际标准，项目/公司之间可比，项目早期（需求定了）已可使用，不受不同开发语言影响，但为什么功能点仍未被广泛使用？
其中一个原因：很多人不懂，要花精力学，要用人工进行计算，耗时，尤其当软件很大的时候,这困难便更明显。下一篇，我们继续探讨有什么好方法。

附录：功能点 简介

功能点，例如，国际功能点 IFPUG 会依据输入，输出，查询的数量，
加上每一个的复杂程度（高中低）来计算UFP。
然后再用14个调整因子
另一种常用的功能点方法 NESMA 也类似

附录：Wideband Delphi(德尔菲) 简介

反馈

一位很熟悉银行业务的IT顾问反馈：
很贴合当前很多软件公司的运行现状，在现在的软件行业竞争很厉害，很多公司为了争取合作机会，不惜亏本销售，而现在的软件人力成本又在不断上升，所以领导的压力很大。(管理者开始关注项目成本控制与估算。)

关于估算，我建议：

1. 对于一些常规功能，如果公司已建立估算模型，建议根据模型估算，这样省时省力，相较比较公正，且符合公司的实际情况（但同时需考虑项目组成员的人员结构）。

2. 对于一些特殊功能，特别是一些复杂且需求不明确的功能，在估算时需要充分考虑到开发过程中的风险因素，建议在功能点估算时增加风险因子的权重。

3. 在大多数企业中，大部分领导层对估算的理解还停留在一次性估算上，但在项目实际实施时，估算是可以根据实际情况进行修正和调整的，这个是需要多方认可的。

4. 公司在向客户报预算时，也需要考虑必要的利润、项目实施环境影响及一些其他的风险因素，需要考虑实施、利益、关系维护之间的平衡。

另一位资深北京项目总监反馈：

1. 首先应该正确认识估算的位置，估算就是为项目进行提供一个参考标杆；实际执行过程中，需要根据实际情况，进行修正和调整

2. 历史数据可以作为参考，对于历史数据，我更关注初始估算与实际发生的偏差，偏差的原因，这个可以指导项目经理估算后进行适当的修正，特别是估算作为报价参考时

3. 个人倾向于专家估算与估算模型结合使用。当然，估算作为一项项目管理活动，上下都重视的时候，才能发挥作用

4. 在有些单位，将项目估算作为项目奖惩的依据，不利于积累正确的估算数据

References

Jorgensen and Boehm: Software Development Effort Estimation: Formal Models or Expert Judgment (2009 IEEE)
PMI : Agile Practice Guide (2017)

源文出自高级评估师宋世杰