跌宕起伏的 2022 年已经成为过去时。在这一年，我们既看到外部环境变幻莫测，也看到研发效能行业沉下心来稳步发展，从宏大的概念和价值，转向具体的问题，和务实、可行动的解决方案。
在新一年的开端上回望，2022 年的研发效能行业关键词是什么？行业的先行者们都做了些什么？研发效能建设过程中普遍性的挑战和困难，他们是如何解决的？在 DevData Talks 2022 年最后一场活动，我们邀请到四位行业专家一起来聊聊这些话题。
作为一个在降本增效压力下逐步走向规模化的新兴行业，知识的沉淀和交换至关重要。先行者踩过的坑，走过的弯路，探索出的模式与反模式，积累下来的方法和思考，都是行业最宝贵的财富。
这一场圆桌，我们攒到了这样一套高配阵容——四位嘉宾老师同为研发效能领域的先进实践者，拥有丰富实战经验和深入思考；同时又来自不同背景，在团队中担任不同角色，将为本次对话带来不同视角。
希望本期摘录自 2 小时直播，长达 8000 字的干货回顾，能够为您的 2023 年研发效能规划提供启发。
-
总结：过去一年在研发效能方面都做了什么？
-
效能建设过程中的阻力和挑战
-
以系统思维做度量
-
各领域的具体问题
-
2023年的效能提升展望
扫描二维码关注公众号，回复： 15554550 查看本文章
1总结：过去一年在研发效能方面都做了什么？
应阔浩：四步建设研发数字化，让数据成为研发团队的共同语言
作为互联网领域的从业者，坦诚来说，2022 年很难绕开“寒气”这个关键词。不仅是席卷整个互联网行业的“毕业潮”，很多公司包括我们自如，业务上都受到了一定冲击。
在这种情况下，“技术对业务的价值在哪里？”成为了一个灵魂拷问。研发是企业的成本中心之一，其 OKR 如何与业务挂钩，如何助力增长，尤其是在大环境不景气的情况下，研发团队的工作中心是否调整、如何调整——这些问题需要研发管理者想清、看清、说清。
这也是自如在 2022 年积极推进研发数字化的原因。我们将焦点放在项目管理的一头一尾——需求立项和回顾复盘环节的优化。在改进之前，我们想先了解现状，却发现没有可用的数据。各团队的流程和工具不一致，相当于各说各话。所以我们先做了流程与工具的统一：
- 流程：盘点已有流程，抽象为四个阶段八个评审点的标准化流程
- 工具：自建项目管理平台，沉淀自如的项目管理模型，保障项目、需求、任务全部线上化
在数据的基础上，我们建设度量体系，并把度量用进日常管理中：
- 度量：思路是自上而下，先让各团队 Team Leader 看得懂。我们结合自身需要总结出了结果表、过程表、业务 APP 表三张报表，从交付效率、质量、稳定性多维度来描述研发现状，作为技术团队之间、乃至技术与业务团队之间交流的共同语言
- 度量应用：将周会作为指标通晒的固定节点，对关键指标、异常指标进行讨论
2022 年自如在研发效能方面的主要工作，就是通过以上四步，实现了研发过程数字化、可度量、度量可转化为行动。
茹炳晟：研发效能驶入深水区
过去几年在谈论研发效能的时候，可能更多还是侧重概念，侧重为什么要做。2022 年的主要变化是大家基本认同了“为什么”，开始问“怎么做”；在一些比较先进的团队中，容易解决的显著痛点——所谓“低垂的果实”，已经解决得差不多了。效能建设在今年进入深水区，我们需要去解决一些更隐蔽，可能也更根本的问题。
2022 年我们做的第一件重要事情，是整合工具链，拉通研发全流程，用接近一站式的工具提升开发者体验，让他们专注于编码等更需要创造性的工作，让工具来代替处理重复的流程性事物。
新方向也带来新挑战：虽然工具链的改变会为工程师带来长期价值，但眼下最直接的是工具替换的阵痛。在这方面我们做了很多工作，尽量降低工程师切换工具的门槛。
第二件事情是效能度量指标不再求多求全，而更关注本质上的目标，目标导向以终为始地寻找少量、有用的指标，建立基线，找到影响因子，推动改进并持续追踪验证。
第三件事是对开发者体验的关注，避免以内卷、损害开发者满意度为代价达成团队效能。
张乐：更务实地解决具体问题
2022年，整个科技行业都在关注降本增效，对研发效能的重视程度更高了。从我的实践经验来看，2022 的年度关键词有两个：
第一个关键词是更务实、更聚焦。今年在腾讯，我们将很多精力投入工具平台的建设和跨 BU 的推广，很少高举高打地去提概念或模型。
工具平台整合工具链，茹老师也有提到，这里我再深入讲工具平台的两点能力：自动化能力和分析能力。
自动化，听起来是个缺乏想象力的老名词。但我们去看市面上的很多一体化平台，就能发现研发工具的自动化能力并没有真正实现。首先，很多平台仅仅将不同领域的工具拼接进一个门户里，开发工作流事实上还是不畅通；另一方面，很多研发工具为了保障管理者看到的数据靠谱，内置了很强的流程管控，要求工程师做很多点击和切换的操作，带来额外的工作量。
今年我们也去观察一些行业变化，比如 JIRA 的母公司 Atlassian，在代码、流程管理、CI/CD等等领域都有布局，今年在他们的产品矩阵下加了一个平台层，平台层的几个核心能力中就包括了自动化。具体来说，就是用低代码/无代码的方式实现自动化规则的配置，把跨领域、跨产品的事件和流程提炼出来，比如任务自动派发、子任务自动创建、时间自动更新、状态自动流转、流水线自动触发等等，把事务性工作自动化，解放工程师的精力。看起来平实，但每一天每一位工程师都能用到，累计价值是很大的。
在自动化工具保障了使用体验和数据准确性的基础上，就可以跨领域、跨数据源进行效能分析，了解研发端到端的效率、质量和浪费。
第二个关键词是从不确定性中找到确定性。
举个例子，平台工程这个新概念最近很火，我个人认为平台工程和当前的 DevOps 实践很大程度上还是重合的，比如提倡给工程师提供可复用的自服务能力，改善开发体验和生产力。但这个新概念也带来了一些启发，比如它更强调贴近开发者视角。今年我们在工具平台上新增了一个应用视角，以应用为核心去串联代码、分支、流水线、制品、资源、部署、日志、监控、可观测，满足开发者的实际需要，降低开发者的认知负担。
在度量方面，我们也更聚焦于具体场景，比如价值流分析提升响应效率、代码提交和发布环节的风险检测，而非建立庞大的模型或发起庞大的运动。
未来几年，软件研发行业的技术可能会继续发生变化，新概念会继续出现，但我认为找到有真实需求的用户，用产品化的思路解决实际问题，这一点将是不变的。
任晶磊：度量打通上下游，基础设施开源化
我的总结会结合思码逸研发效能度量产品的演进脉络来说。作为研发效能行业的开拓者之一，思码逸的一些演进思路也能一定程度上反映行业的最新动向，所以也做个总结，看看是否对大家有参考价值。
第一个动作，是深度代码分析数据与其他领域数据的结合。早期思码逸主要围绕深度代码分析来做度量，是因为我们认为代码领域的指标是更贴近研发、更靠谱、更少人为介入的。今年，我们将编码这一环节的度量与上下游打通，例如和需求打通，校准需求颗粒度，使需求指标更可靠；和测试打通，度量 bug 修复的编码工作量。配合着这个动作，思码逸开发了一个负责跨领域、跨数据源进行研发数据汇集治理的平台 Apache DevLake，开源并捐献给了 Apache 基金会。
第二个动作，是在产品中引入 GQM（目标-问题-指标）方法。就和几位老师说的一样，效能度量不能围绕着指标和数据，而必须是目标导向的。我自己也回过头去研究了 GQM 这套由学术界提出，被称为研发度量事实标准的度量构建方法，感到前人的很多经验可以为工业界所用，所以这套方法也正在全面内化到思码逸产品的场景设计中。
第三个动作是降低研发效能度量数据的消费成本。之前我们尝试了很多 BI 工具，但是通用型的 BI 很多时候无法满足研发效能领域的特定需求，例如一些场景化的下探模型与分析模型。我们也正在开发一个专门用于研发效能领域的展示和下探工具，让数据能够真正为研发团队所用。
第四个动作是研发工具链整合，也和前面几位老师的总结相呼应。思码逸发起的另一个开源项目 DevStream 主要是解决这一部分工作。DevStream 捐献给了 CNCF 云原生基金会，目前也是在开发当中。
我们观察到，研发工具的替换的潜在成本还是相当高的，可能许多企业无法承担自研一站式工具，依然要在每个领域分别使用工具，甚至每个业务研发团队习惯使用的工具都不同。那我们希望用一层 DevOps 工具链管理器，围绕应用实现工具间的打通和整合，最低成本提升工程师体验。
2 效能建设过程中的阻力和挑战
任晶磊：刚刚茹老师和应老师都提到建设并推广一款新工具，这个过程中应该会遇到一些阻力，如何应对？
应阔浩：一款新工具的推广成本 = 新工具体验 - 旧工具体验 + 切换成本。那么降低推广成本可以从几方面入手：
第一，从产品视角把新工具打磨好，重点关注 NPS，第一波用户一定要服务好，保证工具口碑。
第二，尽量贴合团队现有实践，避免引入额外的认知负担，平滑迁移到新工具。
第三，关注迁移期两个工具的兼容性，例如两个工具拿出的数据是否可比。
第四，顺势而为，先把前期准备工作做好，例如度量的埋点、北极星指标的选取，争取到关键决策人支持再去大力推动，事半功倍。
茹炳晟：我补充一点找第一波用户的经验。
我们的策略是找业务、技术上有典型性，战略性的项目，保姆式服务让这些试点的业务研发团队用起来——一方面帮助他们实实在在解决问题，真正看到效能提升的效果；另一方面通过业务部门定义真正的需求，发现痛点和堵点，打磨产品，达成双赢。
在试点跑通之后，再产品化、规模化推广，这时候工具经过了一番打磨，有明确的场景，也建设了文档和 chatbot 来支持规模化的运营，就更有底气面向更大范围的用户。同时，如果业务团队还有个性化的需求，我们也欢迎共建，并开放了插件用于二次开发。
任晶磊：都是很鲜活的一手经验。听起来，内部研发工具的建设也很接近于创业初期，要关注 NPS 值、要考虑使用门槛、要找种子用户并保姆式服务。
接下来我们聊一聊开发者体验。茹老师的 2022 年的研发效能实践中有提到开发者体验，如果不展开讨论似乎有回避之嫌。如何让开发者从效能建设中获益，有体验上的提升？实际上这也是许多团队效能建设推不动的原因，过去很多开发者可能把效能直接等同于内卷。
张乐：我也一直在思考，从研发团队的视角，或者说从管理者的视角看来，想要从现有资源中获取更高的产能，这与个人开发者的工作体验必然是冲突和博弈的关系吗？
我个人的答案是，效能度量更多是工具和手段，还是要看目的。宏观上，组织与个人的结果目标是对齐的，理想情况还是组织效能提升，业务发展，个人从中收益；微观上，管理者不应将工程师单纯作为可压榨的资源、被束缚的对象，这肯定是出问题的。
比较合理的思路是，在工程师产能合理的基础上，不要考核工时去硬卷，而是去解决工程师的具体问题，在组织、管理者与工程师之间达成共识。
今年我们的实践也主要在这一块，少提高举高打的问题，多解决切实的痛点，例如使用自动化工具减少事务类工作的手动操作比例。举个具体的例子，近期我们帮助一个团队用工具，实现了跨应用跨地域复杂编排机制的简化，极大提升了团队的生产力。
任晶磊：在张乐老师的基础上补充一点。当前经济下行，低增长已经是新常态，但对软件工程而言却未必是坏时机。
之前热钱多，产品忙着创新，工程侧一般都是先污染后治理，能跑起来再说。现在脚步都慢下来，反而给了工程侧更多的空间和时间，去重视软件工程的健康度和基础设施，不仅是给团队减少浪费，更是给工程师创造更好体验。
3 以系统思维做度量
任晶磊：接下来我们聊聊研发效能度量的系统性建设。茹老师前面有提到几个关键词，目标导向、构建因果回路、持续度量持续验证等等，有没有实践方法或实例可以分享？
茹炳晟：用一个简单的例子来说明。对于紧急业务的功能性开发，有一个常见的研发模式 DDD ——不是 Domain Driven Design，而是 Deadline Driven Development，Deadline 驱动开发。
具体来说就是交付时间定死，功能定死，倒排计划，目的是提高效率快速交付。貌似也能达到目的，但通过系统性思考，就会发现可能不是这么回事：时间少任务重，就只能降低质量；表面质量不降低，只能降低内在质量。
为了按时交付功能，开发者往往会采用战术性编程，不考虑可扩展性、可测试性和维护成本，积累大量技术债。这些技术债会拖累未来的研发效率，一般 6-12 个月，研发速度就会明显下降。团队要保持交付的速度，就更依赖 DDD，形成恶性循环。
那么如何通过度量打破这个恶性循环，牵引团队走到正确轨道上？团队可以分出一部分精力来度量技术债务的相关信号，比如代码重复度、注释覆盖率、测试覆盖率、code change 联动修改，规则改动引发的代码量等等，来减少 DDD 对软件内在质量的侵蚀。用这种系统性的方式去思考，就能站在更高、看得更长远的视角上。在商业模式的变化减速的时候，优秀的软件工程实践带来的可持续发展能力才是组织的核心能力。
张乐：补充一下。前面茹老师提到了因果回路，包括增强回路、调节回路等等，但是要识别因果关系的成本毕竟比较高。在实践中，我们也常常去看数据指标之间的相关性，用于构建各因素的影响回路。
举一个偏微观的例子，如何降低线上缺陷率，提升软件的品质？我们可能觉得之前代码评审做得不够好，那就去看看代码评审改进后，线上缺陷率是否有相应变化。这里不只是看代码评审做没做，更是看代码评审有没有认真做，比如评审反馈的密度是怎样的？给出的评审反馈是言之有物还是走个过场？不断下钻深度，去分析各因素的相关性。
举一个偏宏观的例子，也是应老师前面聊到的，如何说明 IT 指标和业务的影响？虽然业务受很多因素影响，但我们至少可以分析二者的相关性，比如交付吞吐量、响应市场和业务成长速度是否相关？质量内建与用户满意度和客诉率是否相关？
我们在解读度量的时候，实验的思维非常重要。行业已经多次印证了没有 100% 有效的解决方案。要印证某个实践是否确实对你的团队有效，就可以不断提出假设，再通过数据相关性的分析验证假设。
任晶磊：所谓“用系统方式做度量”，也是为了避免为度量而度量、度量之后只看数字，导致动作揍性。这个问题也是许多观众感兴趣的，如何避免效能度量变成追数字的游戏呢？
应阔浩：分三个点来回答这个问题。
首先，只要度量用于管理，就避免不了有些效能存在问题的团队想走捷径、抓住漏洞刷指标。我个人不建议负责工具或效能的团队做无休止的攻防，这是消耗双方的精力。刷数据本质上来说还是价值观的问题，而且都有历史记录可追溯。如果业务研发团队不想在价值观上跑偏，那应该要有一定的自我约束。
其次，管理者要反思一下，是不是图快速见效，把研发效能与绩效考核、晋升奖惩挂钩了？一旦挂钩，就免不了有人铤而走险，既然管理者要考核 bug 率，最简单的方法就是发现 bug 不报，这当然是我们不愿见到的。软件研发毕竟还是知识产业，像传统制造业一样按件计费是非常愚蠢的管理行为，一定要谨慎考虑是否绩效挂钩。
最后，效能度量不是为了与其他团队比个高低，而更多是团队/项目内的纵向对比，看是否有改进。管理的目的是激发善意，研发效能也一样，目的是激励大家的在实践上做出正向改变。
任晶磊：应老师说的第一点我很赞同，追数据这个事情确实无法避免，或者一定程度上也没有必要去避免。即使不是量化的指标，像 OKR 和 KPI，也会出现抓住漏洞博弈的情况。
度量带来的正向改进和追数据就像硬币的两面，可能更多还是要关注如何放大好的一面，而提高另一面的成本，比如在设计效能度量体系时考虑指标间的相互制衡。只要一线研发者最终把大部分精力放在实践改进上，那度量目的就达到了。
茹炳晟：我们之前的书里引用了霍桑效应这个概念——只要度量指标有人看，必然会有被度量者追数据造数据，人性是违背不了的。
我认为避免追数据的关键在于，度量时避免过度强调单点指标，而是使用多维度的、相互制衡的指标矩阵。刻意追某个指标，其他指标就会出卖你。要把指标矩阵搞好，唯一的路径是真正提升研发效能。这样以系统性的设计实现他律，有助于被度量者自然而然地自律。
张乐：效能度量指标体系中，包含结果指标和过程指标。结果指标建议少而精，用于整体方向的引导和驱动，这类指标由于涉及因素较多，博弈成本比较高；过程指标是更容易被博弈的，建议给团队自主权，让团队自己去决定是否使用，减少通晒和考核，而强调过程指标在发现问题、解决问题方面发挥的作用，也能减少追数据的现象发生。
其次就是任老师和茹老师都提到的，要用一组指标来做度量，包括北极星指标、群星指标和围栏指标，避免短视的博弈。
最后还是回到价值观传达这一点上：效能度量不是有限游戏，而是无限游戏。用追数据的方式去玩，后面一定会玩不下去，引导大家更深入地去思考博弈行为的成本。
任晶磊：这里我们追一个来自用户的问题：度量平台的设计是从上向下吗？指标设计是先做过程指标还是先做结果指标，先做哪个比较好？
张乐：我理解肯定从结果指标开始，以终为始去牵引。过程指标的度量，问题的挖掘乃至改进，是为了达成大目标，而大目标是由结果指标来反映的。
结果指标选定后，先让各研发团队了解现状，接着不同团队达成目标的路径可能是不一致的，那各团队再自选过程指标，去发现并解决问题。
这里再呼应下前面已经提到多次的“目标导向”。《谷歌软件工程》这本书里说，如果拿到指标也做不了什么，那干脆就别度量。在做度量前，一定要把目标考虑得非常清晰。
任晶磊：简单补充一下 GQM（目标-问题-指标）方法与谷歌使用的 GSM （方法-信号-指标）方法之间的差别。GQM 方法更强调通过提问层层下钻，建立隐式模型。所以对于研发效能这样影响因素更复杂，可拆解维度更多、团队个性化需求更突出的领域，GQM 方法更加适用。
张乐：确实现在来看，我也认为 GQM 方法更加适合。GQM 中的 Q 问题可以分为两类，一类是描述性问题，是将目标拆解细化的过程，把模糊的想法拆成可度量的几个方面；另一类是探索类问题，是实验摸索解决方案的过程，先假设一系列影响因素，再通过度量去验证假设。总的来说，GQM 中用问题激发思考，能在目标和指标之间搭建一座更坚实的桥梁。
任晶磊：应总的三大表——结果表、过程表、业务 APP 表让人印象深刻，应总可以分享一下这三大表的设计逻辑吗？
应阔浩：我觉得设计逻辑上和 GQM 是殊途同归。自如非常深度地使用 OKR 体系，和 GQM 一样都是目标导向思路下设计出来的。自如对于 OKR 中的目标有几项要求，一要让业务能看懂，二要有明确的现状和目标的对比，三要可度量。
有了明确的目标，我们就考虑如何在实现目标的价值链上，量化研发团队所做的的工作。
首先看研发活动的结果：交付效率、稳定性、质量等多个维度，这是结果表；在结果表里看到异常，再回头看详细过程，让研发团队能自主洞察根本原因，这是过程表；看到产品在用户侧的表现，例如满意度、日活等等，这是业务 APP 表。后期我们还会继续根据研发管理者和一线工程师的需求持续迭代。
4 各领域的具体问题
任晶磊：接下来是一个需求领域的问题：需求的质量如何管理？如何通过数字体现需求质量？
茹炳晟：需求质量是一个比较少被提及，但非常重要的话题。需求质量不佳会导致产品与研发的反复沟通甚至返工，极大影响软件交付的效率和质量。
几个可能影响需求质量的点：需求的格式是否规范？材料是否齐全？需求描述是否能做到半结构化？甚至，需求文档是否篇幅过短？就像我们上面讲的以终为始，团队可以结合自己当前的实际问题，去考虑如何加强规范，或是设置门禁。
任晶磊：我们有一家客户的实践也拿出来和大家分享下。这家客户关注的是目标型需求的质量，也就是那些能和可量化的业务表现挂上钩的需求的质量。需求交付后，追踪需求价值的达成率，再反推这些目标型需求的质量。
张乐：综合一下两位老师所说，事前强调规范性，事中关注需求变更和由此引发的返工，事后关注需求上线后的达成情况，还是一个比较完整的框架。
茹炳晟：这里有个悖论是，研发团队未必关注业务侧的价值？产品团队应该是关注的。
张乐：研发团队有时也会质疑，产品让我做的需求似乎没什么价值？这时候就需要双方有个共识的基础。
应阔浩：是的，我们研发团队盘点过全年需求，研发团队一年完成了 6000+ 需求，其中 1800+ 是无效的伪需求，包括没有上线和日活非常少的功能。产品有时候也不知道自己要什么。
所以落到实践改进上，一是规范化，自如沉淀了“需求一张纸”这样的简化实践，要求产品方明确回答问题：用户是谁？场景是什么？痛点是什么？期望达成什么样的功能？需要什么资源？二是我也鼓励产品经理和研发工程师质疑对方，把问题聊清楚，从业务到产品再到研发，各方都对最终交付的价值负责。
任晶磊：下一个问题是质量维度的：软件质量体系如何构建？质量内建开展思路？创业团队在追求质效合一的道路上，质量度量应该怎么做？
茹炳晟：如果是初创团队，质量度量有点多余了，当务之急还是活下来，证明产品的市场需求和商业模式成立，这个阶段用战术性编程是没问题的。
那欠了大量的技术债，质量内建完全没做怎么办呢？在一定的时间节点，一般在 6-12 个月内，直接推翻重写一个有内建质量、技术债可控的版本。一旦到这个阶段，就需要对质量进行度量和控制了，严格控制技术债增量。即使有些紧急情况下软件带病上线，也要在最多四个迭代内把技术债还上。
任晶磊：再补充一点。在创业公司的语境下，可能开发人力有限，那就要对 bug 高发或 bug 修复成本高、耗时长的风险模块有认知，把更多时间精力投入到这些薄弱环节中，更加精益地实现质量内建。
5 2023年的效能提升展望
张乐：去年提了一个简单的模型“研发效能黄金三角”，分别是效能实践、效能平台和效能度量。2023 年的主要目标是在公司里持续推动，让这个三角加速转动，更加自洽。
具体来说，实践方面会继续向价值端到端流动的去改进，在业务与产研效能融合方面做更多探索；平台方面除了推进比较朴实的自动化，也会探索一些智能化的应用，例如智能搜索、AI辅助编程、智能精准测试、智能运维等等；度量方面，GQM 方法还是值得进一步挖掘，去发现更多能解决具体问题且成本可控的有效场景，以及效能自动洞察乃至智能推演也是值得关注的方向。
茹炳晟：今天提到了很多次，业界已经验证了没有 100% 适用的方案，大厂在用的方案未必适合。所以 2023 年的关键，还是回到自身的具体问题，脚踏实地，务实地解决问题，既要自上而下对齐效能实践的目标，也要自下而上去优化一些基本的实践规范。
过去几年我们可以看到，在降本增效的带动下，大厂对于研发效能的重视度是上升的，也扩招了很多相关岗位。然而一是低垂的果实已经摘得差不多，二是研发团队的规模可能短期内不会有太大变化，那么效能方面是否有持续投入，其实是有疑问的。2023 年研发效能团队需要更加结果导向，实实在在给业务研发团队创造价值。
应阔浩：2023 年我有三个关键目标：第一，微服务关停并转做减法，控制技术债务，度量关键少数；第二，现有实践更聚焦更落地更细致，提高NPS，在更大范围内把工具和度量用起来，真正帮到一线研发团队；第三，面向业务赋能，考虑建设直接驱动业务的平台。
任晶磊：使 GQM 等基本能力更加普适化，降低研效度量工具的使用门槛，让更多用户以更低成本感知研发效能度量带来的价值。
️
完整视频
DevData Talks 【研发效能】年终答疑
『关于DevData Talks』
DevData Talks 是一个开放分享研发效能实践经验与方法论的系列栏目。
我们会邀请行业专家分享研发效能提升、数字化管理等相关先进实践与深入思考，持续沉淀优质干货内容。与伙伴们共同探讨研发效能领域的实践与思考，一起交流、学习、成长。
独行者速，众行者远。