这是鼎叔的第八十九篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），“阅读原文” 有官方链接。

前段时间参加了深圳敏捷之旅，和几位大咖深入交流，包括吴穹博士和乔梁帮主等，对于研发效能的一些痛点颇有共鸣，大咖们有几句看似悲观的犀利句子能启发出更本质的行动指南。
搞研发效能的痛苦，一是高层往往关心把业务快速打下来，打不下来就撤，而不是省钱和提效，二是让别人提高效能，远比教小孩提高学习成绩难啊，强扭的瓜不甜。提高研发效能的本质，就是带着团队明确度量、无限拆解、刻意练习、自建纪律。

太阳下面没有新鲜事，解决新问题的思路都在人的本性里。
做效能，首先是要提升系统思考能力，找到根本原因。

一 做效能的工程师在企业里面挺卑微的，因为他要让其他团队提高效能，别人心情好可能听你聊聊，配合一下，心情不好就说业务太忙。

我在《无测试组织》第四章说过，质量管理/过程改进工程师，也是同样一类尴尬的角色，要求其他团队交付高质量产品，但是不能帮忙解决现实的痛点。如果我们用传统的监工权力强制执行，在敏捷组织中必将陷入被孤立的境地。如果一线 Scrum 流程中动不动把团队外的角色卷入审批，必然拖慢交付速度，且难以评价收益。

从我个人经验出发，质效工程师一定要尽可能融入到交付团队，帮 scrum team 把特定的工作给做了，共同为交付目标负责。带领效能建设团队的 leader 最好不是孤立 leader，避免屁股决定脑袋的言行。比如，懂敏捷的业务测试 leader 来负责大型组织的效能建设更有机会成功，因为质量和效率的痛苦是双生关系，也是业务测试的压力来源，而大部分项目都有业务测试人员作为 Scrum 成员，他们作为被培训者更容易把改进纪律带进各个 scrum 团队。

二 战养分离。
人才培养，团队氛围和效能改进等工作类似 “养兵”，面向长期目标；眼前业务交付目标就是 “作战”。如果让一线团队 leader 做好战养兼顾，在业务压力之下就会变成以战为主。

我在《无测试组织》最后一章说过，现在的实体测试团队，未来会演变成专家赋能和交流型组织，即测试人员关注 “战”，测试经理转型成 “养” 的责任人。

三 工程师是二十一世纪的铁匠。

过去这么多年的中国软件研发产出如此繁荣，并不能说明工程师水平在进化，主要原因还是赚钱机会太多，公司的第一要务是堆人，抢下更多的市场，敏捷/效能更像是个锦上添花的东西。

实际上，一二十年前调研软件工程团队的十大痛点问题，在今天几乎一模一样，这也是《人月神话》理论的侧面证实。

这几年强调研发效能的声音更大了，主要原因也是市场分割得差不多了，开始要求经营效率了。

如果我们观察团队效能改革的优秀案例，会发现敏捷教练做的事，本质上和球队教练做的事类似，工程师就是今天的普通工种，教练要让他无限拆解迭代周期的工作流程，并在规定时间做规定动作，精确查看度量指标是否提升。

上图是示意图，真实的迭代拆解时间表要复杂个四五倍。

我在《刻意训练》的文章也分享了，提高交付效率，和羽毛球运动员提高成绩，是同一个道理，完全不依赖工程师的天赋，而是在优秀教练的指导下，反复拆解、练习、度量。

规定时间做规定动作，看似死板枯燥，其实是维护大型研发组织的一致性。团队可以负责自己独有的特性，但是否纳入大组织中需要谨慎评估，有一致的衡量标准。

有人会说，这种练习不是抹杀工程师的创造力么，而且也不符合团队自治的文化呀？

我的想法是，敏捷执行就是要克服工程师的懒散习惯，世界上所有领域都是一样的，比如音乐家，舞蹈，足球队，都是如此。野生玩家自由状态下出成果可以，出优秀成果难。

“刻意练习” 的具体时间表、纪律是团队自己画出来的（自治），但是执行框架是由教练/Scrum master 引导的。

光有创造力，没有集体的刻意练习，这个创造力大概率会在市场压力下失败。

反过来，大师级程序员的创造力是体现在高强度训练之中的闪现。

四 技术管理者只关注工程实践闭环就好，不用去操心需求精益环。除非…

学习了《持续交付 2.0》的双环模型，我感觉它类似《系统思考 - 第五项修炼》给出的经典问题分析的环状结构。左边是 “精益需求环”，解决做什么、谁来做、怎么做的问题，右边是 “卓越工程环”，解决怎么按时交付高质量的版本。

左边才是业务交付慢的大头原因。

因为业产研的核心矛盾在左边环的低效，所以我也有冲动去拉通产品团队和技术一起提效，确实进展极慢，想犀利批评一下，很容易被业务产品团队反弹，甚至被带上 “破坏精诚团结” 的帽子。

技术管理者如果不能掌握利益分配权，不决策产品演进路线，还不如专注做好工程环的交付。至于双环提升的措施，给老板看看方案就好，不用强行去整体承担。

五 效能度量不要考核个人！不要考核个人！不要考核个人！

我在《无测试组织》第四章说过，研发度量如果用于个人绩效考核要非常谨慎，最好不要直接使用，而是作为绩效已有判断后的辅助证明。因为每个质效指标都有多种 “作弊” 方法，就跟经济改革一样，工程师都有很聪明的对策。

效能度量的最小单位是一线团队。那有同学就会问，管理者总要给出个人绩效高低呀。

我的答案是，个人绩效主要看三点，第一，OKR 产出和预期的差距，第二，360 度口碑（包括客户），第三所在职级专业能力的高要求和产出的差距。

六 业务团队只要知道哪个技术人员为它提供专职服务，满意度立马提升。

初创团队天生就很敏捷，响应快，因为业务实现不够快就面临生死问题，这个时候业务伙伴一定是满意的。

随着公司成长到数百人以上规模，必然就会考虑敏捷化，“让大象起舞”。

从业务团队的角度，为什么技术团队大了很多，反而响应我的需求更慢了？

团队大了，必然会产生部门分割，多层管理损耗，沟通的损耗，复杂的资源申请流程，等等。

大的产研部门会引入 “部落制”，整个部门分为多个部落，每个部落由数个 Scrum 团队组成，一起承接特定业务部门的需求。

敏捷化的本质就是把业务服务对接精准。确保每个业务方都精确地知道技术侧是谁在解决问题，该和谁沟通。

业务和技术的协作，既不能 100% 由业务侧控制，也不能 100% 由技术控制。如果业务完全主导，就会形成山头主义，技术架构优化就难以落地。推荐的协作方式是业务交付由 Scrum Team/部落横向拉通（战），技术建设由专家团队纵向赋能和风险评审（养）。

七 效能大盘的高价值

如果面向大规模组织的技术管理者呈现效能指标，有一个基于北极星指标拆解下来的实时数据大盘是非常有价值的，这在《无测试组织》最后一章也有说明。

因为高级管理者距离一线 Scrum 比较远，他希望能随时查看整体团队数据，也希望看到高风险的团队指标。效能大盘就是非常好的桥梁，让高级管理者能既掌握全局，又按需（风险）下钻。

大盘的全自动化能力，保障了快速呈现、极低度量成本、可灵活调整的数据获取，让效能能透明化呈现。只要度量数据是围绕北极星指标，科学拆解的，就能长期稳定采集，并能看到趋势健康度。

另外，效能大盘不要只用于领导层偶尔看一看，因为 leader 很可能不经常看数据，导致风险处理被延误。在这种状态下，我们要在一线团队指定观察指标的责任人（有的公司称之为 “效能教练”），按要求行动，充分把大盘的驱动价值发挥出来。

从鼎叔自己的经验来看，有了清晰的实时大盘建设思路，就能把面向大型组织的研发效能汇报成本大幅降低。相对于当年要花几十人天才能完成的效能月报，现在半人天就能输出初版（理论上从大盘到月报可以自动化转换），剩下的工作就是追加人工沟通、分析和总结：为什么部分业务的指标会明显下降或提升，并总结近期的优秀措施和风险。

打造效能大盘的第一个阶段，是把关键效能数据呈现出来；第二个阶段，是对指标进行准确下探、精确拆解和根据基线提示风险；第三个阶段，是通过专家规则建设和 AI，预警团队风险和建议解决步骤。

八 持续交付落地可以卷入各个角色，其中一个角色是…HR

围绕持续交付值得教育的口号和纪律不少，想要深入人心，可以和 HR 合作进行文化建设，他们在这块是专业的，方法层出不穷。未来更深度的合作就是组织激励制度了。