研发质量保证（QA）角色与项目经理、开发、测试的分工，核心在于把“定规则、执行、检查、改进”四类质量动作分别落到具体角色上。QA负责组织级质量体系建设、过程定义与审计、质量度量与改进推动；项目经理对项目目标与交付结果负责；开发对设计与实现质量负责；测试对验证与缺陷发现负责。分工要真正生效，需要写入工作项、评审节点和质量门禁，并留下可查的记录。下文给出角色设置方式、分工对照表、落地步骤与检查清单，并以ONES作为分工落地的流程与数据承载方向之一。
要点总览（TL;DR）
- 研发质量保证（QA）角色主责“定规则”和“检查过程遵循度”，并推动改进；项目交付结果由项目经理承担，实现质量归开发，验证质量归测试。
- QA角色可按独立专职、兼职、虚拟团队三种形式设置，选择取决于项目数量、团队规模与合规要求，可组合使用。
- 分工落地要经过四步：梳理质量活动清单、分配RACI、嵌入评审与质量门禁、建立度量与审计记录，每步都有明确产物和完成标志。
- 决策权与建议权要事先写清：项目经理对范围、排期、资源与交付放行有决策权，QA对过程合规性有判定与整改建议权，门禁规则中约定QA意见的效力。
- 用职责覆盖、评审记录、数据使用、审计闭环、角色冲突识别、边界遵守六项检查，判断分工是否真正落地。
先定分工原则：四类质量动作归谁
讨论分工前，先把质量工作拆成四类动作，再判断每类动作的主责角色。这样能避免“质量人人有责”变成“质量无人负责”，也能解释为什么QA不应直接背项目交付指标。
| 动作类型 | 要解决的问题 | 主责角色 | 典型产物 |
|---|---|---|---|
| 定规则 | 过程应该怎么做、达到什么标准算合格 | QA | 过程规范、模板、检查单、质量门禁标准 |
| 执行 | 按规则完成设计、开发、测试与项目管理动作 | 项目经理、开发、测试 | 计划、设计文档、代码、测试用例与报告 |
| 检查 | 过程是否被遵循、产物是否满足标准 | QA组织审计与评审，项目经理组织项目内评审，测试执行验证 | 审计记录、评审结论、缺陷记录 |
| 改进 | 把问题和数据转化为过程优化 | QA推动，项目经理与各角色参与 | 改进项、责任人与关闭记录 |
四类动作中，QA的主责集中在“定规则”和“检查过程遵循度”，并推动“改进”。项目交付结果由项目经理承担，开发与测试分别承担实现质量和验证质量。QA可以评价过程是否合规、提出整改要求，项目是否按期交付、缺陷是否修复完成，仍由对应角色决策和负责。
还要区分组织级质量保障与单项目质量控制。组织级质量保障关注跨项目通用的过程定义、审计计划、度量口径和改进机制；单项目质量控制关注本项目内的评审安排、测试策略和缺陷处理。QA在组织级承担主责，在单项目中以顾问和审计身份参与，不替代项目经理做项目内质量决策。
研发质量保证角色的设置方式与职责清单
QA角色的设置形式取决于组织规模、项目数量和合规要求，常见有三种，可以组合使用。
| 设置形式 | 适用条件 | 优势 | 需要注意 |
|---|---|---|---|
| 独立专职QA | 项目数量多、有外部评估或强合规要求 | 立场独立，便于跨项目审计与度量 | 需明确其建议权与否决权的边界 |
| 兼职QA | 团队规模较小、质量活动相对集中 | 成本低，贴近一线 | 兼职人员易被项目任务挤占，需固定投入时间 |
| 虚拟QA团队 | 多团队并行、需要统一过程口径 | 汇聚各领域经验，统一标准 | 需明确召集人、议事规则与输出归属 |
无论采用哪种形式，QA的职责清单应包含以下条目：
- 过程定义：维护研发过程规范、模板与检查单，按组织实际情况裁剪，并说明每项活动的输入、输出与完成标准。
- 过程审计：按计划检查项目是否遵循既定过程，记录不符合项，跟踪整改到关闭。
- 质量度量：定义度量口径，收集评审覆盖率、缺陷密度、缺陷逃逸率、审计不符合项关闭率等数据，形成定期报告。
- 改进推动：把审计发现和度量结果转化为改进项，明确责任人、期限与验证方式。
- 培训与辅导：向项目经理、开发、测试宣贯过程要求，在新项目启动时提供过程裁剪辅导。
同时要写清QA不承担的职责：QA不替代测试执行，不负责编写和执行测试用例；不承担项目交付责任，不替项目经理做排期与资源决策；不直接修改开发代码或设计文档。把这些边界写进职责说明，能减少角色冲突。
与项目经理、开发、测试的分工对照表
下表按关键质量活动列出四个角色的主责（A）、参与（C）与知会（I），并标注交接物与评审节点。实际使用时可按组织流程裁剪，但每项活动应只有一个主责角色。
| 质量活动 | QA | 项目经理 | 开发 | 测试 | 交接物与节点 |
|---|---|---|---|---|---|
| 过程规范与模板制定 | A | C | C | C | 规范发布，项目启动时宣贯 |
| 项目质量目标与计划 | C | A | I | C | 项目计划中的质量目标与评审安排 |
| 需求评审 | C（过程与检查单） | A（组织） | C | C | 评审记录、需求基线 |
| 设计与代码评审 | I（抽查遵循度） | C | A | C | 评审意见与关闭记录 |
| 测试策略与用例评审 | C（检查单） | C | C | A | 测试计划、用例评审记录 |
| 提测与准入检查 | I | A（决策） | C | C（提供准入标准） | 提测单、准入检查结果 |
| 缺陷处理与闭环 | I（趋势观察） | C（协调） | A（修复） | A（验证关闭） | 缺陷记录、修复验证结果 |
| 过程审计 | A | C | I | I | 审计报告、不符合项整改单 |
| 质量度量与报告 | A | C（提供项目数据） | I | C（提供测试数据） | 度量报告、改进项清单 |
| 迭代或阶段复盘 | C（提供质量视角） | A（组织） | C | C | 复盘记录、改进行动项 |
决策权与建议权要分开写。项目经理对项目范围、排期、资源与是否放行交付拥有决策权；QA对过程合规性有判定权和建议整改权，涉及是否通过质量门禁时，应在门禁规则中事先约定QA意见的效力，例如“审计不符合项未关闭则不得进入下一阶段”。开发对技术方案与实现方式有决策权，测试对缺陷严重程度分级有建议权，最终由项目经理或约定的缺陷评审机制裁定争议。
落地步骤：从职责定义到评审节点
分工从文档走到日常，需要四步，每步都应有明确产物和完成标志。
步骤一：梳理质量活动清单
输入是现有研发流程、历史评审记录和缺陷数据。动作是按研发阶段列出全部质量活动，标注每项活动的触发条件、参与角色和产出物。输出是一份质量活动清单。完成标志是清单覆盖需求、设计、开发、测试、发布、复盘各阶段，且每项活动都有唯一编号，便于后续分配责任。
步骤二：分配角色与RACI
输入是质量活动清单和现有岗位设置。动作是对每项活动指定主责、参与和知会角色，检查是否存在一项活动多个主责或无人主责。输出是RACI矩阵。完成标志是矩阵中每行恰有一个A，且QA、项目经理、开发、测试四个角色均有明确条目，没有空白格。
步骤三：嵌入评审与质量门禁
输入是RACI矩阵和项目阶段划分。动作是在关键节点设置评审与门禁，例如需求基线前完成需求评审、提测前完成准入检查、发布前完成审计不符合项关闭检查，并写明门禁的通过条件、检查人和记录方式。输出是评审节点清单与门禁规则。完成标志是每个门禁都有检查项、责任人和记录位置，且规则已向项目组宣贯。
步骤四：建立度量与审计记录
输入是门禁规则和历史项目数据。动作是确定度量指标与统计口径，安排审计频次，规定审计记录与整改跟踪的存放方式。输出是度量指标表、审计计划与记录模板。完成标志是首轮审计完成并形成报告，度量数据能按项目和时间段查询，改进项有责任人和关闭状态。
分工落地需要工作项、评审记录和质量数据的统一承载。ONES 研发项目管理平台可围绕项目计划、阶段推进、任务协同和研发过程管理支持团队建立更清晰的项目管理方式；在汽车软件研发等场景中，ONES 研发管理 + ASPICE 解决方案的第一阶段线上化建设支持研发全生命周期流程活动与跨域协作全过程的可追溯性，第三阶段则涉及基于不同视角的研发数据度量体系建设。这些能力可作为把评审节点、审计记录和度量数据放进同一套工作项体系的参考方向，具体配置需结合组织流程设计。
示例：一个迭代中的分工协作
以下为一个两周迭代的示例情景，用于说明四类角色在各环节的动作与交接，不代表统一流程要求。
需求评审阶段
项目经理组织需求评审，提前发出评审材料并设定评审检查单；QA提供需求评审检查单，检查需求是否具备可验证的验收标准，并记录评审过程是否符合规范；开发从实现可行性角度提出意见；测试从可测试性角度提出验收标准补充。交接物是评审记录与需求基线，完成标志是评审意见全部关闭或明确遗留处理方式。
开发与提测阶段
开发按设计规范完成编码与自测，提交代码评审并关闭评审意见；项目经理跟踪提测准入条件，包括自测记录、代码评审结论和构建结果；测试提前准备测试用例并完成用例评审；QA抽查代码评审记录是否完整、提测单是否附有准入检查结果。交接物是提测单与准入检查记录，完成标志是项目经理确认准入通过，测试开始执行。
测试与缺陷处理阶段
测试执行用例、提交缺陷并验证修复；开发修复缺陷并说明根因；项目经理协调缺陷优先级争议和修复排期；QA观察缺陷趋势，识别是否存在同类问题反复出现，并在必要时发起过程改进建议。交接物是缺陷记录与验证结果，完成标志是遗留缺陷已评估并记录处理决定。
迭代复盘中的质量改进闭环
项目经理组织复盘，测试提供缺陷分布与逃逸情况，开发说明主要技术问题，QA提供过程审计发现和度量数据，共同确定改进项。每个改进项应写明责任人、完成时间和验证方式，由QA跟踪关闭。完成标志是改进项进入下一迭代的工作项，并在约定时间验证效果。
完成检查：分工是否真正落地
分工机制是否有效，可以用以下清单逐项核对。每项都应能拿出记录或数据，而不是仅凭口头确认。
- 职责覆盖：质量活动清单中的每项活动都在RACI矩阵中有唯一主责角色，没有职责空白或多人争抢同一决策。
- 评审与门禁有记录：关键评审节点均有评审记录、参与人和结论；质量门禁的检查结果可查询，未通过时有明确的处理记录。
- 质量数据被使用：度量指标有固定口径和统计周期，复盘或管理例会上引用这些数据，并据此产生改进项。
- 审计形成闭环：审计发现的不符合项有责任人、整改期限和关闭验证记录，重复出现的问题有升级处理机制。
- 角色冲突可识别：当QA的合规判断与项目交付进度冲突时，有事先约定的升级路径和裁定角色；兼职QA有固定的质量工作时间，未被项目任务完全挤占。
- 边界被遵守：QA未直接承担测试执行或项目交付指标；项目经理未替代QA判定过程合规性；开发与测试的评审意见有明确关闭状态。
检查中发现职责空白或角色冲突时，回到RACI矩阵调整主责与交接物，并同步更新评审节点和门禁规则。分工机制应随项目类型和组织变化定期复核，保持与实际的研发流程一致。
常见问题
团队规模较小，是否必须设置专职QA？
不一定。项目数量少、质量活动相对集中时，可以采用兼职QA，由熟悉研发流程的成员在固定时间内承担过程定义与审计工作。关键是给兼职QA留出稳定的质量工作时间，并在职责说明中写明其质量职责与项目任务的优先级处理方式，避免被项目任务完全挤占。当项目数量增加或出现外部评估、强合规要求时，再考虑转为独立专职QA或组建虚拟QA团队。
QA与项目经理在质量问题上意见不一致时，谁来裁定？
建议在分工设计阶段就约定升级路径，而不是等冲突发生再临时决定。常见做法是：项目内的质量决策由项目经理裁定，QA保留意见并记录；涉及组织级过程合规、质量门禁是否放行时，按门禁规则中事先约定的条款执行，例如“审计不符合项未关闭不得进入下一阶段”。若规则本身存在争议，提交给质量负责人或研发管理层裁定，并把裁定结果回写到规则中，作为后续同类问题的处理依据。
QA需要参加每一次需求评审和代码评审吗？
不需要逐场参加。QA在评审中的价值主要是提供检查单、抽查评审过程是否符合规范、确认评审记录完整。需求评审可由项目经理组织，QA提供检查单并抽查记录；代码评审由开发主责，QA按计划抽查评审意见的关闭情况。把QA的参与方式写进RACI矩阵，明确哪些评审必须到场、哪些只需事后检查记录，可以避免QA成为所有评审的瓶颈。
质量度量指标应该由QA单独定义吗？
QA负责定义度量口径和统计周期，但指标选择应与项目经理、开发、测试共同确认，确保数据可采集、口径一致、能对应到具体改进动作。例如缺陷逃逸率需要测试提供缺陷数据、项目经理确认发布范围，评审覆盖率需要各评审组织者提供记录。指标确定后，在复盘或管理例会上引用数据并产生改进项，度量才有实际作用；只统计不使用的指标可以精简。
分工机制建立后，多久复核一次比较合适？
可以在每个季度或每完成若干迭代后复核一次，并在组织调整、研发流程变更、引入新的合规要求时触发临时复核。复核时重点看三件事：质量活动清单是否仍覆盖实际流程、RACI矩阵中是否出现新的职责空白或多人主责、门禁规则是否仍与项目阶段划分匹配。复核结论应更新到RACI矩阵和评审节点清单中，保持分工文档与实际做法一致。
