3. 质量体系工程的组织与角色

质量体系工程能否落地，最终取决于“谁对什么结果负责、谁在什么节点参与、谁有权做最终判断”。如果组织角色模糊，常见后果是：质量委员会只在出事后开会，质量保证（QA）被当成文档警察，测试工程被压缩为“上线前点一遍”，过程改进（EPG）沦为写模板，DevOps 只负责流水线可用性。要避免这些错位，需要先把角色职责与协作模式定义清楚，再按企业规模裁剪组织架构，并用 RACI 矩阵把关键活动的责任关系固化下来。

一、五类核心角色的职责边界

质量委员会（Quality Council）是质量体系的治理层，不是执行层。它通常由研发负责人、质量负责人、产品负责人、运维负责人和业务代表组成，职责包括：批准质量战略与年度质量目标、裁决跨部门质量争议、审批重大质量风险豁免、评审质量度量趋势并决定资源投入。质量委员会不直接审批每个版本的发布，而是定义“什么情况下必须升级到委员会”。例如可规定：当线上严重故障（P0/P1）月度累计超过 2 次，或核心链路可用性低于 99.9% 时，由质量委员会介入复盘并调整目标。

质量保证（QA）关注“过程是否被正确执行、体系是否有效”。QA 的典型产出是过程审计报告、质量计划、体系文件维护、不符合项跟踪。QA 不替代测试执行，也不对单个缺陷负责，而对“过程偏差是否被识别和关闭”负责。例如 QA 在迭代审计中发现 3 个需求未做验收标准评审，应开出不符合项并跟踪到关闭，而不是自己去补测试。

测试工程（Test Engineering）关注“产品是否满足质量要求”。职责包括测试策略与测试设计、自动化测试框架建设、测试环境与数据管理、缺陷分析与质量门禁执行。测试工程需要与开发共同定义单元测试、接口测试、端到端测试的分层比例。一个可参考的分层目标是：单元测试覆盖核心逻辑，接口测试覆盖主要服务契约，端到端测试只覆盖关键业务链路，避免测试金字塔倒置。

过程改进（EPG）关注“体系如何持续变好”。EPG 负责过程定义、裁剪指南、度量体系设计、改进项试点与推广。EPG 不应独自承担所有改进执行，而是作为方法提供者和推动者。例如 EPG 引入“缺陷根因分析”实践时，应先在 1 个团队试点 2 个迭代，收集缺陷逃逸率变化，再决定是否推广。

DevOps关注“质量如何被快速、稳定地交付”。职责包括 CI/CD 流水线、环境即代码、自动化质量门禁、可观测性与发布回滚。DevOps 把质量活动嵌入流水线：代码提交触发静态扫描与单元测试，合并请求触发接口测试，预发环境触发端到端测试与性能基线检查，生产发布触发灰度与自动回滚。

二、协作模式：从“串行交接”到“质量内建”

五类角色的协作不应是“需求→开发→测试→运维”的串行交接，而应围绕质量门禁形成并行参与。需求阶段，QA 与测试工程共同评审验收标准；开发阶段，DevOps 提供流水线与质量门禁，测试工程提供自动化用例；发布阶段，QA 审计过程合规性，DevOps 执行灰度与回滚；复盘阶段，EPG 提炼改进项，质量委员会决策资源投入。这样，质量活动被内建到交付链路中，而不是在末端集中拦截。

三、按企业规模裁剪组织架构

组织架构没有唯一正确答案，关键是匹配企业规模与交付复杂度。小型企业（研发 20～50 人）通常不设独立 QA 与 EPG，可由质量负责人兼任 QA，测试工程与 DevOps 合并为“质量与效能组”，质量委员会由研发负责人、产品负责人和 1 名业务代表组成，每月开一次质量评审会。中型企业（研发 100～300 人）可设独立 QA 与测试工程，EPG 由各团队骨干兼职，DevOps 独立成平台组，质量委员会按季度评审质量目标。大型企业（研发 500 人以上）可设质量委员会、QA 部、测试工程部、EPG 办公室和 DevOps 平台部，并建立跨部门质量工作组，按产品线或业务域划分质量责任。

裁剪时可用三个判断问题：第一，质量决策是否需要跨部门裁决？若是，必须设质量委员会。第二，过程偏差是否频繁且影响交付？若是，需设独立 QA 或明确 QA 职责。第三，交付频率是否高到人工质量活动成为瓶颈？若是，需强化 DevOps 与测试自动化。三个问题都指向“是”，才需要完整组织；否则应合并角色，避免组织臃肿。

四、RACI 矩阵：把责任关系写清楚

RACI 分别表示负责（Responsible，执行者）、批准（Accountable，最终责任人）、咨询（Consulted，提供意见者）、知会（Informed，需被告知者）。每个关键活动只能有一个 A，R 可以有多个。以下矩阵以中型企业为例，覆盖质量体系工程的关键活动，可直接作为模板裁剪使用。

使用 RACI 矩阵时要注意两点。第一，矩阵必须与真实活动对齐，不能照搬通用模板。例如“灰度发布与回滚决策”的 A 应是 DevOps 负责人，而不是质量委员会，因为回滚是时效性极强的操作决策。第二，矩阵需要定期评审。当组织调整、交付模式变化或质量目标升级时，RACI 应同步更新，否则会出现“矩阵上有人负责、实际无人执行”的脱节。

总结来看，质量组织设计的核心不是“设多少部门”，而是“每个质量结果是否有唯一责任人、每个关键节点是否有明确参与者、每次改进是否有闭环”。质量委员会管方向，QA 管过程，测试工程管验证，EPG 管改进，DevOps 管交付效率与稳定性。五类角色通过质量门禁和 RACI 矩阵形成协作网络，企业再根据自身规模裁剪合并，才能让质量体系真正运转起来。