导语：对于产品人尤其是没有开发经验的产品人来说，在评估产品工作量时往往会过度听从开发人员的预估，导致产品时间安排不够合理。而且开发人员评审后大致预估的时间会存在较大出入，因而对于最熟悉这个产品细节的产品经理来说，自己来直接估算开发工作量就显得十分有“优势”了，至少再去和开发对线也不至于完全处于被动地位。

一、什么是功能点，功能点估算有什么用？

对于一个软件来说，功能点是一个可以作为标准的一个计量单位，功能点的多少代表着软件的规模大小，那么有了一个同一的量级的表现后，不同产品或者功能通过功能点来表示，就可以很好地反馈出产品或者功能的复杂程度，同时我们利用功能点来辅助计算效率、成本等也有很大作用。

使用禅道作为项目管理工具的小伙伴，也会在提需求的板块，看到有功能点的录入要求，这也是作为项目管理中，工作量的估算的重要性。

二、功能点估算方法与基本过程

功能点的估算方法有IFPUG和NESMA等，下面主要是介绍NESMA功能点估算法，NESMA估算法更多的在项目前期，可以快速的利用逻辑文件，给出预估的功能点数量，起到较好的指导作用。

NESMA估算法有三种类型的功能点估算，包括：指示功能点计数、估算功能点计数、详细功能点计数；分别对应项目的前期，中后期的功能点估算需求，同时估算出来的功能点也是越来越细化和精准。当然操作难度和复杂度也是越来越高。

对于一般性的产品而言，我们主要是使用前两种（指示功能点计数、估算功能点计数）估算方法即可，两种方法的主要区别就在于计算公式的不同，一个粗放，一个则较精细，两种都可以使用，可以根据自身项目的具体要求和所处阶段来进行选择。

指示功能点计数：ILF*35+EIF *15

估算功能点计数：UFP=（7* ILF+5* EIL+4* EI+5* EO+4* EQ)

下面就来介绍上面的公式中用到的因子以及查找方法。

三、两个逻辑文件与三个基本过程

上面的估算方法中提到的ILF、EIF、EI、EO、EQ代表着什么呢？只要弄明白了这几个计算因子，那么带入公式就可以很快知道我们的这个产品或者功能的软件规模有多大了，所需多少开发量，也就有了较为准确的参考标准。

1. 两个逻辑文件：ILF和EIF

首先我们理解一下逻辑文件是个什么东西。功能点估算法，我们是从产品的角度，用户的视角来进行估算的。那么逻辑文件的概念，也就是从用户的视角出发，来进行定义的一类对用户有意义的信息。

举个栗子：钉钉的日程功能中，我们可以组织日程，发布日程约会，预定会议室等。而这里面涉及到的逻辑文件，就会有 会议通知信息、会议室预定信息 等“逻辑文件”，“逻辑文件”对于用户视角来说，代表着一种业务需求的信息或数据，业务流程要进行，则必然离不开这部分的各种“文件”。另一个角度来说，系统就是由文件与交互逻辑组成的。

1）ILF

代表的是内部逻辑文件（内部接口文件：在本系统维护的业务和数据），如上面例子的钉钉的日程功能中，会议通知信息就是一个ILF（内部逻辑文件），也可以理解为会议通知这个动作，所产生的信息内容。发送会议通知是这一功能流程的交互过程，而会议通知信息，则是这个流程中的内部逻辑文件（ILF）。

2）EIF

代表的是外部逻辑文件（外部接口文件：本系统引用，由其它系统维护的业务数据），如上面举例的钉钉日程功能，假设如果有另外的系统（假设是一个会议室预订系统）来专门运营会议室预定的，在查询会议室预定情况时，就需要请求外部系统的接口，来获取会议室的预定情况，那么这种情况下，会议室预定信息就是一个EIF（外部逻辑文件）。

总的来说，查找逻辑文件的过程，需要站在用户的角度，查找业务流程中涉及到的逻辑文件，然后区分是ILF还是EIF。

这里需要注意的点是：逻辑文件一定是从用户的角度出发定义的，任何因为技术问题需要增加的文件内容都不能算作ILF或者EIF。这里有点甲方的意思，我需要发送一则通知，我不会管你因为发送这则通知需要增加多少个工作表才能完成，你做工作表的工作量是不算入一个软件的功能点的。

那么到这里，如果是对于使用指示功能点计数方法估算功能点数量的情况来说，已经可以完成工作量的初步估算工作了（ILF*35+EIF *15），对于项目前期来说，这个功能点计算结果，已经可以提供较为可靠的工作量参考。

2. 三个基本过程：EI、EO、EQ

对于需要较为精细的功能点估算的，或者是一个较小的功能模块的开发需求，则需要继续进行拆分，寻找每个逻辑文件里面的基本过程，也就是我们上文说到的交互逻辑，不同的交互逻辑的工作量不同，比如查找就常常比修改的工作量小一些。

下面我们就来继续了解三个基本过程：

1. 外部输入EI：对数据进行维护或者该改变系统状态/行为的事物（增删改）
2. 外部输出EO：对数据加功工后呈现或输出的事物（操作数据）
3. 外部查询EQ：对已有数据直接呈现或输出的事物（对数据不处理，即查询）

简单来说：

• EI就是增删改操作，比如发送会议通知，提交会议预定申请等，对现有的逻辑文件进行了操作；
• EO是对数据加工后展示的过程，比如一些数据的展示；
• EQ是一些查询操作，他和EO的区别在于EO的数据规模是不确定的，更偏向于是实时更新的数据规模，按照输入的条件整合后输出展示，EQ则是预设的稳定的数据规模，不需要进一步处理而直接输出的基本过程。

如上面的预定会议的例子中，会议通知查看就是一个EQ（对现有数据的查询并直接输出）。找出了产品/功能中的所有逻辑文件以及其中的基本过程之后，就可以直接放入公式中进行计算，从而得出该产品/功能的功能点数量，那么软件规模就大概有了一个单位比较了。

四、适用范围和阶段

使用NESMA估算功能点的方法，可以比较准确的估算出产品的功能点数量，并反馈开发工作量，但是这个估算法也是存在一定的前提的，比如只有指定类型的产品使用此方法得出的功能点才能真实反映工作量，而其他产品则不适用。

比如以数据和交互处理为中心的；以功能多少为主要造价制约因素的（如电子政务，业务管理系统，办公自动化，ERP等系统）适用NESMA估算法；而包含大量复杂算法；创意型软件；以非功能性需求为主（如视频和图像处理软件，杀毒软件，网络游戏，性能优化任务等）等则不适用NESMA估算法。

因此在进行产品功能点估算的时候，需要先区别自己做的产品类型，根据实际情况进行工作量的估算。

本文由 @大飞Eric 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议