研发成熟度与过程改进要真正落地，主线可以概括为三步：先确定评估范围和参照标准，用过程证据做一次基线评估；再把差距转成少量有负责人、有输入输出、有完成标志的改进项；最后按周期复评，确认改进已经进入日常研发活动。本文按这条主线给出各阶段的操作方法、角色分工、一个需求评审过程域的完整示例，以及复评检查清单。
要点总览（TL;DR）
- 起步先定评估范围与参照口径：明确覆盖的组织单元、过程环节、参照模型或自建分级定义、证据来源与评分规则，形成一页式范围说明。
- 基线评估以过程证据为准：按过程域逐项调取工作项记录、评审记录、文档状态等证据，对照参照模型判定等级，再按影响与改进成本排出差距优先级。
- 差距转改进项要写清现状、目标状态、输入、关键动作、输出、完成标志和验证证据，一个周期同时推进三到五项，并预设复评时点。
- 分工上由过程改进牵头人组织节奏，过程域负责人对结论和改进项负责，项目团队执行并留存记录，质量或评审角色独立核对证据出具复评结论。
- 复评判断改进是否生效，看没有额外推动时证据是否仍按预期产生；未生效项按原因分别调整动作、负责人或证据留存方式，并进入下一周期清单。
先定范围与参照：成熟度评估怎么起步
成熟度评估最常见的失败起点是范围过大：一次覆盖所有部门和全部研发环节，评估周期拖长，结论也难以落到具体动作。起步阶段的目标是产出一份一页式的评估范围与口径说明，让参与者在评估开始前对“评什么、按什么标准评、看哪些证据”达成一致。
确定评估覆盖的组织单元与过程环节
先划定组织边界，例如某产品线的三个研发团队，或某事业部的需求、开发、测试三条职能线。再选择本次评估覆盖的过程环节，常见做法是优先纳入与当前业务问题最相关的两到四个过程域，例如需求管理、需求评审、代码评审、版本发布。范围说明中要写明哪些单元和环节本次不纳入，避免后续对结论适用范围产生争议。
选择参照模型或自建分级口径
参照标准有两条路径。其一是采用公开的成熟度模型，按其过程域和等级定义逐项对照；其二是自建过程能力分级口径，例如把每个过程域分为“无定义”“有定义但执行不一致”“有定义且稳定执行”“可度量并持续优化”四级。自建口径的好处是贴合组织实际，代价是需要自行定义每一级的判定条件。无论选哪条路径，都要在范围说明中写清模型名称、版本或自建口径的分级定义，保证不同评估人使用同一把尺子。
明确证据来源与评分规则
成熟度判定依赖证据，而非印象。范围说明中应列出每类过程环节的证据来源，例如工作项记录、评审记录、文档状态、会议纪要、发布记录。评分规则要说明：每个过程域由几项检查点构成，每项检查点需要几类证据支撑，证据缺失时如何判定。规则越具体，评估结果越可复核。
| 范围说明要素 | 填写内容示例 |
|---|---|
| 覆盖组织单元 | 产品线A的三个研发团队 |
| 覆盖过程环节 | 需求管理、需求评审、代码评审、版本发布 |
| 参照模型 | 公开成熟度模型某版本，或自建四级能力口径 |
| 证据来源 | 工作项记录、评审记录、文档状态、发布记录 |
| 评分规则 | 每个过程域若干检查点，逐项判定并附证据 |
这份说明就是后续基线评估的输入，也是复评时判断“范围是否变化”的依据。
基线评估：用过程证据定位能力差距
基线评估的任务是回答“当前处在什么水平、差距在哪里”，产出物是基线评估结果表和按优先级排序的差距清单。评估质量取决于证据的完整性和判定依据的可追溯性。
按过程域逐项收集证据
以过程域为单位组织评估，每个过程域对应一组检查点。评估人调取该过程域在过去一个评估周期内的实际记录：工作项是否记录了需求变更、评审是否留下参与人和结论、文档状态是否反映真实流转、发布是否有审批记录。证据取样要覆盖不同团队和不同项目类型，避免只挑执行最好的项目。
对照参照模型判定等级并记录依据
每个检查点给出判定结论，并附上支撑证据的位置和简要说明。判定为“满足”的检查点要能指向具体记录；判定为“部分满足”或“不满足”的检查点要写明缺失的证据类型。这样形成的评估结果表，任何第三方都可以按图索骥复核。
按影响与改进成本排序
差距清单不宜平铺直叙。建议用两个维度排序：该差距对交付质量、进度可预期性或返工率的影响程度，以及修复它所需的时间、工具和人员投入。影响大、成本低的差距优先进入改进；影响大但成本高的差距拆分成阶段目标；影响小的差距记录在案，暂不占用改进资源。
| 差距编号 | 过程域 | 当前判定 | 缺失证据 | 影响 | 改进成本 | 优先级 |
|---|---|---|---|---|---|---|
| G-01 | 需求评审 | 部分满足 | 评审结论未记录 | 高 | 低 | P1 |
| G-02 | 代码评审 | 不满足 | 无评审记录 | 高 | 中 | P1 |
| G-03 | 版本发布 | 部分满足 | 发布审批缺失 | 中 | 低 | P2 |
把差距转成改进项：输入、动作、输出与完成标志
差距清单描述的是“哪里不足”，改进项描述的是“做什么、谁来做、做到什么程度算完成”。两者之间需要一次转化，转化的质量标准是：每一项都能被独立执行和独立验证。
每个改进项写清五要素
一个合格的改进项至少包含：现状描述（引用差距编号和证据）、目标状态（改进后应达到的判定）、输入（需要哪些现有材料、模板或系统权限）、关键动作（按顺序列出执行步骤）、输出（产生的记录、模板或流程变更）。负责人和完成时间同样要写入，否则改进项无法进入跟踪。
定义完成标志与验证证据
完成标志要可观察。例如“需求评审结论记录率达到100%”比“加强评审管理”更可验证；“连续两个迭代的发布均有审批记录”比“建立发布审批流程”更接近真实生效。每项完成标志应同时写明验证证据的形式和取样方式，便于复评时直接核对。
控制数量，聚焦高优先级差距
一个改进周期内同时推进的改进项建议控制在三到五项。数量过多会导致负责人分散、证据收集不全、复评时难以判断哪项真正生效。未被选中的差距保留在清单中，作为下一周期的候选。
设定改进周期与复评时点
改进周期通常以一个季度或两个迭代为宜，周期结束时安排复评。周期过长会让改进动作与日常研发脱节，过短则证据量不足以判断稳定性。复评时点应在改进项启动时就写入清单，而不是等到周期结束再临时约定。
| 字段 | 填写要求 |
|---|---|
| 改进项编号与名称 | 与差距编号对应，名称体现动作 |
| 现状 | 引用差距描述和证据位置 |
| 目标状态 | 改进后应达到的判定结论 |
| 输入 | 现有模板、记录、系统权限、人员 |
| 关键动作 | 按顺序列出的执行步骤 |
| 输出 | 产生的记录、模板或流程变更 |
| 完成标志 | 可观察、可核对的判定条件 |
| 验证证据 | 复评时核对的记录类型与取样方式 |
| 负责人与周期 | 唯一负责人，起止时间与复评时点 |
角色与交付物分工：谁评估、谁改进、谁验证
评估与改进涉及多个角色，职责不清时容易出现“评估的人不改进、改进的人不交证据”的断点。建议在启动阶段就用一张对照表固定分工和交接节点。
四类角色的核心职责
过程改进牵头人负责整体节奏：组织范围说明的制定、协调评估资源、汇总差距清单、跟踪改进项状态、安排复评。过程域负责人对本过程域的评估结论和改进项质量负责，通常是需求、开发、测试、发布等环节的职能负责人。项目团队是改进动作的执行者，在日常研发活动中落实流程变更并留存记录。质量或评审角色承担独立验证，在复评时核对证据、给出判定结论。
交付物与交接节点
交接节点决定了信息能否顺畅流转。范围说明由牵头人起草、过程域负责人确认；基线评估结果由评估人提交、过程域负责人签认；改进项清单由过程域负责人提出、牵头人审核纳入跟踪；复评记录由质量角色出具、牵头人归档并决定下一周期安排。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 过程改进牵头人 | 组织评估、跟踪改进、安排复评 | 范围说明、改进项跟踪表、复评计划 | 向过程域负责人确认范围；向质量角色发起复评 |
| 过程域负责人 | 对本过程域结论和改进项负责 | 差距确认意见、改进项清单 | 向牵头人提交改进项；向项目团队布置动作 |
| 项目团队 | 执行改进动作、留存过程记录 | 工作项记录、评审记录、文档状态 | 向质量角色提供复评证据 |
| 质量或评审角色 | 独立核对证据、出具判定 | 复评记录、完成检查结论 | 向牵头人提交复评结论 |
改进项的评审与状态更新机制
改进项进入跟踪后，建议每两周做一次状态更新，更新内容包括已完成动作、已产生的证据、遇到的阻碍。状态更新由负责人完成，牵头人汇总。周期中段安排一次改进项评审，重点检查动作是否按计划推进、完成标志是否仍然可验证，必要时调整动作而非降低标准。
这些跟踪动作需要有承载的地方。改进项本身可以作为工作项管理，评审记录和文档状态作为证据留存，复评结论回写到对应改进项的状态中，使评估、改进、复评三段共享同一份记录。ONES 可以在这一层承担改进项跟踪与评审记录留存的管理动作，具体使用方式按团队现有的工作项和文档组织习惯配置。
示例：一个需求评审过程域的改进落地
以下示例为演示情景，用于说明从差距到复评的完整链条，数据为示意。
示例背景与差距描述
某产品线在基线评估中发现，需求评审过程域判定为“部分满足”。证据显示：需求评审会议有召开，但评审结论只存在于会议纪要中，未回写到需求工作项；部分需求在评审后直接进入开发，工作项状态未体现评审通过环节。差距编号 G-01，影响为需求变更追溯困难、返工率偏高，改进成本低，列为 P1。
改进项设计与执行动作
改进项目标状态为“需求评审结论记录率达到100%，评审通过作为需求进入开发的必要状态”。输入包括现有需求工作项模板、评审会议纪要模板、工作项状态配置权限。关键动作：一是在需求工作项中增加评审结论字段和“评审通过”状态；二是规定评审会后一个工作日内由评审组织人回写结论；三是开发启动前检查需求是否处于“评审通过”状态。输出为更新后的工作项模板和状态流转规则。完成标志为连续两个迭代内所有进入开发的需求均带有评审结论记录。负责人为需求过程域负责人，周期为一个季度，复评时点为季度末。
证据留存方式
评审结论记录在需求工作项上，评审会议纪要作为附件关联；状态流转记录由工作项历史保留；开发启动前的检查结果记录在迭代启动检查单中。三类证据共同支撑复评判定。
复评时的判定与结论
复评时抽取两个迭代的全部需求工作项，核对评审结论字段填写率和状态流转记录。若填写率达到目标且未发现绕过评审直接开发的情况，判定改进生效，过程域等级上调；若填写率达标但仍有绕过情况，判定为部分生效，保留改进项并追加状态校验动作；若填写率未达标，分析是模板未落地还是执行意愿问题，调整动作后进入下一周期。
复评与完成检查：判断改进是否真正生效
复评的目的不是再打一次分，而是确认改进动作已经变成日常研发活动的一部分。判断标准是：在没有额外推动的情况下，证据仍然按预期产生。
复评时点与证据要求
复评按改进项清单中预设的时点执行，证据取样覆盖改进周期内的完整记录，而非只挑近期样本。每项改进项的验证证据类型在启动时已经写明，复评时逐项调取核对。取样应包含不同团队和不同项目类型，避免结论只对个别项目成立。
逐项核对完成标志
对照改进项清单，逐项核对完成标志是否达成，并记录支撑证据。核对结论分为生效、部分生效、未生效三档，每档都要写明依据。部分生效的改进项要指出哪部分动作已进入日常、哪部分仍依赖推动。
未生效项的处置方式
未生效的改进项不直接关闭，也不简单延期。先分析原因：是动作设计不可执行、负责人投入不足、还是证据留存方式与团队工作习惯冲突。原因不同，处置不同——设计问题调整动作，投入问题调整负责人或拆分任务，工具冲突则调整证据留存方式。处置结论写入下一周期改进项清单。
机制持续运行的检查项
除了单项改进的复评，还要检查过程改进机制本身是否在运转。以下清单可用于季度检查：
- 评估范围与口径说明是否随组织变化更新；
- 差距清单是否每周期复核，已解决项是否关闭；
- 改进项数量是否控制在可跟踪范围内，每项是否有唯一负责人；
- 改进项状态是否按约定频率更新，评审是否按期举行；
- 复评是否按预设时点执行，结论是否回写到改进项记录；
- 上一周期未生效项的处置结论是否已进入本周期清单；
- 过程证据是否在日常工作中自然产生，而非复评前集中补录。
复评记录与完成检查清单应一并归档，作为下一轮基线评估的输入。当评估、改进、复评形成固定节奏，研发成熟度的提升就从一次项目变成可持续运行的过程改进机制。
常见问题
评估范围应该划多大，第一次做成熟度评估覆盖多少团队和过程域比较合适？
第一次评估建议把范围收窄到能在一个季度内完成取证和复评的程度。组织单元可以选一条产品线或两到三个研发团队，过程环节优先纳入与当前业务问题最相关的两到四个过程域，例如需求管理、需求评审、代码评审、版本发布。范围说明中同时写明本次不纳入的单元和环节，后续引用结论时就不会超出适用范围。范围过大的直接后果是证据收集周期拉长、评估人精力分散，差距清单也难以落到具体负责人。
自建过程能力分级口径和采用公开成熟度模型，应该怎么选？
两种路径的差别主要在贴合度与定义成本。公开成熟度模型的过程域和等级定义已经成型，评估人可以直接对照，代价是部分条款与组织实际流程存在距离，需要解释性映射。自建口径可以按团队真实流程定义分级，例如“无定义”“有定义但执行不一致”“有定义且稳定执行”“可度量并持续优化”四级，贴合度高，但每一级的判定条件需要自行写清楚。选择时看两点：组织是否已有可参照的行业或客户要求，以及是否有精力维护一套自定义判定规则。无论选哪种，都要在范围说明中固定模型名称、版本或分级定义，保证不同评估人使用同一把尺子。
改进项执行到一半发现动作不可行，应该降低完成标志还是调整动作？
优先调整动作，保留完成标志。完成标志代表改进要达成的能力状态，中途降低标准会让复评失去判断意义。动作不可行通常有三类原因：设计时对现有工具或权限估计不足，执行时负责人投入不够，或者证据留存方式与团队工作习惯冲突。对应的处理分别是改动作步骤、调整负责人或拆分任务、改证据留存方式。调整后要在改进项记录中写明变更原因和新动作，并同步给复评角色，避免复评时按旧标准核对。
复评时发现填写率达标，但仍有项目绕过流程，这种情况怎么判定？
这种情况通常判定为部分生效。填写率达标说明记录动作已经进入日常，绕过流程说明流程约束还没有真正生效。处理上先定位绕过发生在哪个环节：是状态校验缺失，让需求可以在未评审通过时进入开发；还是校验存在但被手动跳过；或者是新项目未纳入流程配置。定位后追加约束动作，例如在迭代启动检查中加入状态核对，或把评审通过设为进入开发的必要条件。改进项保留在清单中，下一周期复评时重点核对绕过情况是否消失。
过程改进机制运行一段时间后节奏松了，怎么判断机制本身是否还在运转？
看几个可观察的信号：范围说明是否随组织调整更新过，差距清单是否每周期复核并关闭已解决项，改进项是否仍有唯一负责人并按约定频率更新状态，复评是否按预设时点执行且结论回写到改进项记录，上一周期未生效项的处置结论是否进入本周期清单。另一个关键信号是过程证据的产生方式——如果评审记录、状态流转主要靠复评前集中补录，说明改进还没有进入日常工作。季度检查时把这些项逐条核对，比只看改进项完成率更能反映机制状态。
