做大数据开发多年，CMMI认证前后，我遇到的最大痛点，就是工作量估算。

认证之前，跟很多同行一样，估算全靠经验主义：简单按人天、人时做拆分，把任务分为开发、测试、文档三类，靠组长和资深开发人员拍脑袋。好处是快，但问题是：估算误差完全依赖个人经验，估不准；没法沉淀为组织资产，换个项目、换个人，估算标准就变了；更完全满足不了CMMI EST（估算）实践域对标准化、可追溯、可复用的核心要求。

CMMI认证过程中，我们引入了国际通用的功能点（FP） 估算方法。这套方法的核心逻辑，是把传统前后端开发的增删改查作为基础功能单元，按功能类型、复杂度匹配对应功能点，实现标准化估算。但很快我们就发现了致命问题：这套标准是为应用开发设计的，并不适合我们项目。

数据开发的核心产出物不是页面、接口，而是数据表、处理脚本、ETL映射、指标；任务动作也极少有物理删除，通用FP的增删改查逻辑，完全套不进我们的业务场景。没有现成标准，那就结合一线经验自己造。最终我自己设计了一套适配数据开发的FP功能点体系，顺利通过了CMMI认证，还沉淀了组织资产，最后还结合AI实现了估算提效。

一、体系核心设计：完全贴合数据开发场景的FP框架

这套体系的设计思路非常朴素：先锚定数据开发的核心产出物（实体大类），再匹配真实任务动作（功能类型），最后用量化指标定义复杂度权重，最终对应到可计算的功能点数值，确保每一项工作都能精准对应。

1.第一步：按核心交付物，划分4大实体大类

我从数据开发的真实产出出发，把所有工作内容拆分为4个实体大类，每个大类再细分可落地的小类，实现全工作场景覆盖：

  • 表格类：数据开发的核心基础单元，细分为数据表、视图、触发器等，覆盖数据模型设计的全内容；
  • 代码类：开发工作的核心载体，细分为SQL代码（包含存储过程）、通用程序代码两大类，分开设定估算标准，适配不同开发场景的工作量差异；
  • 映射类：ETL工具的核心产出，就是数据处理的Mapping映射与Workflow数据流，以数据流内的映射数与映射内的组件数量为核心计量维度；
  • 文档类：全流程交付的必备内容，包括部署文档、迁移文档、测试报告、设计文档、运维手册等各类正式交付文档。

2.第二步：贴合真实工作，重新定义功能类型

通用FP的动作为增加、删除、修改，但数据开发场景中，我们几乎不会做物理删除动作，绝大多数工作都围绕新增、迭代、验证、调研展开。因此我重新定义了4类核心功能类型，匹配我们的日常工作：

  • 增加：全新的表、代码、映射、文档的从零开发工作；
  • 修改：对已有产出物的迭代、优化、逻辑调整工作；
  • 测试：分为两类，开发环节的自测，按对应开发功能点的50%计算；交付前的单元测试、集成测试、性能测试等，按测试用例数量、测试步骤复杂度单独核算；
  • 研究：针对新技术、新业务场景的体系化调研与验证。

3.第三步：用量化指标，锁定复杂度权重

每个实体大类，都对应可量化的复杂度判定指标，根据不同情况乘以复杂度系数，全团队统一估算标准，杜绝因人而异。

  • 表格类：核心判定指标为单表列数、数据行数，不同量级对应不同复杂度系数；
  • 代码类：核心判定指标为逻辑块数量，关联表的数量，SQL代码和通用程序代码分开设定基准；
  • 映射类：核心判定指标为映射内分支数量、数据流内分支数量，组件越多、链路越复杂，复杂度系数越高；
  • 文档类：一般复杂为1以内，页码多少只影响任务量基数。

至此，这套体系的基础框架完全成型：任何一项数据开发任务，都能先对应到实体类型，再匹配功能类型，然后按量化指标判定复杂度系统。以各类实体各功能任务基数乘以任务量乘以复杂度系数。最终算出对应工作任务的功能点，最终告别了靠经验估算的粗放模式。

二、落地沉淀：从单次估算，到项目基准库

体系刚搭建完成时，大家用起来比较麻烦，复杂度系数还是靠我们的经验设定。而CMMI的核心，就是过程数据的沉淀与复用，我做了两个关键动作，让这套体系真正跑通。

第一个动作，是设计标准化的填报表格。我做了线上的填报表格，要求团队每个任务完成后，都必须填写对应的实体类型、功能类型、复杂度系数、任务量、人天数，最终核算的功能点，确保每一项Jira任务在填报表格中有对应的数据记录。

第二个动作，是搭建项目功能点基准库。我把所有填报的数据导入数据库，通过SQL统计分析，算出不同实体类型、不同功能类型、不同复杂度情况下，历史平均复杂度系数、功能点数、人天数，形成了我们项目专属基线。这样，我们数据团队承接该客户的项目都可以使用同一套标准，如果客户在下除阶段发布数据项目，则可以根据这样历史平均数据做估算。

三、AI 提效：把基准库装进提示词，打造专属估算助手

有了完整的历史基准数据，AI就有了精准发挥作用的空间。我把这套体系的分类规则、复杂度判定标准、历史平均复杂度系数与功能点，全部写入AI提示词，打造了我们团队专属的功能点估算助手。

这里必须明确一个不可突破的原则：AI永远是辅助，核心的需求拆解、任务拆分，必须由人来主导。AI没法把握客户需求的隐性边界、业务场景的特殊复杂度，这些必须由熟悉业务的人来完成。我们的执行流程非常清晰，既保留人的专业判断，又用AI提效减负：

  1. 客户发布需求后，一般项目经理完成WBS初步拆解，项目组长和组员做任务细分梳理，把大需求拆成可落地的最小任务单元，我们拆分的过程可以用AI来辅助，明确每个任务的核心内容、交付物；
  2. 把拆分后的任务描述、核心交付物，输入给 AI 估算助手；
  3. AI基于提示词里的分类、关键词、复杂度规则，自动完成实体分类、功能类型匹配、复杂度等级评估，再基于历史平均基准，算出每个任务的功能点，最终汇总出整个需求的总功能点；
  4. 最后由人做最终校准，结合业务的隐性复杂度、客户的特殊要求，调整最终的估算结果。

这套流程，既保留了人对业务的深度理解，又用AI解决了人工计算效率低、标准不统一的问题，哪怕是新入职的组员，也能快速做出准确率达标的估算，彻底解决了估算能力过度依赖老员工的痛点。

四、不止于认证：为 CMMI 高成熟度量化管理打下基础

很多人觉得，做功能点估算，只是为了通过CMMI认证。但实际上，这套体系给我们带来的最大价值，是为CMMI4-5级（量化管理、持续改进）的高成熟度要求，打下了坚实的基础。

CMMI高成熟度的核心，是用统计和量化技术，管控组织的过程性能，实现持续的、可预测的改进。而功能点，就是我们所有量化任务的统一度量单位。有了标准化的功能点数据，我们就能精准计算出团队的生产率（功能点 / 人天）、缺陷密度（缺陷数 / 功能点）、交付效率、返工率等核心过程性能指标，建立稳定的组织级性能基线与预测模型。最终实现CMMI的数据驱动、持续改进的要求。

结尾

回头看，这套自己设计的FP功能点体系，从最开始为了满足CMMI认证的尝试，变成了真正提升团队管理能力的核心工具。国际通用的标准再好，不匹配你的业务，就是废纸一张。与其硬套别人的框架，不如沉下心来，结合自己的一线实操，打造适配自己团队的体系。最终你会发现，你收获的不止是一张CMMI认证证书，更是团队与组织能力的真正成长。