外包项目型 vs 自研产品型：CMMI 差在哪

两类业态对照：一张表看清分叉点

先看全局。这张表的用法不是背下来，而是拿它对照自己企业：哪一列的描述更像你，准备重心就在哪一列。现实中不少企业是混合体——外包起家后来做自有产品，或者产品公司接定制单养团队。混合体不能整列照抄，要逐行判断，尤其是"项目边界"这一行：同一家公司里，两条业务线的"项目"很可能是两个意思。

一、项目边界与估算：合同范围，还是版本范围

这一节是两边分叉的源头。后面所有差别——需求怎么管、资产怎么建、度量怎么选——都是从这里推出来的。边界定错了，证据链从开头就是歪的。

外包项目型：项目就是一份合同

外包公司的"项目"通常有很强的外部定义：客户有招标文件、有合同、有任务书、有验收标准，甚至有自己的里程碑命名习惯。这带来一个便利——边界不用自己解释；也带来一个约束——边界的解释权不完全在自己手上。

具体要做的事：

• 把合同拆成可管理的结构。合同里的阶段划分、交付物清单、验收条件，要能对应到内部的项目阶段与工作产品。很多外包项目的记录之所以断，是因为合同按"一期二期"分，内部按"设计开发测试"分，两套话对不上，一抽样就找不到对应关系。
• 估算要有依据，不是先有报价再倒推。投标估算至少写四样：规模（功能点、模块数、接口数，按自己习惯的口径）、复杂度与复用度判断、假设条件（客户提供什么、什么时间提供）、以及历史参照（做过哪类项目、当时偏差多大）。缺了假设条件，估算在评估时就是一句"我们按经验报的"。
• 变更要三边联动。范围变了，工期、成本、人力要同步调；只调其中一边，后面一定是加班补或者减配交付。变更单上要能看到"影响分析"这一段，而不是只有客户签字。
• 多客户并行时，项目主数据要统一。同一个项目在合同台账、立项单、工时系统、验收单里的名称与编号要一致。这是评估时被交叉核对的常见落点。

还有一条容易被忽略：人力外派型项目的过程边界不在自己手里。如果客户派了自己的项目经理、用了客户的流程与工具、交付物直接进客户的库，那么"这个过程是我们组织的"这句话就很难成立。这类项目可以做，但通常不适合当评估样本——不是说它不算项目，而是它的过程证据归属不清。

自研产品型：项目就是一个版本

产品公司的"项目"是自己定义的：这个版本做什么、不做什么、什么时候发、发到什么范围。听起来自由，实际上更难——没有客户替你划边界，边界就得自己写下来并且守住。

具体要做的事：

• 版本范围要有明文。一份版本说明，写清包含哪些需求、不包含哪些、依赖哪些外部条件、验收标准是什么、谁批准的。没有这份东西，"项目"在记录里就是散的：需求散在池子里，任务散在工具里，版本只在发布通知里出现过一次。
• 估算按容量切，不按愿望切。先算这个版本可用的有效人力，再往版本里装需求；装不下就砍范围或者挪版本，而不是先承诺功能再想办法。这一步是产品公司估算与外包估算的关键差异：外包的约束是合同额与交期，产品的约束是团队容量与市场窗口。
• 没进版本的需求要有去处。回到需求池、进下一个版本、或者明确关闭。产品公司常见的现象是"讨论过但没做"，既没记录也没关闭，时间一长就说不清哪些是被否掉的、为什么否。
• 技术债与稳定性要有独立配额。全部容量都给业务需求，版本节奏看着快，两个季度之后发布就开始出事。这一条在评估里对应的是"过程质量有没有被纳入计划"，而不是"你们代码写得好不好"。

二、需求管理：客户变更单，还是需求池与优先级

需求这一节，两边的日常动作几乎是相反的。外包公司的主战场是挡——挡住范围蔓延，把每一次增加都变成有代价的变更；产品公司的主战场是选——从一堆都想要的需求里挑出这一版要做的，并且承担不做的后果。

外包项目型：把口头变成单据

外包项目出问题，多半不是因为需求复杂，而是因为需求以非单据的形式进来了：会上说了一句、微信发了一段、客户领导打了个电话。做完了不算变更，不做又得罪人。

• 变更单要有固定结构。提出人、时间、内容、影响分析（工作量、工期、成本、对已交付部分的影响）、结论（接受/拒绝/延后）、双方确认。结构固定了，才谈得上"每次都走"。
• 影响分析不能只写"增加若干工作量"。要写清影响到哪些已完成的模块、哪些测试要重跑、里程碑要不要挪。这一栏是变更单里信息含量较高的一栏，也是评估时被追问的地方。
• 需求跟踪要能对上三层。合同条款与任务书条目 → 需求条目 → 设计、开发任务、测试用例。三层能对上，才能回答"这条合同要求在哪里被实现了、怎么验证的"。
• 客户评审要留问题记录。客户参加评审是外包公司的天然优势，但如果评审记录只有签到表和"通过"两个字，这个优势就用不上。要留：提出了什么问题、谁负责、什么时候关闭。
• 拒绝也要留痕。没做的需求、没接受的变更，同样要有记录和理由。评估时问"客户提的这个为什么没做"，答"当时忙"和答"评估后认为超出合同范围，已在某次例会向客户说明"是两种完全不同的状态。

自研产品型：把"想做"变成"排序"

产品公司的需求不缺来源，缺的是结构。需求池如果只是一个列表，它很快会变成意见箱：谁都往里丢，谁都不负责关。

• 需求要有状态机。收集 → 评估 → 排期 → 开发 → 验证 → 关闭（或搁置）。每一次状态变化有记录：谁改的、依据什么。有了状态机，"这条需求后来怎么样了"随时能答。
• 优先级规则要明文化。价值（用户价值、商业价值）、成本、风险、依赖关系，四个维度里至少说清看哪几个、怎么比。规则不必复杂，但必须一致——同一类需求在不同版本里用不同标准排序，数据就没法比较。
• 需求与版本要能互查。从版本能列出它包含的需求，从需求能查到它在哪个版本被实现。这一条是产品公司做 CMMI 时常缺的一环，因为它天然被工具切成两半：需求在一个系统，版本在另一个系统。
• 线上反馈要能回流。用户反馈、客服工单、监控告警、数据异常，都要有进入需求池的通道，并标明来源。这条通道存在与否，直接决定"持续改进"在评估时是有据可查还是只有口号。
• 取舍要有人负责。谁定优先级、谁有权插队、插队要付出什么代价（把哪个需求挤出去），写下来。产品公司较常见的失控不是"没人决策"，而是"决策没有代价"——每个紧急需求都插进来，版本范围默默膨胀，事后没人承认改过范围。

三、过程资产：多客户多套流程，还是一套流程多产品线

到了 3 级，这一节是分水岭。3 级要求的是组织有一套标准过程，项目按裁剪指南生成本项目的已定义过程，裁剪有理由、有审批。两类企业在这一条上的失败方式完全不同：外包是"根本没有组织级"，产品是"有组织级但没人按它裁"。

外包项目型：碎片化是天生倾向

外包公司每接一个客户，往往就多一套要求：A 客户要求用它的缺陷管理工具、B 客户要求每月提交固定的度量报表、C 客户要求评审必须有其代表签字、D 客户直接把它的研发流程文件发过来让你照做。这些要求都是真实的合同义务，不能不遵守。于是几年下来，公司里并存着好几套流程，谁也说不清"我们公司的标准过程"是什么。

具体要做的事：

• 把客户要求当裁剪输入，不当新体系。建一份"客户特殊要求清单"，逐条写明：哪个客户、要求什么、对应到我们标准过程的哪一条、差异怎么处理（增加活动、替换模板、增加评审点）。清单本身就是组织级过程资产的一部分，也是评估时很好用的说明材料。
• 项目已定义过程必须由裁剪指南生成。允许项目按客户要求调整，但调整的起点必须是公司标准过程，路径必须是裁剪指南。项目自己另写一份流程文件，就等于组织级断链。
• 公共部分要收归组织级。估算方法、评审规则、配置管理、缺陷分级、结项条件——这些不该跟着客户变。判断标准很简单：这条做法换一个客户还成立吗？成立就归组织级，不成立才进客户差异清单。
• 多套并行的要有主次。如果确实需要两套以上差异较大的流程（比如完全不同的交付形态），就说清适用范围与选择规则，而不是让项目自己挑顺手的那套。

外包公司还有一个特有难点：不同客户的项目在同一个部门里并行，人员是共享的。同一个开发今天在 A 客户项目上按 A 的流程走，明天在 B 客户项目上按 B 的走。这时培训与过程符合性检查的难度会明显上升，检查表要按客户差异做分支，不能一张表打天下。

自研产品型：一套流程容易硬套

产品公司通常不缺一套流程——研发流程、发布流程、代码规范、上线审批，多数公司都有。问题在于这套流程往往是"按主力产品长的"，套到新业务线、套到小团队、套到维护型版本上就开始别扭，于是团队私下绕开，流程名存实亡。

具体要做的事：

• 用裁剪档位代替"每个团队自定"。按交付形态或团队规模定义几档（比如新功能版本、维护版本、紧急修复），每档写清哪些活动必做、哪些可合并、谁批。档位是组织级定义好的，不是团队临时决定。
• 把发布与线上纳入标准过程。产品公司的过程资产如果只写到"测试通过、准备上线"，就漏掉了自己特有的那段——灰度、回滚、线上问题处理、版本对比。这一段恰恰是产品公司相对外包的差异所在，也是评估时会重点看的地方。
• 平台、中台、业务线的差异要有依据。不同产品线用不同流程是合理的，但"合理"要写下来：因为什么差异、差异体现在哪些活动、由谁批准。写不下来，就只是习惯。
• 过程资产要跟着组织变。产品公司组织调整频繁——拆团队、并团队、换技术栈。每次调整后，过程资产如果不更新，就会和实际做法脱节，一年后就成了"归档文件"。

四、度量与数据：工时与验收，还是发布与线上指标

度量这一节很能看出业态差异。外包公司的数据天然围绕"履约"生成——工时、进度、验收；产品公司的数据天然围绕"版本"生成——发布、缺陷、可用性。两边都不缺数据，缺的是能把数据用于判断的那一层。

外包项目型：数据长在项目台账里

外包公司的度量体系通常已经很成熟，因为它服务于结算：工时填报、月度对账、里程碑确认。这套数据的问题是服务对象是财务与客户，不是过程。拿它直接当过程度量，会出现两个偏差：工时口径按合同分而不是按活动分，缺陷统计按客户分而不是按阶段分。

• 工时口径要能拆。至少要能区分：需求、设计、开发、测试、评审、返工、售前支持、维护。只有总数，就无法回答"返工占了多少""评审投入和缺陷数量有没有关系"。
• 缺陷要按阶段与严重度统计。需求阶段发现的、开发自测发现的、系统测试发现的、客户验收发现的、上线后发现的——分阶段统计才有过程含义。只统计总数，只能说明"这季度出了不少问题"。
• 返工要单独记。返工是外包公司成本的主要漏点，也是常被忽略的度量项。返工原因要分类（需求不清、设计缺陷、沟通问题、客户变更、环境问题），分类之后才有改进的落点。
• 进度偏差要有统一算法。按里程碑算还是按完成量算，全公司要一致。同一个项目在周报里"完成八成"、在月度会上"延期两周"，这种矛盾在评估现场很难解释。
• 验收与客户评价要结构化。验收一次通过情况、验收提出的问题数量与类型、客户满意度调查的结果，都可以入度量，但要有固定口径。

自研产品型：数据长在流水线与监控里

产品公司的优势是数据自动产生：代码提交、构建、部署、缺陷、告警、埋点。优势也带来一个误区——以为有数据就等于有度量。工具里几百个图表，没人用它做版本判断，那只是仪表盘，不是度量体系。

• 需求交付周期要能算。从需求进池到上线的时间，按类型分开算（新功能、优化、缺陷修复）。这是产品公司衡量"迭代快不快"的硬指标，比"我们两周一个版本"可靠。
• 发布相关指标要成组看。发布频率、发布失败与回滚情况、发布后短期内出现的缺陷——三个一起看才有意义。只看发布频率，会鼓励"多发但发不稳"。
• 线上质量要能回溯到版本。缺陷按发现阶段分类（内测、灰度、全量、客户报障），能追到是哪个版本引入的。逃逸到线上的缺陷比例，是产品公司过程能力的一个直接反映。
• 口径写死，不许中途换。同一个指标，算法换了就要标出新旧口径的分界点。产品公司团队变动快，换一个人换一套算法是常见现象，结果是历史数据接不上，基线建不起来。
• 至少有一组数据是用于决策的。判断标准很朴素：上一次因为数据不好而调整计划、砍需求、加人、改流程，是什么时候？如果找不到这样一次，说明数据只是给别人看的。

五、供应商与外包管理：再分包，还是开源与云依赖

这一节两边的风险形状不同。外包公司要管的是往下再包出去的那一层——分包方的活干得怎么样、过程跟不跟得上；产品公司要管的是往上依赖的那一层——开源组件、云服务、第三方接口变了，我们的版本计划跟不跟得上。

外包项目型：分包方的过程要拉进本项目

外包公司再分包很常见：人力不足时分给合作团队、特定技术栈交给专精方、非核心模块整体外购。问题在于，分包方交的是结果，评估看的是过程。如果分包方只交了一个能跑的模块，没有评审记录、没有测试记录、没有配置基线，那么这个模块在项目证据链上就是个洞。

• 分包方要有清单与能力评估。谁能做什么、做过什么、评价如何，形成台账；同一类分包不要每次重新找。
• 分包协议里要写过程要求。交付物清单、评审参与方式、缺陷处理与回归要求、配置与版本交付格式、保密与知识产权、进度报告频率。这些条款在签的时候嫌麻烦，出问题时是主要的依据。
• 分包方的进度与质量要纳入本项目跟踪。不能只看"它交没交"，要看它的计划、它的缺陷、它的变更。项目周报里如果分包部分只有一句"分包方正常推进"，等于没管。
• 外派人员要双重管理。人在客户现场、按客户流程工作，但劳动关系、能力评估、培训记录在自己公司。这类人员的项目角色任命要能说清：他在这个项目里承担什么、向谁汇报、由谁评价。
• 客户指定分包要单独说明。有些项目里分包方是客户指定的，过程要求由客户定。这种情况要留下说明：谁指定的、过程要求从哪来、我们做了什么跟踪。不能因为"不是我们选的"就不记录。

自研产品型：依赖变更就是计划变更

产品公司的外部依赖大多不是"人"，而是"东西"：开源组件、云服务、第三方 SDK、支付与推送通道、应用市场审核规则。这些东西平时不用管，一出事就是版本级的影响。

• 依赖清单要有人维护。用了哪些组件、什么版本、什么许可证、谁引入的、用在哪。这份清单在安全合规里要用，在过程管理里同样要用——出了漏洞，能不能马上定位影响范围。
• 漏洞与升级要有决策路径。发现组件漏洞，谁评估、多久内决定、升级影响哪些版本、要不要发补丁版本。这条路径写下来，才不至于每次临时开会。
• 云服务与第三方接口要有降级方案。对方不可用、限流、改接口、涨价，四种情况分别怎么应对。这一类风险在外包项目里也存在，但产品公司更集中——因为一套服务被多条产品线共用。
• 外采与定制开发要按项目管。产品公司也会外采模块或委托定制。这部分要有验收标准与验收记录，不能因为"是内部产品"就跳过验收。
• 分发渠道的规则变化要纳入计划。应用市场的审核要求、隐私政策要求、接口权限收紧，都会影响发布。这类外部变更如果从来不进版本风险评估，发布延期的原因就永远说不清。

六、人员与培训：项目组进场退场，还是长期团队与梯队

人员这一节，两边的管理节奏完全不同。外包是"项目节奏带人"，项目来了招人、项目结束散人；产品是"团队节奏带项目"，人相对稳定，产品线长期存在。这个差异会直接影响培训设计、角色任命和知识沉淀的方式。

外包项目型：要能快速补位

外包公司的人员流动有外部原因：合同结束、客户不满意换人、项目间调配。这意味着培训的目标不是"培养专家"，而是"让新人能在可控时间内按流程干活"。

• 角色任命按项目下发。每个项目的项目经理、需求、开发、测试、配置管理角色，要有书面任命，且与实际做事的人一致。人员中途更换要有变更记录，不能只在群里说一声。
• 交接清单要固定。代码、文档、客户接口人、未关闭问题、待确认事项、环境与账号。交接做得糙，下一个接手的人就得重新摸一遍，这段时间的过程记录通常是空的。
• 培训分三段。公司级（流程、工具、质量要求）、客户级（这个客户的特殊要求、沟通习惯、交付格式）、项目级（这个项目的业务与技术）。三段里客户级常被跳过，也常出问题。
• 关键角色要有备份人。项目经理、配置管理员、客户接口人，各有一个备份。这不是为了评估好看，而是项目密集交接时的现实需要。
• 多项目共享人员要有边界。一个人同时挂三个项目，工时怎么分、任务优先级谁定、出问题找谁——这些要在计划里写清，否则三个项目的跟踪记录都会失真。

自研产品型：梯队比人手重要

产品公司的风险不是"人走了项目断"，而是"人走了这块没人懂"。一个核心模块只有一个人熟悉，这个人休假两周，版本就要延期；这个人离职，接手的人要读三个月代码。

• 按产品线建能力矩阵。横轴是模块或技术域，纵轴是人，标出"能独立负责、能参与、不了解"三档。矩阵的作用是让单点暴露出来，而不是做一张漂亮的表。
• 关键模块要有第二个人能接手。不是要求两个人干同样的活，而是要求除了主责人之外，还有人能改、能上线、能处理线上问题。这一条落到计划里，就是轮换、结对、代码共读这些动作。
• 培训分三层。入职通用（公司、流程、工具）、产品专属（业务、架构、领域知识）、过程工具（估算、评审、发布、缺陷处理）。产品公司常缺的是第二层——业务知识靠口口相传，新人上手全靠带。
• 技术等级与过程角色挂钩。谁能当评审人、谁能批发布、谁能做估算复核，与能力和资历对应起来，而不是临时抓人。这样评审才有分量，不至于变成走过场。
• 知识要沉淀在文档与代码里。设计决策、口径定义、运维手册、常见故障处理——这些不进文档，就只存在人的记忆里。产品公司的过程资产之所以容易空，往往是因为知识从来没被写下来过。

七、评估现场容易被追问的点

评估的思路是一致的：顺着范围—计划—执行—度量—改进抽一条链，看它能不能一路走通，并且访谈时做事的人能不能讲出"当时为什么这么做"。但抽到的东西，两类企业完全不同。

外包项目型常被追的

• 抽到的这个项目，是我们自己承接并主导过程的，还是人力外派、过程由客户定义的？
• 合同签约主体、项目执行主体、参评人员的劳动关系，是不是同一个主体？跨主体的部分怎么说明？
• 客户参加的评审，能不能拿出问题清单与关闭记录？还是只有签到与"通过"？
• 合同变更与项目计划变更是否对得上？变更之后测试范围、验收标准改了吗？
• 几个客户流程不一样，差异有没有裁剪说明与审批？公司自己的标准过程是哪一份？
• 验收单是不是只有签字？验收提出的问题有没有闭环？
• 分包那部分的过程记录在哪？分包方的评价是什么时候做的、依据什么？
• 工时数据与项目计划的工作量能不能对上？差得多的部分怎么解释？

自研产品型常被追的

• 版本范围是谁批的？砍掉的需求有没有记录，理由是什么？
• "我们迭代很快"——快是用什么数据说明的？口径什么时候定的、中途变过吗？
• 这个版本跳过了哪些活动（评审、测试、灰度）？依据哪一条裁剪、谁批的？
• 线上问题是怎么回流到需求池和过程改进的？有没有一条完整的例子？
• 发布记录与版本库里的标记能不能对上？谁批的发布、依据什么？
• 多条产品线共用一套流程，差异在哪、依据什么裁的？
• 需求池里躺了很久的需求，是谁决定不做的？有没有定期清理的机制？
• 关键模块的人员备份情况如何？交接有没有记录？

两类企业共用的骨架

说清差异之后，也要把共同的部分讲明白——这部分不必按业态重做，做了也不会因为业态不同而失效。模型对两类企业的要求是同一条：组织的做法被定义过、被执行过、被度量过、被检查过、被改进过。

共用的框架是这一套：组织单元与评估范围界定；过程资产（方针、流程、模板、检查单、裁剪指南、角色职责、度量定义），每份都有版本、生效日期与维护人；项目已定义过程与裁剪审批；计划、估算与执行监控；需求与变更控制；评审与验证；配置管理与基线；度量收集与组织级汇总；过程符合性检查与不符合项闭环；培训与能力；根因分析与改进机制；高层支持与治理。等级名称为 1 级初始、2 级已管理、3 级已定义、4 级量化管理、5 级优化，逐级含义可对照 CMMI 1-5 级逐个拆。

可以完全共用的三类内容：

• 文件骨架：方针—流程—作业指导—模板与记录的四层结构，编号规则、审批、发放、版本控制、保存期限。
• 管理动作：内审式的过程符合性检查、不符合项报告与整改验证、管理评审的输入输出与纪要、纠正措施跟踪。
• 项目通用回路：估算—计划—跟踪—偏差—纠正—结项，这套回路在两个业态里字面一样，只是"偏差"的含义不同（外包是交期与成本，产品是版本范围与质量）。

不能共用的只有专业内核：外包的合同与变更结构、客户流程差异清单、分包与外派管理；产品的需求池与版本结构、发布与线上数据、依赖与分发渠道。换句话说，骨架相同，填进去的边界、证据和数据不同。

两个业态在级别上的常见位置也值得说清：外包公司常停在 2 级，理由是项目类型差异大、客户定义过程、同类复用少；产品公司容易自认为已经在 3 级，因为"我们有一套统一的研发流程"——但统一不等于已定义，还要有裁剪指南、裁剪审批与组织级可汇总的度量。3 级的具体准备内容，见 CMMI 3 级评估：准备什么。

同时在做 ISO 27001 或 ISO 20000 的企业，可以把文件控制、内审、管审、培训、供应商评价这几块合并运行，但要注意：体系的文件不能直接当 CMMI 的过程资产，项目过程记录也不能共用——一个查控制措施怎么落，一个查项目怎么跑。国内另有 CSMM 等同类模型，定位差异可参考 CSMM 五级拆解 与 CSMM 百科；几套体系怎么选，见 ITSS/CMMI/DCMM/CSMM 怎么选。

常见误区：两边各有一个"想当然"

外包公司：以为"每个客户一套流程"就是灵活。 这是外包项目里代价比较大的一种误判。多套流程在交付上确实灵活，但到了评估现场，问的头一句往往是"你们公司的标准过程是哪一份"，答不上来，3 级就无从谈起。更麻烦的是内部：新项目经理上手靠问人，过程符合性检查没有统一依据，度量口径每个客户一套，到头来连自己都没法比较哪个项目做得好。正确做法不是消灭客户差异，而是把差异变成裁剪——一套标准过程，加一份客户特殊要求清单，加每个项目的裁剪说明与审批。灵活依然在，但它有据可查。

产品公司：以为"迭代快"就等于过程成熟。 两周一个版本，听起来比外包的项目制先进，但评估不看节奏，看可复制与可核查。如果版本范围没有明文、需求取舍没有记录、评审只有群里的几句对话、发布没有基线、线上问题没有回流，那么节奏再快，过程能力依然停在低级别——快只是做得熟，不是做得稳。而且这种"快"通常有个代价：技术债堆着、线上问题反复、核心人员一走就乱。真正成熟的产品公司，快是结果，不是理由。

另外几个两侧都常见的误区：

• 以为有工具就有过程。 Jira、GitLab、流水线、监控平台都能产生数据，但工具不定义过程。评估看的是"你按什么规则用这个工具"，不是"你买了哪个工具"。
• 拿 ISO 的文件顶上。 ISO 9001、ISO 27001 的体系文件可以作为骨架复用，但 CMMI 要的项目已定义过程、裁剪记录、项目度量，只能从项目里长出来。
• 把顾问当答题人。 访谈对象必须是真正做事的人。顾问讲得比员工还熟，在评估里是减分项而不是加分项。
• 范围写得比实际大。 写"全公司"但只有一条业务线在按过程跑，抽到另一条线就是空白。范围要按组织单元与项目类型划清，宁可小一点、实一点。
• 把评估当终点。 结果有有效期，期内过程停摆、记录断档、核心人员流失，到期再评估基本等于重来。有效期与再评估的具体要求，以当期规定为准。
• 先写文件再找项目。 顺序反了，就会出现文件生效日晚于项目记录、模板版本号在记录里出现"未来版本"这类硬伤。正确顺序是先定过程、再让项目真跑、记录自然长出来。

行动清单：共用先做，外包与产品分开做

下面这份清单按"先共用、再分叉"排列。用法是：带【共用】的先做，做完再按自己的业态做【外包】或【产品】那一段。混合型企业两段都要做，可以按业务占比排先后；如果两条业务线共用同一批人，先做共用的那几条，收益更大。

• ⬜共用定范围：用一句话写下评估覆盖的组织单元、业务与项目类型，逐个确认"有人、有记录、有过程痕迹"
• ⬜共用定人：一位能跨部门调人的负责人，加上过程改进、QA、配置管理、度量四个角色的实际承担人
• ⬜共用定级别：目标等级以客户或招标文件原文为准，不按行业惯例猜，也不按"同行都在做"跟
• ⬜共用盘项目：列出候选项目，只保留本企业真实承接、过程由自己主导、能拿出完整记录的项目
• ⬜共用建资产：标准过程、模板、检查单、裁剪指南、度量定义，五样都要有版本、生效日期、维护人
• ⬜共用跑记录：选几个真实项目按新过程跑一段，让评审、变更、基线、度量记录成串长出来
• ⬜共用做检查：过程符合性检查跑一轮，不符合项要闭环；管理评审要有真实输入与结论
• ⬜共用对口径：项目名称、起止时间、参与人、规模与工作量，在所有材料里只能有一个版本
• ⬜外包范围基线：每个抽到的项目，合同范围、任务书、内部计划三者能对上，变更三边联动
• ⬜外包变更台账：所有变更单集中一份台账，含影响分析与客户确认，拒绝的变更也入册
• ⬜外包客户要求清单：逐个客户列出特殊要求，映射到标准过程的哪一条、差异怎么处理
• ⬜外包评审质量：客户评审留问题清单、责任人、关闭日期，杜绝"只有签到与通过"
• ⬜外包分包与外派：分包协议含过程要求，分包方进度与缺陷进本项目跟踪，外派人员角色有书面任命
• ⬜外包工时口径：能按活动拆分（需求、设计、开发、测试、评审、返工），返工单独统计并分类原因
• ⬜产品版本范围：每个抽到的版本有一份范围说明，含做什么、不做什么、验收标准、批准人
• ⬜产品需求池规则：状态机跑起来，优先级规则写下来，未做的需求有明确去向与理由
• ⬜产品发布与线上：发布审批、灰度、回滚、线上问题处理，四件事都进标准过程并有记录
• ⬜产品度量口径：交付周期、发布质量、线上缺陷三项定死口径，历史数据能接上，不中途换算法
• ⬜产品依赖清单：开源组件、云服务、第三方接口有人维护，漏洞与停服有决策路径与降级方案
• ⬜产品能力矩阵：关键模块有第二人能独立接手，交接与带教有记录，单点暴露出来
• ⬜共用自抽查：按自己的业态抽三条链走一遍，只靠现有材料讲完，不靠口头补充
• ⬜共用问评估方：范围、参评项目口径、证据要求与排期，以主任评估师当期要求为准

把两类企业放在一起看，结论其实很朴素：CMMI 检查的从来不是"你有没有一套研发流程文件"，而是"你把活做出来的方式，能不能被别人接手、被数据说明、被持续改好"。外包公司回答这个问题时，证据在合同、变更单和验收记录里；产品公司回答同样的问题时，证据在需求池、版本记录和线上数据里。搞清楚自己的"项目"到底是什么边界，准备就不会从错误的样本开始，也不会在访谈现场被一句"那这个范围是谁定的"问住。

▍不确定自己的项目边界该怎么划、哪些项目适合当样本？留言备注"业态对照"，把主营业务、交付形态与团队结构发给我们，我们按业态给一份项目边界与证据形态的对照表。

普华智科 / CertFastLine 普华认证｜出口认证 & 检测 & 管理体系咨询 本文为合规科普参考，非法律或评估结论；等级名称、模型版本、评估方法与判定要求以 CMMI Institute 当期模型文件及主任评估师要求为准