项目质量责任追踪要解决两个问题：每项质量工作由谁负责，以及责任是否真正落实。做法是先按本项目质量控制范围列出质量活动与交付物，建立“活动—角色—责任类型—交付物—完成标志”的责任矩阵，再把矩阵条目转成带状态、证据和更新时点的记录，在例会与阶段评审中逐项核对，推动问题关闭。本文聚焦单项目内的矩阵建立与状态记录，组织级质量制度和测试执行过程不展开。
要点总览（TL;DR）
- 先按单项目质量控制范围列出质量活动与交付物，标注评审、检查、问题整改、验收等类型，并为每项写出可核验的完成标志。
- 责任矩阵采用“活动编号—活动名称—交付物—主责人—配合角色—验收人—知会对象—完成标志”字段，每项活动只设一个主责人，验收人与主责人按风险分离。
- 把矩阵每行转成一条状态记录，统一使用未开始、进行中、待验收、已完成、已延期五类状态，附证据、计划完成时间和最近更新信息。
- 待验收项由验收人复核，未通过写明原因退回；已延期项在例会上说明并升级，影响里程碑的由项目经理决策，闭环证据与状态记录对应归档。
- 用完成检查清单核对矩阵与状态记录：无空缺行、完成标志可判断、延期有升级记录、关闭有复核结论，并在项目例会上实际过账。
责任矩阵先定哪些质量活动与交付物
建立矩阵的第一步是确定追踪对象。质量责任追踪容易失效，往往是因为一开始就把“质量”当成一个笼统职责分给某个人，而没有落到具体活动上。可追踪的责任必须对应一项可完成、可判断结果的工作，因此需要先从项目已有材料中提取质量活动，再为每项活动写明交付物和完成标志。
提取来源主要有四类：项目计划中的阶段划分与里程碑，质量目标中承诺的指标与要求，评审节点安排，以及当前问题清单中的待整改事项。从这些材料中逐条梳理，形成一份活动清单，避免凭印象补充。
活动类型建议分开标注，因为不同类型的责任人和关闭条件不同：
- 评审类：需求评审、设计评审、阶段评审等，交付物为评审记录与结论，完成标志是评审意见已记录并明确处理方式。
- 检查类：过程检查、交付物检查、配置检查等，交付物为检查结果，完成标志是检查项逐条有结论。
- 问题整改类：针对评审或检查发现的问题，交付物为整改说明，完成标志是整改结果经复核确认。
- 验收类：阶段验收、交付物验收，交付物为验收结论，完成标志是验收人签署意见。
每项活动都要写出完成标志，且标志应能被第三方判断。例如“完成需求评审”不够具体，“评审记录已归档，所有阻断性意见已关闭或有明确处理结论”才具备可核验性。活动清单整理完成后，可用下表作为中间产物，再进入矩阵填写。
| 活动编号 | 活动名称 | 活动类型 | 交付物 | 完成标志 |
|---|---|---|---|---|
| QA-01 | 需求评审 | 评审 | 评审记录 | 阻断性意见全部关闭或有处理结论 |
| QA-02 | 模块交付物检查 | 检查 | 检查结果表 | 检查项逐条有结论 |
| QA-03 | 缺陷整改 | 问题整改 | 整改说明 | 复核人确认整改有效 |
| QA-04 | 阶段验收 | 验收 | 验收结论 | 验收人签署通过意见 |
这份清单是矩阵的输入，范围限定在本项目内。跨项目的质量制度、测试用例执行过程等不在本文追踪范围内，避免矩阵过宽而难以维护。
责任矩阵的字段设计与角色分工
矩阵的作用是把活动清单转成角色承诺。字段设计要保证两件事：每项活动有人真正负责，且责任可以被验收。建议采用以下字段：
| 字段 | 填写要求 |
|---|---|
| 活动编号 | 与活动清单一致，便于交叉引用 |
| 活动名称 | 具体到可执行的动作 |
| 交付物 | 活动产出的记录、结论或文档 |
| 主责人 | 唯一，对活动结果负责 |
| 配合角色 | 提供输入或参与执行的角色，可多个 |
| 验收人 | 判断完成标志是否达成 |
| 知会对象 | 需要了解进展但不必参与执行的角色 |
| 完成标志 | 可核验的完成条件 |
角色分配有三条规则需要明确。第一，每项活动只设一个主责人。主责人可以是岗位也可以是具体人员，但同一活动出现两个主责人时，责任会在交接处落空，状态记录也会出现互相等待的情况。第二，验收人与主责人分离适用于结果需要独立判断的情形，例如整改类活动、验收类活动，以及主责人同时是执行者的检查活动；对于低风险、结果自明的活动，可由主责人自检后由上一级角色抽查，但抽查安排要写入矩阵。第三，角色按项目实际岗位填写，不预设团队规模。小团队中一人可能承担多个角色，此时应在矩阵中注明兼任关系，避免验收环节形同虚设。
填写完成后，建议由项目经理和质量负责人共同过一遍矩阵，重点检查是否存在“主责人空缺”“验收人等于主责人且无替代复核”的行。矩阵确认后即作为本项目质量责任的基准版本，后续调整需记录变更原因。
责任落实状态的记录方式与状态取值
矩阵回答“谁负责什么”，状态记录回答“现在做到哪一步”。两者要建立一一对应关系：矩阵中的每一行，在状态记录中至少有一条对应条目，条目随活动推进更新，而不是另建一套台账。
状态取值建议统一为五类，覆盖从启动到关闭的完整过程：
| 状态 | 含义 | 进入该状态的条件 |
|---|---|---|
| 未开始 | 责任已分配，工作尚未启动 | 矩阵已确认 |
| 进行中 | 主责人已开展活动 | 有实际动作或产出草稿 |
| 待验收 | 主责人认为完成标志已达成 | 交付物已提交 |
| 已完成 | 验收人确认完成标志达成 | 验收结论已记录 |
| 已延期 | 超过计划完成时间仍未完成 | 计划时间已过且状态未到已完成 |
每条记录除状态外，还需包含证据字段和更新信息。证据可以是评审记录、检查结果、整改说明的存放位置或编号，作用是让验收人不必依赖主责人口头说明即可判断。更新时点建议固定在三个场合：周例会前由主责人更新本人负责的条目，阶段评审时整体核对，问题关闭时同步更新关联条目。状态每次变更都要留下变更人、变更时间和变更原因，便于回溯责任落实过程。
状态记录表可采用如下结构：
| 活动编号 | 主责人 | 当前状态 | 证据 | 计划完成时间 | 最近更新人/时间 | 备注 |
|---|---|---|---|---|---|---|
| QA-01 | 需求负责人 | 已完成 | 评审记录 R-012 | 第2周周五 | 质量负责人/第2周周四 | 阻断意见已关闭 |
| QA-03 | 模块开发负责人 | 待验收 | 整改说明 F-007 | 第3周周三 | 模块开发负责人/第3周周二 | 等待复核 |
状态记录的价值在于可核对。若某条记录长期停留在“进行中”且无证据更新，本身就是需要关注的信号，应在例会上要求主责人说明。
从责任记录到问题闭环的推进机制
状态记录只有进入复核和升级流程，才能推动问题真正关闭。推进机制围绕两个触发点设计：状态为待验收，以及状态为已延期。
待验收状态的推进动作是复核。验收人应在约定时限内查看证据并给出结论：确认达成的转为已完成；未达成的退回进行中，并写明未通过的具体原因。复核结论要记录在状态条目中，不能只在口头沟通。对于问题整改类责任，关闭条件应更严格：整改说明需经复核人确认问题已消除或风险已受控，必要时补充验证记录，复核人不能是整改执行人本人。
已延期状态的推进动作是升级。延期发生后，主责人需在例会上说明原因和新的完成时间；若延期影响阶段里程碑或验收节点，应升级至项目经理协调资源或调整计划。升级路径建议写清楚：一般延期由质量负责人在例会上跟踪，影响交付节点的延期由项目经理决策，涉及范围变更的提交变更评审。升级记录与状态条目关联，作为后续复盘依据。
质量例会的过账方式可以直接使用状态清单：按活动编号逐项核对当前状态、证据是否齐全、待验收项是否已复核、延期项是否有处理结论。会议产出是状态更新和待办分配，而不是重新讨论责任归属。闭环证据按项目归档要求存放，与状态记录中的证据字段保持一致，保留期限遵循项目文档管理约定。
在工具承载上，ONES 的项目计划支持按交付物或项目阶段分解工作，并为任务设置依赖和里程碑，可把矩阵中的质量活动对应为计划中的工作项；团队可持续查看任务状态、阶段进展和待处理问题，用于例会上按状态清单过账。设置计划和里程碑基线后，还能对比计划与执行的偏差，帮助识别延期项。若需要把责任落实数据汇总观察，ONES 效能管理可基于系统内流转的数据形成分析指标。具体字段配置和状态取值需结合团队实际在系统中确认。
示例：一个迭代内的责任矩阵与状态记录
以下为演示情景，用于说明填写方式，不代表真实项目数据。某项目在一个迭代内设置四项质量活动，矩阵填写如下：
| 活动编号 | 活动名称 | 交付物 | 主责人 | 配合角色 | 验收人 | 完成标志 |
|---|---|---|---|---|---|---|
| QA-01 | 需求评审 | 评审记录 | 需求负责人 | 开发负责人、测试负责人 | 项目经理 | 阻断性意见全部关闭 |
| QA-02 | 代码检查 | 检查结果表 | 开发负责人 | 模块开发人员 | 技术负责人 | 检查项逐条有结论 |
| QA-03 | 缺陷整改 | 整改说明 | 模块开发负责人 | 测试负责人 | 质量负责人 | 复核确认缺陷已关闭 |
| QA-04 | 阶段验收 | 验收结论 | 项目经理 | 各角色负责人 | 项目发起人 | 验收意见签署通过 |
状态更新过程示例：第2周，QA-01 由进行中转为待验收，主责人提交评审记录，项目经理复核后转为已完成。QA-02 在检查中发现两项问题，状态保持进行中，检查结果表持续补充。QA-03 因缺陷修复依赖外部接口，计划完成时间已过，状态标记为已延期，模块开发负责人在例会上说明原因，项目经理协调接口方并更新完成时间，该延期记录进入升级跟踪。第3周，QA-03 提交整改说明转为待验收，质量负责人复核确认后转为已完成。QA-04 在阶段评审会上依据前三项的状态和证据进行验收，签署结论后转为已完成。
这个示例说明两点：状态记录要跟随实际动作更新，而不是到节点前集中补填；延期项必须留下升级和处理记录，否则闭环无法证明。
完成检查：矩阵与状态记录是否可用
矩阵和状态记录建立后，可用以下清单逐项核对，判断是否达到可用标准：
- 每项纳入范围的质量活动都有唯一主责人和明确的验收人，无空缺行。
- 每项活动都有交付物和可核验的完成标志，完成标志不依赖主观描述。
- 每条责任记录都有当前状态、证据和最近更新信息。
- 状态取值统一，未出现清单之外的自定义状态造成口径混乱。
- 待验收项均有复核结论，退回项写明了未通过原因。
- 延期项有升级记录，包括原因、处理决定和新的完成时间。
- 已完成项有验收人确认，问题整改类有复核结论。
- 矩阵与状态记录在项目例会上被实际使用，会议记录能对应到具体活动编号。
- 闭环证据按约定位置归档，与状态记录中的证据字段一致。
核对中发现的问题应当场转为待办并指定责任人，检查本身也作为一次责任落实的记录。矩阵和状态记录保持同步更新，项目结束时即可作为质量责任追踪的完整依据。
常见问题
小团队里一人兼任主责人和验收人，责任矩阵怎么处理才不流于形式？
小团队角色重叠是常见情况，处理方式是在矩阵中如实注明兼任关系，并为验收环节补一个独立判断动作。可选的安排包括：由上一级角色抽查并记录抽查结论，或在阶段评审会上由其他角色交叉复核。关键是验收结论要有记录，不能由主责人口头确认完成。若某项活动风险较低、结果自明，主责人自检后由项目经理定期抽查也可接受，但抽查频次和记录位置要写入矩阵，避免验收环节被省略。
质量活动进行到一半，项目范围或计划调整了，责任矩阵和状态记录要怎么同步？
矩阵确认后作为基准版本，调整时保留变更记录。范围或计划变化时，先判断受影响的活动：新增活动补入矩阵并指定主责人和验收人；取消的活动在状态记录中标注取消原因和决定人，不直接删除条目；完成标志或计划时间变化的，更新矩阵并注明变更原因。状态记录中受影响的条目同步更新计划完成时间和备注，已产生的证据保留在原位置。这样项目结束时能看出责任范围如何演变，复盘时也有依据。
状态记录长期停留在“进行中”，例会过账时应该怎么处理？
长期停留在“进行中”且证据没有更新，说明责任落实可能遇到阻碍，例会应要求主责人说明具体情况：是工作未启动、遇到外部依赖，还是完成标志本身定得不清楚。根据说明分别处理：未启动的确认新的启动时间；外部依赖导致的评估是否升级；完成标志模糊的回到矩阵修订标志。说明和处理结论记入状态条目的备注，下次例会继续核对。若同一活动连续多个周期无进展，应升级至项目经理协调，而不是继续在例会上重复询问。
问题整改类责任的关闭条件比其他活动更严格，具体要留下哪些记录？
问题整改类活动建议至少留下三类记录：整改说明，写清问题原因、采取的措施和影响范围；复核结论，由非整改执行人的复核人确认问题已消除或风险已受控；必要的验证记录，例如复测结果或检查结果。三项记录与状态条目中的证据字段对应，状态从待验收转为已完成时同步填写复核人和复核时间。若整改涉及范围或计划变更，还需关联变更评审记录。关闭条件写清楚，后续复盘时才能判断整改是否真正有效。
用工具承载责任矩阵和状态记录时，需要重点确认哪些配置能力？
选型或配置时重点确认四件事：工作项能否按活动类型区分并设置负责人字段；状态取值能否覆盖待验收、已延期等过程状态，且状态变更留有记录；评审记录、检查结果等证据能否关联到具体工作项；能否按项目或阶段汇总查看状态分布，供例会过账使用。ONES 的项目计划支持按交付物或项目阶段分解工作，并为任务设置依赖和里程碑，团队可持续查看任务状态、阶段进展和待处理问题；设置计划和里程碑基线后可对比计划与执行的偏差。具体字段配置和状态取值需结合团队实际在系统中确认。
