聊聊质量管理工程师的郁闷

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

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》已出版（机械工业出版社），《无测试组织：测试团队的敏捷转型》(张鼎)【摘要 书评 试读】- 京东图书。

研发度量和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（丰田生产制度）精髓，其本质是：没有单独的质量组织，整个组织就是质量组织。每个人都要为整个生产线负责，一旦发生问题就要“拉绳”把流水线停下来，检查质量问题，立即改进。软件持续交付流水线就是参考这种模式。

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

后面我们详细聊聊。