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

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

上文 聊聊质量管理工程师的郁闷https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484687&idx=1&sn=2dd34c5b84a9ced839bf9208ae274582&chksm=c24fb06df538397b8dd79c2462ef7d78f462ac8071301799e6acae874d9cb8bdaa7680001204&scene=21#wechat_redirect，
说到质量保障（QA）工程师的困惑。传统研发质量的管理体系一直有比较大的局限性，在敏捷团队中推动度量常常缺乏成就感。质量管理如果作为独立处罚型部门，难以产生推动质量内建的文化。两种环境下的质量观有哪些关键的差异？

一、强调规范文档 VS 弱化文档

传统 QA 管控团队的杀手锏就是一切用书面记录下来，强调规范化，带来的文档处理成本很高。而敏捷质量模式则是重沟通、轻文档。文档也可以是辅助交流的生动工具，但不会使用过于死板的形式。团队内部写文档更多是为了知识沉淀，在测试方面确保理解场景即可。只有要交付外部客户时才会对文档做规范处理。

二、严格约束角色的权限 VS 高度信任的管理

因为质量管控的权力大，“以质量和安全为名” 会给日常操作流程的成本层层加码，却没有人大胆做质量控制的减法。在传统研发公司就会呈现出 “缺乏信任” 的氛围，很多并非那么保密的资料非要申请权限，对合作方员工防范严格，进一步造成协同办公的高成本，但少有人公开质疑这点。
敏捷团队应该拥有高度信任的氛围，设置规范的主要目的不是 “限制权限”，而是鼓励明智地授权，让集体交付价值最大化，避免短期冲动冲破健康运营的 “护栏”。

三、各司其职 VS One Team

传统的软件度量，因为是建立在 “准确追责” 的基础上，很容易导致各个角色只关注自己的份内之事，害怕被高管关注到 “短板”。个体的聚焦反而暴露了团队缺乏互相补位的不足。遗漏到线上的事故，往往不是需求测试不充分，而是跨子领域的协同场景缺乏看护。
敏捷推崇的自组织形式就是 One Team，这并不是要求人人都是全栈高手。而是指每个人不但擅长自己的专业领域，而且能在关键时刻互相补位提醒风险。One Team 会带给成员更好的安全感和更有勇气的探索尝试。

四、红黑榜扣分 VS 团队集体负责制

传统质量管控因为要强调令行禁止的纪律，习惯性的建立惩罚型度量机制，比如红黑榜，出现一次跟进不及时，则扣除绩效分，多了会影响奖金回报。这种比较压抑的氛围在崇尚自主风格的新生代员工中不能起到提高效率的作用，反而会导致优秀人才的批量流失。
敏捷的 One team 追求集体共担质量风险，形成内部共识的 “纪律”。就算需要提醒负面现象，通常也是通过有趣的方式去 “惩罚”，如站会迟到的处罚：俯卧撑，买下午茶，表演舞蹈等等。
在回报激励上，One Team 首先是看一线团队的整体交付价值大小来分配利益，辅以成员间和客户的认可度评价，而对内部单一岗位的产出指标度量并不是给回报排序的决定因素。

五、 威权管理者 VS 仆从管理者

在传统质量管控的导向下，研发团队的经理会被强化威权，成为研发人员的法官。领导提出了技术意见或者不太合理的评价，员工通常不太敢反驳。这种氛围会导致研发风险被滞后发现，员工也不敢提出对现状的大胆变革，因为没有人保证发起变革就一定会有正向数据，甚至度量变革的指标还会在一段时间内明显下跌。
曾有一个部门负责人对我说，“你看，部门有几百号人，如果我不能让大家聚焦在最核心目标的达成率上，那对公司而言是多大的资源浪费啊！” 而我的回应则是，对于这么庞大的团队，如果以领导的意志为指挥棒，以死板的年初考核指标为准绳，那领导个人决策能力就会成为团队发展的瓶颈，这才会形成真正的浪费。人才因为不敢认领新的挑战而让自己的才能被埋没，从而大规模离职。
敏捷研发时代，谁能保证年初定的目标和考核指标到了年底还是最合理的？这本身就是违反敏捷价值观的做法。
敏捷价值观强调的是领导要么成为明智的干系人，在团队之外提供资源和建议，但领导的意见仅供团队参考，团队应该自主运作；要么成为团队的 “仆从领导”，关心团队当前运作的主要困难，并第一时间寻求解决之道，为员工排忧解难。

这也是鼎叔在聊聊每日站会中认为的，Leader 应该把 “48 小时内发现并着手处理阻塞问题”，作为团队管理者的敏捷要求。

六、质量至上 VS 有损发布

在质量至上的 “理所应当” 之下，可能掩盖研发行为上的低效短板，容忍自动化技术停滞不前。比如，有一个 VIP 客户向手机测试大领导反馈了一个第三方游戏的机型适配问题，后面公司制定的改进措施是增加三倍的人工测试员，并覆盖五倍于目前适配测试覆盖的第三方游戏数量，“以降低客户投诉率”。这就是典型的不计成本的 “提升质量”。但是平均每款游戏的测试力度是下降了，总成本支出却大涨了，这样真的能给公司带来质量团队的价值么？显然不会，顾客不会为了手机适配测试买单，当市场经营形势不利时甚至可能带来 “测试大裁员”。

总之，提升质量却不考虑成本，就是在 “耍流氓”。背后往往是决策者没有认真分析遗漏到线上的质量问题的产生根源在哪里。增加测试的范围或颗粒度，不一定提高质量问题的拦截率。我们首先需要看看哪些质量提升活动是值得投资的。

那 “有损发布” 又是什么概念？

既然敏捷研发的目的是尽快交付用户价值，我们就不能保证所有缺陷都消灭掉才能发布，团队应该集体决策，在发布时间（价值变现时刻）和品质满意度上取得平衡。

很多产品都会确立发布质量标准及衡量指标，但是这些标准不一定是基于用户价值视角，而是依赖一定的专家经验。针对不同的产品发展阶段，不同的需求优先级，我们其实可以探索灵活的标准，在局部场景降低测试力度，或者允许带有一部分缺陷上线。如图所示。比如创新型产品，我们允许其带有更多的非核心体验上线，试探市场的反应，迅速确定发力方向。

图 产品特征四象限

核心产品如果到了关键发布期之前，仍然遗留了较多的缺陷，我们应该集中力量处理必须修复的关键缺陷，这部分的质量标准不应降低。但是非关键缺陷在后期可以只记录不处理，以免在验证不充分的情形下引入更危险的新缺陷。

另外，我们也可以从不同产品的业务特征来看有损发布，例如：

UGC 类产品，对于性能要求高，但是准确性要求不高，发布质量的重点在于展示快，但是画面显示内容可以有一些问题（有损）。

电子商务产品，对页面响应性能要求也高，最终交易结果要让顾客满意，但是处理中间过程可以有一定的等待时间（有损）。

金融产品，处理响应可以稍慢（有损），但是展示的金额数据要和预期绝对一致，不能有差错。

七 对上级管理者负责 VS 对一线团队负责

QA 作为人数很少的岗位，经常直接对管理层汇报，承接管理者的改进诉求，在传统公司，QA 对管理者负责是必然的结果。然而在敏捷组织中，对一线团队负责也是 QA 必须兼顾的价值观。这两者如何权衡是一种艺术，因此敏捷团队中的 QA 需要具备更稀缺的综合能力。

如何从上传下达的传声筒，变成上下级之间信息传递的桥梁和加速器？

拉通度量指标的共识，并把指标透明化展示，是第一步。多聊聊指标背后的理论、思考逻辑、参考案例、对未来的美好期待。切忌把老板的质量管理观点强压到一线团队身上。

通过访谈，识别团队落地改进的几个最大困难，并迅速确定措施跟进人和定期评估机制，是第二步。系统思考：关键指标做得不好，背后的根本原因是什么？QA 的价值在于挖掘背后的增量信息（包括主观判断），这个没法依赖自动化平台了，得点对点沟通。纸面上的数据差距下通常埋藏着更本质的理由。

阶段性完成改进动作后的鼓励、反省、规则化，是第三步。具体改进规则不应该是 “正确的废话”（对所有团队都通用），而是针对特定团队在特定阶段的主要风险。

八 强调合同的精准稳定 VS 强调合同的自适应性

这点很有意思，本质上还是传统协作管理和敏捷协作管理在文档上的观念差别。

如果我们把合同每个字都抠得非常精细，不准改动，会有什么结果？

业务需求方一定会一次性把需求都加进去作为约束，不管是不是很需要，因为改合同的成本太高，频率太低了。开发体量被增大，但是功能体验感反而被稀释了。

敏捷的产研合同应该约定的是功能的价值和验收场景，鼓励按通过验收的故事点收费，或按迭代收费可变期限合同。只要有需求发布就可以支付费用，什么时候用户需求满足了就停止开发，可以提前完成合同。

研发管理规范也是同样道理。再厉害的专家团队也不可能一下子给出完善规范，它应该是和团队充分互动的。

最后，小心——

有的 QA 团队为了展示自己在质量管理上的专业度，热衷于在管理层汇报专业报表，把质效指标机制设计得非常宏大复杂，这违背了基本的敏捷规律：

质效改进的工具和看板，应该是迭代演化出来的，像产品一样简洁明了，它应该适应一线团队的阶段性发展，而不是大幅增加一线团队的认知负担。

如何制订出既完善又高效的敏捷度量指标体系，如何减少指标被滥用的概率，是本专辑后面的文章要详细阐述的。