美国著名的IT咨询公司——Standish集团，从1996年开始，在每年的报告中都发布关于项目成功率的统计信息，在这超过20年的时间内，虽然IT技术以及软件工程方法日新月异，但IT项目的成功率一直徘徊在40%左右。
为什么IT这么难以成功呢？
我们首先要先定义一下：项目“成功”的标准是什么？
国际上比较普遍的认识——按时，按预算，交付客户满意的结果。这里插一句，自从进入了21世纪，项目管理的理论一直都在强调着客户满意。
blob.png
仔细分析，这三个特点都与项目的“估算”工作有密切的关系。为了确保项目的成功，我们首先应该精确地进行进度、成本以及客户期望的估算。
对于软件项目而言，无论是什么估算，其基础都应该是“规模”的估算。也就是要对项目的内容进行“量化”的预估。
在众多的规模估算的方法中，“功能点方法”既符合ISO标准，也符合我国工信部的标准，应该是一个很好的工具。但是在现实中，无论是美国，还是中国，应用还不是很广泛。
挑战
2017年，会迎来IFPUG（国际功能点用户组）章程发布30周年的纪念日。尽管已经走过了30年，目前，国际上的专家认为功能点方法正处于“上升突破期”。
blob.png
在功能点的发明地——美国，还是有很多软件企业不知道，或者是拒绝使用这套方法。我有一位朋友在美国，在世界第二大ERP公司工作过了十多年，他所在的那个团队还是在使用传统的“代码行”方法进行度量。
在中国的情况也差不多，功能点方法的应用主要还是集中在金融、电信行业中的有先进意识的大中型企业。
IFPUG组织的委员David Herron先生，也在2017年最新一期的发刊词中感慨：我们是先进的“少数派”。
之所以面临这样的“少数派困境”，主要原因就是：1、功能点方法需要投入较多的人力和时间成本；2、需要较高水平的功能点分析专家。
而使用“故事点”和“代码行”，需要投入的时间、人力成本就低了很多。
但是,也许信息的成本越低，意味着其自身的价值也不高。
这两种方法都没有形成国际标准，又各自有天生的缺陷。代码行法体现的是成本而非价值，容易造假；故事点法没有办法在不同团队之间进行客观的比较。
那么，我们这些“少数派”如何去突破这个“上升期”，如何去撬动这个标准，而又不投入过多的成本？
应对挑战
国际上有些组织在尝试“基于场景”的方法（behind the scenes），来解决这个问题，尤其是用来解决业内公认的难题——项目早期估算。
前几年，国内“万众创业”的时代，经常有土豪找到我咨询——做一个APP需要多少钱？这个问题真是很难回答。
所谓的早期阶段，项目可能还没有真正立项，仅仅是一个概念，一个想法。在这个阶段，项目的决策层最渴望信息——需要投入的人力、物力是多少？进度计划是多少？
而这个阶段，得到这些信息的基础往往又很薄弱——只知道软件的大概功能范围；根本达不到需求规格说明（specification）的层级。
在这种情况下，如何快速的进行估算呢？
这里就可以用到所谓的“基于场景”法——
1、先找到组织或者项目最典型的场景；
2、对其进行功能点计数，建立起功能点字典（功能点样例）；
3、将场景与用户的业务需求产品，例如：用例（use case）或用户故事（use story）建立折算关系，得到之间的“换算因子”；
4、在新项目的早期，梳理得出大概的业务需求产品后，就能快速计算出软件规模。
举个例子吧——某线下的教育公司X，准备进行“互联网+”，自己没有开发人员，需要找到合适的外包团队。因此在软件开发项目的初期，在招标之前，迫切希望知道大致的成本预算。
他们经过分析得出，其所需软件产品最典型的应用场景就是“课程注册”、“线上支付”、“在线学习”等等。
然后，找到功能点专家针对这些“场景”建立功能点字典——使用标准的功能点方法进行计数，得到相应个功能点数（FP）。再统计得出，对应此“场景”的用例数（use case），用户故事数（use story）。
这里说明一下，X公司中将“用户故事”定义为“用例”的组成部分、一种细分结构。
经过计算，可以得到下表的转换因子。
blob.png
有了这个数据基础，X公司可以针对新项目进行早期的规模估算——
方案一：
先梳理出新项目的场景数量；用数量乘上相应的转换因子，以得到粗略的软件规模结果。
例1：总计10个场景，软件规模即为1246.7个功能点（FP）。
方案二：
分析出所有场景的“用例”数量，用数量乘上相应的转换因子，以得到比较精确的软件规模结果。
例2：分析得出90个用例，软件规模即为1310.4个FP。
以规模结果为基础，再去网上查到2016年软件开发“生产率”的行业数据，就可以得出此项目的工作量。例1的情况，1246.7*7.16=8926人时；大概是50.72个人月。
再以北京地区的人月费率（2.43万/人月）为例，此新项目的预算即为123.24万元。来源：北京软件造价评估联盟