不是标题党，只是敢于说真话，说出许多人想说而不敢说的话。为何会有这样的结论，请听我慢慢道来。不过，文中说的现象，只是存在于某些公司中，不是每个公司都有的现象，也不要对号入座。

        ● 研发效能最近几年的确比较热，各个大厂先后成立工程效能团队或部门，开发了一些效能平台，推出白皮书或举办效能峰会等，例如：2014年百度公司成立工程效率部，2019年和平台测试部合并成立工程效能部

        ● 2015 年滴滴工程效能团队成立，构建项目管理、代码管理、持续交付、效果验证等多个平台。

        ● 2015年 腾讯一站式软件研发管理平台—CODING上线

        ● 2015年底，阿里巴巴全面启动集团中台战略

        ● 2016年12月 华为云DevCloud（一站式云端 DevOps 平台）发布

        ● 2017年发布《百度工程师手册》

        ● 2017年6月首届阿里研发效能峰会召开

        ● 2018年10月发布《百度工程能力白皮书》 

        ● 2019 年 5 月,百度推出百度效率云（前身是内部工具链），包含三大平台——iCafe, iCode, iPipe

        ● 2020年9月 首届QECon（全球软件质量与效能大会）在上海成功举办

        ● 2021年5月 相聚鹏城、论道质效：QECon大会深圳站圆满落幕

        即使“研发效能” 这么红火，但不少人对“研发效能”还是有误解，最近还看到一个采访，被采访的专家说 “研发效能是指单位时间产出量”，将“效能”和“效率” 搞混了。

研发效能

究竟什么是研发效能？

        其实，研发效能不等于研发效率。效率是指单位时间产出量，英文常用Efficiency，相当于生产力（Productivity），即效率 = 产出/所用的时间。而效能是指对业务有实际价值的效果、成效，更强调有效性、效益，英文常用Effectiveness，效能 = 有价值的产出/所用的时间，效能公式的分子是效率公式分子中有价值的一部分——有效的成果。

        简单地从软件研发来看，效能= 对客户有价值的需求 + 效率 ，在需求有效的情况下，效率越高，效能越高；效率/生产力不变，需求对客户的价值越高，开发效能就越高。

        如果考虑到商业环境变化比较快，还需要考虑研发是否有能力适应环境的变化能与时俱进，保持稳定的、有价值的交付，即我们经常所说的可持续性。另外，短时间的苦干也可以有高产出，但不能持续。我在上项目管理课程时，曾经问过同学：如果及时、按质按量、按预算完成项目交付，一定能说明项目获得成功吗？多数同学毫不犹豫说，项目成功了。等他们回答完了，我给他们讲了一个真实的例子：一个团队，为了及时、按质按量地完成项目，每周工作7天、每天工作12小时（比996还辛苦），连续干了3个月，终于完成项目目标，但项目结束后，大家都离职了，因为公司要控制成本在预算内、没有加班费，而且大家干的很辛苦。似乎项目 “成功” 了，团队却跨了，这能说是一个成功的项目吗？不能。所以也有人认为：效能 = 有效性 + 效率 + 可持续性，即简单地说，效能就是能长期可持续地、高效地开发出有价值的软件产品。

为何不想提升研发效能呢？

        记得多年前，在美国的一位从事软件开发的同学对我说，写代码不写出几个Bug，就容易被老板解雇，而且也不能清除所有的Bug，自己的价值也不容易得到体现。代码没问题，老板都不知道你，而线上出问题，你去救火（troubleshooting）救成功了，就是英雄，正像扁鹊，名气很大，而最有价值的老大（扁鹊的大哥）一点名气都没有。

        本来高质量带来高效率，但开发人员并不这么想，总想留点Bug在代码中，从而让公司挽留他。虽然上面那样的想法，不是每个程序员都有，但一定会有一部分程序员有类似的想法。

        更何况国内的加班文化进一步促进大家对效能的提升没那么在意，一个员工特别忙，就显得勤奋，常常被认为是一个好员工；如果员工不忙、轻松工作，往往被看成是偷懒，往往不会被看作是一个好员工，所以有人会在白天上班时间拖拖拉拉，然后去吃一个免费的晚餐，在科技园区逛一逛，再回到办公室加班，直到晚上9、10点下班，给领导一个良好的印象。

        幸运之处，软件总不是那么好度量，如果你按代码行来度量大家的工作量，会被骂死，因为这的确不科学。更何况度量专家常说，不能将度量的结果作为个人绩效的考核指标。所以，开发人员每天完成的工作也很难度量，唯一的硬性度量指标就是工作时间。

        员工是那样，许多管理者更没有动力去提升研发效能。如果效能提升了，人员是不是要减少？团队规模缩小，自己的价值就很可能降低。因为团队规模越大越能体现管理者的价值，带的人越多，预算也就越多，越有操作的空间。所以，团队/部门的研发管理者，从来不会想减少自己的人，而是希望扩充自己的团队。

        曾经想帮研发团队梳理并优化整个研发过程，提升效能，大力缩减研发成本，但和一些朋友沟通，大家都觉得阻力会很大，主要原因如上分析。

        我们也曾看到，有效能专家说，一套解决方案帮助团队提升到 “10倍的响应速度、10倍的过程质量、10倍的有效价值”，那是不是效能提升100-1000倍，原来几万人的队伍可以降到几十～几百人？有人说，人不能少，会做更多的事情。我看了他所在的大厂，产值的确增加了30%左右，已经很不错了，但没有增加十倍，更不用说100-1000倍。

        如果只做正确的事，哪有那么多正确的事可做？就像软件功能，刚开始的确有不少新功能要开发，所以刚开始加人是正常的，到了稳定的时候，管理者也不会主动要求减人，甚至还是喊 “人不够”，从来就没有感觉人够的时候，然后就开发一些没有价值的功能，改来改去，效率有（如交付的代码、特性），质量（指功能、性能、兼容性、安全性等）也不错，就是没有效能，没有价值。

        所以，重复造轮子的事，在软件研发过程中常见的现象；有的团队可以采购一些工具或引入一些开源工具，但没有，而是自己开发；有些团队把简单的事情复杂化，有些团队不断尝试新的技术、不断迁移平台......就是从来不做正确的事，不能这么说应该说：有相当一部分时间不做正确的事。

        做对事情，似乎是由业务部门、产品经理来决定，其实不是，交付哪些功能或特性、技术选型、是否要迁移到不同的平台、是否采用新的技术、是否采用新的流程等等，还是在研发部门。业务部门，只是说要能解决哪些业务问题、用户有什么需求，而功能如何实现，那还是研发部门的事，业务部门也不懂，究竟需要多大的工作量业务部门就更说不清楚，因为研发部门自己都说不清楚。

如何提升研发效能呢？

        虽然有些人不想提升研发效能，还是会有不少人想提升研发效能，否则研发效能不会这么热。

        管理大师彼得·德鲁克曾在《有效的管理者》一书中指出：效率是‘以正确的方式做事’，而效能是‘做正确的事’。如果是这样，不断提升对用户/业务的认知，控制好需求质量，就可以提升效能。但今天我们给研发效能赋予更多的内涵，让软件研发效能既要做到‘做正确的事’，又要做到‘以正确的方式做事’，还要具有可持续性。

        如果每个人都想提升研发效能，其实也很容易，因为大家不笨、有智慧，心中常有“效率、有效性、持续性”这样的意识，不断反思，就能及时发现工作中这类问题，并能一起努力解决这些问题，持续提升效能。效能提升，也不能一口吃成胖子，一定是一个持续的过程。

        按照前面讨论的逻辑思维，要提升研发效能，必须和产品收入、人均产值等结果捆绑起来，类似游戏工作室、事业部那样的建制，产品营收（利润）的一定比例用于奖励研发人员、市场人员和业务人员，人均效益越高，奖励比重越高。业务驱动研发，市场驱动效能，让研发不再只是按预算来运行的一个独立部门，而是和市场收益直接绑定的一部分。

        ● 在研发内部如何提升效能呢？提升研发效能的具体实践很多，可以列出一堆，例如技术选型、中台、低代码构建、Serverless、开发工具、脚手架、代码规范、代码仓库管理、代码托管、本地代码检查、代码提交规范、代码审查、接口文档平台、接口测试平台、即时协作和企业通讯、团队知识库、任务调度平台、配置中心、项目管理、CI/CD 流水线、容器管理平台、监控告警、日志平台、可视化数据管理、链路追踪等。但归纳起来，按照传统的观点，会从“人、流程和技术” 三个维度去提升研发效能，建立良好的组织文化，提升全员的素质和能力，持续优化流程，构建良好的研发基础设施......像百度还会加上数据，因为许多公司拥有编程大数据（如源代码数据、缺陷数据、日志数据等），的确可以帮忙分析问题、度量效能，以提升效能。但如果按照前面的效能定义，问题会相对简单，就是提升软件研发的效率、有效性和可持续性：效率提升：过去几十年一直在讨论中，积累了很多经验，从CMU SEI的PSP（如个人能力）、TSP（如团队协同）开始直到敏捷、精益和DevOps（如高度自动化的交付流水线、迭代速度、交付周期等），以及到今天将人工智能（AI）赋能软件研发、运维，都能致力于效率的提升；

        ● 有效性：即做对事情，甚至可以理解为需求质量、设计质量和代码质量，如确保需求是有效的，来自于真实的业务需求和用户需求，准确、有效的定义需求；选择正确而合适的架构和开发技术等；

        ● 可持续性：主要指可持续性交付与团队能力的可持续性发展，这也和软件的质量（特别是软件的内部质量，如可维护性）相关，例如系统架构强耦合、代码不规范、复杂度高，即软件研发的技术债快速上升，最终就很难做到可持续的快速交付。这其中也要求确保公司体制、流程的可持续的、稳步改进和系统平台的可持续的、稳定的演化，关注方法、技术和工具前后的连贯性或衔接性，并力求做到团队的持续建设和培养、组织文化的持续提升等。

        研发效能的提升离不开业务，而且是为了业务、服务于业务，也就是我们常说的“不忘初心”。效能提升的过程，也应该是企业成本下降、利润提升的过程，否则说明研发效能的提升一定是有问题的。研发效能的提升要有一个愿景：效能驱动效益，最大化企业的价值。

        具体如何做，后面会提供非常有价值的、大厂实践的详细资料，供大家下载学习，不是几千字能讲得清楚。

如何度量研发效能呢？

        软件研发效能度量也是争议比较大的一个问题，虽然度量会产生副作用，但是必须做，不度量，就不知自己在哪里，就无法改进。如果其它配套措施跟上，就能最大程度消除副作用。例如，每千行代码缺陷数常常被用于度量开发编写代码的质量，如果你纠结这单一的指标，它的确会有问题，如人们常常说的，一个能力弱的程序员将几千行就能实现的功能特性写成1-2万行代码，分母增大了，每千行代码缺陷数就下降了不少，不能反映真实情况。但是，加上代码评审、代码复杂度度量、单元测试、单元性能指标等其它配套的措施和度量，这样的问题就能发现。

        研发效能的度量一是要成体系，系统、全周期、科学合理的设置，并和研发活动、项目管理等结合起来，如需求评审、设计/技术方案评审、代码评审、过程评审、管理评审、等。度量也没那么复杂，更没那么可怕，先做起来，及时发现问题及时纠正；一面实施一面改进，持续改进度量自身，消除各种隐患和不合理的度量，就能让度量成为一种驱动效能提升的坚实力量。

        说起研发效能度量，人们会常常提起阿里云效的五大度量指标，相对比较简单、清晰。在云效平台上，针对研发效能洞察上，侧重代码洞察、项目洞察。

        （阿里云效的研发效能度量指标体系）

        如果从本文给的研发效能的定义（有效性 + 效率 + 可持续性），滴滴的研发效能度量指标体系更吻合一些，在特征指标中强调了“有效性、可持续性”，涉及8项指标，但是除了“代码复杂度、测试覆盖率、团队构成及人数（影响评判有些困难）” 这3项指标之外，其它指标具有一定的主观性，难以自动获取数据。一旦度量数据靠人工输入，问题就会比较大。

        像ThoughtWorks研发效能指标体系就回归到传统的两大度量指标：交付效率和交付质量，只是在具体度量指标设置上考虑了可持续性，如技术债天数、需求停留时间、研发停留时间等。