研发质量策划需要输出哪些文档和模板

研发质量策划的输出物可以归为四类:质量策划总纲、质量活动与检查点计划、质量职责与角色矩阵、质量记录与度量模板。本文给出可直接复制填写的空白表格,覆盖质量目标、职责分工、活动检查点与问题跟踪,并配套字段说明、必填选填划分和一个迭代周期的填写示例。质量目标与检查点的跟踪记录,可以放在ONES的工作项与文档中承载,便于后续评审和复盘时查阅。



要点总览(TL;DR)


  • 研发质量策划的核心输出物分四类:质量策划总纲、质量活动与检查点计划、质量职责与角色矩阵、质量记录与度量模板。
  • 最小可用组合是质量目标表、职责矩阵、活动与检查点表加问题与改进跟踪表,其余文档按组织成熟度增补。
  • 质量目标表要写清度量口径、目标值、责任人和检查时点;职责矩阵每项活动有且只有一个A,负责人与活动表保持一致。
  • 活动与检查点表的准入、准出条件要可核查,记录形式指向评审记录或问题跟踪表,形成目标、检查、问题闭环。
  • 模板按项目规模裁剪时只减表格或字段,不删检查点;字段增删需重新评审并保留版本记录。


研发质量策划输出物清单总览


质量策划的输出物按用途分为四类。第一类是总纲性文件,回答“质量目标是什么、覆盖哪些范围、谁负责、按什么节奏推进”;第二类是活动计划,回答“在哪些节点做哪些检查、满足什么条件才能进入下一阶段”;第三类是职责矩阵,回答“每项质量活动由谁执行、谁审批、谁被通知”;第四类是记录与度量模板,回答“活动做完留下什么证据、问题如何跟踪闭环”。四类文件互相引用,缺一类就会出现目标无落点、活动无责任人、问题无记录的情况。


下表列出各类输出物的名称、用途、主要使用角色和最小可用版本。最小可用版本指能够支撑一次完整质量策划并留下可核查记录的最低配置,组织可在此基础上按成熟度增补。


输出物 用途 主要使用角色 最小可用版本
质量策划总纲 明确质量目标、适用范围、组织职责与里程碑安排 质量负责人、项目负责人 一页纸:目标表+范围说明+里程碑清单
质量目标表 把质量要求转化为可度量、可检查的目标项 质量负责人、各角色责任人 目标项、度量口径、目标值、责任人、检查时点五列
质量职责矩阵 明确每项质量活动的执行、审批、协作与知会关系 项目负责人、质量负责人 角色×活动的R/A/C/I矩阵
质量活动与检查点计划 安排评审、审计、验证节点及准入准出条件 质量负责人、评审组织者 阶段、活动、检查点、准入条件、准出条件、负责人、记录七列
评审与审计记录 留存每次评审和审计的结论与待办 评审组织者、被评审方 基本信息+问题清单+结论三部分
问题与改进跟踪表 跟踪问题从提出到关闭的全过程 质量负责人、问题责任人 问题描述、来源、责任人、期限、状态、验证结论
度量与报告模板 按周期汇总质量数据并形成报告 质量负责人、管理层 指标清单+数据来源+趋势说明

组织成熟度提高后,可按需增补:质量策划评审记录、供应商与外协质量要求、配置管理与变更控制说明、质量培训计划、质量成本统计表。增补的原则是每增加一份文档,都要明确它的使用角色和检查时点,避免形成只归档不使用的文件。



可复制空白模板:质量目标与职责矩阵


质量目标表把抽象的质量要求落到可检查的条目上。填写时先确定目标项,再约定度量口径和目标值,最后指定责任人和检查时点。目标值应来自项目实际约束或历史数据,没有依据时先留空并在策划评审时补齐。


模板一:质量目标表


序号 目标项 度量口径 目标值 责任人 检查时点 数据来源 备注
1
2
3
4
5

模板二:质量职责矩阵


矩阵采用R/A/C/I分工:R为负责执行,A为最终审批,C为需征询意见,I为需被知会。每项活动有且只有一个A,R可以多人,C和I按需填写。


质量活动 项目负责人 质量负责人 开发负责人 测试负责人 产品负责人 配置管理员
质量目标制定
质量策划评审
需求评审
设计评审
代码审查
测试准入检查
发布准出评审
质量问题跟踪
质量复盘

两张表的填写位置说明:目标表的“检查时点”填写具体节点或日期,例如“迭代评审前”“每月末”;“数据来源”填写数据从哪个系统或记录中取,避免度量时口径不一致。职责矩阵的行按本项目实际开展的质量活动增删,列按项目角色设置,角色名称与组织实际称谓保持一致。



可复制空白模板:质量活动与检查点计划


活动与检查点计划是质量策划中执行性最强的一份文件。它把每个阶段要做的质量活动、对应的检查点、进入和退出条件写清楚,使评审和验证有明确依据。准入条件写“满足什么才能开始”,准出条件写“满足什么才能结束并进入下一阶段”,两者都要可核查。


模板三:质量活动与检查点计划表


阶段 质量活动 检查点 准入条件 准出条件 负责人 计划时间 记录形式

模板四:评审与审计记录


项目 内容
评审/审计名称
日期与地点
组织者
参与人员及角色
评审对象与版本
检查依据(标准、清单或计划)
发现问题清单(编号、描述、严重程度、责任人、期限)
评审结论(通过/有条件通过/不通过)
后续动作与复查安排

模板五:问题与改进跟踪表


问题编号 问题描述 来源 严重程度 责任人 提出日期 计划关闭日期 当前状态 改进措施 验证结论

三张表之间存在引用关系:活动计划表中的“记录形式”指向评审记录或问题跟踪表,评审记录中发现的待办进入问题跟踪表,问题关闭后在活动计划表的检查点结论中体现。保持这种引用关系,质量策划才形成闭环,而不是三份互不相关的表格。



字段说明与必填选填划分


字段说明的作用是让不同填写人对同一列有相同理解。必填字段是模板成立的最低要求,缺失会导致表格无法支撑检查;选填字段按项目需要补充。下表按模板分组说明。


模板 字段 含义 必填/选填 填写要求
质量目标表 目标项 要达成的质量结果 必填 一条只写一个目标,表述可判断是否达成
质量目标表 度量口径 目标值的计算方式 必填 写清分子分母、统计范围和统计周期
质量目标表 目标值 期望达到的数值或状态 必填 有依据时写数值,无依据时标注待定并在评审时补齐
质量目标表 责任人 对该目标结果负责的人 必填 写具体人名或岗位,不写部门统称
质量目标表 检查时点 何时核对目标进展 必填 写节点名称或日期
质量目标表 数据来源 度量数据的出处 选填 建议填写,便于复核
职责矩阵 质量活动 矩阵的行,即需要分工的活动 必填 与活动计划表中的活动名称保持一致
职责矩阵 角色列 矩阵的列,即参与角色 必填 按项目实际角色设置
职责矩阵 R/A/C/I标记 该角色在该活动中的分工 必填 每行至少一个A,且只有一个A
活动与检查点表 阶段 活动所属的研发阶段 必填 与项目阶段划分一致
活动与检查点表 质量活动 要开展的质量工作 必填 一条只写一项活动
活动与检查点表 检查点 用于判断活动完成情况的节点 必填 写可核查的检查对象
活动与检查点表 准入条件 开始该活动的前置条件 必填 条件可验证,避免“基本完成”一类表述
活动与检查点表 准出条件 结束该活动并进入下一阶段的条件 必填 与准入条件对应,写明遗留问题处理方式
活动与检查点表 负责人 组织该活动的人 必填 与职责矩阵中的A保持一致
活动与检查点表 计划时间 活动预计开展时间 选填 按项目计划填写
活动与检查点表 记录形式 活动留下的记录类型 必填 指向评审记录、问题跟踪表或测试报告
评审与审计记录 评审对象与版本 被评审内容的标识 必填 写清名称和版本号
评审与审计记录 发现问题清单 评审中识别的问题 必填 无问题时写“无”,不空置
评审与审计记录 评审结论 对评审对象的判定 必填 从约定的结论选项中选取
问题跟踪表 问题描述 问题的具体表现 必填 写现象和影响,不写笼统评价
问题跟踪表 严重程度 问题的影响等级 必填 按组织约定的分级标准填写
问题跟踪表 责任人 负责解决问题的人 必填 写具体人名
问题跟踪表 当前状态 问题所处处理阶段 必填 使用统一状态词,如待处理、处理中、待验证、已关闭
问题跟踪表 改进措施 解决问题采取的动作 选填 问题关闭前补充
问题跟踪表 验证结论 对改进结果的确认 必填 关闭问题时填写验证人和结论

必填与选填的划分不是固定的。组织在模板评审时可以调整,但调整后要同步更新字段说明,避免模板与说明脱节。



填写示例:一个迭代周期的质量策划


以下示例为演示情景,项目背景设定为一个六人团队、双周迭代的软件研发项目,目标值仅用于说明填写方式,不作为行业基准。


示例背景与范围:本次质量策划覆盖一个双周迭代,范围包括需求评审、设计评审、代码审查、测试准入与发布准出五个检查点。质量负责人组织策划,项目负责人审批。


质量目标表填写示例


序号 目标项 度量口径 目标值 责任人 检查时点 数据来源
1 需求评审一次通过率 一次通过的需求条目数÷评审需求条目总数 ≥80% 产品负责人 需求评审后 评审记录
2 代码审查覆盖率 已审查变更数÷迭代内变更总数 100% 开发负责人 迭代结束前 代码库审查记录
3 测试准入一次通过率 一次满足准入条件的提测次数÷提测总次数 ≥90% 测试负责人 每次提测时 测试准入检查记录
4 发布前遗留问题数 发布评审时未关闭的严重及以上问题数 0 质量负责人 发布评审时 问题跟踪表

职责矩阵填写示例


质量活动 项目负责人 质量负责人 开发负责人 测试负责人 产品负责人
质量目标制定 A R C C C
质量策划评审 A R I I I
需求评审 I C C C A/R
设计评审 I C A/R C I
代码审查 I I A/R I I
测试准入检查 I C R A I
发布准出评审 A R C C C
质量问题跟踪 I A R R I

活动与检查点表填写示例


阶段 质量活动 检查点 准入条件 准出条件 负责人 记录形式
需求 需求评审 需求评审会 需求文档完成并提前一天发出 评审结论为通过或有条件通过,问题已登记 产品负责人 评审记录
设计 设计评审 设计评审会 设计文档完成,接口说明齐全 关键设计问题关闭或有明确处理计划 开发负责人 评审记录
开发 代码审查 合并前审查 变更提交并附说明 审查意见处理完毕 开发负责人 代码库审查记录
测试 测试准入检查 提测检查 自测完成,构建可部署 准入清单逐项确认通过 测试负责人 准入检查记录
发布 发布准出评审 发布评审会 测试报告完成,遗留问题清单明确 严重及以上问题为0,结论为通过 质量负责人 评审记录+问题跟踪表

记录模板填写示例:需求评审记录中,评审对象写“订单模块需求说明书V1.2”,发现问题清单登记两条,一条为“异常流程描述缺失”,严重程度中,责任人为产品负责人,期限为评审后两天;评审结论为“有条件通过”,复查安排为“修改后由质量负责人确认”。这两条问题同步进入问题跟踪表,状态从“待处理”推进到“待验证”,验证通过后关闭,并在发布准出评审时核对遗留问题数为0。


这套示例体现了表格之间的对应关系:目标表中的“需求评审一次通过率”对应活动表中的需求评审检查点,职责矩阵中的A与活动表中的负责人一致,问题跟踪表承接评审记录中的待办。质量目标、检查点和问题记录分散在不同表格中时,用ONES的工作项和文档统一承载,可以让责任人在同一处看到目标进展与待办状态,减少跨表核对。



模板的调整与维护方法


模板需要随项目规模和组织变化调整,否则会出现小项目填表负担过重、大项目覆盖不足的问题。调整和维护按以下规则执行。


按项目规模裁剪:小规模项目保留质量目标表、职责矩阵和活动检查点表三张核心表,评审记录可并入活动检查点表的记录列;中大型项目增加度量报告模板和独立的评审记录;跨团队项目增加接口质量要求和联合评审安排。裁剪时只减少表格数量或字段,不删除检查点本身。


模板评审与发布:模板由质量负责人起草,经项目负责人和相关角色代表评审后发布。评审关注三点:字段是否支撑检查、必填项是否可实际填写、表格之间的引用是否清晰。发布时标注适用项目类型和生效日期。


版本与变更记录:模板文件保留版本号和变更记录,记录变更内容、原因、提出人和生效时间。字段增删属于版本变更,需重新评审;仅调整填写说明的,可由质量负责人直接更新并通知使用人。


定期复盘与更新触发:每个季度或在项目复盘时检查模板使用情况,出现以下情况触发更新:多个项目反映某字段无法填写、检查点与实际阶段划分不符、问题跟踪表出现大量重复登记、组织角色设置发生变化。更新后同步修订字段说明和填写示例,保持三者一致。


维护规则清单可归纳为:裁剪只减表格不减检查点;发布前完成角色评审;每次变更留版本记录;复盘发现字段失效即触发修订;模板、说明、示例同步更新。



常见问题


小团队做研发质量策划,最少要准备哪几份模板?


六人左右、单迭代交付的团队,保留三张核心表即可支撑一次完整策划:质量目标表、质量职责矩阵、质量活动与检查点计划表。问题与改进跟踪表可以先用活动检查点表的记录列承接,等评审中问题数量增多再独立成表。裁剪时减少的是表格数量和字段,检查点本身要保留,否则质量策划就失去了核查依据。


质量目标没有历史数据,目标值怎么填?


没有历史数据时,目标值先标注“待定”,在质量策划评审时由项目负责人和相关角色共同确认,并写明确认依据,例如上一版本的实际表现、客户要求或团队约定。度量口径必须同时写清,包括分子分母、统计范围和统计周期,否则后续核对时容易各算各的。目标值确定后,在检查时点按数据来源复核,第一个周期结束后可作为下一轮策划的参考。


职责矩阵里一项活动出现两个A怎么办?


一项活动有且只有一个A(最终审批),出现两个A通常意味着活动边界没有拆清。处理方式是把活动拆成两项,例如把“发布准出评审”拆为“发布材料准备”和“发布准出决策”,分别指定A;或者明确其中一个是执行负责人R,另一个是审批人A。拆分后同步更新活动与检查点表中的活动名称和负责人,保持两张表一致。


模板上线后,什么情况下需要修订?


出现以下情况时触发修订:多个项目反映某字段无法实际填写;检查点与项目阶段划分不符;问题跟踪表出现大量重复登记;组织角色设置发生变化。字段增删属于版本变更,需要重新评审并记录变更内容、原因和生效时间;仅调整填写说明的,可由质量负责人直接更新并通知使用人。修订后同步更新字段说明和填写示例,避免模板、说明、示例三者脱节。


质量策划的模板和单项目质量控制是什么关系?


质量策划模板解决的是“策划阶段要产出哪些文件、每份文件写什么”,属于组织质量保障体系的层面;单项目质量控制关注具体项目执行中的检查、评审和问题处理。本文提供的模板可以直接用于单个项目的策划,但项目执行中的测试活动、缺陷处理等细节不在本文展开,需要结合项目质量管理与测试管理的相应流程执行。