本文根据单虓晗老师在2025年QECon大会同名演讲整理，文中图片里展示的所有数据、人名等信息，均做了脱敏处理。
今天的分享有4部分：
理念与方法：快速对齐认知，研发效能是什么？大家普遍认可的效能提升方法和路径是什么？
实践与案例：字节过去4年来的实践和案例，主要包括效能基础设施如何建设？在公司内如何应用？整体效果如何？
未来与展望：从2024年开始到未来1-2年的探索方向。
原理与思考：轻松的环节，作为效能领域的长期实践者，分享自己的一些观察和总结。
什么是研发效能呢？如图所示，我们可以把研发过程分为三层，从整体视角看，对于一家企业或一条业产研一体化的完整业务线来说，通常需要在业务价值、研发交付、技术实现3个层面同时达成3个目标，让3类角色满意，才会被认为是“高效能”。
业务层：业务负责人，会关注业务价值的流动，以“业务目标”为核心，希望创建更多有效、可验证、可闭环的价值，保证业务结果、业务成功。（注：不同的业务类型，定义的“业务目标”可能不同，比如商业化团队看成本收入指标、2C产品团队可能看各项用户指标、技术中台团队可能看的是技术稳定性指标或研发交付效率指标（和研发交付层一致））
研发交付层：技术Leader（包括配合Leader工作的产品经理、质量保障人员），会以“需求流动效率”为核心，希望需求可以持续、快速、高质量的交付，以满足业务负责人对研发的要求。
技术实现层：一线开发人员，会希望每个研发活动，都可以顺畅、高效、低成本的完成。
研发效能如何提升呢？如图所示，一家企业的研发效能提升一般都要经历三个阶段，三个阶段可以并行开展，但是大部分情况都有先后依赖关系。
在线化：先建设效能平台，把线下人拉肩扛的研发过程搬到线上。比如最简单的例子，把用本地Excel管理的需求、缺陷搬到线上管理，这样多个角色可以更快的协同。
标准化：在效能平台中沉淀研发标准和普适的好做法（也称为“研发最佳实践”）。比如代码规范沉淀到代码静态扫描工具中，再加到质量门禁中自动拦截问题。
数字化：量化研发过程，构建指标体系，持续分析问题，并驱动改进。
因此，从系统视角看，三个阶段对应的三个要建设的关键要素，把它们之间的相互影响关系用「系统循环图」（也叫因果循环图）抽象表达，就是张乐老师的经典理念「研发效能黄金三角」了。
三者之间的运转关系为：
效能实践有管理实践、工程技术实践、组织实践等，我们需要把这些实践提炼出来，并沉淀到效能平台上。
反过来，效能平台去承接实践的落地和规模化。
同时，我们需要通过效能度量去洞察研发过程中产生的数据，基于度量的结果找到瓶颈，再去进一步优化效能实践和效能平台。
所以，这三者之间构成了可以彼此强化、持续迭代的增强回路，是有机整合的共同体。
从下图中的这些案例可以看出，业界各互联网大厂虽然建设时间、建设顺序各有不同，但是基本都是在围绕这三个核心要素建设的，当然，也包括今天要分享的字节跳动。
接下来，我会系统性的分享字节跳动的具体实践，如下图所示，是一个宏观的全景图。我会分2部分，分别从研发效能基础设施的建设与应用2个角度，分享7个实践：
左侧，建设效能基础设施。按黄金三角的框架，分为3个实践：效能平台、效能实践、效能度量。
右侧，我觉得更重要，也是业界分享中最容易被忽略的，即如何应用效能基础设施，驱动万人规模的庞大组织提升效能？这里，我们采用的是一种分而治之的思路——分层分级提效，主要有4个实践：公司级驱动、业务线级提效、团队级改进、个人级优化。
2.1、建设「效能基础设施」，平台 实践 度量
① 效能平台：Bits 研发平台，全流程、标准化、数据化
1. 发展历程
字节的研发工具链整体发展经历了3个阶段：
点：2019年以前，单点工具建设，属于“群雄割据”的时代，很多团队在自建工具，同一个领域可能存在多个同类工具，最终优胜劣汰之后还有90多款。
线：2019-2020年，逐步向三端开始整合，服务端、客户端、前端。
面：2022年开始，汇总了所有主流工具，进行融合，形成了统一的平台Bits。（其中可看到飞书项目和OKR在内部是独立的，和Bits的协同关系）
2. 核心方案
如上图所示，是Bits 研发平台的产品架构图，业界各大厂的内部平台建设，从功能的角度，其实大抵如此，大家都差不多，没有太多差异化的东西，因此本文就不赘述了。上图来源于杨月在EE大会的分享《字节跳动 一站式研发平台实践》，希望深入了解平台建设细节的同学，可在本文最后的“材料下载”中获取当时的分享材料。
3. 建设结果
做效能领域的同学们应该也都知道，如果只把做工具看做一种“业务”，这种工具类型的业务上限一般都不高。从结果上看，可以用3个指标来衡量：目标用户覆盖率、用户量（日活/周活）、用户满意度，当这三个指标上做到一定程度，可以认为工具链建设和推广基本告一段落了。
一般来说，这个阶段难度都不会太大，产品的用户量、用户体验，只要有投入，能扎扎实实做好，一般不会遇到太大的问题和挑战。
② 效能实践：研发最佳实践体系，理念→方法→方案→案例
1. 发展历程
按标准方法，一般是先要定义效能实践，然后建设效能平台。不过字节有一个“自下而上”的习惯，很多事情一开始都不会做体系化的顶层设计，而是先野蛮生长，往往都是各业务线、各团队先自发单点建设，再涌现，再体系化。字节的效能实践体系的形成过程也是如此，整体经历了3个阶段：
2019-2022年：我们发现各个业务线都有各自特点的优秀实践，我们通过公司的活动，把实践按季度征集上来，促进业务线之间相互学习。
2023年：工具建设逐步趋于成熟，我们将各业务线的共性实践提炼了出来，就形成了上面这张图，被定义为“研发最佳实践”。其中每个入选实践都需要至少要达到3个标准：具有普适性且被验证有效、明确的目标和度量指标、有公司级平台可支持。
2024年至今：抽象出一套标准的研发模式，在全公司范围内推广。
2. 核心方案
类似Google、百度一样，我们也有自己的一套方案集合，其中包含了大约20个适合字节的实践，每个实践方案都需包含了：背景、目标与指标、实践方案以及成功可参考的案例。如下图所示，是单元测试实践的示意。
3. 建设结果
实践体系的实施效果是什么样呢？我们有一个效能专家团队会和各个业务线一起去分析问题，并导入最佳实践。从结果上，可以看2个角度：
从整体视角看，随着实践的规模推广，核心指标是否有明显变好，比如推广单元测试，可以看单元测试的团队使用率、增量代码覆盖率。这个角度，可以观测与评估实践开展的广度。
从业务视角看，每年是否有1到多个完整的业务线效能提升的标杆案例，即某个业务线通过多个实践的组合应用，最终提升了效能。这个角度，可以观测与评估实践开展的深度。如下图所示，是202X年标杆业务线效能提升结果的总结，第二列可以看出，有些是公司标准的实践，也有一些就是针对部门具体问题的实践，因为最终还是以业务线本身的效能提升为结果导向。
③ 效能度量：DevMind体系，构建效能提升的“导航仪” + “发动机”
1. 发展过程
整体演进分了四个阶段：
数据阶段（2020-2021年）：由于工具链是分散的，但是我们在数据层面先把各个工具的数据连接了起来，构建了数据中台。
度量阶段（2021年）：开始引入效能度量构建标准的指标体系，组织级指标和白皮书形成。
洞察阶段（2022年）：开始聚合各个指标构建自动洞察报告，降低数据分析门槛，开始陆续服务各个业务线洞察问题，实施改进。
管理阶段（2023年至今）：部分业务线开始为技术Leader把多个洞察报告聚合起来，建设研发管理驾驶舱，更体系化的沉淀了管理实践，实现技术目标、产品目标、交付、研发情况等“一张图”管理。
2. 核心方案：
如图所示，是DevMind的解决方案和产品架构图。DevMind体系在过去几年已经有很多公开材料了，希望深入了解建设细节的同学，可在本文最后的“材料下载”中获取当时的分享材料，本文也不展开了。
3. 建设结果
在实施效果上，可以分别从3个角度评估：
数据：接入了公司多少工具，形成多少有效数据资产。
指标：建设了多少有价值的权威指标，并被应用。
产品：用户量和服务人群的满意度。
2.2、应用「效能基础设施」，分层分级提效
① 公司级：建立全局标准，持续运营，驱动各业务持续开展效能提升工作，带动整体效能提升
这个层面，看似很“虚”但却非常重要。“虚”的原因是“公司”并非实体，而是由横向的管理层和一条一条核心业务线的管理者组成。“重要”则是因为效能提升的导向或目标，必须想办法和这些核心人员达成共识，并获得足够的支持，才能降低推行的难度和阻力。
根据以前我在华为、蚂蚁的经验，一般要先定一个非常专业的方案，然后逐层汇报、立项，总之就是想办法得到公司技术委员会的支持，然后类似商鞅变法一样，做个正式的发文通告，以确保大家“书同文、车同轨、量同衡”，明确目标、导向，再开始自上而下开展工作。但很遗憾，这种方式并不适合字节，字节有一个文化叫“context no control”，所以也没有一个类似技术委员会一样能发红头文件的组织，各条业务线基本也是各自为战的。但这也倒逼我们重新思考研发效能工作开展的本质，究其根本，我们希望在公司层面上开展这项工作，必须先想清楚2个问题：
我们做什么，能为公司核心管理层提供一些价值的输入，让他们能认同效能提升这件事？
我们做什么，能自上而下的为各业务线负责人提供一些有价值的输入，让他们愿意跟随我们定义的全局标准？
答案就这这张图里——《研发效能分析报告》，我们会在每年发布两次报告，里面有各项研效指标的基准数据，并分析半年来的变化和原因。一方面，这份报告为公司横向管理层提供了有价值的输入，几年来，从之前的可有可无变成了必看报告；另一方面，每个业务线都通过报告了解到公司的研效数据基线，并反过来可以看清自己的指标、差距。我们从2022年开始做这件事，持续做、坚持做，再结合一些运营活动，最终就形成了一套公司层面例行开展的动作和标准了。
② 业务线&团队级：导入「研发最佳实践」，持续洞察与改进，分阶段、逐步提效
这两个实践的思路一样，差异在于提效团队的规模不同、复杂度不同，因此过程会有差异。我先介绍整体的方法，再结合2个具体案例，以加深理解。
1. 0→1的阶段：导入「研发最佳实践」，分阶段提效。
当遇到1个没有做过任何研发标准化过的团队，大致是上图中红色的状态：每个环节都有工具用，但是都是单点使用，各环节串不起来，流程五花八门，开发、发布过程也都缺少管控。你想分析一下效率、质量问题，数据也是散乱的。自然，一线开发人员的使用体验也不会太好。如何提效呢？解法就是按部就班的一个一个导入最佳实践，变成上图中绿色的状态。我们会通过5个实践逐步实施，最终达到理想状态：
研发流程标准化：用一套标准研发流程串联从开发（拉分支）到发布。
研发质量防控：在研发过程的每个环节，加入质量防控手段。
研发&需求双流联动：研发流程标准化后，就可以自动同步需求的状态了。
研发全流程洞察与改进：基于1-3的实践后，需求过程、研发过程都有了准确的数据，可以用于分析和改进。
一站式研发体验：当所有开发人员都使用标准化工具后，就可以通过调研+数据的形式，持续关注体验和效率，并驱动工具改进了。
2. 1→100的阶段：持续洞察与改进，逐步提效
对于已经导入了最佳实践的团队，如何进一步提效呢？可以类比人体体检，首先了解人体结构，再通过各项指标找到异常，从而找到解决方案，对症下药。
我们为一个业务线或者团队提升效能也是类似的思路，先量化现状，再诊断问题，再驱动问题解决。如下图所示，是我们基于字节跳动的效能度量和效能实践，匹配到不同的研发过程给出的体检全景图：
蓝色的标记是指标，绿色是效能实践。其中，深绿色的实践是公司级通用的实践，浅绿色则是没有通用解法，只有大体的思路，具体如何改进需要具体业务具体问题具体分析。这套体检模式可以避免我们在为团队看病的时候，只看“光照的见的地方”，比如只见到我们自己想推广的实践，而忽略了其他的问题。
接下来，我们根据大量的业务线、团队的诊断治疗经验，把效能提升工作按难易度分为两大类，类似把病人分为“轻症”和“重症”：
第一类是团队改进，通常50人以内，主要提升目标是交付质量、效率和工程能力。“治疗”方法也相对比较简单。
第二类是业务线提效，通常是100-1000人规模，由于规模较大，提升目标从相对比较简单的只提升工程能力，到提升交付质量&效率，甚至到业务目标&成本基本都包含。而且“治疗”的措施也比较复杂，周期也比较长。
下面，我会用2个案例来分享一下这个“治疗过程”大致是什么样的。（这里顺带提示一下，这2个案例是我根据字节内很多业务线和团队的真实案例聚合出来的，所以每个案例看起来“病”得特别重）
团队级改进（<50人）
1. 0→1：分步导入「研发最佳实践」→ 导入配套研发工具。
Step1：设计标准流程
Step2：在工具上配置标准流程
Step3：在团队中推广并确保标准流程运行
2. 1→100：问题洞察→实施改进（业务、研发交付、研发基本功）
如下图所示，这个团队大约20人左右的规模，从它的「研发管理驾驶舱」结构上能清晰看出来它的特点：
首先，最关注的是产品和技术目标（图里没表达出来的是每个节点下是可以一层一层展开的，目标最后都会关联到具体工作项）
其次，团队交付的情况，通过图中“效能体检”节点表达，包含看产品指标、交付指标、研发基本功指标等等。
下面我们逐层对这个小团队进行问题诊断和治理：
Step1：业务层诊断，主要是看业务线目标和达成度。
由于每个业务形态和目标都不一样，没太多通用性，但这里更多的是想表达2点：
对于一个业务/产品/研发一体化的交付团队而言，业务目标一定是第一优先级应该被关注的。
需要用有效的数字化的方式定义和拆解目标，并量化跟进。
Step2：交付效率诊断，这主要是通过需求交付相关的指标，找到核心问题。
小团队的好处是可以不严格依赖指标统计，而是可以具体看数据详情。比如这个Case，即使各项指标整体向好，但是微观看数据，还是可以发现问题的，以下图中的案例为例：
流程上，P0需求消化比例降低，需要Review需求排序和优先级的问题。
把交付周期长的需求Case拉出来，会识别出复杂度高的需求，可以反压产品做好拆解。
3个验收质量差的需求，通过单个需求Case复盘，就可以找到很多质量防护上的优化。
Step3：交付质量诊断，可以通过线上缺陷的分析，反过来找到研发各个阶段可以改进的措施。
Step4：研发基本功诊断。这里就更像体检，按研发各个阶段，找到细节的问题，并进行针对性治理，包括代码静态分析、单元测试等工程实践都是通过这个过程被带入的。
3. 实施效果：团队级改进可以简单粗暴的直接看交付层的结果指标（需求平均交付周期、需求交付数、万行责任事故数、线上严重缺陷逃逸率），来确认最终的改进效果是否符合预期。对于此案例而言，结果如图所示：
上述的过程，在效能基础设施建设比较完备的情况下，难度并不大。根据我在很多团队的治理经验，只要有投入，有分析，有驱动，就会有收益。接下来，再我们看看千人级团队的“大病”怎么治。
业务线级提效（1000+人）
先介绍一下这个2B的团队的背景，他的人员1000人以上，平均每个季度交付的需求是4600多个，整体被认为有效能问有题来源2个：一是业务反馈，重点客户反馈提了一个很小改动的需求，半年都没有交付，二是客观数据，需求交付周期平均是44天。接下来，如何提升整体的需求交付效率呢？这里我们用了一种综合宏观+微观的分析方式，先看看问题在哪里：
微观：采样调研所有的异常交付的需求，总结出了5-10个大类问题。
宏观：用客观指标印证原因是个例还是共性。印证后，有四类问题，不仅是个别Case的个例也是整体性的问题，直接的反应就是对应的统计指标表现比较差。
根据每一类问题的特点做分析和归因：
需求复杂度问题：主要用微观的Case分析的方式，识别数据中的异常Case，锁定问题，并给出需求拆解上的优化方案。
资源&流程问题：同理，也是找到未预期交付的需求，分析不符合预期的原因，并给出流程上的治理优化方案。
研发质量问题：主要是客观指标分析，将结果指标，按研发阶段分解出过程指标，逐一分析和归因，改进项纳入对研发基本功的治理专项中。
研发效率问题：同理，将工程效率的指标，按研发阶段分解出过程指标，逐一分析和归因，改进项纳入工程效率的治理专项中。
分析到这里，相信有分析经验的同学会问2个问题：
问：资源&流程问题，为什么不使用「需求价值流分析」？
答：适合单需求分析，对于海量需求（4600+）场景，想提取共性问题，只能依靠数据寻找共性特征和规律。
问：研发质量&效率问题，为什么不分析「人员能力」、「系统架构」这两个因素？
答：两者都是比较难提升的，作为千人级团队的横向改进项目，常把人员的意愿&能力、系统架构复杂度作为基本约束条件（假定无法提升），而去关注更容易提升的机器效率和研发工具问题，即聚焦减少开发人员研发过程中的等待和浪费。（先摘取低垂的果实）
四类问题分别的解法如下：
1. 解法1，需求交付流程优化
流程治理的方法相对简单，先梳理预期的标准流程，定义准入准出标准，再调研现状找到落差，尤其是分析其中的BadCase，最后明确改进措施，并开始实施。这个Case的治理案例如下图所示：
2. 解法2，研发基本功提升
主要的治理过程分为3个阶段：
阶段一，小团队试点：深入到1个团队中试点，去寻找与印证适合的方法，并形成案例，用于举证和更大规模的推广。
这个Case的治理案例如下图所示。通过问题分析，明确要引入单元测试和代码评审来提升，那么分析出团队具体的有效措施，比如单元测试，一般需要三个阶段，按先固化再优化的思路，先提升覆盖率，再提升有效性，再提升完备性。最终，经过一段时间的验证后，再用数据印证哪些措施是有效的。
阶段二，数据驱动，规模复制：有了1-2个小团队案例之后，会可以尝试获得团队总负责人的认可，并自上而下推行，再配合数据通晒等手段，驱动整体性的提升。
阶段三，工具化、流程化：所有“运动”都是有周期的，当用数据推广的时候，一定得同步启动一件事，就是把规范融入流程，尽可能做到自动化，当这个事情做完后，运动就可以停了，因为整体的有效措施已经被固化在了流程和工具里了。
3. 解法3，工程效率提升
主要分为2步：
Step1，共性问题的治理：这种治理的好处是不需要每个一线开发人员投入，只需要投入工程专家或架构师，识别研发过程中的工程问题，统一解决掉，所有一线开发人员都会收益。比如CI流水线上的优化。
Step2，提效工具的推广：必须通过推广某种提效工具才能提效的，比如接口测试工具、编码辅助工具等，通常有2种推广手段，也可以并用：
使用运营等方式推广工具到每一位研发人员手里。
面向团队技术Leader推广工具，并在组织层面上通过数据指标观察或驱动使用情况。
4. 实施效果
一套组合拳下来，再持续观测最初的结果和过程指标，评估提效的结果和收益。对这个Case而言，主要效果如下图所示：
③ 个人级：各角色标准&正确的使用「生产力工具」，顺畅、高效、低成本完成工作
这个实践的目标是面向所有的一线开发人员，提升他们的开发效率。从某种意义上看，这个实践是最基础、也是ROI最高的。如下图所示，当我们带入一线开发的视角，梳理他们的实际工作流，会发现主要影响他们效率的有2类因素：
自动化的环节：比如编译构建、环境部署（如下图所示，绿色的活动），影响点是“触发一次后，多久能跑完”，我们称这个时间为“反馈时间”，优化目标就是尽可能缩短每个自动化环节的反馈时长。
人工的环节：比如写代码、本地调试、代码评审（如下图所示，黄色的活动），影响点是“如果出现返工，就会浪费时间”。优化目标，则是能否让一线开发人员尽量一次性把事情作对，消除多次修正带来的浪费。
因此，对应的实践也是分别从工具和人两方面入手：
工具
工具注入研发最佳实践，让研发活动标准化。
持续优化，缩短单点耗时，降低每个自动化环节的反馈时长。
人：
依托标准研发活动，学习研发指南。
持续提升研发基本功，践行个人级效能提升实践，提升人工活动的生产力，并减少返工次数，消除多次修正带来的浪费。
具体实施过程，由于每家公司的文化不同、工具技术栈不同，优化方式可能存在差异，此处暂时不再下钻更多细节了。
2.3、实践总结
1. 做了什么？
如图所示，依托建设好的效能基础设施（平台、实践、度量），通过4个实践将全公司驱动起来：
公司级驱动：构建字节整体的效能报告，清晰的呈现现状怎么样？和之前比变好了还是变差了？哪些业务线可能有问题需要提升？持续和公司管理层达成共识。
业务线级提效：有强烈诉求或公司关注度高的重要业务线，我们会和业务线负责效能的同学合作，基于业务线的效能痛点，并结合标准化的方案，构建一个适合解决这个业务线问题的实例化方案，并实施。
团队级改进：由于一线技术团队非常多，效能专家人数有限，无法每个团队配置1个，这种时候，工具就起到了作用。我们会通过DevMind提供数据诊断能力，让他们自己体检，并参考标准实践和案例自驱改进。
个人级优化：为每位研发人员提供标准研发指南，并持续优化工具效率，提升个体效率和体验。
2. 如何衡量？
公司整体：会使用统一的效能指标衡量。
各业务线：除了统计业务线的核心指标变化，更多还是关注其工程能力、阶段到了什么程度，落地了多少优秀实践。
3. 带来哪些变化？
如图所示，是字节3年来的核心指标变化。这里大家可能会有点奇怪，主要措施的顺序是不是颠倒了？一般来说，是先做标准化工具，然后是实践，最后是度量。不过字节因为一些现实的情况和困难，我们整个实践过程是倒着做的：
先做了度量，推广并用标准指标驱动各业务线提效。
然后分环节提炼共性的研发最佳实践，和业务线共同做联合治理。在这个过程中，可以看到除了核心指标的提升，各业务线优秀案例开始涌现。研发满意度的主观度量也开始有了基线。
最后配合工具链推行研发全流程标准化，并结合实践与度量两种手段，和各业务线进行更深入的治理，研发满意度、工程效率也开始提升。
这种倒着做的实践，我戏称之为“欧阳锋逆练九阴真经”，虽然没有按套路出牌，但一套组合拳实践下来，效果也是比较让人满意的。
3. 未来与展望除了低头走路，还要仰望星空。这个章节分享一下我们从2024年启动的长期建设的2个方向。
3.1、方向1：平台工程，持续深入建设
方向1是平台工程，终极目标是降低开发者认知负担，提供极致的研发体验。从中长期看，Bits 研发平台的建设，还是需要以“一站式研发平台”的五个层级为标准和方向来演进，才能让现实逐步接近平台工程的终极理想。
在预期效果上，我们会持续观察这3个指标：
标准研发流程占比：统计所有的开发到发布的过程，观察使用标准工具和流程的比例。
变更前置时间：和DORA的标准一样，从合入到发布的平均时间。这个客观指标可以持续衡量和迁移工程能力提升。
研发体系满意度：这是调研一线开发人员的感受获得，可持续衡量平台工程对简化认知、提升使用体验的效果。
3.2、方向2：AI X 研发效能，探索能力与效果的上限
方向2则是AI的探索，我们相信在AI加持下，一线开发的工作效率或者说软件的生产效率会极大提升。因此，工具链从当前平台形态到新形态，会经过3个阶段的演进：
阶段1：Copilot形态，基于当前平台的功能，提供AI功能，为研发过程中某个子任务提供辅助。如图所示，是从24年年初至今，字节已经在当前工具链上建设和公司内推广应用的能力，目前可以基本确认能在单点的效率提升上起到一定作用。
阶段2：Agent形态，可独立完成某一个阶段的研发任务。从结果看，可以以对应的工作任务的自动化完成率来衡量效果。从这个阶段开始，才可以真正说的上是下一代平台。
阶段3：Owner形态（或者叫Agentic），为了区别被“用烂”的Agent概念，我们特意增加了一个概念，这个形态是现今为止能推演出来的AI开发的终极形态“AI工程师”，可以独立完成部分需求从设计到发布的所有过程。
在预期效果上，Copilot形态比较简单，最终结果还是为开发人员节约时间，所以从结果上看，主要度量和观察2个指标：
编码场景：AI代码贡献率，即入库代码中由AI生成并入库的比率。
非编码场景：无论做了多少个AI辅助功能，最终都可以换算成为每个人每天节约的时间，统一观测。
未来，如果Agent、Owner（Agentic）形态出现，预计应该可以度量工作任务完成率、需求完成率，不过目前为止，平台还在建设和试点，因此暂时没有可观测的指标。
3.3、方向1 + 2的思考：“终极”解决方案？
最后提一下我自己非常感兴趣并在持续探索的方向。从效能提升负责人的视角看，效能黄金三角框架也好、平台工程也好、AI工具链也好，说到底，目标和价值无非两个：
个体效率：服务一线开发人员，大幅提升其工作效率和使用体验。
整体效率：服务公司内各业务线，使其研发交付的质量、效率、工程能力持续提升。
目前，业界也好、公司内也好，并不缺乏优秀的垂直产品，但它们都只能服务研发过程的几个环节，因此这些垂直产品和组织级效能提升目标之间总有一道沟壑，所以你不得不自己设计一套合适的解决方案，对上承接效能提升目标，对下把这些垂直产品连起来。如果需要架一座桥，这座桥应该是一个十分厉害的水平产品，它既能兼顾平台工程的极致用户效率和体验，又能为公司内各业务线通过研发标准化持续提效，还能持续演进为AI工具链，进一步提效。
可惜目前为止，达成这些目标的每个手段基本都是单独演进的。要么是分阶段实施，比如今年做标准化，关注整体效率，发现牺牲了个体效率后，明年再补齐用户体验（当然，也有反过来的情况）；要么是独立几个项目组分头作战，比如一个项目做当前工具链，另一个项目做下一代工具链。这就导致了我们常见的2大问题：
建设周期非常长。大部分组织其实没有足够的耐心和资金持续投入，通常几年的时间只能单独达成1-2个目标，还常常按起葫芦起了瓢。
建设成本非常高。这其中有非常多的过程损耗，包括能力的重复建设、工具&产品方案的反复、项目之间的资源抢占、短期和长期的平衡取舍等等。
目前还没有出现一个厉害的产品+解决方案把这些单点连起来，尽可能用一套手段，同时兼顾多个目标的达成。当然，既然今天提出来，这也是我自己在未来1-2年希望探索的方向之一。
4、原理与思考4.1、软件工程的本质和原理
首先，分享一下这套效能提升方法、实践所依据的理念、方法的由来。
很多企业都希望把软件过程类比成工厂流水线生产，因此都会制定精确的流程，并度量每个环节，期望类似丰田精益生产一样的思路来提效。而实际上，虽然软件研发最终交付的是一种信息化的产品，但软件的研发过程本质上是一种复杂手工业，即“知识手工业者”的大规模协作。因此，软件交付过程，存在大量的模糊性、不可见性，既很难观察，也无法精确度量。
困境：每一个最小软件交付团队都面临着各种各样的复杂性，在一个万人级企业中，希望拉动整体性的研发能力提升，等价于服务2000+这样的最小交付团队提升效能，这样的复杂度和难度几乎是一个“不可能完成”的任务。
破局思路：作为负责研发效能提升的基础设施部门，必须把万人级的软件研发组织看做一个整体，精准的找到控制这个整体改善的最关键、最有效的共性机制和措施（杠杆解），才有可能实现ROI最大化的效用（最小投入、最大收益）。这背后需要应用复杂系统控制的基本原理——“负反馈调节控制”：
首先，先假定整个公司是一个复杂系统，一个黑箱，由N个业务线M个软件研发团队组成，即没有人精确理解、设计和控制这个复杂系统。先假定自己“不知道”是很重要的一步。
然后，设置一个控制器，持续向系统重注入能量，再观察系统的反馈，并对比反馈与目标的差距，再次调节这个系统。
如此循环往复，就会让系统逐步逼近目标。
今天分享的研发效能提升实践，在整体上，就是这套控制论思路的具象化。要“控制”一个几万人的组织，我们把效能基础设施当成一个大型的控制系统，再把软件研发交付组织这个复杂系统切分为四层，分层分级实施控制，最终牵引或者说助推这个系统向着效能提升的北极星方向迈进。
4.2、心得：效能提升工作心法
最后，分享一下这么多年来，我自己开展效能工作的心得总结，希望为同样做效能工作的同路人提供一点输入。
我的经验一句话总结叫：用好“三眼”。（注明：“三眼”的说法源于日本流传比较广的一种“成功学”，但我觉得很形象有趣，就借鉴过来了）
“鸟眼”看全局，全面、整体的分析问题
鸟眼一种全局视角。
首先，掌握这个领域的通用解决方案，在理念世界里，了解什么是最好的，才知道我们要往哪里走。
其次，是回到现实，了解我们在当前要治理的公司内的现状是什么样的，再和理念世界对比，找到落差，才能看清所有要解决的问题有哪些。基于理念，再结合实际，才能构建出“接地气”能解决具体问题的解决方案，我们称之为“实例化解决方案”。
比如以字节的案例为例，按正常的理念是应该效能平台优先，在线化到一定程度再启动效能实践、效能度量，实际上整个过程是反过来的。
“鱼眼”看趋势，把握事物走向，顺势而为
有了实例化解决方案就一定能落地了吗？并不是。每个行业的发展阶段不一样，组织每年的导向不一样，技术也在日新月异的变化，这些都会影响这个实例化方案的具体执行顺序。
举一个眼前的例子，都说2023年是“大模型元年”，2024年是“Agent元年”，仿佛做什么事情不加“大模型、Agent”的前缀就不好意思和人家打招呼，于是23年所有的项目名称都变成了“基于大模型的用例生成”、“基于大模型的效能平台”，24年的项目都是“XXX的Agent平台建设”。这背后表现出来的是一个行业趋势，而这个趋势又影响了公司内的组织导向，你做一个项目，如果不匹配公司的导向，就无法获得足够的资源。有时候就是这样现实，没有诗和远方的故事和投入，你可能压根没机会解决眼前的苟且问题。
“虫眼”看细节，贴近地面观察，趴着解决问题
最后就是虫眼，只有实例化的方案、组织的支持也还不够。因为在具体实施的过程中，有着丰富的细节需要了解和解决。比如：
解决一个业务线的效率问题，除了数据体检，还需要去分析大量的具体的Case才能了解这个团队的真实情况，这样才能对症下药。
做一站式研发平台，想优化用户体验，除了看产品数据，还需要去访谈更多的工程师，了解真实的用户路径和感受。往往有时候我们以为他用好了，一观察才发现他的用法和产品设计是完全不一样的。
在落地实施过程中，多运用“虫眼”，贴近地面观察，不怕弄脏衣服，“趴在地上”解决问题，往往才能有实际效果。
5、结语：一幅漫画的思考，与同路人共勉
最后，分享一幅漫画，很多效能领域的同行应该非常熟悉它，我们常用这幅漫画来映射我们这些做效能基础设施的人和业务团队的关系：我们拿着“圆轮子”去“售卖”，但是业务方辛辛苦苦的用着“方轮子”干活，却说没时间来换我们的“圆轮子”。这里我有两个自己的思考，分享给做效能领域的同路人：
从基建建设的角度，我们得首先保证自己提供的“轮子”确实是“圆”的，或者至少比现在那个“方”的要好，不能强卖，这算是我们的职业操守。反之很容易被我们自己的工具反噬，导致口碑崩盘，甚至组织解散，历史上这样的案例比比皆是。
从基建应用的角度，如果轮子确实“圆”但卖出不去，也别过度苛责轮子了。用DevOps圈广为流传的一句话来说：
“People matters...Process doesn't.Process matters...Tool doesn't.”
当你发现一个明显的效率问题，但用工具解决不了，可以往前看看是不是流程有问题，如果流程也解决不了，通常就是人的问题了。每次遇到这种情况，我总能想起《太白金星有点烦》小说里的一句话，“一切不合理的事情背后，都有一个合理的理由，只是你不知道罢了”，这种情况倒也不必强求了，可以把时间和精力放在更有价值的事情上。
6、后记自从2016年“入局”研发效能工作，一直以实践者的姿势不停探索，不敢懈怠，从团队效能治理到工具、度量体系建设，再到公司级的效能提升，AI在效能领域的应用也早在2019年“专有模型时代”就开始尝试，基本上把这个领域涉猎的各方向都摸爬滚打过一遍了。所谓“阳光底下无新鲜事”，对很多行业老前辈、过来人来说，研效领域的这些方法、实践、工具、人和事，近20年来，反反复复兜兜转转，可能早已没什么新鲜感了。但对我个人而言，还是找到了适合自己的2个兴趣点：
更大范围的改变现实：软件工程是技术，更是一门实践的艺术。虽然理论、方法总是完满、光滑的，但在现实中却全是粗糙的地面。每当我“妄图”把这些方法用于现实，希望更大范围的改变现实——让一个复杂系统趋近于理想状态，就必须面对非常多的实际困难。对这些困难的抽丝剥茧的分析、拆解、消除，是非常有趣的。对实践者而言，要改变现实，必须跨越理论和实践之间沟壑，复杂性和不确定性尽在于此，是挑战，也是乐趣。
探索领域的边界和上限：当碰到理论跟现实不一样的时候，对实践者来说，指责理论或现实都没意义，反而会从两者不一样的地方看到机会。如果能弄清楚冲突的根源，再寻求通用的解法，就有机会能从某个角度刺穿领域的上限，为这个行业带来一些新输入。
我定期会把实践过程和结果做体系化的总结、分享，也是出于以上的2个兴趣。
一方面，希望从领域的视角，输入新的实践方法、产品建设思路或具体案例，提供更多的可能性，扩大实践的边界。
另一方面，希望能影响更多同行，让大家探索的方向、思路、方法可以大致相同（当然，具体手段可以百花齐放），以更大范围的影响和改变现实，让这个领域有更多“成功”或者说被认可的有价值的案例出来，减少在错误路径上的低水平重复和失败。
