这是鼎叔的第一百零七篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），https://item.jd.com/14105386.html。

研发度量和 QA

研发的度量，不应该是基于绩效处罚，阻碍创新，而是应该帮助团队自我改进，这需要各个关键角色的自发推动和积极支持。本专辑会先从传统度量的局限性开始剖析，重点阐述如何基于敏捷设计度量指标，让过程改进（质量管理）的工作更加适应敏捷研发，并借助敏捷度量体系高效推动团队的健康运作。

在传统技术行业，质量管理是一个专业的独立角色，它代表管理层，起到了重要的过程量化和纪律督促作用。但是在敏捷研发时代，专职的质量管理人员，经常走到了研发效能的对立面，尽管做得很辛苦，但频频被吐槽，缺乏成就感。

一线质量管理者，在很多公司简称为过程改进工程师（PI）,也有很多公司称之为 PQA（质量保障工程师）。然而还有很多企业把测试工程师也统一称为 QA， 本文内容中 QA 特指不进行测试技术实施的过程改进人员（或质量管理人员）。质量管理工程师和测试技术工程师，本质上都属于质量角色，甚至可能是同一个团队来负责的。

先从 QA 的郁闷说起

在研发规模比较庞大的组织中，专职 QA 通常承担了下列重要工作内容：

向技术高管汇报当期主要质量风险、质量数据趋势、质量改进措施的进展。

针对线上事故组织回溯，落实整改措施。宣导事故定级或纪律审计措施，公布奖惩结果。

年度质量规划，确认质量改进专题和落地到业务的责任人，确认考核指标，组织相应主题培训或部门宣导。

推动质量过程关键指标的量化和定期晾晒，对于告警数据提醒处理。

鼎叔曾经长时间从事过 QA 工作以及 QA 组的组建，也和行业中各知名公司的 QA 有过深入交流。在敏捷转型大潮下，感觉 QA 的职业发展道路是容易迷失的，从业者普遍缺乏价值成就感，想招到一个满意的懂敏捷的 QA 非常困难。

具体表现在以下几个困惑：

1. QA 到底向谁负责？

QA 应该对技术高管负责，还是对一线团队负责？

很多情况下，QA 被高管招聘进来，老板的期望是 QA 能够通过研发效率和质量数据的分析，及时暴露一线团队的风险短板，找到可以立即改进的切入点。同时能够建立上行下效的质量规范，定期自省。

但是，QA 的日常工作模式是和一线成员沟通，甚至深入到团队的关键会议中，分析问题案例并向上汇报。

一线团队出于本能是不希望暴露失误被高管批评的。而 QA 因人力非常有限（因为不承担具体技术实现工作，团队预算通常很少），不能紧跟一线项目，不太可能提前给出具体的预警建议，帮助团队尽早规避风险。与此同时，QA 因为要提取考核数据和保障汇报材料的准确性，还会让一线团队投入一定的人力支持。

时间一长，一线团队对 QA 的负面看法就会愈发明显，他们不能从支持工作中受益，还容易被高管批评（有时甚至是被背锅），因此对 QA 的支持和评价就会逐步走低。

另一个维度，如果 QA 把主要精力投入到团队协同支援上，重视团队感受，那在高管眼里，可能就形成 “质量规划和呈现能力不足”、“不能暴露尖锐问题” 的看法。

2. QA 的成果是促进了敏捷，还是阻碍了敏捷？

QA 各项推动成果最终会固化下来，通过监控指标体系、规范流程梳理、内部审计等方式，所谓 “没有规矩，不能成方圆”。成果越宏大，度量管理成本越高。

团队会因此产生什么变化么？是真正降低了运营风险，还是研发氛围更保守，交付更低速了？

很多时候，员工评价是后者，运营事故还是会不断频发，但是团队为了质量规范达标，投入了相当多的 “额外精力”。

以我经历的一个敏捷项目转型为例，某研发团队自发启动敏捷变革（包含专业的 DevOps 平台建设），高管提出 QA 能加入协助，于是 QA 组就主导输出了一系列的效能度量标准要求（非常庞大的指标体系，超过 50 项度量要求），强力推动该研发团队去落实。这本身就违反了敏捷原则，敏捷转型应该是团队自组织的，内驱改进现有问题，让交付更顺畅，让自己更爽，而不是为了向高管汇报庞杂的标准化成果。这种规则强加式的安排，很容易引发研发团队的反感，最终影响转型目标的达成。

3. QA 的工作，是否可以由自动化平台替代？

强调技术驱动的团队，希望所有的过程质量和可预警的风险，都能够通过工具平台自动化的呈现和推动，这样效率确实是很高的。但是 QA 在策划和汇报的质量体系各个要素，不一定都能自动化的获取，原因是有些要素需要主观综合判断，而有些要素需要人工录入元数据，为了达成向上汇报的要求，研发需要投入相当的人员精力，以满足质量分析的 “准确”。

在这个越来越强调自动化质量治理的时代，QA 人员对自身职业发展也产生了担忧。研发人员自主完善质量监控自动化，显然是更高效的，不需要咨询所谓 “质量督导” 角色，除非，QA 人员有非常深厚的软件工程量化能力。

4. QA 为啥经常成为流程中尴尬的二传手角色？

团队很容易默认 QA 是规范流程的协调制定者和守护者，所以一旦引入了新的流程环节，就习惯把 QA 纳入流程把关环节。QA 莫名其妙成为了流程中的审批者，却起不了特别价值。

实际上，QA 人数通常非常少，不可能深入到每个项目的研发测试过程中，不具备对具体需求的质量风险判断力。强行放入一个把关角色反而会成为流程的瓶颈，导致拖沓。

优秀 QA 应该能制定出能够充分防范风险，同时让成本尽量低（简洁）的共识流程，同时自己要能脱离其中，参与到下一类急需改进的任务。

所以，鼎叔认为优秀的 QA 应该成长为一个专家教练角色，而非流程角色。TA 应该敏锐识别可改进的地方，借助数据分析和大家的反馈，明确能够马上改进的 TOP N 措施，一旦措施落实（形成团队习惯）后，QA 应该抽身而退，瞄准下一个目标。

团队为什么讨厌被度量

理解了团队为什么讨厌被度量，也就理解了 QA 工作的难处。

老板要求产研度量，本意肯定是提高交付效能，提升公司的市场竞争力，无可厚非。当 QA 和敏捷专家吭哧吭哧抛出一个度量方案，总会收获一些质疑声。深入剖析这些质疑声，我们就能知道 QA 在工作推进中要特别小心什么。

质疑一：各个团队看到了度量数据，很容易内卷起来，有何意义？

未来我们还会具体解读，敏捷实践中如何避免内卷。

发生低价值的内卷场景，往往因为管理者只看纯指标，不看背后的具体做法。指标为什么提升，以及是否保持提升，比 “提升了多少” 更有意义！

所以，度量不能唯结果论。QA 更多的精力要用来关注原因、可持续性、可复制性。

质疑二：一线 leader 懒政怎么办，把指标压力传递给员工。

首先，之前文章聊聊研发效能建设的痛点说过，效能度量不要关联绩效！不要关联绩效！

只要关联绩效，或者暗示会影响绩效，员工的动作就会变形。

对于容易引起这种误解的指标，建议 leader 先自行分析，核实原因，再和员工对齐靠谱的改进手段。

当团队对该指标已经形成日常的健康应对习惯，再完全透明化不迟。

质疑三：你拿出的度量指标和措施报告，对我们团队真的适用么？

这个质疑也是人之常情，度量指标有可能来自其他公司，甚至其他行业，是否一定适用于当下呢？

这也很考验 QA 的分阶段落地能力。

理论上来说，研发效能痛点是高度相似的，不同公司的研发痛点相似度远远大于业务痛点相似度。所以，大概率上，好的措施也是跨公司通用的。

但是员工的工程水平、工作压力、信任度、兴奋度不同，QA 推进方案时也不能一刀切。应该聚焦大家最痛的指标，最愿意接纳的几个措施（不超过 3 个）来行动。

当 QA 组织输出第一份正式度量报告时，尤其要小心核实，有些指标可能是误报，如工具统计口径没有对齐，字段填写规则没有对齐，或者团队发生了众所周知的特殊情况。

就算指标数据没错，我们分析原因和改进建议也不能想当然，最好和当事人访谈，确认下真实的原因（GO-SEE）。充分考虑业务差异、团队差异带来的指标差距。

如果初期发布的报告和员工感知大相径庭，会给后面的工作带来负面影响。

质疑四：研发过程中，填写各种质效相关字段很烦躁。

本质上，这是研发管理平台的产品流程设计（易用性）问题，需要专业思考和跨角色碰撞，后面有机会详细展开。

这里简单说一句：让一线团队先理解背后的原因，再在日常活动中顺手填写或自动填写默认值，字段设计应该遵循金字塔原理，简洁、正交、不重叠不遗漏。通过用户可用性调研，尽可能做到填写成本最低。

传统质量观 VS 敏捷质量观

在敏捷研发时代，QA 同学会有这么多的郁闷和自我怀疑，本质上还是因为质量组织和质量观发生了显著的变化。

传统行业的质量管理源自 20 世纪初的泰勒科学管理理论，在当年这是提高生产效率的有效手段。它强调管理者事先做好计划，建立明确的量化的工作规范，开创了精细化管理的先河。传统行业会把质量控制作为一个独立于业务生产的关键部门，它和生产及销售同等重要，质量部门把计划和执行分离，对执行动作不规范的部门及人员进行偏惩罚性的纠正，因此质量人员普遍让人感觉缺乏建设性，“和生产人员不是一伙的”。

与之对应，敏捷研发的质量观，推崇的是精益生产的质量管理模式，借鉴丰田公司的 TPS（丰田生产制度）精髓，其本质是：没有单独的质量组织，整个组织就是质量组织。每个人都要为整个生产线负责，一旦发生问题就要 “拉绳” 把流水线停下来，检查质量问题，立即改进。软件持续交付流水线就是参考这种模式。

严格管控规范的传统质量管理，对比敏捷精益的质量管理模式，体现在软件研发的质量文化上，体现在过程改进工程师的工作导向上，会有什么鲜明的不同呢？

后面我们详细聊聊。