本文是敏捷外包工程系列的第七篇。(
专栏目录
)
各种报价策略分析(下)
上一篇提到一个问题,如果项目“平台化”了,生产一个软件的速度会加快,实际人天会减少,这时候怎么报价?
答案就是
卖功能而非人天。
卖功能而非人天
大约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集成,外部邮件系统的的“联系人”则会被当作一个外部接口文件。
各种报价策略分析(下)
上一篇提到一个问题,如果项目“平台化”了,生产一个软件的速度会加快,实际人天会减少,这时候怎么报价?
答案就是
卖功能而非人天。
卖功能而非人天
大约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集成,外部邮件系统的的“联系人”则会被当作一个外部接口文件。