研发效能提升最佳实践的探索

小小鲁班

现代的软件行业已经不再是以前“大鱼吃小鱼“的时代了，而是转变成了”快鱼吃慢鱼“的时代。对于很多大型传统软件企业，原本“大“是其优势，现在却陷入了”大船难掉头“的尴尬。对于大量小而美的互联网软件项目，当创意和细分领域被确认之后，各大友商比拼的就是研发能力，具体来讲就是从需求转化成软件或者服务的能力，这其中研发效能的高低对于需求转化速率起到了至关重要的作用。同时，如何有效降低研发和运维的成本也是研发效能需要关注的重要课题，尤其是大型互联网项目，当某个环节哪怕只有少量优化的时候，由于其规模效应（比如集群规模，用户流量等）的放大作用，最终节省的成本也会是相当可观的。

和敏捷的概念类似，到底什么是研发效能其实很难精确定义。其实很多复杂概念不是定义出来的，而是逐步演化出来的，是先有现象再找到合适的表述。要理解这类复杂的概念，最好的方法是理清发展脉络，回到历史中，回到诞生的时间，漫步一遍它的发展历程，才能真正理解其本质。但是由于时间关系，本次演讲我们没有足够的时间带着大家重走一遍历史，所以我准备先通过几个案例让大家能够先直观的感受一下“研发效能提升之美“。

先来看第一个例子，很多时候我们在做产品原型设计的时候都需要借助产品原型工具来实现产品GUI界面的设计，以此作为沟通的基础去开展后续的工作。但是你会发现即使已经有了类似Axure和Modao等原型工具，但是“画界面“的成本依然很高。这里介绍一种可以将图片GUI设计稿，甚至是手画GUI设计稿转化成目标平台代码的一键自动化生成方案。

在上面的例子中，先手绘GUI界面设计，然后通过Sketch2Code可以直接转换成目标平台的代码，如果你指定的目标平台是Web，那就直接生成html，如果你指定的目标平台是iOS，那就会生成XCode的项目，通过编译打包后就可以直接在iPhone上安装执行了。这种方式的引入将大幅提升原型构建环节的效率。

再来看第二例子。API接口测试过程中，输入参数临界值没有妥善处理的问题很常见，比如某个输入参数是String类型，但是代码实现中没有考虑String变量取值为NULL等情况。这类问题通常都会在后期API集成测试或者联调阶段才会集中被发现，此时发现再去修复的成本通常都会比较高，而且修复之后还要考虑回归测试的成本。所以我们可以引入一种机制，去主动扫描获取API输入参数的类型，然后根据参数类型生成容易出错的取值，用这些取值自动调用API，如果发生500错误或者抛异常就是发现了问题。（比如，对于String类型的输入参数就可以生成NULL，超长的字符串，包含非英语字符的字符串，SQL注入字符串等等。）进一步我们可以把这个方案和CI流水线集成，在CI执行过程中主动执行此类测试，以求问题更早地被暴露。

上面两个例子都是由技术主导的。接下来的例子就和技术没有太大关系了，而是由流程主导的。上面图中厨师做三明治，左边图中由于各个食材摆放没有特定的顺序，造成厨师必须不断来回走动才能完成任务，而右边图中食材按使用顺序摆放，厨师可以站在原地轻松完成三明治的制作，大大节省了不必要的走动时间，从而大幅度提升了效率。由此可见，效率的提升既可以由技术来驱动，也可以由流程来驱动。

看完了上面的例子，我想你已经对研发效能提升有了一个非常感性的认识了。接下来，我们来看一下研发效能的本质。如果要用一句话来总结研发效能的话，我会用“顺畅、高质量地持续交付有效价值的闭环“。解释一下其中几个关键概念：

• 顺畅：价值的流动过程必须顺畅，没有阻碍
• 高质量：如果质量不行，流动越快，死的也会越快
• 持续：不能时断时续，小步快跑才是正道，不要憋大招
• 有效价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。（关于本质问题我想多说一句，女生减肥不是本质问题，女生爱美才是，可以自己体会一下。）
• 闭环：强调快速反馈的重要性
  * A9 `& |& r6 d4 }

在这个概念的引导下，我觉得五个持续（持续开发，持续集成，持续测试，持续交付和持续运维）是这个概念能够落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。

理想情况下更多的时间占比应该放在“未雨绸缪象限“，少量的时间用于“救火象限“。

“未雨绸缪象限“做好了，“救火象限“事件的概率会变小。如果一个公司大部分时间在救火，通常说明这两个象限的时间分配失衡或者倒挂了，需要关注投资那些长期重要但不紧迫的事情。

对于软件研发而言，“未雨绸缪象限“中最重要的一环就是研发效能。

最后用一个更形象的例子做个比喻，相信大家都听过鹅生金蛋的故事。是不是鹅生的金蛋越多，效能就越高呢？其实不是，一味地让鹅全日午休地生金蛋早晚会把鹅累死，这不是可持续的长远战略。真正的效能应该是让鹅生鹅，鹅再生鹅，让更多的鹅一起来下金蛋。

腾讯TEG内部快速发展中的智研平台，阿里已经走向产品化的云效平台，百度基于工程效能白皮书来落地的效率云等等都是研发效能领域的标杆，可是你有没有想过，为什么最近几年各大行业龙头企业都纷纷开始在研发效能领域发力，而且步调如此一致，我认为背后的原因有以下这么三点：

• 就像“中台“概念一样，现在很多大企业的产品线非常广，其中存在大量重复的轮子，如果我们关注业务上的重复轮子，那么就是业务中台；如果我们关注数据建设上的重复轮子，那么就是数据中台；如果我们关注研发效能建设上的重复轮子，那就是研效平台，其实研效平台在某种程度上也可以称之为”研发效能中台“，其目标是实现企业级夸产品夸项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0到1“，没人有精力去关注更有价值的”1到n“。现在的研效平台会统一来打造组织级别通用研发能力的最佳实践平台。
• 从商业视角来看，现在toC产品已经趋向饱和，过去大量闲置时间等待被APP填满的红利时代已经一去不复返了，以前业务发展极快，那么用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是最佳选择，那个时代关心的是软件产品输出，研发的效率都可以用钱填上。而现在toC已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。
• 从组织架构层面看，很有企业都存在“谷仓困局“，就像上面第二张图展示的，研发各个环节内部可能已经做了优化，但是光环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能试图解决的一大类问题。
  

最后一点大家都容易理解“做自己研效平台的第一个用户“，研效平台本身的研发必须通过自己的平台走，这样才能站在用户的角度看待自己的方案，才能和业务线用户”共情“。

0 o5 S4 O4 L' S6 r: [8 W: k5 S2 P

大小的小

做自己研效平台的第一个用户