功能点（Function Point）度量的是软件规模，衡量软件从用户视角看“有多大”，并不直接度量投入了多少工作量。它按外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件等组件计数，再结合复杂度与调整因子得出规模值。工作量需要在这个规模值的基础上，结合生产率、团队能力、技术条件等因素另行估算。理解这一层次关系，是正确使用功能点、避免把它与人天混用的前提。
要点总览（TL;DR）
- 功能点（Function Point）从用户可感知的业务功能出发度量软件规模，回答“软件有多大”，不直接度量投入的工作量。
- 功能点通常按外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件五类组件计数，结合复杂度定权，并可按调整因子修正；计数前需明确系统边界。
- 规模与工作量是两个层次：规模是输入，工作量需在规模基础上结合生产率、团队能力、技术条件另行估算，功能点相同不代表工期或成本相同。
- 功能点、故事点、人天各有用途：功能点适合跨团队规模对比，故事点适合团队内部迭代计划，人天适合排期与成本核算，三者并用时需保持换算关系透明。
- 功能点不能直接当人天使用，也不能替代工时填报与产出考核；功能点数量多不代表质量或价值高。
功能点度量的对象：软件规模
功能点的计量对象是软件的功能规模。它描述系统向用户提供了多少可识别的业务功能，与用什么语言实现、由几个人开发、采用何种架构相对独立。同一个业务需求，用 Java 还是低代码平台实现，功能点计数结果可以一致；但两种实现方式投入的人力和时间往往差别明显。这正是功能点作为规模单位的价值：它提供了一把相对稳定的尺子，让不同系统、不同团队之间的“大小”具备可比基础。
规模与工作量属于两个层次。规模是输入，回答“要做的东西有多大”；工作量是派生结果，回答“做完这些东西需要投入多少”。从规模到工作量，中间需要引入生产率参数，例如每个功能点平均耗费多少工时。这个参数因团队经验、技术栈、需求清晰度、质量要求而变化。因此，功能点相同不代表工期相同，也不代表成本相同。
把这两个层次分开，能避免一类常见误用：用功能点直接排期或报价。更稳妥的做法是先确定功能规模，再用本组织历史数据形成的生产率基线换算工作量，最后结合人员可用性形成计划。是否采用功能点估算，取决于组织是否需要跨团队可比的规模口径，以及是否积累了可用的生产率数据；缺少稳定基线时，功能点更适合作为规模参照，而非精确排期依据。
功能点的定义与计量边界
功能点是一种从用户视角识别和计数软件功能的规模度量单位。计数时关注的是用户能够感知、能够使用的业务功能，例如录入一张订单、查询一份报表、维护一份客户档案，而不是代码行数、数据库表数量或模块个数。代码行数会随语言和编码风格大幅波动，模块数量取决于设计划分方式，两者都难以跨项目比较；功能点从业务功能出发，绕开了这些实现差异。
功能点计数关注业务功能组件，技术实现细节不直接计入。系统采用什么框架、部署在何处、使用哪种数据库，这些属于实现层面的选择，不改变用户可见功能的规模。计数前需要明确系统边界：哪些功能属于被计数的系统，哪些属于外部系统或已有系统。边界不清，同一套需求可能数出差异很大的结果。
功能点有明确的计量边界，以下内容不属于它的度量范围：
- 不度量进度：功能点不回答“多久能做完”，工期需要另行估算。
- 不度量成本：功能点不直接换算金额，成本要结合人力单价与投入量计算。
- 不度量质量：缺陷密度、返工率等质量指标独立于功能规模。
- 不等同于工时填报：功能点是需求侧的规模计数，工时填报记录的是实际投入，两者数据来源和用途不同。
- 不评价价值：功能规模大不代表业务价值高，优先级判断需要结合业务目标。
功能点的组成与计数机制
功能点计数通常围绕五类功能组件展开，它们覆盖了用户与系统交互以及系统内部数据维护的主要形态：
| 组件类型 | 含义 | 典型例子 |
|---|---|---|
| 外部输入 | 外部用户或系统向本系统录入、修改数据的功能 | 新增订单、修改客户信息 |
| 外部输出 | 系统向外部输出数据，且包含加工逻辑的功能 | 生成月度销售报表、导出对账单 |
| 外部查询 | 系统响应外部请求、展示数据但基本不做加工的功能 | 按编号查询订单状态 |
| 内部逻辑文件 | 本系统内部维护、被自身功能使用的数据集合 | 订单主表、客户档案 |
| 外部接口文件 | 本系统引用、由外部系统维护的数据集合 | 读取外部征信系统的客户评级数据 |
计数流程一般分三步。第一步划定系统边界，明确计数范围与用户视角。第二步识别上述五类组件，并按数据元素数量、引用文件数量等维度判定每个组件的复杂度等级，赋予相应权重。第三步汇总各组件权重，得到未调整功能点；如采用调整因子方法，再根据系统特性对未调整值进行修正，得出调整后功能点。不同功能点方法在组件命名、复杂度判定和调整因子上存在差异，实际计数应统一采用同一套方法口径，避免混用。
计数结果落到研发管理流程中，通常需要与需求条目、工作项建立对应关系，便于后续按需求追踪规模变化。ONES 的需求与工作项管理可以承载这类对应关系；当估算结果需要与实际投入对照时，ONES 资源和工时管理解决方案支持统计项目工时、查询和导出工时登记日志明细，帮助项目经理把规模估算与实际投入放在同一项目上下文中查看。
功能点、故事点与人天的区别
这三个概念常被混用，但它们的度量对象和适用场景不同。功能点面向功能规模，具有绝对性，理论上可跨团队比较；故事点是团队内部的相对估算单位，依赖团队共同建立的基准故事，不同团队的故事点之间没有可比性；人天是投入的工作量单位，直接受人员能力、协作条件和任务复杂度影响。三者在估算流程中可以衔接：先用功能点或故事点确定规模，再结合生产率或团队速率换算为工作量，最后形成人天口径的计划。
| 维度 | 功能点 | 故事点 | 人天 |
|---|---|---|---|
| 度量对象 | 软件功能规模 | 团队内部的相对工作量感受 | 投入的工作量 |
| 计量性质 | 绝对性度量，有统一计数规则 | 相对估算，依赖团队基准 | 绝对性投入单位 |
| 跨团队可比性 | 较高，前提是采用同一方法口径 | 低，不宜跨团队直接比较 | 中等，受人员与条件影响 |
| 主要用途 | 规模度量、跨项目规模对比、合同规模基准 | 团队内迭代计划与速率跟踪 | 排期、成本核算、资源安排 |
| 典型误用 | 直接当人天用于报价 | 跨团队比较产能 | 脱离规模与生产率直接承诺工期 |
选用建议可以按目的区分：需要跨团队、跨项目比较软件规模，或需要为合同建立相对客观的规模基准时，功能点更合适；团队内部做迭代计划、跟踪速率，故事点更轻量；排期、成本核算和资源安排，最终要落到人天或工时口径。三者并用时，应保持换算关系透明，例如记录本团队每个功能点对应的平均工时，并定期用实际数据校准。
具体例子与常见误解
设想一个客户管理模块，经计数为 120 个功能点。A 团队技术栈成熟、需求稳定、成员经验丰富，历史生产率约为每个功能点 6 工时，对应约 720 工时；B 团队首次采用新框架、需求频繁变更，生产率约为每个功能点 12 工时，对应约 1440 工时。两个团队的规模相同，投入却相差一倍。这个演示情景说明：功能点回答“有多大”，工作量回答“要投入多少”，后者必须结合具体条件估算，不能由规模直接推出。
围绕功能点，有几类误解值得纠正：
- 误解一：功能点数等于人天。功能点与工时之间需要生产率参数换算，且该参数因团队和技术条件而异。把功能点直接当人天使用，等于假设所有团队生产率相同，估算结果会系统性偏离。
- 误解二：功能点可以替代工时填报与产出考核。功能点是需求侧的规模计数，工时填报记录的是实际投入，两者用途不同。用功能点替代工时记录，会丢失实际投入信息；用功能点做产出考核，则容易诱导拆分功能、虚增计数，偏离度量初衷。
- 误解三：功能点越多代表质量或价值越高。功能规模只反映大小。一个功能点较多的系统可能质量平平，一个功能点较少的系统可能创造了更高业务价值。质量、价值需要各自的指标衡量。
当组织希望把规模估算、实际投入和效能表现放在一起观察时，ONES 效能管理提供从交付效率、交付质量、资源效率、完成情况四个维度分析的度量实践体系，并自动收录系统内日常流转的研发数据形成分析指标。功能点计数本身仍需按所选方法人工或借助专门工具完成，ONES 资料未提及内置功能点计数能力；它的作用更多体现在承接估算之后的需求管理、工时记录与效能分析环节，让规模数据与实际投入数据在同一流程中可追溯。
常见问题
功能点计数结果能直接用来报价或排期吗？
不建议直接使用。功能点给出的是规模值，报价和排期需要的是工作量与成本，两者之间还需要生产率参数换算。更稳妥的做法是先确定功能规模，再用本组织历史数据形成的生产率基线换算工作量，最后结合人员可用性和质量要求形成计划。缺少稳定生产率基线时，功能点更适合作为规模参照，而非精确排期依据。
同一个系统，不同人做功能点计数结果会不一样吗？
有可能出现差异，主要来自三方面：系统边界划定不同、对功能组件的识别口径不同、复杂度判定与调整因子的使用不同。要减少差异，需要统一采用同一套功能点方法口径，在计数前明确系统边界和用户视角，并对组件识别规则形成书面约定。不同功能点方法在组件命名和复杂度判定上存在差异，混用方法口径会让结果失去可比性。
团队已经在用故事点，还有必要引入功能点吗？
取决于目的。如果只需要团队内部做迭代计划和跟踪速率，故事点更轻量，继续使用即可。当出现跨团队、跨项目比较软件规模的需求，或需要为合同建立相对客观的规模基准时，功能点的绝对性度量更有优势。两者可以并存：用功能点做规模基准，用故事点做团队内迭代估算，但应保持换算关系透明，避免同一需求出现两套互不衔接的数字。
功能点估算之后，实际投入数据从哪里来？
功能点是需求侧的规模计数，实际投入需要靠工时记录获得，两者数据来源和用途不同。ONES 资源和工时管理解决方案支持统计项目工时、查询和导出工时登记日志明细，并可查看成员的工作量、可用性与饱和情况，便于把规模估算与实际投入放在同一项目上下文中对照。功能点计数本身仍需按所选方法完成，ONES 资料未提及内置功能点计数能力。
用功能点做团队产出考核合适吗？
不合适。功能点反映的是功能规模大小，与质量、业务价值没有直接对应关系。把它当作产出考核指标，容易诱导拆分功能、虚增计数，使度量结果偏离真实情况。观察团队效能更适合使用交付效率、交付质量、资源效率、完成情况等多维指标。ONES 效能管理提供从这四个维度分析的度量实践体系，并自动收录系统内日常流转的研发数据形成分析指标，可作为效能观察的参考。
