研发质量策划模板要能直接填写，核心是一张主表加四张附表：主表登记项目范围、质量目标与验收口径，附表分别承载质量目标、职责分工、质量活动与检查点。本文给出可复制的空白表格、逐字段填写说明、必填与选填规则、一份完整填写示例，以及模板的维护方法，适用于软件研发项目在立项或版本启动阶段编制质量策划。
要点总览（TL;DR）
- 模板主体是一张质量策划主表加四张附表：主表登记项目范围、质量目标摘要、验收口径与版本，附表分别承载质量目标、职责分工、质量活动与检查点。
- 质量目标字段需包含指标名称、目标值、度量口径、数据来源、统计周期与责任人，判断标准是换人按口径统计能得到相同结果。
- 职责写到角色并落到具体人，通过活动编号与检查点编号关联，保证每项活动与检查点都有明确责任人。
- 项目范围、验收口径、关键角色职责、各阶段活动及输出、评审与放行检查点的通过条件与证据属于必填最小集合，其余字段可按项目规模裁剪。
- 模板需配套填写示例与版本变更记录，由质量负责人或过程改进角色定期复核目标与检查点。
可复制空白模板：质量策划主表与四张附表
以下五张表构成模板主体。使用时先填主表确定范围与口径，再依次填写四张附表；附表中的每条记录都应能回溯到主表中的项目范围或质量目标。
表1 质量策划主表
| 字段 | 填写内容 |
|---|---|
| 项目/版本名称 | |
| 策划编号 | |
| 项目范围 | 包含的产品模块、需求范围、不纳入本次策划的内容 |
| 质量目标摘要 | 引用表2中的目标编号与目标值 |
| 验收口径 | 以何为准判定质量目标达成，如缺陷统计规则、测试通过标准 |
| 适用标准或过程要求 | 如内部研发过程规范、行业评估要求 |
| 策划版本 | V1.0 起，每次修订递增 |
| 编制人 / 审批人 / 生效日期 |
表2 质量目标表
| 目标编号 | 指标名称 | 目标值 | 度量口径 | 数据来源 | 统计周期 | 责任人 |
|---|---|---|---|---|---|---|
| Q1 | ||||||
| Q2 | ||||||
| Q3 |
表3 职责分工表
| 角色 | 姓名 | 质量责任 | 对应活动编号 | 对应检查点编号 |
|---|---|---|---|---|
| 项目经理 | ||||
| 质量负责人 | ||||
| 开发负责人 | ||||
| 测试负责人 | ||||
| 评审人 |
表4 质量活动表
| 活动编号 | 阶段 | 活动名称 | 输入 | 输出 | 完成标准 | 责任人 |
|---|---|---|---|---|---|---|
| A1 | ||||||
| A2 | ||||||
| A3 |
表5 检查点表
| 检查点编号 | 节点 | 检查内容 | 通过条件 | 所需证据 | 不通过处理 | 检查人 |
|---|---|---|---|---|---|---|
| C1 | ||||||
| C2 | ||||||
| C3 |
字段说明：每个字段填什么、怎么判断填对了
模板能否被不同项目复用，取决于字段口径是否统一。下表按四类信息说明填写要求与判断标准。
| 字段类别 | 代表字段 | 填写要求 | 填对的判断标准 |
|---|---|---|---|
| 质量目标 | 指标名称、目标值、度量口径、数据来源、统计周期 | 目标值写成可比较的数字或比例；度量口径说明分子分母、统计范围与排除项；数据来源指向具体记录系统或台账 | 换一个人按口径统计，能得到相同结果；目标值与验收口径不冲突 |
| 职责 | 角色、质量责任、对应活动与检查点编号 | 写到角色级并落到具体人；责任描述用动作表达，如“组织需求评审并记录结论” | 每项活动和检查点都有明确责任人；同一事项不出现两个最终负责人 |
| 活动 | 阶段、活动名称、输入、输出、完成标准 | 输入输出指向具体文档或工作项；完成标准写成可核验的状态 | 活动输出能作为下游活动的输入；完成标准可被检查人直接判定 |
| 检查点 | 节点、通过条件、所需证据、不通过处理 | 通过条件用可观察的事实描述；证据写明文档名或记录类型；不通过处理写明退回、整改或升级路径 | 检查人无需额外解释即可判定通过与否；证据在检查时能够调取 |
字段之间存在对应关系：表2的目标编号应被表4的活动和表5的检查点引用，说明该目标由哪些活动保障、在哪个节点验证；表3的职责行通过活动编号和检查点编号与后两张表关联。填写时先定目标，再排活动和检查点，最后分配职责，可以避免出现无人负责的检查点或没有验证手段的目标。
必填与选填：哪些字段不能空、哪些按项目裁剪
模板裁剪的原则是：决定“质量是否可判定”的字段必须保留，描述管理细度的字段可按项目规模调整。裁剪针对行和列的数量，不针对字段本身。
| 类别 | 字段 | 理由或适用条件 |
|---|---|---|
| 必填 | 项目范围、验收口径、策划版本 | 界定策划边界，缺失会导致目标无法判定 |
| 必填 | 至少一项质量目标的指标名称、目标值、度量口径、责任人 | 没有量化口径的目标无法验证 |
| 必填 | 质量负责人、开发负责人、测试负责人及其质量责任 | 保证每项活动与检查点有人负责 |
| 必填 | 各阶段至少一项质量活动及其输入、输出、完成标准 | 活动是目标落地的载体 |
| 必填 | 评审、验证、放行三类检查点的通过条件与证据 | 放行前必须有可判定的质量结论 |
| 选填 | 适用标准或过程要求 | 项目涉及外部评估或客户过程要求时填写 |
| 选填 | 统计周期、数据来源的细化说明 | 小型项目可按版本统一统计，无需逐目标单列 |
| 选填 | 评审人一栏的具体名单 | 评审人按每次评审临时确定时可只保留角色 |
| 选填 | 不通过处理的升级路径 | 组织已有统一问题升级流程时可引用流程名称 |
按项目规模裁剪时，小型项目可将质量目标压缩到三至五项、活动按阶段合并，但必须保留最小集合：项目范围与验收口径、每项目标的口径与责任人、关键角色职责、各阶段活动及输出、评审与放行检查点的通过条件和证据。涉及外部评估或交付验收的项目，检查点数量和证据要求应从严，不宜按规模删减。
填写示例：一个研发项目的完整质量策划表
以下为演示情景，用于说明模板用法，不代表任何真实项目数据。
示例背景：某研发团队启动“订单服务 V2.3”版本，范围包括订单创建、支付回调与对账三个模块，不含历史数据迁移；版本周期八周，需通过内部发布评审后上线。
主表填写结果
| 项目/版本名称 | 订单服务 V2.3 |
| 项目范围 | 订单创建、支付回调、对账三个模块；不含历史数据迁移 |
| 质量目标摘要 | Q1 至 Q3，见下表 |
| 验收口径 | 以测试管理记录中的缺陷数据为准，严重缺陷以评审结论为准 |
| 策划版本 | V1.0 |
质量目标
| 编号 | 指标名称 | 目标值 | 度量口径 | 数据来源 | 统计周期 | 责任人 |
|---|---|---|---|---|---|---|
| Q1 | 遗留严重缺陷数 | 发布前为 0 | 严重级别缺陷中未关闭的数量 | 缺陷记录 | 发布评审前 | 测试负责人 |
| Q2 | 需求评审一次通过率 | 不低于 80% | 一次评审通过的需求数 ÷ 评审需求总数 | 评审记录 | 每轮评审 | 质量负责人 |
| Q3 | 核心接口自动化用例通过率 | 100% | 订单创建与支付回调接口用例通过数 ÷ 执行总数 | 测试执行记录 | 每次回归 | 测试负责人 |
职责分工
| 角色 | 质量责任 | 对应活动 | 对应检查点 |
|---|---|---|---|
| 项目经理 | 确认策划版本并组织放行评审 | A1、A4 | C3 |
| 质量负责人 | 组织需求评审、维护质量目标口径、汇总检查结论 | A1、A2 | C1、C2 |
| 开发负责人 | 完成设计评审整改、提交自测记录 | A2、A3 | C2 |
| 测试负责人 | 执行回归测试、统计缺陷数据、提交测试报告 | A3、A4 | C2、C3 |
活动与检查点
| 活动编号 | 阶段 | 活动名称 | 输入 | 输出 | 完成标准 |
|---|---|---|---|---|---|
| A1 | 需求 | 需求评审 | 需求文档 | 评审记录与整改项 | 评审结论已记录，整改项已关闭 |
| A2 | 设计 | 设计评审 | 设计说明 | 评审意见与修订版设计 | 意见逐条回复并确认 |
| A3 | 开发与测试 | 接口回归测试 | 测试用例、构建版本 | 测试执行记录 | 核心接口用例全部执行并记录结果 |
| A4 | 发布 | 发布评审 | 测试报告、缺陷清单 | 放行结论 | Q1 至 Q3 均达成或已批准例外 |
| 检查点编号 | 节点 | 检查内容 | 通过条件 | 所需证据 | 不通过处理 |
|---|---|---|---|---|---|
| C1 | 需求评审结束 | 需求完整性与可测试性 | 评审意见全部关闭，Q2 口径已确认 | 评审记录 | 退回需求修订后重新评审 |
| C2 | 测试完成 | 缺陷与用例执行情况 | Q1 为 0，Q3 达到 100% | 测试报告、缺陷清单 | 修复后重新回归，未达标不得进入发布评审 |
| C3 | 发布前 | 质量目标达成情况 | Q1 至 Q3 达成或例外经审批 | 测试报告、评审结论 | 暂缓发布，明确整改责任人与期限 |
示例中每个检查点都能对应到具体目标：C2 验证 Q1 与 Q3，C3 汇总全部目标；每项活动都有责任人和可调取的输出，与字段说明中的判断标准一致。
调整与维护：模板如何随项目与组织变化更新
模板的长期可用性依赖版本记录和定期复核。建议由质量负责人或过程改进角色担任模板维护人，在每次项目结项后收集填写问题，按季度或半年度发布一次修订。
| 版本 | 变更内容 | 变更原因 | 影响范围 | 修订人 | 生效日期 |
|---|---|---|---|---|---|
| V1.0 | 初版发布 | 建立统一质量策划结构 | 全部研发项目 | ||
| V1.1 |
不同项目类型复用模板时，保持主表与四张附表的结构不变，调整目标数量、活动阶段划分和检查点密度：迭代型项目可按版本复制并精简活动行；涉及外部评估的项目应增加检查点与证据要求。检查点与质量目标需定期复核，重点看目标值是否仍可达成、度量口径是否与数据来源一致、检查点是否仍卡在关键风险位置。
当质量目标、检查点和证据需要在团队日常工作中持续跟踪时，可以把表2至表5的内容落到协作平台中承载。ONES 支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性；其研发管理与 ASPICE 解决方案包含项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于将质量目标关联到工作项、把检查点结论和评审记录沉淀为可追溯的证据。是否采用平台承载，取决于团队已有的记录方式和追溯要求；模板本身仍以表格形式独立可用。
常见问题
小型项目用这套模板时，最少要保留哪些内容？
小型项目可以压缩目标数量、合并阶段活动，但最小集合建议保留：项目范围与验收口径、每项质量目标的度量口径与责任人、质量负责人与开发测试负责人的职责、各阶段至少一项活动及其输入输出、评审与放行检查点的通过条件和证据。涉及外部评估或客户验收的项目，检查点与证据要求应从严，不按规模删减。
质量目标定几个比较合适，定多了会有什么问题？
目标数量取决于项目范围与可采集的数据。目标过多会分散统计精力，也容易出现口径重叠。建议每个版本聚焦三到五项能直接支撑放行判断的目标，例如缺陷、评审通过率、关键用例执行情况；其余指标可作为观察项记录，不进入放行条件。目标值需与验收口径一致，避免出现目标达成但无法判定放行的情况。
检查点不通过时，模板里应该怎么写处理方式？
不通过处理要写到可执行的动作，例如退回修订后重新评审、修复后重新回归、暂缓发布并明确整改责任人与期限。若组织已有统一的问题升级流程，可以引用流程名称，不必在模板中重复展开。关键是让检查人知道判定不通过之后下一步做什么、由谁跟进。
模板填写完成后，质量目标和检查点还需要调整吗？
需要。项目范围变更、数据来源调整或阶段划分变化时，应同步修订目标口径与检查点位置，并记录策划版本。建议在项目结项后收集填写问题，按季度或半年度统一修订模板；单个项目内的调整则在策划版本中留痕，保证检查时能追溯到当时的判定依据。
质量策划表需要放到协作平台里管理吗？
取决于团队的记录方式与追溯要求。表格形式可以独立使用；当质量目标、检查点结论和评审记录需要在日常工作中持续跟踪时，可考虑放到协作平台承载。ONES 支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性；其研发管理与 ASPICE 解决方案包含项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于将质量目标关联到工作项、把检查点结论沉淀为可追溯证据。具体开通范围以实际部署为准。
