1.2 研发效能的实践框架

核心观点

● 建设研发效能的“黄金三角”，形成具有增强回路效果的研发效能提升体系。

● 效能实践、效能平台和效能度量三部分相互促进，彼此增强。

● 提炼并坚持研发效能的价值主张，做正确的事情与正确地做事情同等重要。

笔者结合对业界各大互联网公司和头部软件研发企业的研究，将研发效能提升的思路和先进经验整理成一个具有“增强回路”效果的体系化实践框架，称之为研发效能的“黄金三角”，如图1.2.1所示。

研发效能的“黄金三角”由三个部分组成，分别是效能实践、效能平台和效能度量，它们彼此独立，但又相互关联。其关联关系如下：

● 效能实践中的优秀实践可以固化、沉淀到效能平台；反过来，效能平台支撑了效能实践的落地。

● 效能平台产生的大量研发数据形成效能度量中的效能洞察；反过来，效能度量可以持续观测效能平台中产生的数据，并进行下钻和深入分析。

● 效能度量中的洞察和分析结果可用于针对性地优化效能实践；反过来，效能实践可以给效能度量更多的输入，帮助其完善度量指标集和分析方法。

由此，效能实践、效能平台、效能度量就形成了一个彼此增强、迭代优化的回路，有效利用好这个“增强回路”可以帮助企业持续提升研发效能。

下面我们分别从目标、价值主张、实践分类和实施建议几个维度对它们展开讨论。

1.效能实践

研发效能实践地图，如图1.2.2所示。

目标：提炼和采纳与上下文匹配的DevOps及效能提升实践。

价值主张：产品导向+工程卓越。

● 产品导向：区别于项目导向的交付模式（在特定时间内，以相对确定的预算和人力交付预先计划的内容），我们更倾向于以产品导向的交付模式组织相关效能实践。产品导向让我们面向长期的业务价值，组织长期稳定的敏捷团队，持续迭代和优化与时俱进的产品。我们承认需求的不确定性，要持续改进产品，而不是简单地遵从既定计划；我们要考虑长期产品和团队能力的建设，而不是把短期项目做完了事；我们要考虑持续为客户创造价值，而不是看项目有没有超过预算；我们要面向工作结果进行响应，而不是盯着一些局部的工作产出。

● 工程卓越：我们必须持续关注工程和技术的卓越性，而不仅仅是交付了多少需求或特性。比起多完成几个小功能，也许工程和技术上的提升所带来的价值会更大。就像微软CEO萨蒂亚·纳德拉所说：“每一天我都在开发新特性和提升我们的生产力之间进行权衡。”我们要追求用工程化的方法持续把确定性、重复性、机械性的任务自动化，从而在提升效率的同时让工程师将更多时间花在有创造性的事情上。用工程化的思路解决问题，追求工程卓越就是一种“反内卷”的表现。

实践分类：业务敏捷创新实践、敏捷精益协作实践、持续交付工程实践、云原生技术实践、组织和团队拓扑等。

实施建议：业界一致认为，DevOps领域和研发效能领域都从来就没有“一刀切”的解决方案，不要迷信某个成熟度模型和某种规模化框架一定能对你有帮助。正确的实践选择一定要基于上下文，找出价值流中最大的障碍，选取工具箱中适当的实践，从小范围开始，纵向进行实验，应用敏捷思维来提升组织效能，逐个解决瓶颈问题，循环往复。

2.效能平台

一个典型的大型研发组织效能平台框架图，如图1.2.3所示。

目标：打造一站式、一体化的效能平台，支撑软件交付全生命周期。

价值主张：自动化+自助化、场景化+生态化。

● 自动化：自动化很好理解，DevOps讲究“自动化一切”，这正是DevOps的精髓“CALMS”中的A（Automation），研究表明高效能的企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远高于中低效能的企业。

● 自助化：自助化代表上下游角色可以通过平台紧密衔接，工具平台被某种角色创建出来之后，上下游其他角色应该都可以按需、自助地使用，降低了对某种角色或者某个人的依赖，这样组织协作效率才能提升。

● 场景化：我们经常看到很多所谓的“一站式、一体化”，是按功能领域进行划分并展现相关能力的，或者说是一个“拼凑”起来的平台，而真正让管理者和工程师使用趁手的、易用的平台一定是按研发场景进行组织的。比如，以某一产品为主线贯穿DevOps流程，方便用户管理产品的相关需求，创建特性分支，迭代开发和交付。同样，以应用为主线对运维人员来讲会更加友好。

● 生态化：在互联网大厂搭建效能平台时，普遍遇到的难点就是业务复杂、规模庞大、业务独特、场景众多，很难通过一个团队的努力满足整个公司的需求。但是各个业务部门如果什么都自己做、重复造“轮子”，甚至相互恶性竞争就更不好了。因此，作为平台建设者应该更加开放，分离平台底座和原子能力的建设，即通过生态合作伙伴关系促进公司效能平台的良性发展。从公司角度来看，减少重复建设和避免内耗也都是“反内卷”的表现。

实施建议：效能平台的建设切忌开始就追求“大而全”，所谓的“一站式、一体化”只是手段而不是目的，最终以能满足研发场景的诉求为主。尤其是在平台建设初期，不妨以支持ToB客户的思维来进行平台运营，深度绑定和跟进种子团队，深刻理解业务痛点和需求，这样做出来的平台首先马上就会有人用，然后收集反馈，像滚雪球一样越做越完善。另外，还要注重需求价值流和工程价值流之间的联动，而不要将其分裂成毫无关联的两个系统。

3.效能度量

目标：在正确的方向上开展研发效能度量和数据洞察，指导和驱动效能改进和提升。

价值主张：数据驱动+实验思维。

● 数据驱动：我们经常遇到的现象是，一个组织或者团队在消耗了大量的“变革”时间成本和人力资源后，却无法回答一些看似本质的问题。比如，你们的研发效能到底怎么样？比别的公司或团队的好还是差？瓶颈和问题是什么？采纳了敏捷或DevOps实践之后有没有效果？下一步应该采取什么行动？我认为，效能度量的目标就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不要总是凭直觉感性地说“我觉得……”。用真实和有效的数据说话，勇于挑战现有流程和规则，直指研发痛点和根本原因，也是一种“反内卷”的表现。

● 实验思维：研发效能提升没有“一招鲜，吃遍天”的万能招式，而是要基于上下文进行有针对性的实验和探索。比如，想提升线上质量，降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖，完善代码评审（Code Review，CR）机制，做好自动化测试案例的补充。但是，这真的有效吗？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做得不到位。比如，只是为了指标好看，编写缺少断言的单元测试，找熟人走过场通过代码评审，覆盖一些非热点代码来硬凑测试覆盖率目标等。因此，我们需要实验思维，找到真正有用的改进活动及其与结果之间的因果关系，有的放矢才会更有效率和效果。

实施建议：效能度量本身也是一个比较复杂的体系，包含自动采集效能数据、度量指标体系、度量分析模型、度量产品建设、数据驱动和实验思维等方面，将它们整理后，称为研发效能度量的“五项精进”，如图1.2.4所示。

（1）构建自动采集效能数据的能力。通过系统分层处理好数据接入、存储计算和数据分析。比如，小型团队在通过MQ、API等方式把数据采集之后，使用MySQL（存放明细数据和汇总数据）、Redis（存放缓存数据）和ES（数据聚合和检索分析）三件套基本就够用了；而大规模企业由于数据量庞大，汇聚和分析逻辑复杂，建议使用整套大数据分析解决方案，如流行的流批一体的大数据分析架构。

（2）设计效能度量指标体系。选取结果指标用于评估能力，过程指标用于指导分析改进。比如，需求交付周期、需求吞吐量就是结果指标，可用于对交付效率进行整体评估；交付各阶段耗时、需求变更率、需求评审通过率、缺陷解决时长就是过程指标，可用于指导分析改进。通过先导性指标进行事前干预，通过滞后性指标进行事后复盘。比如，流动负载（在制品数量）是一个先导型指标，根据利特尔法则，在制品过高一定会导致后续的交付效率下降、交付周期变长，识别到这类问题就要进行及时干预；而线上缺陷密度就是一个滞后性指标，线上缺陷已经发生了，我们能做的只有复盘，对缺陷根因进行分析，争取在下一个统计周期内能让质量提升，指标好转。

（3）建立效能度量分析模型。这里的模型是指对研发效能问题和规律进行抽象后的一种形式化的表达方式。比如，将流动时间（需求交付周期）、流动速率（需求吞吐量）、流动负载、流动效率、流动分布五类指标结合在一起，就是一个典型的分析产品/团队交付效率的模型，通过这个模型可以讲述一个完整的故事，回答一个关于交付效率的本质问题。模型还有很多种，如组织效能模型（如战略资源投入分布和合理性）、产品/团队效能模型、工程师效能模型等，我们还要合理采用趋势分析、相关性分析、诊断分析等方法，分析效能问题，指导效能改进。

（4）设计和实现效能度量产品。先将数据转化为信息，然后将信息转化为知识，让用户可以自助消费数据，主动进行分析和洞察；简单的度量产品以展示度量指标为主，比如按照部门、产品线等维度进行指标卡片和指标图表的展现；做得好一点的度量产品可以加入各种分析能力，可以进行下钻或上卷，可以进行趋势分析、对比分析等；而做得比较完善的度量产品应该自带各种分析模型和逻辑，面向用户屏蔽理论和数据关系的复杂性，直接输出效能报告，并提供问题根因分析和改进建议，让对效能分析不是很熟悉的人也能自助使用。

（5）实现有效的效能数据运营体系。放在最后的其实才是最重要的，我们有了度量指标、度量模型和度量产品，但一定要避免不正当使用度量而产生的负面效果，避免将度量指标KPI化而导致“造数据”的短视行为。根据古德哈特定律，度量不是武器，而是学习和持续改进的工具。正所谓“上有政策，下有对策”“度量什么就会得到什么”，为了避免度量带来的各种副作用，我们首要的度量对象应该是工作本身，而不是工作者。另外，效能改进的运作模式也很重要，如果只是把数据报表放在那里，效能不会自己变好，需要有团队或专人负责推动改进事宜。建议在组织中建立度量数据的应用场景，以场景应用带动数据的有效利用，通过建立阶段性的目标推动反馈闭环。例如，团队可以在Scrum回顾会议中建立团队阶段性度量改进目标并设定改进措施，部门可以以月度、季度为周期设置目标并推动反馈闭环。