设计研发过程符合性检查项，核心是把过程文件里的要求转成可观察、可取证、可判定的条目，再配套抽样规则和统一判定口径。本文按“要求拆解—字段设计—抽样—判定—角色分工—示例—上线核对”的顺序展开，适合正在组织研发过程检查的负责人直接套用。
要点总览（TL;DR）
- 检查项从过程文件、阶段交付物和评审记录中提取要求，按“过程域—阶段—活动—交付物”逐层拆解，一条检查项只对应一个要求。
- 每条检查项统一字段：编号、所属过程域与阶段、检查内容、证据来源、责任角色、判定口径和抽样要求，保证不同执行人得出相近结论。
- 抽样按过程风险等级和变更频次分层，区分全量检查、比例抽样和重点抽查，并保留抽样规则编号、样本清单和抽样人记录。
- 判定采用符合、部分符合、不符合三级口径，证据充分性看来源、覆盖要素和可追溯性，争议由复核人裁定并记录理由。
- 检查项体系上线前核对覆盖度、可判定性、抽样与判定口径一致性及版本维护机制，之后定期复审保持与过程要求同步。
检查项从哪里来：把过程要求拆成可检查的条目
检查项不能凭经验临时想，而要有明确的要求来源。常见来源有三类：过程文件（研发流程规范、作业指导书、模板）、阶段交付物（需求规格、设计文档、测试报告、评审记录）、以及评审与变更记录。设计前先把这些材料收集齐，标注版本和生效日期，避免用过期文件做依据。
拆解按“过程域—阶段—活动—交付物”四层逐级展开。以需求管理为例：过程域是需求管理，阶段是需求分析与评审，活动是需求评审，交付物是评审记录与需求基线。每一层都问一句“这一步要留下什么、由谁做、做到什么程度算完成”，答案就是检查项的素材。
拆到活动层后，把每条要求单独转成一条检查项。一条检查项只对应一个要求，例如“需求评审记录是否包含参与人、评审意见与结论”和“评审意见是否逐条闭环”应拆成两条，否则判定时无法区分是记录缺失还是闭环缺失。拆完后做一次反向核对：每条过程要求是否都有检查项对应，每个检查项是否能追溯到某条要求。
拆解产物是一份检查项来源清单，列出要求编号、来源文件、对应过程域与阶段、拆出的检查项编号。这份清单既是设计底稿，也是后续覆盖度核对的依据。
一条合格检查项包含哪些字段
检查项要能被不同的人执行出相近结果，字段结构必须统一。建议至少包含以下字段：
| 字段 | 作用 | 填写要求 |
|---|---|---|
| 检查项编号 | 唯一标识，便于引用和追溯 | 按过程域缩写加序号，如 REQ-01 |
| 所属过程域与阶段 | 定位检查在研发流程中的位置 | 与过程文件层级一致 |
| 检查内容 | 说明查什么 | 一句话一个要求，用“是否”“有无”等可判定表述 |
| 证据来源 | 说明去哪里取证 | 写具体系统、文档或记录名称，如“需求评审记录”“配置库基线标签” |
| 责任角色 | 明确被检查方与取证对接人 | 写岗位而非人名 |
| 判定口径 | 说明符合与不符合的界线 | 与判定标准表对应，必要时附示例 |
| 抽样要求 | 说明查多少、怎么选 | 引用抽样规则编号 |
填写示例：编号 REQ-03，过程域需求管理，阶段需求评审，检查内容“需求评审记录是否包含评审结论及后续处理意见”，证据来源“需求评审记录文档及评审问题跟踪表”，责任角色“需求负责人”，判定口径“记录齐全且结论明确为符合；记录存在但结论缺失为部分符合；无记录为不符合”，抽样要求“按抽样规则 S-2 抽取当期评审记录”。
字段设计好后，建议先拿三到五条检查项做试填，让不同执行人独立判定同一份证据，看结论是否一致。分歧大的字段要补充说明或示例，再批量推广。
抽样方式怎么定：按风险和频次分层
研发过程检查通常无法全量覆盖，抽样规则要在检查计划阶段就定好，避免执行时随意增减。分层依据主要有两个：过程风险等级和变更频次。风险高、变更频繁的过程域提高抽样比例，稳定成熟的过程域降低比例。
| 抽样方式 | 适用情形 | 样本量建议 |
|---|---|---|
| 全量检查 | 高风险过程、首次检查、发生重大变更或近期出现问题的环节 | 当期全部对象 |
| 比例抽样 | 中等风险、运行稳定的常规过程 | 按约定比例抽取，如当期对象的 20%–30% |
| 重点抽查 | 低风险过程或补充验证 | 选取代表性对象，覆盖不同项目或团队 |
抽样记录要保留：抽样规则编号、抽样总体范围、抽样方法、样本清单、抽样人、抽样日期。样本清单写清具体项目、版本或记录编号，便于复核时复现。
抽样不足时，例如样本记录缺失或无法覆盖关键场景，可采用补充取证：调取相邻周期的记录、访谈执行人并形成访谈记录、查看系统操作日志。补充取证同样要记录来源和获取方式，不能以口头说明替代证据。
判定标准怎么统一：分级口径与证据要求
判定分歧多来自口径不清。建议采用三级判定：符合、部分符合、不符合。符合指要求全部满足且证据充分；部分符合指要求部分满足，或证据存在但不足以完整证明；不符合指要求未满足或无法提供证据。每一级都要在判定标准表里写清定义和典型情形，检查项字段中的判定口径直接引用该表。
证据充分性看三点：证据是否由要求指定的来源产生、是否覆盖检查项涉及的全部要素、是否可追溯到具体时间与责任人。截图、导出记录、评审纪要都可以作为证据，但要注明获取路径和日期。仅有口头确认、无记录支撑的，按证据不足处理。
判定争议由复核人裁定。执行人与被检查方对结论有分歧时，先补充证据，仍不能一致的提交复核人，复核结论和理由记入检查记录。判定结果直接对应整改动作：不符合项开整改单并定责任人、期限；部分符合项明确补正内容；符合项归档留证。
角色分工与各阶段交付物
检查项体系涉及三类角色。检查项设计人负责从过程要求拆解检查项、维护字段与判定口径；检查执行人按计划和抽样规则取证、填写检查记录、给出初判；复核人审核判定一致性、处理争议、签认检查结论。角色可以由同一人兼任，但设计与复核建议分开，保证口径独立。
| 阶段 | 主要产出 | 责任角色 |
|---|---|---|
| 设计 | 检查项来源清单、检查项字段表、抽样规则、判定标准表 | 检查项设计人 |
| 计划 | 检查计划（范围、时间、抽样安排） | 检查负责人 |
| 执行 | 检查记录、证据清单、问题清单 | 检查执行人 |
| 复核 | 复核意见、检查结论 | 复核人 |
| 整改 | 整改跟踪表、关闭记录 | 被检查方与检查执行人 |
各交付物之间要有引用关系：检查记录引用检查项编号和抽样记录，问题清单引用检查记录条目，整改跟踪表引用问题编号。评审与签认环节放在复核之后，由复核人签认检查结论，整改关闭后再做一次确认签认。
当检查项、检查记录和整改问题需要在同一处流转时，可以借助研发管理平台承载。ONES 支持项目管理、知识库、工单管理等模块组合，可将检查项作为工作项管理、检查记录与整改问题关联跟踪，形成可追溯的记录链；具体功能与版本需结合实际环境确认。
示例：一个阶段检查项的设计过程
以“设计评审”阶段为例演示完整过程。第一步提取要求：过程文件规定设计评审需有评审计划、评审检查单、评审记录和问题闭环记录。第二步转成检查项：DES-01 是否在评审前形成评审计划并明确参与角色；DES-02 评审是否使用检查单并逐项记录结论；DES-03 评审记录是否包含问题、责任人和处理期限；DES-04 评审问题是否全部闭环并有验证记录。每条检查项分别设定证据来源为评审计划文档、评审检查单、评审记录、问题跟踪表。
第三步定抽样：设计评审属中高风险过程，按比例抽样，抽取当期评审记录的 30%，覆盖不同项目组。第四步判定：以 DES-04 为例，问题全部闭环且有验证记录判为符合；问题已处理但缺验证记录判为部分符合；存在未处理问题判为不符合。检查记录中写明证据编号和判定理由。
这个示例可迁移的规律是：先锁定阶段交付物，再逐条对应要求，最后为每条检查项配证据来源和判定口径。换到测试阶段或变更管理阶段，方法相同，只需替换交付物和风险等级。
完成检查：检查项体系上线前的核对项
检查项体系发布前，按以下清单逐项核对，全部通过再投入实际检查：
- 覆盖度：关键过程域和阶段是否都有检查项，每条过程要求能否追溯到至少一条检查项。
- 可判定性：每条检查项的证据来源是否写到具体文档或系统，判定口径是否可直接对照执行。
- 抽样一致性：抽样规则是否与检查项的风险等级匹配，抽样记录字段是否齐全。
- 判定一致性：判定标准表是否覆盖三级口径，争议处理路径是否明确。
- 角色与交付物：设计、执行、复核职责是否落实到岗位，交付物之间的引用关系是否建立。
- 版本维护：检查项是否标注版本和生效日期，过程文件变更时是否有触发更新的机制。
上线后建议每季度或在过程文件重大变更时复审一次检查项，记录变更原因和影响范围，保持检查项与过程要求同步。
常见问题
过程文件本身写得比较笼统，检查项还能拆得出来吗？
可以拆，但需要先补一层解释。遇到“评审要充分”“记录要完整”这类笼统表述时，先和过程文件的编写人或流程负责人确认其具体含义，把“充分”“完整”落到可观察的对象上，例如评审参与角色、评审意见条数、结论字段。确认结果记入检查项来源清单，注明依据和确认人。若过程文件长期无法细化，可先按当前理解设计检查项并标注待确认，在检查计划评审时统一澄清，避免执行人各自解释。
抽样时发现样本记录缺失，应该直接判不符合吗？
先区分是记录缺失还是过程未执行。样本记录缺失时，可按抽样规则做补充取证：调取相邻周期记录、查看系统操作日志、访谈执行人并形成访谈记录。补充取证能证明过程已执行且要求满足的，按证据情况判定；补充取证仍无法证明要求满足的，判为不符合或部分符合，并在检查记录中写明取证过程和结论依据。补充取证的口头说明要转成书面记录，不能仅凭口头确认结案。
不同项目组的研发流程有差异，检查项要按项目分别设计吗？
以组织级过程要求为基准设计一套检查项，项目差异通过适用性说明处理。对确实不适用某条检查项的项目，在检查计划中标注不适用及理由，经复核人确认后不纳入抽样和判定，而不是临时删减检查项。项目有额外要求时，可在通用检查项之外增设项目级检查项，编号上做区分，便于汇总时识别。这样既保持口径统一，也保留项目灵活性。
检查结论和整改由不同团队负责时，怎么保证闭环？
关键是让问题清单和整改跟踪表使用同一套编号并建立引用关系。检查记录引用检查项编号和抽样记录，问题清单引用检查记录条目，整改跟踪表引用问题编号，每个问题明确责任岗位、整改期限和验证方式。整改完成后由检查执行人验证并记录验证证据，复核人确认后关闭。跨团队时建议约定固定的同步节奏，例如每周更新整改状态，避免问题在交接中失去跟踪。
检查项体系上线后，过程文件改版了怎么办？
建立触发更新机制：过程文件发布新版本时，由检查项设计人比对变更条款，判断是否影响现有检查项的内容、证据来源或判定口径，受影响的部分修订并记录变更原因和影响范围。未受影响的检查项也标注已复核。建议每季度做一次定期复审，与过程文件的版本记录对照，确保检查项与现行要求一致。修订后的检查项更新版本号和生效日期，旧版本归档保留，便于追溯历史检查结论的依据。
