研发数据质量校验要长期做下去，需要把三类资产固定下来：规则清单说明校验哪些数据、按什么口径判断；校验配置模板说明每条规则由谁执行、多久校验一次、达到什么条件触发处置；问题记录模板留下异常从发现到关闭的完整证据。三张表共用同一套规则编号，规则清单定标准，配置模板定执行，问题记录留证据。下面直接给出可复制的空白表、字段口径、必填判定、填写示例与维护方法。
要点总览（TL;DR）
- 研发数据质量校验可沉淀三张表：规则清单定标准、校验配置模板定执行、问题记录模板留证据，三表用同一套规则编号关联。
- 规则清单写清校验对象、校验维度、判断口径和严重级别；判断口径要写成可执行条件，例如字段非空、时间先后、状态流转顺序。
- 校验配置为每条规则补责任人、频率、阈值、触发条件、处置动作和升级路径，严重级别要与处置动作成对定义。
- 问题记录覆盖发现、影响范围、原因分类、修复动作、复核结论和关闭状态，影响范围与原因分类不宜留空。
- 模板启用后先保证最小必填集，再按季度复核频率与阈值，规则增删改保留版本记录并同步三张表。
可复制空白模板：规则清单、校验配置与问题记录
三张表建议放在同一份文档或同一套在线表格中，按“规则清单—校验配置—问题记录”的顺序排列。填写时先建规则清单，再为每条规则补配置，最后在异常发生时追加问题记录。以下表格可直接复制到表格工具中使用。
表一：研发数据质量规则清单
| 规则编号 | 校验对象 | 校验维度 | 判断口径 | 数据来源 | 严重级别 | 规则说明 |
|---|---|---|---|---|---|---|
| DQ-001 | ||||||
| DQ-002 | ||||||
| DQ-003 |
表二：校验配置模板
| 规则编号 | 责任人 | 校验频率 | 阈值或容差 | 触发条件 | 处置动作 | 升级路径 |
|---|---|---|---|---|---|---|
| DQ-001 | ||||||
| DQ-002 | ||||||
| DQ-003 |
表三：数据质量问题记录模板
| 问题编号 | 关联规则 | 发现时间 | 发现来源 | 现象描述 | 影响范围 | 原因分类 | 修复动作 | 复核结论 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|
| QI-001 | |||||||||
| QI-002 | |||||||||
| QI-003 |
字段说明：每列填什么、口径怎么统一
三张表能配合使用的前提是字段含义稳定、引用关系明确。规则编号是唯一主键，配置表和问题记录表都通过它回指规则清单；同一编号在三张表中必须指向同一条规则，规则停用后编号保留、不再复用。
| 字段 | 所属表 | 填写要求 |
|---|---|---|
| 规则编号 | 规则清单、校验配置、问题记录 | 采用“DQ-三位序号”格式，全团队唯一，作为三表关联主键 |
| 校验对象 | 规则清单 | 写明被校验的数据实体，如需求状态、工时记录、缺陷流转记录、迭代范围 |
| 校验维度 | 规则清单 | 写明检查哪一类性质，如完整性、及时性、一致性、有效性、唯一性 |
| 判断口径 | 规则清单 | 写成可执行条件，包含字段、比较方式与取值，例如“需求关闭时‘实际完成时间’非空”“缺陷从‘已修复’回到‘处理中’须有备注” |
| 数据来源 | 规则清单 | 写明数据所在系统、项目或报表名称，便于定位原始记录 |
| 严重级别 | 规则清单 | 按影响分为高、中、低三级，与配置表中的处置动作和升级路径对应 |
| 责任人 | 校验配置 | 填写对校验结果负责的岗位或人员，避免只写团队名称 |
| 校验频率 | 校验配置 | 写明每日、每周、每迭代或每次发布前等具体节奏 |
| 阈值或容差 | 校验配置 | 给出可判定的数量或比例，如“异常记录数为 0”“缺失率不超过 2%” |
| 触发条件 | 校验配置 | 说明达到什么状态即启动处置，如“连续两次校验超阈值”“单次异常影响超过一个迭代” |
| 处置动作 | 校验配置 | 写明先做什么，如通知责任人补录、冻结相关报表、发起问题记录 |
| 升级路径 | 校验配置 | 写明超时未处理或影响扩大时向谁升级，以及升级时限 |
| 发现来源 | 问题记录 | 填写定期校验、发布前检查、报表复核或人工反馈等渠道 |
| 影响范围 | 问题记录 | 写明涉及的项目、迭代、报表或决策场景，以及受影响的数据条数 |
| 原因分类 | 问题记录 | 常见取值包括录入遗漏、状态流转错误、口径理解不一致、系统同步延迟、权限配置问题、外部数据变更 |
| 复核结论 | 问题记录 | 写明复核人、复核时间与结果，如“已抽查 20 条记录，全部符合口径” |
| 关闭状态 | 问题记录 | 使用待处理、处理中、待复核、已关闭、挂起五种状态之一 |
严重级别与处置动作需要成对定义。高级别规则触发后应直接发起问题记录并通知责任人，中级别规则可先由责任人当日修正，低级别规则纳入周期性清理。只分级不定义动作，规则就难以执行。
必填与选填：哪些字段不能空
模板刚启用时不必要求所有字段一次填满，先保证最小可用集，再逐步补充增强字段。判断标准是：缺少该字段会导致规则无法执行、问题无法追踪或结论无法复核，就列为必填。
| 表 | 必填字段 | 可后补或选填字段 |
|---|---|---|
| 规则清单 | 规则编号、校验对象、校验维度、判断口径、严重级别 | 数据来源、规则说明；数据来源在首次执行校验前补齐 |
| 校验配置 | 规则编号、责任人、校验频率、触发条件、处置动作 | 阈值或容差、升级路径；定性规则可不设数值阈值，但须写明判定方式 |
| 问题记录 | 问题编号、关联规则、发现时间、现象描述、影响范围、原因分类、关闭状态 | 发现来源、修复动作、复核结论；问题关闭前修复动作与复核结论必须补齐 |
选填字段留空时，建议在备注中说明原因，例如“定性规则，无固定阈值”。影响范围与原因分类在问题记录中属于必填，前者决定是否需要升级，后者决定后续改进方向；暂时无法判断原因时，可先填“待定位”，并在复核前更新为具体分类。
填写示例：一条规则从配置到问题闭环
以下示例演示一条规则如何依次进入三张表。示例中的项目名称与数据为演示情景，实际填写时替换为团队真实信息。
规则清单中的填写
| 规则编号 | 校验对象 | 校验维度 | 判断口径 | 数据来源 | 严重级别 | 规则说明 |
|---|---|---|---|---|---|---|
| DQ-007 | 需求状态记录 | 完整性 | 需求状态为“已完成”时，“实际完成时间”字段非空，且不早于“开始开发时间” | 项目管理系统需求模块 | 高 | 保障迭代完成率统计的时间基础 |
校验配置中的填写
| 规则编号 | 责任人 | 校验频率 | 阈值或容差 | 触发条件 | 处置动作 | 升级路径 |
|---|---|---|---|---|---|---|
| DQ-007 | 项目管理专员 | 每周五迭代结束前 | 异常记录数为 0 | 单次校验发现 1 条及以上异常 | 通知对应需求负责人补录或修正时间字段，并在问题记录表登记 | 超过 2 个工作日未修正，升级至项目负责人 |
问题记录中的填写
| 问题编号 | 关联规则 | 发现时间 | 发现来源 | 现象描述 | 影响范围 | 原因分类 | 修复动作 | 复核结论 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|
| QI-012 | DQ-007 | 2025-03-14 | 迭代结束前定期校验 | 3 条已完成需求的“实际完成时间”为空 | 影响本迭代完成率与平均交付周期两张报表，涉及 1 个项目 | 录入遗漏 | 需求负责人补录完成时间，项目管理专员抽查同批次记录 | 3 月 17 日复核，补录时间与代码合并记录一致，同批次另抽查 10 条无异常 | 已关闭 |
示例中三张表的规则编号、校验对象与严重级别保持一致；问题记录的影响范围对应配置表中的升级判断，复核结论对应关闭前的必填要求。团队照此顺序填写，就能形成从规则定义到问题关闭的完整链路。
调整与维护方法：模板如何随团队演进
模板投入使用后，规则会随流程变化增减，阈值也需要根据实际数据分布调整。维护的重点是让三张表同步变化，并保留变更痕迹。
- 规则增删改流程：新增规则先由提出人填写规则清单，经数据责任人确认判断口径可执行后，再补校验配置；停用规则时在规则清单标注停用日期与原因，编号保留不复用，问题记录中的历史引用不受影响。
- 版本记录：在规则清单中增加“版本号”和“变更说明”两列，或单独维护变更日志，记录每次修改的时间、修改人与影响范围。
- 频率与阈值复核：建议每季度复核一次校验频率和阈值。若某规则连续多个周期零异常，可评估降低频率；若频繁触发但修复率低，应检查判断口径是否过严或责任人不明确。
- 问题记录归档与统计复用：已关闭问题按月归档，按原因分类和关联规则统计频次，识别高频问题类型，作为下一轮规则优化和流程改进的输入。
- 三表同步变更：规则编号、判断口径或严重级别发生变化时，同步更新校验配置中的处置动作与升级路径；问题记录模板的字段调整应保持向后兼容，历史记录按原字段保留。
当团队使用 ONES 承载研发过程数据时，规则清单与校验配置可以作为文档沉淀，异常问题则以工作项形式登记和流转，责任人、状态与复核记录随工作项保留。ONES 研发效能管理解决方案对交付效率、交付质量、进度情况、资源效率等效能数据进行展示，形成“量化—实施—分析—改进”的闭环；Performance 能同步业务数据并支持选取数据集、自定义报表和图表展示，便于在复核环节对照原始记录与报表结果。将模板中的规则编号写入工作项标题或自定义字段，可以让问题记录与规则清单保持可追溯的对应关系。
常见问题
规则清单、校验配置和问题记录三张表，应该先建哪一张？
先建规则清单。规则编号是另外两张表的关联主键，没有规则清单，校验配置就没有可挂靠的对象，问题记录也无法回指具体规则。实际操作中，先由提出人把校验对象、校验维度、判断口径和严重级别写进规则清单，确认口径可执行后，再为每条规则补校验配置。问题记录表在异常发生时追加，不需要提前填满。
定性规则没有数值阈值，校验配置里的“阈值或容差”怎么填？
定性规则可以不设数值阈值，但要在该列写明判定方式，例如“状态流转顺序正确”“必填字段全部非空”“同一需求不存在重复关联记录”。同时把触发条件写清楚，说明达到什么状态即启动处置。留空时建议在备注中注明“定性规则，无固定阈值”，避免后续复核时误以为漏填。
问题记录里的“原因分类”暂时判断不出来，可以先空着吗？
原因分类在问题记录中属于必填字段，因为它决定后续改进方向。暂时无法定位时，可以先填“待定位”，并在复核前更新为具体分类，例如录入遗漏、状态流转错误、口径理解不一致、系统同步延迟、权限配置问题或外部数据变更。这样既保证记录及时登记，也保留后续补充的空间。
模板用了一段时间后，规则停用或修改，历史问题记录怎么处理？
停用规则时在规则清单标注停用日期与原因，规则编号保留、不再复用，历史问题记录中的引用继续有效。修改判断口径或严重级别时，同步更新校验配置中的处置动作与升级路径，并在规则清单的版本号与变更说明中记录修改时间、修改人与影响范围。问题记录模板的字段调整应保持向后兼容，历史记录按原字段保留，不追溯改写。
校验频率和阈值多久复核一次比较合适？
建议每季度复核一次。复核时看两类信号：某条规则连续多个周期零异常，可以评估降低校验频率；某条规则频繁触发但修复率低，应检查判断口径是否过严、责任人是否明确或处置动作是否可执行。复核结论记入规则清单的变更说明，避免频率和阈值长期不调整导致校验流于形式。
