质量目标分解表把项目质量要求拆成一行行可检查、可交接、可关闭的记录，核心主线是“阶段—交付物—责任人—检查方式—整改要求”。本文提供一张可直接复制到文档或表格工具中的空白模板，并逐字段说明填写口径、必填与选填的取舍、一张完整示例行，以及模板落地后的调整与维护方法。
要点总览（TL;DR）
- 质量目标分解表以“阶段—交付物—责任人—检查方式—整改要求”为主线，每行对应一个可独立检查的质量目标。
- 必填字段为阶段、质量目标、交付物、责任人、检查方式、整改要求；验收标准、检查时点、整改责任人、整改期限、关闭状态建议填写。
- 小项目可精简检查记录等选填列，复杂项目可扩展风险等级、复检人、关联里程碑等字段。
- 模板需按项目类型调整字段，阶段推进时更新行状态，检查后当天更新记录，复检通过后再关闭。
可复制的质量目标分解表空白模板
下表按五类核心字段展开，同时保留质量目标、验收标准、检查时点、检查记录、整改责任人、整改期限和关闭状态等配套列。复制到表格工具后，第一行作为表头，第二行起每行填写一个质量目标；示例占位符可直接替换为项目实际内容。
| 序号 | 阶段 | 质量目标 | 交付物 | 验收标准 | 责任人 | 检查方式 | 检查时点 | 检查记录 | 整改要求 | 整改责任人 | 整改期限 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | （填写阶段名称） | （填写该阶段要达成的质量目标） | （填写可检查的产出物） | （填写判定合格的口径） | （填写交付物负责人） | （填写评审/抽检/核对等方式） | （填写检查发生的时点） | （填写检查结论与证据位置） | （填写问题描述与整改动作） | （填写整改执行人） | （填写完成整改的日期） | （未开始/整改中/已关闭） |
| 2 | ||||||||||||
| 3 |
表格中“阶段、质量目标、交付物、责任人、检查方式、整改要求”为必填列，其余列按项目管控强度选填。行数按阶段和质量目标数量增减，同一阶段可以有多行，每行只对应一个可独立检查的目标，避免一行塞入多个交付物导致责任和检查口径混淆。
每个字段的含义与填写口径
字段填写的共同原则是：让另一个人拿着这一行就能判断“查什么、谁来查、怎么查、查出问题怎么办”。下表逐列说明含义与常见写法。
| 字段 | 含义 | 填写口径与常见写法 |
|---|---|---|
| 阶段 | 该质量目标所属的项目生命周期节点 | 与项目实际计划节点对应，如启动、规划、设计、开发、测试、验收、收尾；也可按里程碑命名。划分口径以项目类型和交付节奏为准，同一项目内保持统一，不混用两套阶段名称。 |
| 质量目标 | 该阶段要达成的质量结果 | 写成可判断的表述，如“需求文档评审一次通过率不低于约定比例”“接口联调问题在约定时限内闭环”。避免只写“保证质量”这类无法检查的表述。 |
| 交付物 | 承载质量目标的产出对象 | 写具体文件名或成果名称，如“需求规格说明书V1.0”“接口测试报告”“上线检查清单”。交付物应是可打开、可核对的对象。 |
| 验收标准 | 判定交付物合格的口径 | 与交付物分开填写，写清检查项和合格线，如“覆盖全部需求条目，无未关闭的高优先级评审意见”。验收标准回答“怎样算合格”，交付物回答“检查什么”。 |
| 责任人 | 交付物的直接负责人 | 填具体人名或岗位，负责按标准产出交付物并配合检查。一个交付物对应一个主责人，协作人可写在备注或检查记录中。 |
| 检查方式 | 检查采用的手段 | 常见写法：文档评审、抽样检查、逐项核对、现场演示、系统数据比对。检查方式要与验收标准匹配，标准要求逐项覆盖时不宜只做抽检。 |
| 检查时点 | 检查发生的时间或触发条件 | 与检查方式成对填写，如“交付物提交后2个工作日内评审”“阶段结束前完成抽检”。只写方式不写时点，检查容易被推迟到项目后期集中补做。 |
| 检查记录 | 检查结论与证据位置 | 记录检查日期、检查人、结论（通过/有条件通过/不通过）以及证据所在位置，如评审记录编号、文档链接或会议纪要。 |
| 整改要求 | 检查不通过时的处理要求 | 写清问题描述、整改动作和复检要求，如“补齐缺失的需求条目并重新评审，复检通过后关闭”。整改要求要能对应到具体问题，避免只写“限期整改”。 |
| 整改责任人 | 执行整改的人 | 通常为交付物责任人或其指定的执行人。与“责任人”列分开，是为了在问题出现时明确由谁改、由谁验。 |
| 整改期限 | 整改完成的截止时间 | 写具体日期或相对时限，如“检查结论发出后3个工作日内”。期限应与问题严重程度匹配。 |
| 关闭状态 | 该行质量目标的处理进度 | 建议使用固定取值：未开始、检查中、整改中、已关闭。关闭需以复检通过为依据，不能仅凭口头确认。 |
责任人与整改责任人的分工值得单独强调：责任人对交付物质量负责，整改责任人对问题修复负责。两者可以是同一人，但在表中分列填写，检查不通过时才能清楚区分“谁产出、谁修复、谁复检”。
必填与选填字段的取舍
必填字段保证每一行都能被检查和闭环，选填字段用于补充证据和过程信息。项目规模小、交付节奏快时，先保证必填列完整；管控要求高、参与方多时，再逐步补齐选填列。
| 类别 | 字段 | 取舍原则 |
|---|---|---|
| 必填 | 阶段、质量目标、交付物、责任人、检查方式、整改要求 | 缺少任一列，该行就无法回答“在哪个阶段、查什么、谁负责、怎么查、查出问题怎么办”，应始终填写。 |
| 建议填写 | 验收标准、检查时点、整改责任人、整改期限、关闭状态 | 直接决定检查能否执行和整改能否关闭。项目再小，也建议保留验收标准、检查时点和关闭状态。 |
| 选填 | 检查记录、序号、备注类扩展列 | 检查记录可放在表内，也可链接到评审记录或协作工具中的工作项；序号便于引用和统计。 |
| 复杂项目扩展 | 风险等级、复检人、关联里程碑、证据链接 | 参与方多、交付物需要多方确认时增加，用于分级处理和追溯，不要求所有项目套用。 |
小项目可以只保留必填列加验收标准、检查时点和关闭状态，把检查记录写在交付物所在文档的评审区。复杂项目则建议补齐整改责任人和整改期限，并增加复检人列，让整改关闭经过第二人确认。取舍的判断依据是：这一列是否会影响某次检查的执行或某个问题的关闭；会影响就保留，不影响就放到备注或关联记录中。
一张填好的示例：某阶段质量目标分解行
以下示例为演示情景，用于说明字段之间如何配合，不代表任何具体项目的真实数据。
| 阶段 | 质量目标 | 交付物 | 验收标准 | 责任人 | 检查方式 | 检查时点 | 检查记录 | 整改要求 | 整改责任人 | 整改期限 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 设计阶段 | 概要设计覆盖全部已确认需求，评审意见在进入开发前关闭 | 概要设计说明书V1.0 | 需求条目逐条有对应设计说明；高优先级评审意见全部关闭，中低优先级意见有处理结论 | 设计负责人 | 文档评审，逐条核对需求覆盖情况 | 设计文档提交后2个工作日内组织评审 | 评审记录编号与结论：有条件通过，2条中优先级意见待处理 | 补充异常流程设计说明，对2条中优先级意见逐条给出处理结论并复评 | 设计负责人指定模块设计人 | 评审结论发出后3个工作日内 | 整改中 |
解读这一行：阶段限定在设计阶段，质量目标写的是可判断的结果而非笼统要求；交付物是具体的文档版本，验收标准把“合格”拆成需求覆盖和评审意见处理两部分；检查方式与检查时点配对，说明由谁在什么时间用什么手段检查；检查记录保留了结论和待处理项；整改要求直接对应检查发现的问题，并指定整改责任人和期限；关闭状态显示该行尚未闭环，需复评通过后才能改为已关闭。
当这类表格需要在团队中持续使用时，检查记录和整改状态需要有承载位置。ONES的项目计划支持按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点；项目计划和里程碑基线可用于对比计划与执行的偏差。质量目标分解表中的每一行，可以对应到项目计划中的任务或里程碑，检查记录与整改状态随任务推进更新，使表格从静态清单变成可跟踪的记录。具体字段配置与状态流转方式以实际版本和套餐为准。
模板的调整与维护方法
模板的价值在于持续可用。项目启动时按类型调整字段，执行中按阶段更新行状态，阶段结束时核对关闭情况，版本变化时保留可追溯的记录。
- 按项目类型增删字段。研发类项目可增加“关联需求编号”“测试覆盖情况”；交付实施类项目可增加“客户确认人”“验收签字”；采购或外包参与的项目可增加“供方交付物”“来料检查结论”。新增字段应说明填写口径，避免同一列在不同项目里含义不同。
- 阶段推进时更新行。进入新阶段前，把上一阶段各行的关闭状态核对一遍，未关闭的行带入下一阶段并注明原因；新阶段按质量目标新增行，阶段列填写统一名称。阶段名称变更时整表同步替换，不留下新旧混用。
- 按固定节奏维护检查记录与整改关闭。建议在每次检查后当天更新检查记录，整改期限到期前核对整改责任人进度，复检通过后再改关闭状态。每周或每个里程碑节点做一次整表巡检，重点看“整改中”且已超期的行。
- 做好模板版本管理。模板本身标注版本号和生效日期；字段增删、取值调整记录在版本说明中，已启动项目沿用启动时的版本，新项目使用新版本，避免执行中途改口径导致前后数据不可比。
- 定期复盘字段有效性。项目收尾时统计哪些列经常空白、哪些列从未用于判断，空置的选填列可以删除，频繁补填的列考虑转为必填，让下一版模板更贴合实际检查动作。
维护的核心是让每一行都有明确的当前状态和下一步动作：谁在什么时候检查、查出问题由谁在什么期限内整改、复检通过后由谁关闭。做到这三点，质量目标分解表就能在项目执行中持续发挥作用。
常见问题
质量目标分解表与项目计划中的任务是什么关系？
质量目标分解表是质量控制清单，项目计划中的任务是执行安排。两者可以对应：分解表中的每一行可关联到项目计划中的任务或里程碑，检查记录与整改状态随任务推进更新。这样表格中的质量目标就有了执行载体，检查时点也可与任务时间对齐。ONES的项目计划支持按目标、交付物或项目阶段等维度分解工作，并可为任务设置前后置依赖、用里程碑标记重要时间点，可作为承载检查记录与整改闭环的协作工具之一。
检查方式写“评审”够不够？还需要补充什么？
只写“评审”偏笼统，建议同时写明评审类型（文档评审、设计评审、代码评审等）、参与角色和输出物（评审记录、问题清单）。检查方式要与验收标准匹配：如果验收标准要求逐条覆盖，检查方式应写“逐条核对”而非“抽检”。检查方式还需与检查时点成对填写，说明在什么时间或触发条件下执行检查，避免检查被推迟。
整改要求只写“限期整改”可以吗？
不建议。整改要求应写清问题描述、整改动作和复检要求，例如“补齐缺失的需求条目并重新评审，复检通过后关闭”。同时填写整改责任人和整改期限，期限写具体日期或相对时限。只写“限期整改”会导致整改动作不明确、复检无依据，关闭状态也难以判断。
小项目字段太多填不过来，最少保留哪些列？
最少保留必填列：阶段、质量目标、交付物、责任人、检查方式、整改要求。在此基础上建议保留验收标准、检查时点和关闭状态，这三列直接决定检查能否执行和整改能否关闭。检查记录可以写在交付物所在文档的评审区，不单独占列。序号和备注类扩展列可按需取舍。
模板用了一段时间后，如何判断哪些字段该删或该加？
项目收尾时统计各列的使用情况：经常空白的选填列可以删除，频繁补填的列考虑转为必填。同时回顾检查记录和整改关闭过程中是否因缺少某列导致信息不全，若有则增加对应字段。字段调整后更新模板版本号和生效日期，新项目使用新版本，已启动项目沿用启动时的版本，保证前后数据可比。
