从效能公式解构研发效能

Posted 2022-12-30 阿里云云栖号

这几年，云原生、Web3.0、元宇宙等技术的出现和应用，正在深刻地改变着我们这个世界。以数字技术应用为主线的数字化转型是此次人类文明变革的核心动力。在这一变革过程中，软件研发模式的发展起到了重至关重要的作用。从早期瀑布式、精益敏捷、DevOps，再到BizDevOps，其实背后一直在解决的是效能的问题。

效能公式

我们常常聊效能，但研发效能对于不同的人来说，有着不同的定义。对于处在研发一线的个人来说，效能就是提升自己的工作效率，提升工作的幸福感；而对于企业经营者来说，效能就是在不确定性的环境下，确定性地获得最大的商业成功。

因此，提升效能，就是让每个人能够高效、专注的工作，工作更有成就感；提升效能，就是让一群人干成一件值得骄傲的事。

我们之前定义过，研发效能就是组织持续、顺畅、高质量交付有效价值的能力。从提升效能的角度，研发效能就是提升个体和协同效率，最大化价值。将这个三个变量组合在一起，形成的效能公式就是：

个体效率 x 协同效率 x 价值 = 研发效能

个体效率

对于个人而言，个人的工作效率其实是最影响幸福感的。事情做不好，很大部分原因是，事情理不清、理不顺。老师通过看一个学生的课桌和书包，基本就可以判断这个学生的学习成绩好不好了。桌面干不干净、书本整不整齐、教材和教辅分类是否清楚、考卷有没有分门别类整理等，这些都直接影响着学习的效率。所谓“学霸两支笔，学渣文具多”，如果绝大多数时间和专注力花在找书本找文具上，学习自然是好不了的。

另一个影响的效率的重要因素，是那些高频且低效或易于出错的工作。简单重复性强的工作，引入自动化的手段就可以解决。高危操作，出错和返工的成本都极高。将这些问题，交给工具来完成，可以极大地减少由于人为操作导致的问题。

所以，我们希望在日常工作中，事情能够有条理的按部就班，要的东西找得到，看得见。重复繁琐的事情，让工具代替手工，更轻松地做，省心、安心、放心。我简单总结，就是三个关键词：找得到、看得见、轻松做。

今年，云效分别升级了全站搜索、个人工作台、代码合并、智能测试和应用发布等能力，旨在让：

零散信息找得到：通过个人工作台，我们可以将自己关心的工作内容展现在一个页里，“我的项目、我的任务、我的提交、我的发布”，个人工作台就是自己的专属线上办公桌。像整理自己桌面一样整理好自己的工作台，让任务轻松触达；同时，通过全站搜索能力，无论是需求、任务、缺陷、代码、应用、变更等等，都能通过 CMD + K 找到。

任务、进度看得见：每个人对自己关心的任务、关心的进展，都能轻松地看见。就像观测地铁到站表一样，非常清晰地知道当前任务经过了哪些阶段，当前处在什么阶段，到结束，还需完成哪些阶段。

代码提交轻松合：开发者有大量的代码合并和评审的场景，通过辅于自动化的检测能力，帮助开发者在代码合并的时候，轻松判断合并条件，有针对性地进行评审，放心轻松地合并代码。让代码合并省心。

回归测试轻松测：测试工作在软件研发过程中，承担着非常重要的质量守护工作，测试工作从写case、准备环境、准备数据...，琐碎而重复，对于这样的工作，我们建议这样的工作交给工具来做，云效除了接口测试、UI测试这些传统的测试工具之外，推出智能流量回放测试。采用智能流量回放测试，可以自动生成测试用例，自动生成测试数据，自动Mock，大幅节省回归测试的成本。让质量内建安心。

应用上线轻松发：软件的发布在云研发时代是一个高频操作，同时也是高危操作。云效应用发布平台AppStack，推出面向云原生的应用发布能力，将资源、流程和工具以应用为核心组织在一起，从应用的创建、代码变更、部署发布整个流程固化下来，减少过程中由于人为操作不当而引起一系列问题。同时，部署是最后的临门一脚，辅于发布过程中的可观测能力和部署模式的支持，有效降低发布过程中的风险，应用的发布上线不再熬夜加班。让应用发布放心。

只要善于发现，可提升、改进的机会还有很多。不要低估持续不懈地优化和改变，进步的力量，始于每一点微小的改变。

协同效率

如果说个体效率的提升，影响的是工作幸福感的话，那么协同效率的提升反映的就是组织的成熟度和活力。

软件研发是典型的集体性创造活动。人多了，就会有分工，分工有很多好处，亚当·斯密最早提出了分工理论，通过比较优势，分工可以提高效率。但随着组织的发展，职能分工带来最直接的问题就是：效率竖井。

关于效率竖井，我们以前讲过很多次。不同的职能分工，职能间的关注点不同，优先级不一致，经常出现扯皮的现象。同时，在整个交付过程中，出现阻塞、等待、返工的情况。彼此沟通过程中，概念不一致，鸡同鸭讲，聊不到一块儿。这样的后果是，每个团队看上去，繁忙而高效，而整体却效率低下。

协同的目标，就是让一群人确定性地共同完成一件大事。整个协同应该是一条通路，通是关键。在DevOps中，打破Dev和Ops的墙是为了通，在BizDevOps中，打通Biz和DevOps的墙，也是为了通。这里我把它归纳为两个关键词：连接和透明

通过一个需求，与应用的变更建立关联，通过一个需求，与代码合并请求建立关联。双向互联互通，基于统一的数据模型，将这些核心作业对象关联起来，形成一张价值网，这样就建立起来了从协作到工程的完整链路。

连接的意义，远大于在研发流程中，将工具简单的拼装在一起。有了核心工作对象的关联，就像接通了整个研发协同系统的血液循环，活了过来，整个系统也就具有了生命力。

连接建立了基础，透明化就不再话下。这样，整体的工作进展，从需求、代码、发布完全打通，工作进展更准确、透明。迭代进展能够及时、准确地看到；工作安排是否合理，通过工作负载也能展露无疑。

有了连接做为基础，数据在各环节就能共享，任务和进展可以轻松看得见，效能现状也能轻松看得见。

一群人，安排了哪些活、在哪一天，工作量是否过大等等。对于管理者而言，效能现状也能做到胸有成竹，团队效能有没有“病”，要不要“吃药”，有了数据的支撑，就能做到对症下药了。

同时，通过关系和信息的配置，将流程固化在工具上。让过程管理不再局限于纸面文章，而是可运行、可重复、可推广。

然而，无论是提升个体效率，还是协同效率。在软件研发工作中最大的问题，其实是机会的浪费。

价值

选择比努力重要。资源这么多，只能选择最有价值的事情来干。如果说连接是血液循环系统的话，那么价值就是这个系统支撑的魂。但实际的工作中，往往容易丢了“魂”。丢了“魂”的工作是怎么样的呢？

是工作说不清楚价值；是需求很多，但不知道哪个更重要；是我的工作和老板关心的工作不一致；是需求层层分解、任任层层转交，导致信息严重失实。

人就那么多，时间也很有限，选择一件对的事情，并且做好分解和传递很重要。所以，我认为做好价值最大化的两个关键因素是：选择和传递。

关于选择，收益和成本是最简单的两个变量，通过收益除于成本就可以简单得到一个基础投资收益得分，基于此做为选择需求的参考。

一定会有朋友说，价值模型有很多，单纯靠这两个变量是否过于简单。其实，从本质上讲，无论多么复杂的价值模型，背后的底层逻辑都是收益和成本。有了这两个简单的变量，争论便有了基础，而不是看谁嗓门大、关系亲疏、职级高低来决定做哪个需求。这就很有意义，让价值的争论发生在越早越好。

同时，有了评估选择的基础，我们就可以做到：以终为始（在开始的时候，就以最终想达成的结果来进行评判选择）和量出而入（在排入需求的时候，就以输出的时候为标准，无论是质，还是量）。

从收到一个前线的原始需求，转化为一个产品主题，再逐层分解，直到开发任务，这是整个价值传递的过程。研发的整个流程，其实就是价值流，价值流上的各环节是增值活动。这样，整个价值链上的每个事情都是有价值的，每个事情也都能说明价值。

同时，对于业务、产品或技术来说，用一套话语体系说话。从原始输入，到产品需求，再到技术任务，云效通过关联所有的核心对象，让事事有着落，件件能溯源。

写到最后

通过让事情找得到、看得见、轻松做，提升工作的幸福感，提升个体效率。通过连接和透明化，建立彼此协作的桥梁和信任，提升协同效率。通过价值有效选择和传递，最大化价值。整体共同作用，提升研发效能。

基于这个逻辑，让我们从面向流程到面向价值进化，从提升效率到提升效能进化。当然，云效也无法兼顾到研发活动的方方面面，我们愿意和我们的伙伴和用户一起努力，做一点点改变。进化，其实就是每一点点进步。

感谢我的同事们努力的工作，让进步一点点发生。最后，欢迎大家对我们的产品提出更多的想法和建议。

原文链接

本文为阿里云原创内容，未经允许不得转载。