很多人对CMMI的认知，停留在“高层定制度、项目经理管全局、为认证做文档”的层面，但在真实的技术开发与交付的场景里，项目组长才是CMMI实践域落地的核心执行者。我们没有项目经理的全局决策权，没法影响客户的整体项目节奏，却要带着团队把客户需求落地、把CMMI的标准从纸面落到日常工作里，既要保障交付质量，又不能让流程变成团队的负担。

结合CMMI认证落地的一线实操，我从计划、需求管理、估算三个环节，分享一下自己的经验，同时厘清AI在其中的作用。

一、计划：以客户需求为核心，搭建可落地的计划体系

CMMI中PLAN（计划）实践域的核心，从来不是闭门造车做一套完美的计划模板，而是围绕项目目标，让计划指导项目执行。我们所有计划的起点，永远是客户的真实需求。

我们的计划体系，分为核心主线计划、配套支撑计划、主动提效计划三个层级，完全贴合CMMI的计划要求，同时适配项目组长的执行权限：

1.核心主线：交付计划与冲刺任务划分

这是所有计划的锚点。客户发布需求、明确交付节点后，我们第一时间拆解交付计划，把大的交付目标拆分到每个冲刺迭代，明确每个迭代的任务边界、交付物、责任人，确保团队每个人都清楚“要做什么、什么时候做完、做到什么标准”。客户主导的每日晨会、冲刺规划会，就是我们对齐计划、同步进度的核心载体，确保计划不脱离客户的真实节奏。

2.配套支撑：保障交付不脱节的细节计划

很多企业落地CMMI时，只会做交付计划，却忽略了支撑计划，我们基于客户的交付要求，搭建了相应的配套计划：

  • 人员培训计划：跟着客户需求的扩张走，客户业务扩容需要新增人手，我们就同步启动招聘与针对性培训，确保新人能快速适配客户的技术规范、业务要求，贴合CMMI OT（组织级培训）实践域的要求；
  • 请假与人员备份计划：基于客户的交付规则，明确了每人每月请假上限。每个组员至少有其位一位组员了解其任务主要内容，岗位可以备份，即使客户急需完成或产生需求变动，也可以减少对交付的影响；
  • 干系人联系方式、组织结构的动态更新计划：我们会定期更新客户侧、团队侧相关人员的联系方式、职责边界、组织结构，避免出现问题时找不到对接人，造成沟通断档。

3.主动提效：项目组长可主导的月度复盘计划

作为项目组长，我们没法改变客户的整体项目节奏，却能在团队内部主动发力，而月度复盘会议，就是我们落地CMMI过程改进要求的核心抓手。月度会议的核心目标只有两个：一是复盘迭代中团队遇到的共性问题，找到根因，制定一劳永逸的解决方案，避免重复踩坑；二是开展新技术、新工具的探讨，比如2023年AI爆发时，我们测试不同情景下的能力，当时AI上下文能力弱、幻觉还是比较多，但还是能比较好回答技术问题，尤其是对老技术文档的翻译与解答。因为客户用着一款比较老的数据库，没有中文文档，人要通过英文多次查找与翻译文档，而当时AI能一步查找到相关文档，并给出翻译后的解答，可以提升效率。

关于AI在计划环节的作用，我的结论很明确：只能锦上添花，无法替代核心工作。随着和客户的长期合作，我们已经沉淀了成熟的计划模板、培训模板、任务拆分表格，AI可以帮我们做表格数据的汇总、总结，但核心的计划排期、风险预判，必须由熟悉业务、熟悉团队、熟悉客户的人来完成。

二、需求管理：做需求的“翻译官”

需求开发与管理（RDM）是CMMI的核心实践域，而项目组长在这个环节的核心定位，不是需求的决策者，没法从执行层去开发用户的需求，而是需求的 “翻译官”——我们没法主导客户的需求决策，却要把客户模糊的、主观的需求描述，转化为团队可执行、可测试、可验收的客观标准，同时守住需求边界，避免无限制的变更拖垮交付节奏。

结合CMMI的RDM要求，我整理了3个关键动作：

1.需求拆解第一步：先画流程图，理清全链路逻辑

尤其是我们做大数据开发场景，客户的需求往往围绕数据同步、数据处理、数据输出展开，数据的流转链路长、依赖多，稍有遗漏就会出现问题。所以面对新的项目阶段、新的核心需求，我一定会先带着团队画完整的数据流程图，把数据的来源、流转规则、处理逻辑、输出目标、上下游依赖做初步的理清。流程图画明白了，需求的边界就清晰了，后续的任务拆分、风险预判才有了基础。

2.CMMI硬要求：需求与测试的双向匹配

CMMI认证之前，我们常出现“需求做需求、测试做测试”的脱节问题，测试用例有没有覆盖全部需求，全靠测试人员的经验判断。而CMMI的RDM 与VV（验证与确认）实践域，明确要求需求与测试必须双向追溯。我们的落地方法，就是之前沉淀的需求检查清单。大数据开发的客户需求，分为功能性需求和性能需求两大类，我们基于行业标准和客户的业务特性，总结了自己项目的需求检查清单。拿到客户的需求文档后，我们会用清单逐项核对，把客户主观、模糊的描述，转化为可验证的客观需求点，同时排查有没有遗漏的需求维度。如果发现有客户没提到、但业务场景必须覆盖的内容，我们会主动和客户沟通，确认是否需要纳入需求范围，从根源上避免后期的需求变更与交付争议。

3.需求变更闭环管理：先书面对齐确认，后落地调整执行

需求变更是项目交付中不可避免的场景，也是RDM实践域中，实现“需求全生命周期可追溯、可管控”的核心环节。结合过往踩坑的经验，我们给团队定下了一条重要的执行规则：所有需求变更，必须先完成双方的书面确认，再启动落地执行，绝对不接受口头变更。具体执行中，面对客户提出的需求变更，我们不会直接接下需求安排团队开发，而是先完双方沟通好：一是明确变更的范围、业务逻辑、验收标准，厘清变更的边界；二是全面评估变更对现有交付计划、工作量、成本、上下游依赖的影响，同步给客户做决策参考；三是和客户对齐变更后的交付节点、优先级，形成无歧义的共识。哪怕这些内容已经在晨会、日常沟通中口头聊透，最终也必须通过正式邮件完成书面确认，形成客观、可追溯的新需求。

在需求管理这个环节，AI几乎很难发挥核心作用。需求的核心是人和人之间的精准对齐，是对客户业务场景、隐性诉求的理解，最终的需求确认必须由人来完成。AI 最多能帮我们做需求文档的格式整理、要点提炼。

三、任务拆分与估算：从粗放管理到标准化的CMMI升级

有了清晰的计划和明确的需求，接下来就要落地CMMI的EST（估算）实践域，核心就是任务拆分与工作量估算。这也是我们在CMMI认证前后，变化最大、提升最明显的环节。

1. 任务拆分：用WBS拆解到最小可执行单元

我们的任务拆分，完全遵循WBS（工作分解结构）的逻辑，从客户的大需求出发，层层拆解，直到拆成可分配、可执行、可验收、可追溯的最小任务单元。举个大数据开发的典型例子：一个客户的数据同步需求，我们会先拆成需求调研与确认、数据流程图设计、同步脚本开发、单元测试、集成测试、模拟环境部署、文档输出 7 个大模块，每个模块再继续拆解，比如脚本开发会拆成源端数据对接、数据清洗规则开发、目标端写入开发、异常处理逻辑开发等最小任务，每个任务明确责任人、工期，确保不会出现“任务边界模糊、责任不清”的情况。

2. 工作量估算：CMMI带来的标准化升级

CMMI认证之前，我们的工作量估算非常粗放，就是简单的用人天、人时做预估，把任务简单分为开发、测试、文档三大类，全靠项目组长和核心开发的经验判断，误差大、也没法沉淀成组织级的标准。CMMI认证之后，我们引入了国际通用的功能点（FP）估算方法，同时结合大数据开发的业务特性，自己设计了适配大数据开发场景的功能点计算体系。具体怎么做，我会在下一篇文章讲述（《CMMI落地实操：为数据开发场景设计了一套功能点(FP)估算体系》）。

在任务拆分与估算环节，AI可以做一些辅助工作，比如基于我们拆解的WBS框架，做初步的任务细分建议，但核心的拆分逻辑、复杂度判断、工作量校准，必须由人来完成。业务的隐性复杂度、团队的能力边界、客户的特殊要求，这些都是 AI 无法精准把握的。