项目质量责任要落到可执行的程度，需要先把质量目标拆成可判定的验收口径，再按阶段列出质量活动，为每项活动指定唯一责任人、验收人、交付证据和判定时点，形成一份质量责任矩阵。本文围绕单项目质量控制展开，给出从目标设定到责任检查的完整步骤，并附可填写的矩阵模板与检查清单。
要点总览（TL;DR）
- 明确质量责任的前提是把质量目标写成可判定的验收口径：每条目标写明验收标准、判定方式、判定时点和判定依据，责任才有落点。
- 把目标转成按阶段排列的质量活动清单，每项活动写清输入、动作、输出和完成标志，并标注哪些属于本项目控制范围。
- 用质量责任矩阵固定分工：每项活动只设一个责任人，验收人独立于执行人，签署权与验收权分离时写清先后关系。
- 按角色汇总交付物并在启动会上逐行确认，评审记录、检查单和问题单作为责任履行的证据同步留存。
- 用检查清单逐条核对责任人是否唯一、证据是否可查、判定时点是否明确，发现空缺先补人再补记录。
先定质量目标与验收口径
责任无法落到“保证质量”这类笼统表述上。明确责任的第一步，是把项目质量目标写成可以判定的条目，让每个责任人都知道自己在什么时点、依据什么标准、交出什么结果算完成。
质量目标通常分两类。可交付物级目标针对具体产出，例如需求规格说明的完整性、接口文档与实现的一致性、版本发布前的缺陷收敛情况。过程级目标针对活动本身，例如评审是否按计划完成、评审意见是否全部关闭、变更是否经过影响分析。两类目标都要落到条目上，避免只写方向。
每条目标需要写明四项内容：验收标准、判定方式、判定时点和判定依据。验收标准描述达到什么状态算合格；判定方式说明是评审、检查、测试还是数据比对；判定时点明确在哪个阶段节点或里程碑之前完成；判定依据指记录在什么载体上，如评审记录、检查单、问题单或报告。
| 目标项 | 验收标准 | 判定方式 | 判定时点 |
|---|---|---|---|
| 需求规格说明 | 关键需求均有验收条件，需求方确认无遗漏 | 需求评审 | 设计启动前 |
| 接口文档 | 与实现一致，异常场景有说明 | 文档检查与联调验证 | 联调开始前 |
| 版本质量 | 遗留缺陷均有处理结论 | 缺陷清单核对 | 发布评审时 |
需要区分边界：本节处理的是单个项目内部的质量控制目标。组织级的质量方针、过程规范和审计要求属于研发质量保证体系的范畴，项目只需引用并落实其中适用于本项目的部分；测试用例设计与测试执行的具体安排属于测试管理，项目质量目标只需引用其结论作为判定依据，不必在本节展开测试方法。
按阶段列出质量活动清单
目标确定后，要把它转成可以分配给人的活动。做法是按项目阶段逐段梳理，每项活动写清输入、动作、输出和完成标志，形成分阶段质量活动清单。
常见阶段及对应活动包括：需求阶段的需求评审、需求变更影响分析；设计阶段的设计评审、接口约定确认；开发阶段的代码评审、单元自测记录；测试前的准入检查，确认提测条件满足；交付阶段的发布评审、遗留问题处理确认、交付物归档检查。阶段划分可按项目实际裁剪，关键是每项活动都能对应到前一步设定的目标。
每项活动的四要素要写具体。输入指开展活动所依据的材料，如需求文档、设计稿、代码提交记录；动作指谁做什么，如组织评审、逐条核对、执行检查；输出指活动产生的记录或结论，如评审纪要、检查单、问题清单；完成标志指可以判定活动结束的状态，如评审意见全部关闭、检查项全部通过。
- 输入：需求规格说明初稿、上一版评审遗留问题清单
- 动作：需求方与技术人员逐条评审，记录意见并指定处理人
- 输出：评审记录、问题清单
- 完成标志：所有意见有处理结论并关闭
梳理时同步标注活动归属。属于本项目控制范围的活动，由项目内角色承担并在矩阵中分配；由组织制度规定的活动，如过程审计、组织级评审，项目只需配合并提供材料；属于测试管理的活动，如用例设计、测试执行，项目关注其结论和准入条件。这样标注可以避免把项目外的责任写进矩阵，造成责任虚化。
用质量责任矩阵分配角色与签署权
质量活动清单完成后，用一张矩阵把每项活动的责任固定下来。矩阵的核心规则是：每项活动只设一个责任人，其余角色以执行、验收、签署、提供证据的身份出现。
| 字段 | 填写要求 |
|---|---|
| 活动 | 来自分阶段质量活动清单，一项一行 |
| 责任人 | 唯一，对活动按时按质完成负总责 |
| 执行人 | 实际开展活动的人，可与责任人相同 |
| 验收人 | 判定活动结果是否合格的人，不能与执行人相同 |
| 签署权 | 有权确认放行或关闭的人，明确签署动作 |
| 证据 | 活动完成后留存的记录载体 |
| 判定时点 | 验收与签署必须完成的阶段节点 |
只设一个责任人是矩阵能否落地的关键。多人共同负责时，容易出现“都以为对方在跟”的情况。可以由一人负责组织与推动，其他人作为执行人或验收人参与，但活动整体状态由责任人一人对项目负责。
角色分工上，项目经理通常对质量活动计划的完整性和节奏负责，确保活动按阶段开展、问题有人跟进；技术负责人对设计评审、代码评审等技术类活动的质量负责，并承担技术方案的签署；质量角色负责检查活动是否按约定执行、证据是否齐全，对过程符合性进行把关；需求方对需求相关活动的验收负责，确认需求理解与验收条件。执行层面的开发与测试人员承担具体活动的执行和记录。
签署权与验收权分离时，要写清两者的先后关系。验收人先判定结果合格，签署人再据此确认放行；签署人发现验收依据不足时，可以退回补充证据，但不能替代验收人直接判定技术结果。两者由同一人承担时，在矩阵中注明，并在检查时重点核对该活动的证据是否独立可查。
矩阵落到协作工具中时，可把每项质量活动建成工作项，责任人、验收人和判定时点作为字段填写，评审记录、检查单和问题单作为附件或关联记录留存。ONES 的项目计划支持按交付物或项目阶段分解工作并设置里程碑，可作为承载质量活动与判定时点的载体；测试相关的准入与缺陷结论可在测试管理中形成记录，作为矩阵中相应活动的证据来源。
角色及交付物对照
矩阵确定后，按角色汇总各自要交出的东西，便于在项目启动会上逐人确认，也便于后续检查时按角色核对。
| 角色 | 主要交付物 | 在评审、放行、问题闭环中的动作 |
|---|---|---|
| 项目经理 | 质量活动计划、责任矩阵、阶段检查记录 | 组织阶段评审，跟踪问题关闭，确认放行条件满足 |
| 技术负责人 | 设计评审记录、技术方案签署、代码评审结论 | 主持技术评审，对技术类活动结果签署 |
| 质量角色 | 过程检查单、证据完整性核对记录 | 核查活动是否按约定执行，提出补正要求 |
| 需求方 | 需求确认记录、验收条件确认 | 参与需求评审，确认验收口径，验收需求相关产出 |
| 开发执行者 | 自测记录、代码提交与评审响应 | 按约定完成自测，处理评审意见 |
| 测试执行者 | 准入检查结论、缺陷记录 | 执行准入检查，提交缺陷并跟踪关闭 |
角色缺位时需要提前安排替代。项目没有独立质量角色时，可由项目经理承担过程检查，但验收职责应交给未参与执行的人，避免自查自验。一人多角时，在矩阵中如实标注兼任情况，并对兼任的验收类活动增加一次交叉核对，例如由技术负责人复核项目经理兼任质量角色时出具的检查结论。
示例：一个迭代的质量责任分配
以下为演示情景，用于说明填写过程，不代表真实项目数据。
某迭代的目标是交付一个订单查询功能。质量目标设定为三条：需求验收条件经需求方确认；接口文档与实现一致；发布前无未处理的阻断级缺陷。判定方式分别为需求评审、联调核对和发布评审，判定时点分别在设计启动前、联调开始前和发布当天。
对应活动与分配如下：需求评审由产品经理任责任人，需求方验收并签署确认，证据为评审记录；接口文档核对由技术负责人任责任人，后端开发执行，技术负责人验收，证据为联调记录；提测准入检查由测试执行者任责任人并执行，质量角色验收，证据为准入检查单；发布评审由项目经理任责任人，技术负责人与需求方参与验收，项目经理签署放行，证据为发布评审记录和缺陷清单。
执行中出现过一次责任冲突：接口文档核对原定由后端开发自行验收，与执行人重合。处理方式是把验收人调整为技术负责人，开发人员只负责修改与提交，验收结论单独记录。另有一次提测准入未通过，测试执行者按矩阵判定不予放行，开发补充自测记录后重新检查通过，两次检查单均留存，形成完整证据链。
责任落地与完成检查
矩阵填写完成不等于责任落实。需要在项目启动时完成确认与发布，在执行中留存证据，并用检查项逐条核对。
启动确认的做法是：在项目启动会或迭代计划会上逐行过矩阵，责任人和验收人当场确认，对判定时点有异议的当场调整，确认后的版本作为项目基线发布，后续变更需记录变更原因和确认人。
证据留存要求与活动同步。评审类活动留存评审记录和意见关闭情况；检查类活动留存检查单和结论；问题类活动留存问题单及其关闭依据。证据应能在活动完成后随时调取，而不是事后补写。
| 检查项 | 通过标准 | 不通过时的补正动作 |
|---|---|---|
| 每项活动是否有唯一责任人 | 矩阵中无空白、无多人共担 | 指定唯一责任人，其他人改为执行或验收角色 |
| 验收人是否独立于执行人 | 两者不同，或兼任时已安排交叉核对 | 调整验收人，或增加复核记录 |
| 判定时点是否明确 | 每项活动对应到具体阶段节点或里程碑 | 补充时点，并与项目计划对齐 |
| 证据是否可查 | 活动完成后能调取对应记录 | 补建记录载体，明确留存位置和责任人 |
| 问题是否闭环 | 评审与检查发现的问题均有处理结论 | 建立问题清单，指定关闭责任人和时限 |
检查可按阶段节点执行，也可在里程碑前集中核对。发现责任空缺时，先补人再补记录；发现证据缺失时，确认活动是否实际开展，未开展的补做，已开展但未留痕的由责任人补充说明并经验收人确认。检查结果记入阶段检查记录，作为下一阶段责任分配调整的依据。
常见问题
项目里没有独立的质量角色，质量责任还能分下去吗？
可以。质量角色的核心职责是检查活动是否按约定执行、证据是否齐全，这部分工作可以由项目经理兼任，但验收类职责要交给未参与执行的人，避免自查自验。矩阵中如实标注兼任情况，并对兼任的验收活动增加一次交叉核对，例如由技术负责人复核项目经理出具的检查结论。角色缺位时提前安排替代，比事后补位更稳妥。
质量责任矩阵和项目计划是什么关系，需要各做一套吗？
两者是同一套安排的不同视角。矩阵回答每项质量活动由谁负责、谁验收、留什么证据；项目计划回答这些活动排在哪个阶段节点、什么时候必须完成。实际操作中可以把矩阵中的活动直接建成计划里的工作项，责任人、验收人和判定时点作为字段填写，避免两套记录对不上。ONES 的项目计划支持按交付物或项目阶段分解工作并设置里程碑，可作为承载质量活动与判定时点的载体。
评审意见迟迟不关闭，责任应该算谁的？
算活动责任人的。矩阵中每项活动只有一个责任人，评审意见的关闭状态属于该活动的完成标志，责任人负责推动到全部关闭。执行人负责按意见修改，验收人负责判定修改是否到位，但整体进度由责任人一人对项目负责。如果意见涉及跨团队协作，责任人应在问题清单中写明关闭责任人和时限，并在阶段检查时核对。
项目中途发生需求变更，质量责任矩阵要重新做吗？
不需要整体重做，按变更影响局部调整即可。变更影响到哪些质量活动，就更新对应行的责任人、验收人或判定时点，并记录变更原因和确认人，保持矩阵与项目基线一致。如果变更引入了新的可交付物，先补充对应的质量目标和验收口径，再新增活动行。调整后的版本重新发布，避免成员按旧版本执行。
质量活动的证据留存到什么程度算够？
标准是活动完成后能随时调取，且能支撑验收人的判定。评审类活动留存评审记录和意见关闭情况，检查类活动留存检查单和结论，问题类活动留存问题单及关闭依据。证据与活动同步产生，事后补写会削弱可信度。测试相关的准入结论和缺陷记录可在测试管理中形成，作为矩阵中相应活动的证据来源；ONES 测试管理支持未通过用例快速创建缺陷任务并在测试与研发团队间流转。
