‍

阅读本文你将收获：

1、当下热议的各种研发效能度量误区，有哪些是无效焦虑？

2、研发效能度量有效性的基础是什么？

3、为什么技术发展会让所有团队最终都使用研发度量？

4、当数据成为研发的基础设施，有哪些"深度〃和〃智能” 技术将成为核心？

5、研发效能度量的本质是什么？

‍

前言：05.25日K+Talk邀请了思码逸创始人任晶磊、腾讯技术工程事业群DevOps与研发效能资深技术专家的张乐，大咖对话一起分享讨论关于研发效能度量的各自看法，内容非常精彩，以下是文字版干货回顾；

‍

嘉宾介绍：

任晶磊——思码逸 创始人&CEO

清华大学计算机系博士，前微软亚洲研究院研究员，斯坦福大学、卡内基梅隆大学访问学者；《软件研发效能度量规范》标准专家组核心专家。在软件系统、软件工程领域从事前沿研究多年，具备丰富经验。曾在FSE、OSDI 等顶级国际学术会议上发表论文多篇，亦参与过微软下一代服务器系统架构设计与实现。同时，也是一位积极的开源贡献者。现任思码逸CEO，通过打造先进的深度代码分析技术和研发大数据平台，以数据驱动软件工程，助力企业和团队提升研发效能。

张乐——腾讯 技术工程事业群 DevOps与研发效能资深技术专家 。

前百度工程效率专家、前京东DevOps平台产品总监与首席架构师，曾任埃森哲、惠普等全球五百强企业咨询顾问、资深技术专家。长期工作在拥有数万人研发规模的一线互联网公司，专注于研发效能提升、敏捷与DevOps实践落地、DevOps 工具平台设计、研发效能度量体系建设等方向，是《研发效能宣言》发起人及主要内容起草者，EXIN DevOps 全系列国际认证授权讲师、凤凰项目沙盘授权教练。著作：《软件研发效能提升实践》、译著：《独角兽项目：数字化转型时代的开发传奇》

‍

软件开发的生产力不可度量。

——MartinFowler

用代码行数度量开发进度，就像用重量来衡量飞机的生产进度。

——比尔·盖茨

‍

研发效能度量有哪些误区？

‍

张乐：近两年，研发效能度量是一个热点话题。在行业里几乎每家公司都在关注怎么去做研发效能度量，有很多刷屏的文章，有很多声音说研发效能度量很难做，甚至还引发了各种“血案”的发生。所以，在现如今如火如荼的研发效能度量领域，我们先聊一聊会遇到哪些研发效能度量误区，大家都有哪些焦虑，又有多少是无效焦虑呢？

‍

研发效能管理先于研发效能度量

‍

张乐：Martin Fowler在多年前的博客中曾经写道，软件开发的生产力（Productivity）不可度量，因为软件行业缺乏效能度量工作有效性的一些最基本的元素。微软前CEO比尔·盖茨也说，用代码行数度量开发进度，就像用飞机的重量来衡量飞机的生产进度一样。从经典的管理学角度，到软件工程的角度，度量似乎一直是业界非常有争议的话题。

任晶磊：

Martin在他那篇著名博客中提到，有很多领域没有度量，但也存在管理。这一点我比较赞同，但我们可以继续深挖。彼得·德鲁克说没有度量就无法管理，它其实隐含着一个意思，度量是先于管理的。就是你首先要度量，然后有了数据，才谈得上去做管理。

‍

但我的观点是管理应该先于度量。在我的理解里面，度量这件事情是辅助管理行为的。首先，你要有管理的目标，有管理的认知，有管理的行为。数据只不过就是把其中可能人做的成本特别大的，或者人没有办法很精确知道的，再或者是人比较难做到的这部分，用数据或其他的工具方式去完成，所以说度量其实是辅助于管理的，应该是管理先于度量。

至于研发效能到底能否被度量，这里就要区分两类度量，如果在这个地方说的度量是那种像物理学一样的度量，那没错，这句话100%正确。所谓物理学度量指的是用精密的仪器去度量长度、时间、重量等。但实际管理当中所做的度量其实是服务于管理的，就是前面的观点，你要达成一定的目的，然后通过数据去反映管理当中的一些问题，或者是这个团队当中的一些行为。那这个时候其实你并不是追求绝对的精确，你要的是能够通过一定的维度或者通过若干个维度的数字去反映某种规律、某种现象，这就足够了。这是统计学度量。如果从这个层面来理解度量的话，那我认为，研发是可以度量的。

‍

张乐：

在研发过程中，很难做到精确，但是如果数据在统计上它符合一定的规律，具备一定的意义，其实你的目标就达成了。所以这就回到刚才说的，研发效能度量到底跟管理是什么样的关系？其实是一种相生相伴的关系，我们先要设定一个目标，我们的目标要先清晰，然后再去找某种指标，用研发效能度量的手段带给我们一些反馈，再根据反馈信息，去验证这个目标是否达成，如果没有达成就要再实施下一步改进措施。

从这个角度来讲，先有度量还是先有管理，确实是一个相对的关系。所以这也是我们很多小伙伴很焦虑的原因，我经常听人说“我们有200个、2000个指标”，这个其实已经很多了，指标多可能证明管理的精细度很细，但实际上呢，也会让大家产生焦虑，我相信没有一个人能记住2000个指标所有的定义、公式、计算逻辑。所以我们应该首先关注这些指标背后的目标和故事，你想去验证什么，然后再去度量它。

‍

焦虑可能源于失败的研发效能度量

‍

张乐：

我们不妨引用一个敏捷度量模型的案例，诺基亚很早之前就在做规模化的敏捷。当时他们做了一个衡量敏捷成熟度的模型，叫Nokia Scrum Test，可能很多人知道这个模型，它其实是一种基于过程性的、衡量活动成熟度的研发效能度量模型，比如说会考察PO做的怎么样、用户故事管理的好不好、迭代运行的是否符合规范等等，每个维度计算出相应的分数，最后把多个维度合成一张雷达图，得到一个指数，类似方法其实很多人都在用。

有人问研发效能领域有没有这么一个模型，我们能不能去参考？这类模型可以引导大家使用敏捷的工具，使用敏捷的方法，使用敏捷的实践，让大家的日常工作、活动做到更成熟的”标准化”。但是在这个故事中出现了一个问题，就是在管理层认知的敏捷的成熟度，与工作实际的情况是有很大偏差的。从领导层的角度来看，这个成熟度得分一直在往上涨，看起来形势一片大好，但是工程师的感觉却不是这样的，因为他们是被要求去使用一个不喜欢用的敏捷需求管理工具，于是很多人就只是应付一下，比如在快要上线的时候再后补一个需求，活生生把一个敏捷工具用成了文档记录工具。而且，真正的问题出在工程上，塞班60操作系统非常复杂，技术债务堆积成山，到后来一次编译就要48小时才能完成。但这些瓶颈，并没有能反映到所谓的敏捷成熟度指标上，这所以就产生了一个非常严重的脱节。就是说研发效能度量的分数看起来很好，但是实际工作中工程师正在煎熬。在实际交付的层面已经出了很大问题了，但是从管理层看到的敏捷度量指标却很高。所以，这个例子说明了，使用狭隘的、基于过程的、活动导向的研发效能度量方式，类似的成熟度模型，在我们当前的环境下应用是有很大问题的。做好度量，还是要首先以结果为导向，不要因为选错研发效能度量指标、研发效能度量方式，而让公司决策南辕北辙。

‍

研发效能度量有效性的基础

‍

任晶磊：

说回到比尔·盖茨那句话。直观理解似乎是个很好的类比，但这里面也隐含着一些前提。我们假设飞机生产过程能够被清晰地定义出来，特定进度下的重量其实就确定了。如果存在这样一个模型，那么用重量来算生产进度就没有问题。再往本源问，人是怎么定义这个“进度”的呢？把飞机翅膀造完了，进度是10%还是20%呢？我们发现，人们本质上就是用一个数据模型来描述“进度”这样一个概念。

万物皆数，今天的数据其实在扮演更重要的角色，并且变成我们去model这个世界、认知这个世界的一个重要途径。研发正在从流程驱动进入到数据驱动的范式升级中。流程有效的基础在于，首先人要有一个有效的工程实践，人是先于流程的，这是最基本的。数据有效的前提也是人要先于数据，人要有获得某种认知的有效手段。在流程驱动里，目的是推动协作，而在数据驱动里，目的是获得认知。比如问流程是不是有阻塞，那么人会如何做出判断？然后我们再跟上度量，跟上数据，然后去解决问题或者辅助人做事。未来有一天数据的积累，技术的积累，工程的积累足够充分之后，数据智能就可以帮人做好自动化，帮人判断、决策或者提醒，达到一个更好的状态。

人先于数据的意思就是首先从目的上来说，数据是服务人的认知的；然后从方法上来说，数据也没有那么玄，数据就是去模拟人的行为，模拟人的认知，所以我觉得这个应该是研发效能度量有效性的基础。

‍

研发效能度量的硬核技术

‍

张乐：想做好研发效能度量，必须重视研发效能度量的基础设施，它不是一个单一的工具，也不是单一的数据分析方法。首先要把研发过程的数据相对合理和准确客观的采集上来，这步其实也并不容易，要从数据中粗炼出信息，再把信息精炼出知识，这个过程相当考验功力。其次要打破数据孤岛，把工作过程中的产生的各种制品串联起来，形成建立在工具链网络基础上的制品网络，并形成信息流间联动。研发效能度量的基础设施的建设可以是商业化的，也可以是自研的，还有一些开源的平台可以选择。

任晶磊：大部分用户在自己单独做基础设施。各大厂里都有自己的这种研发效能数据平台，也有的把一些开源的项目整合一下，从而服务自己的流程，然后去存储数据。数据会变成研发方面一个新的基础设施，就像数据库、云计算等基础设施一样。今天可能大家还没有享受这种便利性，但未来可能就是一个唾手可得的东西。建设基础设施最好的方式还是开源路径，我们看从操作系统到数据库到CloudNative这些框架，其实都应该把很多重复的工作整合在一起，然后share给别人去使用。思码逸最早就做这个领域，后来我们就把数据平台和初步分析能力开源出去了，并且直接捐献给Apache基金会了，现在叫Apache DevLake（开源地址：https://devlake.apache.org/）

张乐：开源可能是让产品快速成长很好的一种方式。现在我们已经把数据采集上来，但可能还涉及到一个细加工的问题。比如我们在谈一个词叫“噪音”，一个数据系统提供多少功能可能不是最重要的，但如果提供的数据不准，研发效能度量平台的根基就没有了。

任晶磊：去除这些噪音无非就是两个途径，一是做某种意义上的清洗，但这个清洗并不是简单的类似于大数据里面的一些数据的清洗，而是需要一些比如程序分析的技术；二是做数据间的关联和校准，一个数据可能是某一个维度或者某一个角度的数据，你可以用统计学方法做一定的控制，或者指标本身可能跟另外一个指标相互之间是可以做校准的，比如需求的数据和代码的数据，就可以做相互的校准。为什么说人先于数据呢？就是通过这些过程去反映人怎么去看这个问题，一旦固化在机器上，其实是不需要人花精力去做了，就可以自动化的去做了。那其实数据的处理就是一个过程，目的是想把黑盒打开，把人看这些东西的逻辑，固化到计算机里面去，让计算机能够在可接受的误差范围下，去模拟很多人的这种过程，出来这些数据其实可以直接被管理者拿去做参考。

张乐：我觉得我们在不同的场景下，有时候需要把研发过程当做黑盒，但有时候也要打开黑盒。要关注从业务到研发，再到交付给客户的全过程，这体现出端到端的价值交付结果，相关的研发效能度量要从系统的外部来衡量；但我们在做具体的研发效能改进的时候，还要把黑盒打开，我们要看到端到端价值流是怎样流动的，什么地方有阻塞，什么地方有浪费，什么地方要改进，要从宏观看到微观细节，不论是管理上还是工程上。研发效能度量的各种技术也要结合专业的方法，比如价值流分析方法、代码工程质量评价的方法等等，形成一个专家系统，形成研发效能洞察和改进的闭环。

‍

让研发效能度量回到洞察的本质上去

‍

张乐：我现在更喜欢用洞察这个词，研发效能度量给人的一种印象是定指标、做考核、给人贴标签，但洞察更强调分析系统的本质，找到过程中的问题。我们不要把研发效能度量当成抽鞭子，而是要把它看做是一面镜子，给你客观的反馈；把它看做是一份体检报告，告诉你哪里不正常；把它看做是一份健身指南，告诉你应该怎么科学锻炼和健康饮食，最终目标都是为了让人变得更好，这样的研发效能度量才是我们的最终的目标。所以不光是个人，包括团队，甚至到部门和公司，其实都应该有这么一个思维去引导，研发效能度量不是定几个指标，然后一刀切的考核。举个例子，比如单独要求单测覆盖率达到80%以上，其实意义可能并不是很大，我们首先要找到复杂度很高的地方，复杂度很高可能就容易出错；然后看看这些代码是否频繁改动，是不是热点代码；再有就是看看历史从这个地方出现的问题是不是很多，还有一些其他的维度等等。如果既复杂、又频繁改动、还经常出错，那这个地方就应该多补补单测，而不是一刀切地说要达到一个什么样的水平，这所以就是一种基于场景化的方法，去让研发效能度量或者洞察更好的发挥作用的例子。

任晶磊：数据智能比较充分之后，人就可以省下很多做改进的精力。对这块儿有一个很形象的比喻，就是大家天天写code肯定有bug，你需要去看各种各样的trace，各种各样的log，特别是复杂的分布式系统，肯定是要有各种各样的log去看的。其实研发数据是帮你看清楚整个研发的过程，然后去帮助你debug研发过程。

张乐：所以这个过程用“洞察”这个词描述可能更好一些。洞察其实就是看问题本质，研发效能度量会让很多人想到定KPI指标。行业里的趋势也是这样的，从关注指标，到把指标进行自动化加工，进而发展到一些智能化的分析，通过专家系统可以给出洞察分析的结论。

任晶磊：分析会遇到三个层次的障碍，技术层、工程层、成本层。像腾讯部署这些分析的话，可能都是几十万个代码库去分析的，这些其实也有成本和效率的问题，这里面其实也有很多工程和技术上的挑战。

张乐：挑战是需要我们持续探索的，因为研发效能度量也好，洞察也好，正在一个方兴未艾的时期，相信很快会有更多的研究成果出来，包括研发效能度量的新方法、新模型和技术的突破，值得期待！

‍