5.2 质量保证活动与评审

5.2 质量保证活动与评审

属性目标定了，本节讲拦截图：质量保证的各类活动里，评审是性价比最高的一道闸。本节先分清 QA 与 QC 这对常被混用的称呼，再把正式评审的流程、角色、数据一笔一笔拆开——你会看到为什么同样的缺陷，在纸面上抓出来比在线上抓出来便宜一个数量级。

安检的三道闸：QA、QC 与测试

三个称呼各管一段，混用会直接导致职责错位：

• 质量保证（QA）：面向过程——查开发活动有没有按规程走，产物是审计结论与流程修订。安检员不负责开车，负责确认发车流程合规；
• 质量控制（QC）：面向产品——对工件做检查与测试，判定它达不达标，产物是测试报告与放行建议；
• 测试：QC 的执行手段之一，在运行中找缺陷，是第 3.4 节的主场。

QA 与 QC 的分界用一个问题就能试出来："这个缺陷谁负责修？"——QC 找到缺陷、记录缺陷，修复责任在作者；QA 发现的是"流程没拦住这类缺陷"，责任在流程改进。一个团队若让 QA 既审流程又背缺陷修复的锅，两件事都会做砸。

评审：最便宜的缺陷捕手

评审是一组人按规程逐项检查工件的集体活动，强度从轻到重大致分三档：

正式审查之所以贵得有理，靠的是三个纪律：会前准备——每人事先独立审完并提交发现，不带准备到会等于没审；角色分工——主持人控场不参加技术争论，宣读人逐段推进，记录员只记发现不做评判，作者只答问不辩护；数据跟踪——发现的每条缺陷分级记录，返工后复核关闭。

评审省钱这件事可以算账。用行业反复观察到的数量级做个对比演算：

[演算] 一处需求缺陷的两条捕获路径成本对比

缺陷：满减与折扣的叠加顺序在需求里没写清。

路径一：需求评审阶段发现
  评审会中花 10 分钟澄清，改文档半行
  成本 ≈ 0.3 人时，零波及

路径二：上线后被客服发现
  定位：跨计费、对账、客服三个模块排查 ≈ 6 人时
  修复与回归 ≈ 8 人时
  已生成的错误账单冲正与客诉处理 ≈ 20 人时
  信任损失：仓库主管从此手工复核每张账单
  成本 ≈ 34 人时 起步，且没有封顶线

两条路径相差约一百倍。
评审的本质是把缺陷拦截在"改动最便宜"的工件上。
​

一百倍不是夸张的艺术——是"改半行文档"与"改三个模块加安抚用户"的真实差距。评审被管理者嫌弃的唯一理由是它花钱在前面、省钱在后面看不见，这恰好是第 4 章度量要解决的可见性问题。

过程审计：查流程不查人

QA 的另一半职责是过程审计：定期对照规程抽查——需求变更是否都走了闸口、走查记录是否真实存在、发布检查单是否逐项执行。审计的产出不是处分名单，而是"规程哪里形同虚设"的证据链。云梯的一次季度审计发现了两件事：变更台账里有三条没附影响评估（补评估，并追查为什么闸口被绕过）；两个团队的走查记录是发布前一晚补写的（走查纪律重申，评审数据纳入团队仪表盘）。

⚠️ 审计一旦滑向"抓人"就永久失效——被审计的团队会开始精心补材料，而不是按规程干活。审计的正确姿势是盯系统不盯个体：某类违规反复出现，改的多半是规程本身（它可能麻烦到了没人愿意遵守的程度）。

让评审有活性的三个诀窍

• 控制规模：一次审查的工件量以两小时内能过完为限，需求文档按章节分场，代码按几百行一批；
• 喂检查单：把历史缺陷模式做成检查项，新人也能查出老师傅靠经验才看出的毛病——第 4 章缺陷模式榜在这里直接变现；
• 公布捕获数据：各评审会的缺陷发现密度公开对比，不是排名批斗，而是让"走过场的评审"自己现形——连续三场零发现的评审会，主持人该自查了。

评审的效率账：发现密度与准备时长

评审投入怎么定规模？两个指标帮着算账。一是发现密度——每审查一小时提出的有效发现条数，健康的评审应稳定在每小时两到四条有效发现；连续低于一条，要么工件质量已经很好（可降低评审强度），要么评审流于形式（查准备是否充分）。二是准备产出比——云梯统计发现，会前一小时的独立准备平均贡献六成以上的发现，会上现场灵光只占四成；这组数字成为硬规定的依据：未提交书面准备的与会者，意见不计入评审记录——不是惩罚，是把有限会议时间留给有准备的观点。两项数据按季度回看，评审强度随工件质量动态调节，安检与产能就不必你死我活。

审计节奏：季度深度加日常抽查

过程审计的频率设计也讲究投入产出。云梯采用"季度深度审计加日常抽查"的双层节奏：季度审计全流程走一遍（变更闸口、走查记录、发布检查单、缺陷闭环），产出改进项进复盘跟踪；日常抽查则每月随机抽两三件工件核对记录真实性——十分钟的抽查，威慑价值远大于其成本。记录造假的被发现概率不需要高，"随时可能被抽查"这件事本身就让补材料无利可图。审计结论的处理沿用第 4.4 节复盘的规矩：改进项落到规章修订，两周内核验。

两个高频疑问

问：人手不够，评审能不能砍？ 能砍强度，别砍高危工件的评审。优先级排序是：需求基线与接口契约的评审雷打不动（它们决定下游所有工作），核心算法与安全相关代码次之，外围界面与文案可以走轻量走查甚至自查清单。砍错地方——比如砍掉接口评审省下两小时——下游会在集成与联调时加倍还回来。

问：评审总变成技术权威的一言堂怎么办？ 结构化的角色分工就是解药：宣读人逐段推进，每个人的发现按轮次陈述，主持人保证每位与会者至少发言一次；权威的观点同样以"发现"的形式进记录，与新人意见同权重表决分级。一言堂的评审会把发现密度骤降——数据不会撒谎，把发现密度按人公开，气场平衡往往自愈。

本节要点回顾

• QA 面向过程，QC 面向产品，测试是 QC 的执行手段；三者职责错位则双输。
• 评审分走查、技术评审、正式审查三档，越正式越贵，也越能拦高危缺陷。
• 正式审查的三纪律：会前独立准备、角色分工控场、缺陷分级跟踪。
• 同一缺陷在评审阶段与线上阶段的捕获成本相差约百倍，评审是把拦截点前移。
• 过程审计盯系统不盯个体；评审活性靠规模控制、检查单投喂、数据公开。

拦截数据攒下来了，下一节把它们变成仪表——度量怎么算、过程怎么升级。