张乐：研发效能的黄金三角及需求与敏捷协作领域的实践｜直播回顾

7 月 27 日，ONES 研发管理大师课第一期课程正式开课啦。本期邀请的大咖讲师是腾讯 DevOps 与研发效能资深技术专家张乐老师，分享主题为《研发效能的黄金三角及需求与敏捷协作领域的实践》。通过「黄金三角」这一框架，探讨研发效能的重要性和关键要素，助力企业实现效能提升。

以下是张乐老师当天分享的主要内容。

研发效能需关注效率性和有效性

现如今，互联网、软件、数字化等企业发展势头迅猛，但是研发效能问题往往被忽略。在企业规模化和复杂度不断提升的情况下，研发效能如何保持较高水准、助力企业提效，是该议题核心要解答的问题。

效能的目标是什么？基于业务目标，我们一般会规划两个元素——理想的功能和质量、理想的工作量。同时，有理想就有现实，所以也就会有实际的功能和质量、实际的工作量。通常，在理想和现实之间会客观存在一定的 Gap，这就出现了「效率」和「有效性」上的差距。所以，研发效能既要关注投入，也要关注产出；既要关注效率，也要关注有效性。

研发效能，一句话，就是更高效、更高质量、更可靠、可持续地交付更优的业务价值。高效指的是效率的维度，高质量和可靠指的是有效性的维度，在此基础之上我们还要关注可持续性，能够持续为业务的成功赋能。

研发效能的「黄金三角」

目标我们确定了，接下来要如何落地呢？在调研了国内外多家公司后，我发现他们无外乎都在关注研发效能的这三个维度：效能平台、效能实践和效能度量。因此，我把这三部分整理成一个模型，并把它称为研发效能的「黄金三角」。

先简单解释一下它们三者的关系：效能实践有管理实践、工程技术实践、组织实践等，我们需要把这些实践提炼出来，并沉淀到效能平台上；反过来，效能平台去承接实践的落地和规模化；同时，我们需要通过效能度量去洞察研发过程中产生的数据，基于度量的结果找到瓶颈，再去进一步优化效能实践和效能平台。所以，这三者之间构成了可以彼此强化、持续迭代的增强回路，是有机整合的共同体，我把它成为研发效能的「黄金三角」。当然，只有这个高阶模型还不够，我们来看看具体如何落地吧。

「黄金三角」第一角——效能实践。它由四个部分组成：构想阶段、研发阶段、发布阶段、运维阶段。构想阶段是在进行产品探索并形成相对明确的需求的阶段；研发阶段要以产品为导向，并不是以项目为导向去开展研发工作；随后是追求工程卓越的部署和发布阶段，以及以应用为中心的运维阶段。

接下来，我们来看看这四个阶段分别对应的实践地图：

• 构想阶段：产品规划、影响地图、需求结构等

• 研发阶段：敏捷协作、分支模式、持续交付等

• 发布阶段：环境治理、发布策略、线上实验等

• 运维阶段：云原生基础设施、混沌工程、监控和可观测性等

实际上，研发活动又可以分成两个不同的部分——前半部分以研发活动中独一无二的创造性活动为主，包括需求分析、设计和编码等，特点是具有高度的不确定性，需要持续地探索和实验，这是敏捷实践的作用域；而从代码提交后，就会逐步流转到已知的、确定性强的活动中去，特点是可以多次重复运行、有优秀实践的、可以自动化的过程，这是精益实践、工程和技术实践的作用域。所以，当在谈论研发过程到底要不要工业化和标准化的时候，实际上应该分成这两个不同的部分去探讨。软件是精益流水线上，敏捷制造出来的产品。

「黄金三角」第二角——效能平台。效能平台是什么呢？很多企业都说我们需要一个一站式的 DevOps 平台，工程师们不用进入多个入口，全在一个平台可以完成需求管理、代码管理、流水线、部署发布、监控日志的管理等。但事实上，在很多所谓的「一站式平台」里，会出现一个问题：所有功能都有，但平台是拼凑起来的，工程师用起来并不顺手。追究其根本原因是，它没有按照具体的场景去组织，缺乏研发活动的主线。就像我经常说的，产品要有灵魂，而研发效能平台成功的关键就是要用研发场景作为主线去贯穿功能和逻辑。

基于此，我绘制了一张图。第一条主线是「以特性流动为核心的敏捷协作」——把需求特性的流动作为整体驱动力，拉动跨职能团队（前端、后端、测试、运维）去沟通、去对齐、去协作；第二条主线是「以变更为主线的交付流」——承接需求的落地实现，还得创建特性分支、写代码、测试、部署上线等等。这里变更的是应用发布的最小单位，将其作为主线贯穿研发生命周期的一些列工程活动的，落地形式可以是我们常说的「流水线」；第三条主线是「以应用为中心的运维」——结合云原生时代的主流模型，把所需的基础设施以及组件的关联模型建立起来，以应用的生命周期去对齐，这样才能更好地完成后面的部署和运维自动化，保障系统的稳定性。

「一站式平台」的其中一个优势就是让研发全链路的活动和信息能够互联互通。比如在上线的发布单里面，可以关联很多信息，需求是什么、代码提交有哪些、有没有经过测试、能否构建关联版本、部署到的哪个环境等等，这些信息都会对齐，且都是透明的；另一个优势是状态联动。比如说，我们在需求关联分支的时候，就把需求变成开发中状态；在发起测试或发布的时候，就把需求变成待测试或待发布的状态，做到互联互通和自动联动。

「黄金三角」第三角——效能度量。在研发过程中产生很多数据，我们可以把它拿来评估、分析、改进，助力企业提升研发效能，这就是做效能度量的必要性。我将效能度量分为五项精进，分别是：度量基础设施、度量指标体系、洞察分析模型、度量产品建设、数据驱动和实验思维。

我们先来简单看看度量指标的 Cube 模型，我把它称为效能度量指标体系的「魔方」。它不是一个平面，而是立体的，大家可以在下图中将「业务价值」往上提，能看出来它其实是个立方体，它有「结果面」和「过程面」。从「结果面」需要考虑的，分别是效率、质量、成本和价值，可以概括为我们经常说的「多、快、好、省」。这里面有很多结果的指标，比如说需求交付周期、需求吞吐量、线上缺陷密度等等。为了达成这个指标，我们还有很多过程性的工作要做，所有也要看「过程面」，比如协作能力、工程能力、技术能力和组织能力的提升。所以，我们要基于结果指标做整体的评估和驱动，通过过程指标的细化和分析，去驱动具体的改进活动。

此外，效能度量中还有很多模型需要理解。比如价值流分析的五大流动指标，分别是流动效率、流动速率、流动时间、流动负载和流动分布。综合利用好这五个指标，就可以去讲述一个关于研发价值流的完整故事，回答关于交付效率的本质问题。

需求与敏捷协作领域的六大实践

软件研发里最重要且最难的事情，就是精确地知道到底要做什么。如何让需求更靠谱、如何更有效地组织需求、如何实现跨角色的高效敏捷协作等等问题应接不暇，让很多工程师头疼。因此，为了以终为始地提升有效性，我们提出了需求与敏捷协作领域的六大实践。

先来看看六大实践的流转过程：首先，通过「产品三步法」做出合理、适当的产品规划；有了规划之后，可以用影响地图的方式把业务目标和产品功能对应起来；接着，再用故事地图构建需求的全景，避免对局部的过度关注丧失了对需求的全局理解。紧接着，将需求逐层分解，让它不断往下传递，基于各自的研发工作流高效地分工协作。最后，用实例化需求的实践将需求有效澄清，给研发提供高质量的输入，最终进入到敏捷协作中去。

我们来详细解读一下这六个实践方式：

第一，产品规划。我们要锚定产品目标、判断需求价值以及制定路线图。如何衡量一个需求的价值？这里有两大要素，一个是业务价值，它跟收入和成本相关，分为增加收入、保护收入、规避损失和降低成本增加收入这几个维度；另一个要素是开发过程中发现的信息价值，这可以降低开发中未来的特性风险，带来新的商业机会。

第二，影响地图。我们让业务目标对应到具体的功能上去，可以使用影响地图的方法。其实可以理解为这四个单词——Why（什么是需要实现或达到的业务目标）、Who（哪些角色会影响到业务目标的达成）、How（如何通过这些角色达成业务目标产生影响）和 What（需要做些什么实现这些影响）。

第三，用户故事。它帮助我们构建需求全景地图。需求拆分容易带来「只见树木、不见森林」的问题，用户故事地图就是一种在需求拆分过程中仍然让人保持清晰的需求全景方法。打个比方，用软件打车，乘客要先叫车，司机才能接单；接单之后，司机才能前往出发地，行程结束之后才能评价……所以，任何一个功能如果不放在对应的场景里去看，它都是孤立的，找不到前后因果，就无法确定版本规划和优先级。

第四，需求结构。需求的传递并不是一个需求条目或者一个用户故事那么简单，它需要有不同的考虑层次和拆分逻辑，我们一般分成三层：业务需求层、产品需求层和技术实现层。业务需求承载的是业务价值，一般由业务人员去负责收集、创建和维护，关注的核心是怎么去接收、规划和实现这个需求；产品需求层承载的是产品的具体功能，是产品集成和测试的基本单位，一般是产品经理关注的层面；技术实现层基本就是前端和后端任务，是工程师角色较为关注的。

第五，实例化需求。用实例说明需求，是精益和敏捷开发的基础需求实践，它帮助团队分析、澄清、拆分和沟通需求，为开发活动提供高质量的输入。核心有三个步骤——第一步：确定目标，描述背景，澄清用户问题和业务目标 ；第二步：列出用户操作及步骤；第三步：澄清业务规则，用实例的形式表达场景和业务规则。

第六，敏捷协作模式——Scrum 和 Kanban。很多团队都听说过 Scrum，但真正做好的也并不容易。2020 年，「Scrum 指南」引入了「Product goal」概念，跟刚刚我们讲的产品规划、目标导向是一个意思。做一个产品，首先总目标要清楚，当然每一个 sprint 的目标也要清晰。另外要注意，在 Scrum 模式中，「自管理」也很重要。很多人以为「自组织」就是无组织、无纪律，其实 Scrum 的自管理是要围绕产品目标全流程参与，保证它能够顺畅运作。

除此以外，我们还有 Kanban 模式。它是精益在软件研发过程中的应用，有很多原则，比如工作可视化、管理流动、显示化流程规则、协作式改进等。今天先不细讲，在后面的第二期、第三期课程里面会再详细讲解 Scrum 和 Kanban 的场景案例。

效能的实施路径、模式与反模式

最后，我们来讲讲怎么样去组织一个良好的组织结构，这其中有四种关键的团队。第一种是业务团队，他们是业务研发，对结果全权负责，首要的目标就是实现业务需求。业务团队需要时刻记住：「我们为什么出发？」也就是一定要明确自己的痛点。如果痛点是要更快地交付，那么需要主动承担一些技术债务；如果痛点是要提升稳定性，比如需要高并发的在线支付业务，质量是第一位，对于效率，正常发挥就好。因此，我们一定要基于目标出发，以终为始。

第二种团队是工具团队，例如 DevOps 平台、效能平台要做的就是提供高质高效的服务。这个团队的人要有两点考虑。第一，你服务的最大群体是工程师，应该给工程师最好的支持度；第二，所谓的一站式平台，一定是按照研发场景去组织的。就像我刚才提到的，以特性为核心的敏捷协作、以变更为主线的交付流、以应用为中心的运维。那有什么常见的反模式呢？它的反模式就是「强推工具平台」，逼着大家通过行政命令去上工具，强加给用户某一种特定的研发模式，这是不可取的。

第三种团队是效能专家或是敏捷教练。它通过一系列方法和实践导入和落地，形成合力，让研发效能实践不断去推广和落地。同时，他们会把成功案例和效能提升经验整理为效能提升知识库。

第四种团队是组织级管理团队。他们主要职责是去从整体上推进研效重大事项，制定公司统一的代码规范、推广公司统一的编码风格、普及代码质量意识、推广代码文化等等。但是，我们不要一刀切地盲目推崇一致性，不要过度控制。

最后，送给大家一句话：「不躺平、不内卷、行稳致远」。真正让效能提升，让好的理念、好的方法、好的技术深入到日常研发工作中，帮助我们变得更高效，也让我们的生活更好。

ONES 研发管理大师课第一季课程还在继续，「精益敏捷组合管理如何提升效能」「大型软件团队高效协作的方法与实践」等课程即将上线。

关注 ONES 视频号，更多直播即将来袭！