质量活动安排与责任分工是项目质量计划模板中最容易写空的两张表：活动写成“加强评审”，分工写成“由相关人员负责”，执行时便无法判断谁在什么时点做什么、做到什么程度算完成。本文按“活动—对象—时点—方法—输出—完成标志”和“角色—职责—权限—交接对象”两组字段给出可直接套用的表结构、逐字段填写标准与一条完整示例，适用于单项目质量计划的编制与发布前核对。
要点总览（TL;DR）
- 质量活动安排表按“活动编号—活动名称—适用对象—触发时点—执行方法—输出物—完成标志—前置依赖”八列设计，活动名称用动宾结构指向具体工作产品，触发时点写事件或阶段节点。
- 责任分工矩阵按“角色—对应活动编号—职责描述—权限边界—交接对象—替补角色”六列设计，按角色而非人名填写，一项活动只设一个主责角色。
- 两张表通过活动编号关联：活动表回答做什么、何时做、做到什么程度，责任矩阵回答谁来做、能决定什么、交给谁。
- 输出物与完成标志要分开填写，输出物是可归档的记录，完成标志是可判定的通过条件，例如评审意见全部关闭并签署结论。
- 发布前按核对清单检查活动完整性、时点可判定、责任覆盖、交接与替补、变更与记录，任一项不通过即阻断发布。
模板整体结构与字段清单
项目质量计划模板建议按五部分组织：质量目标与范围、质量活动安排表、责任分工矩阵、评审与验收节点、变更与记录。前两部分说明项目要达成什么质量目标、覆盖哪些工作产品；中间两张表是模板的主体，分别回答“做什么、何时做、做到什么程度”和“谁来做、能决定什么、交给谁”；后两部分固定评审验收的关口位置，以及计划变更时如何留痕。
两张核心表的字段清单如下，可直接照此建表。
| 表 | 字段 | 填写内容 |
|---|---|---|
| 质量活动安排表 | 活动编号 | 唯一标识，如 QA-01、QA-02 |
| 活动名称 | 动宾结构，指向具体工作产品 | |
| 适用对象 | 被检查、评审或度量的工作产品 | |
| 触发时点 | 事件或阶段节点 | |
| 执行方法 | 评审、检查、走查、度量等具体动作及依据准则 | |
| 输出物 | 可归档的记录或报告 | |
| 完成标志 | 可判定的通过条件 | |
| 前置依赖 | 本活动开始前必须完成的活动编号或输入 | |
| 责任分工矩阵 | 角色 | 岗位角色名称，非人名 |
| 对应活动编号 | 引用活动表中的编号 | |
| 职责描述 | 该角色在活动中的具体动作 | |
| 权限边界 | 可否批准、豁免、关闭问题 | |
| 交接对象 | 活动完成后记录与结论交给谁 | |
| 替补角色 | 主责角色缺位时的承接角色 |
字段命名与编号规则要统一：活动编号采用“QA-两位序号”格式，责任矩阵中的“对应活动编号”必须与活动表完全一致，不另起编号体系。这样两张表可以通过编号做交叉核对，任何一项活动都能在责任矩阵中找到对应行，任何一行责任记录也能回溯到具体活动。角色对应人员另附一张简表，写明角色名称、当前承担人和替补人，人员变动时只改这张表，不动主表。
质量活动安排字段怎么填：从输入到完成标志
活动安排表的价值在于让执行者不依赖口头交代就能判断该做什么。填写时逐字段对照以下标准。
活动名称用动宾结构，宾语必须是具体工作产品。合格写法如“评审需求文档”“检查接口设计说明”“走查核心模块代码提交”“核对测试报告覆盖率”。不合格写法如“加强质量控制”“做好评审工作”，这类表述无法确定对象，也无法安排时点。
触发时点写事件或阶段节点，例如“需求文档提交评审申请后2个工作日内”“设计说明完成内部自检后”“代码合入主干前”。避免写“及时”“定期”“根据需要”，这些词在计划中不可判定，执行时也无法追责。若活动按周期开展，应写明周期起点和频率，如“每个迭代第一周周三”。
执行方法写具体动作和依据准则。例如“按《需求评审检查单》逐条核对完整性、一致性与可测试性，采用会议评审方式，参与角色不少于产品、开发、测试三方”。方法要能回答“怎么做”和“按什么标准做”，准则可以是检查单、编码规范、模板或历史缺陷清单。
输出物与完成标志要分开。输出物是活动产生的记录，如评审记录、检查单、问题清单、度量报告；完成标志是可判定的通过条件，如“评审意见全部关闭并签署评审结论”“检查单无未关闭的高优先级问题”。只写输出物不写完成标志，活动容易停留在“开过会、填过表”的状态。
前置依赖与异常处理同样要落到字段里。前置依赖写清本活动开始前必须完成的活动编号或输入物，例如“QA-01 需求评审通过后方可启动 QA-02 设计检查”。活动未按时执行时，在活动表中记录实际状态与偏差原因，由主责角色在例会上说明，超过约定时限未关闭的升级至项目负责人。异常处理规则写在模板的变更与记录部分，不散落在各活动行内。
责任分工字段怎么设计：角色、职责与权限
责任分工矩阵按角色填写，不直接写人名。角色是稳定的组织单元，人员会调整，角色职责不应随人员变动重写。模板后附角色对应人员表，列出每个角色的当前承担人与替补人，人员变化只更新这张附表。
职责描述写该角色在活动中的具体动作，例如“组织评审会议、汇总评审意见、跟踪意见关闭”“签署评审结论”“将评审记录归档至项目文档库”。避免“负责相关工作”“配合完成”这类无法核对的表述。
权限边界回答三个问题：该角色能否批准活动通过，能否对特定问题做豁免，能否关闭问题项。例如“测试负责人有权关闭一般缺陷，高优先级缺陷需项目经理批准后关闭”。权限写清楚，评审结论才有约束力。
交接对象与替补角色用于消除单点依赖。交接对象写明活动完成后记录和结论交给谁，例如“评审记录交配置管理员归档，问题清单交开发负责人跟踪”。替补角色写明主责缺位时由谁承接，替补角色应具备相同权限或明确代理范围。
负责人唯一性原则是这张表的核心约束：一项活动只设一个主责角色，协作角色另列一行并标注“协作”。主责角色对活动的启动、结论和记录负责，协作角色只对分工范围内的动作负责。若一项活动出现两个主责，说明活动本身需要拆分，或职责边界尚未划清。
填写示例：一个需求评审活动的完整记录
以下示例为演示情景，展示两张表如何通过活动编号关联填写。
活动安排表记录：活动编号 QA-01；活动名称“评审需求文档”；适用对象为需求规格说明书 V1.0；触发时点为“需求文档提交评审申请后2个工作日内”；执行方法为“按需求评审检查单逐条核对完整性、一致性与可测试性，会议评审，产品、开发、测试三方参与”；输出物为“需求评审记录、问题清单”；完成标志为“评审意见全部关闭并签署评审结论”；前置依赖为“需求文档完成内部自检”。
责任分工矩阵对应记录：
| 角色 | 对应活动编号 | 职责描述 | 权限边界 | 交接对象 | 替补角色 |
|---|---|---|---|---|---|
| 产品负责人（主责） | QA-01 | 发起评审、组织会议、汇总意见、跟踪关闭 | 可批准评审通过；需求范围变更需项目经理确认 | 评审记录交配置管理员归档，问题清单交开发负责人 | 产品经理 |
| 测试负责人（协作） | QA-01 | 核对需求可测试性，提出验收标准缺失项 | 可提出阻断意见，无权单方关闭问题 | 意见提交产品负责人汇总 | 测试工程师 |
| 项目经理（批准） | QA-01 | 确认评审结论，裁决范围争议 | 可批准结论、可豁免非关键问题 | 结论同步至项目例会纪要 | 项目副经理 |
| 配置管理员（记录归档） | QA-01 | 接收评审记录并归档至项目文档库 | 无审批权，负责版本与归档完整性 | 归档完成后通知产品负责人 | 项目助理 |
示例中的异常处理：若评审申请提交后2个工作日内未组织评审，产品负责人在周例会上说明原因并给出新的评审日期；超过5个工作日仍未评审，由项目经理升级处理并在活动表中记录偏差。从这条示例可以归纳出可迁移的规律：活动表定义可判定的完成条件，责任矩阵为每个条件指定唯一主责角色和明确的交接路径，两张表靠编号对齐，异常规则集中写在模板的变更与记录部分。
在项目管理工具中落地这套模板时，可以把每项质量活动建成工作项，用负责人字段对应主责角色，用前后置依赖表达活动顺序，用里程碑标记评审与验收节点。ONES 的项目计划支持按交付物或项目阶段分解工作、为任务设置前后置依赖并用里程碑标记重要决策点，也支持设置计划基线对比执行偏差；质量计划文档可放在 ONES Wiki 中，通过模板库创建、按角色配置读写权限，并与项目任务关联。这样活动表与责任矩阵在文档中定义，执行状态在工作项中更新，评审记录归档后可回溯。具体配置以实际版本能力为准。
完成检查：模板可用性的核对项
模板发布前逐项核对以下清单，任一项不通过即视为阻断项，需修改后再发布。
| 核对项 | 通过标准 | 不通过的处理 |
|---|---|---|
| 活动完整性 | 每项活动都有编号、名称、适用对象、触发时点、执行方法、输出物、完成标志 | 阻断：补齐缺失字段 |
| 时点可判定 | 触发时点均为事件或阶段节点，无“及时”“定期”类表述 | 阻断：改写为可判定节点 |
| 方法有依据 | 每项活动写明具体动作和依据的准则或检查单 | 阻断：补充准则来源 |
| 责任覆盖 | 责任矩阵覆盖全部活动编号，无孤儿活动；每项活动仅一个主责角色 | 阻断：补行或拆分活动 |
| 交接与替补 | 每项活动填写交接对象，主责角色有替补 | 阻断：补齐交接与替补 |
| 变更与记录 | 模板明确计划变更的发起、审批与记录方式，异常升级规则已写入 | 阻断：补充规则条款 |
核对时建议由质量负责人和项目经理各走一遍：质量负责人检查活动与准则是否覆盖项目关键工作产品，项目经理检查角色权限是否与实际授权一致。两项检查都通过后，模板方可作为本项目质量计划的正式版本发布，后续变更按模板中的变更规则留痕。
常见问题
质量活动安排表里“触发时点”写“每两周一次”可以吗？
可以，但需要补全周期起点和判定口径。按周期开展的活动，应写明周期起点与频率，例如“每个迭代第一周周三”或“每月第一个工作日的质量例会”，让执行者能直接算出下一次执行日期。若活动实际由事件驱动，例如需求文档提交评审申请后启动，则优先写事件节点。两种写法都要求时点可判定，避免只写“定期”“及时”这类无法追责的表述。
一项质量活动涉及多个部门时，责任分工怎么填才能避免推诿？
把活动拆到可归属的粒度，再为每项活动指定唯一主责角色。跨部门协作的活动，主责角色对启动、结论和记录负责，其他部门作为协作角色另列一行，写清各自在活动中的具体动作和权限边界。若一项活动确实需要两个角色共同决策，说明活动本身应拆成“评审”和“批准”两项，分别设主责，再用前置依赖关联。这样每项活动只有一个负责人，协作关系也留有记录。
模板中的角色对应人员表需要多久更新一次？
没有统一周期，按人员变动触发更新即可。角色对应人员表的作用是让主表保持稳定：角色职责写在责任矩阵中，具体承担人和替补人写在附表里。人员入职、转岗或离岗时更新附表，主表不动。建议在项目启动、阶段评审和人员变动后各核对一次，确认每个角色都有当前承担人和替补人，避免主责角色缺位时活动无人承接。
质量活动没有按时执行，模板里应该记录在哪里？
在活动安排表中记录实际状态与偏差原因，由主责角色在例会上说明。异常升级规则集中写在模板的“变更与记录”部分，例如超过约定时限未关闭的活动升级至项目负责人处理，不把规则散落在各活动行内。这样活动表保持字段整洁，异常处理有统一依据，后续复盘时也能按活动编号追溯偏差记录。
用项目管理工具落地这套模板时，活动表和责任矩阵还需要保留文档版本吗？
建议保留。工具中的工作项承载执行状态，文档承载计划定义与评审记录，两者通过活动编号对应。ONES 的项目计划支持按交付物或项目阶段分解工作、为任务设置前后置依赖并用里程碑标记重要决策点，也支持设置计划基线对比执行偏差；质量计划文档可放在 ONES Wiki 中，通过模板库创建、按角色配置读写权限，并与项目任务关联。文档版本用于回溯计划变更，工作项状态用于日常跟踪，具体配置以实际版本能力为准。
