敏捷外包工程之七：报价管理（功能点）

本文是敏捷外包工程系列的第七篇。（ 专栏目录 ）

各种报价策略分析（下）

上一篇提到一个问题，如果项目“平台化”了，生产一个软件的速度会加快，实际人天会减少，这时候怎么报价？

答案就是 卖功能而非人天。

卖功能而非人天

大约2008年左右还没有加入IIOM（国际外包管理协会）的时候，我曾经接到一个电话，说老外拿来一个需求文档，能回答两个问题的人可以得到这个项目。两个问题是：“这个项目要多少钱？为什么？”这个问题最早被提出来，应该是整个世界第一次出现“软件”这种东西的时候了，但最终被解答却是在1970以后，国外外包领域现在已经广泛应用，而中国至今很少有公司在使用。

那就是功能点。

功能点简介

操作类功能点

此处的功能点（英文Function Point）和我们平时说的功能点不是一个概念，是由相对严格的方式定义、甲乙方都可以理解和计数的功能的数量。

比如“用户增删改操作”“查看所有用户”在我们看来是两个功能，但功能点认为是增、删、改、查看所有四个操作，因为这四个操作都满足：

1. 可识别性

每一个操作都是客户可以理解的，他们能意识到这是自己的“业务”。

所谓“业务”，就是他们购买此软件的目的。比如，一个OA系统，里边应该有维护人员的工作要做，客户的系统管理员会认为“对用户进行增删改查”是自己的日常工作的一部分。

2. 独立性

在某一次操作中，客户可以独立操作其中一个（尽管之前很久可能曾经操作过另一个，或之后很久可能也会操作另一个）。

独立性与我们常说的功能依赖性之类的相似但又不尽然相同。

比如我们会想：一个人如果未曾添加用户，如何查看或删除？一个人如果不先查看并找到用户，怎么可能把它删除？如果不列出所有用户，那么怎么点击查看单个用户或编辑其中一个用户？所以这些功能之间是有“依赖”的。

但对于用户而言，他们理解的“业务”依赖性，是指是否每次都要同时执行其中两个业务。

比如：

a 有人离职了，管理员进来删除了一个用户。这时候管理员感受到的是自己做了一次“删除用户”操作。举一个形象的场景：管理员的领导问“你今天上午做什么了？”管理员会回答“我删了三个离职的员工”，他不会列举查看了所有员工，并查到了三个员工，并打开查看了详情以便确认，然后才删除的。这就是要注意业务操作和功能的区别。

b有人问系统中有多少用户，管理员点击打开了用户列表，并回答说有N个。他感受到的是此系统有“查看所有用户”的业务功能。

c有人报告自己的名字被写错了，管理员帮他修改好。他感受到的是此系统能“修改用户信息”。

等等。

3. 完整性

每一个业务操作都向客户交付了一个完整价值，完成操作后系统进入一个相对稳定的状态（比如可以离开、关机）。

相对稳定的状态不是太好描述，但整体上说，即使整个业务链还没有完成，但系统已经进入一个在等待别人响应，而自己工作已经告一段落的状态。比如“发送邮件”后，基本上就没有马上一定要做的事情了，尽管对方还没有收到。但是“将邮件添加到发送队列”“队列马上或定时发送走”这两个操作，则不是单独满足完整性的，他们是技术上的两个步骤，但不是业务上的。从业务上说，这两个加在一起才是“发送邮件”。

比如：

注册用户：点击注册链接，在弹出的窗口中，填写用户名密码，重复输入密码，再点击下一步；填写邮箱和……，再点击下一步；……；点击“完成”按钮；一封邮件会发送到邮箱中；到邮箱中点击链接，激活并完成注册。

这整个事情，是一件事情，就是注册用户。

操作类功能点的分类

操作类功能点被分为三种：

EI外部输入（增、删、改等影响内部数据为主的操作，也包括“杀毒”等启动类操作）

EQ外部查询（不涉及计算的原始数据查询，比如打印流水表之类）

EO外部输出（涉及计算和复杂输出操作，比如复杂的年度报表，图表等）

下面会提到 简化估算中，可以不区分操作类型，但应该意识到其存在。

当然同一个功能，有简繁之分，所以功能点提供了一些评判简繁的方法。可惜，这些方法需要很多业务细节（与技术无关），比如有读写多少个业务数据，分别有多少个字段等等。这些细节对于分析业务有很多好处，也为后来功能点的定义、数据分析做出了贡献。但对于每次都要做估算的项目而言，有点过于细节。后面会讲到如何细化。

数据类功能点

除了操作外，被管理的业务数据也要被功能点计数。

业务数据的定义大致如下：

1. 可识别性

就是客户能识别和理解这些数据。

比如一个OA系统，应该有用户、角色、权限……邮件、会议……这些要管理的信息。而一个手机应用，则可能管理联系人、短信、黑名单……等。

业务数据很类似数据库中的表，但注意在数据库中，这些信息有可能1：1或1：N或N：1或N：N地存储于不同的表中，这些都是技术问题。比如“用户”的用户名、密码、邮箱可能单独存储于一个表格，而兴趣爱好则再另外一个地方，但客户不会因此而按数据库表的数量评估有多少个业务数据，只会笼统地认为有一个“用户”在被管理。

2. 要管理的数据是客户的业务数据

所谓业务数据，就是客户购买或使用我们产品的最终要管理的数据。

比如，为了填写订单时能帮助用户查找自己的邮政编码，电子商务网站可能会帮助用户根据地址查找“邮政编码”，但邮政编码却不是他们要管理的业务内容。所以尽管可以理解，并不会真的把“邮政编码”当作业务数据。在功能点分析中这类数据叫做Code Data，编码文件。

3. 对每个业务数据，大致有4～9个业务操作

这一条是我自己加的，已被刚发布的行业标准所采纳为“简易识别规范”（等等说它的依据）。

1和2的定义还是很含糊，为了方便确定哪些“名词”是业务数据，哪些不是，加个操作数量最直观。

因操作太少而不是业务数据的例子：

再来看“邮政编码”，肯定没有增删改这些操作，只有一个“查”；或许还有一个“批量更新”，就是发生变化后一次性把所有修订后的版本更新上去。所以，只有1～2个操作，不是业务数据。一般而言，缺乏“增删改查”5个操作的名词一般都不是业务数据 （“查”一般是两个，查看单个，查看所有）。

因操作太多而需要拆分的例子：

而“邮件”，则可能“新建、编辑、保存（草稿）、打开（草稿）、发送、抄送、密送、发给群组……”或“接收、转发、回复、回复所有、删除、挪文件夹……”太多了，要怀疑包含多个业务数据的可能。其实，前者是“发件”，后者是“收件”，是2个。刚才提到的“会议”也很可能超过这个数目，而应该被拆分为“会议计划”“会议通知”“会议记录”等，取决于实际情况。

在有这条简易识别规范之前，有一个很拗口的官方识别方法，很不好操作而且主观性很大。 这条简易识别规范实际上来自于NESMA的简化功能点时做的假设，即每个业务数据大致对应7个操作。

数据类功能点的分类

数据类功能点有两种：

一种是内部逻辑文件（ILF）即系统内部存储的业务数据，比如前面提到的用户、角色、权限和邮件、会议。

一种是外部接口文件（EIF）即系统要调用别人的数据，比如如果做LDAP集成，外部邮件系统的的“联系人”则会被当作一个外部接口文件。