数十位研发发声：研发效能度量，别玩成了一场数字游戏

度量确实是个好东西，但度量指标的错误选取、度量数据的不准确、度量方法的错误使用都有可能将你的团队陷入困境，作为 Team Leader or 一线研发，大家多多少少都吃过一点度量的亏，也对以下问题感到困惑——

• 研发效能和 DevOps 有没有区别？

• 度量需要有哪些指标？

• 不同难度值的研发任务，如何公平地度量？

• 度量后要不要跟考核挂钩？

7 月 31 日 18:00-19:00，QCon 全球软件开发大会（广州站）2022 现场，以「研发效能度量是“深坑”？」为讨论主题的晚场闭门会中，数十位资深研发针对以上问题进行了深度的探讨。在场嘉宾所在的行业各不相同，有互联网从业者，也有金融行业、制造业等偏传统的行业研发人员。

“我们公司是做虚拟化的，今年也想推广 DevOps，所以就想来看看别的公司是怎么做研发效能度量的。”

“我既做过敏捷教练，也做过研发，经历过极其严格的度量，也经历过完全没有度量的时期。”一位来自头部大厂的嘉宾表示，“站在研发角度去看，我十分痛恨度量这个东西，我觉得没有什么用。但如果站在管理者角度去看，它一定是个非常好的指标，所以我希望看看其他人是怎么去平衡这个问题的。”

在简单的自我介绍环节之后，现场展开了讨论，以下为文字整理（为避免不必要的麻烦，以下内容均隐去公司名字及嘉宾姓名，为优化阅读体验，也做了不改变原意的增减）——

主持人：我们今天找讨论的主题是研发效能度量，对吧。在刚刚的开场自我介绍的环节，很多老师都是一会儿说 DevOps，一会儿说研发效能。因为我本身是做 DevOps 的，我也经常会说 DevOps 研发效能，但是这两个东西到底是不是有区别的，我们今天的讨论就先从这个问题开始。这边有个面板，“DevOps 和研发效能到底有没有区别？”这个问题已经在上面了，白天的时候大会现场已经有一些投票了，那么在座的老师，咱们也花一分钟时间投个票吧，把 Yes 或者 No 的贴纸贴到相应的位置就好，认为有区别选 Yes，没区别就选 No。

主持人：绝大多数嘉宾选的 Yes，说研发效能和 DevOps 有区别，只有 4 个选择了 No，比例相当失衡。我随机采访两位老师，说一下为什么选 Yes 或者选 No。先请选择 No 的这位老师，为什么你认为研发效能和 DevOps 没有区别呢？

嘉宾 Cherry：因为我刚才也分享了一个演讲，也特别探讨了一下研发效能。大家如果有看《Accelerate》那本书的话，就会记得它里面讲过各种度量的方法，讲过怎么去衡量你是不是一个 High Performance 的团队。其实我觉得跟我们公司在做的 DevOps 的度量是没有差别的，所以我就选了没有差别。那本书里面讲的就是四个点，你的发布频率，你的变更失败率，你的 Lead Time to Deployment，也就是你的变更时长，还有一个，你的恢复时间 MTTR，所以在我看来，DevOps 跟研发效能的度量最被认可的这四项是一样的。

主持人：谢谢。Chris 你选择了 Yes，但因为刚才你一直混着说 DevOps 和研发效能，你能不能解释一下你的基本理解？

嘉宾 Chris：我是一个学习者，因为我们没经验，主要想来听大家怎么看。我个人理解这两者是有区别的，如果不推 DevOps，按理说应该也有研发效能，那这部分就不等同。

主持人：好的，谢谢 Chris。要不我们这位台湾的朋友来说说你的想法？

嘉宾 Frank：我觉得这两个是高度相关的，但是多多少少还有些区别。DevOps 如果做得好，我认为可以提升 研发量能，但是研发的效能可能更多的还是得看这个研发的具体的实力跟一些工具的应用。所以它如果讲到效能，那就不是说把 DevOps 做好，你的效能就能够提升。但是量能是可以的，我们把时间节省下来，放在更多的开发能量上，那确实是有点帮助的。

主持人：理解，你觉得效能这个范围会更大一些是吧，Simon 你看呢？

嘉宾 Simon：我理解研发效能的话，是偏指标或者说整个生命周期，譬如说像从一个需求的诞生到真正交付上线。那整个研发效能它衡量的是全流程化的，期间比如说一个流程或者说一个环节慢，那到底是慢在哪个环节，是产品需求慢了，还是说研发测试慢？再或者说是卡在这个交流和沟通上。那 DevOps 的话更偏向这个研发体系的一些的工具类，或者说期间那些指标的沉淀。

主持人：好，谢谢 Simon。不同老师有不同的见解，二十位老师就有二十个哈姆雷特。我是做工具出身的，刚做 DevOps 的时候，我就认为 DevOps 就是做工具，很多时候很多同学对于 DevOps 的理解就是，我用了工具我就用了 DevOps 对吧，这个其实也不一样。那研发效能呢，我简单讲一下我的个人经历。我在英国待过十几年，在一家银行工作过，那会儿我们有做 DevOps 的人，有做敏捷的人，做敏捷的人会认为我们 DevOps 是做敏捷的一部分，反过来，我们做 DevOps 的人会认为敏捷是我们 DevOps 的一部分。 这就有点像今天大家混用研发效能和 DevOps，就看大家怎么去理解这个东西。不过就像前面一位老师说的，DevOps 做好了肯定是可以提升效能或者说量能的，但它俩之间并不是等于关系。

主持人：前面的话题只是开胃菜，现在我们回到今天这个度量主题上来。Scott 老师，听说你们公司在推度量，站在研发的角度来谈谈你的感受可以吗？

嘉宾 Scott：我们这边确实是在整个公司最先做这个研发效能相关的事情的。刚开始和主持人说的会比较类似，我们做了很多工具来提升效率。因为 DevOps 是研发同学要去负责 Operations，所以我们就在各个环节都落地了工具建设。

主持人：我们其实想知道，当时你们推度量的时候，作为研发的你们是什么样的一个感受，或者说你们当时怎么推度量的？

嘉宾 Scott：打个比方，网上有数据说 Google 一周能发 100 个版本，Facebook 一周能发 200 个版本，那我们要比他们更快，就要去想之前怎么会慢，整条流程里面都是手工作业，我们就要搞工业化和流水线，要建很多工具。那这些东西建设出来之后，我不去度量怎么会知道和之前有没有区别呢？所以，从老板的角度来看，他也需要知道做这些事情到底有没有实际的提升，我觉得这是一个很正常的想法。

再举个例子，据朋友说，在硅谷，一个人在 Facebook 工作了好几年，再去 Google，或者再去别的地方都一样，他写的代码大家都能看得懂。但在这里不一样，这个人写的代码只有他自己看得懂，后面的接手的人就感觉是在爬屎山，心想我还不如把它给撸掉全部重写。

也就是说，许多不统一的问题确实是存在的，比如代码的规范、文档的注释，等等。那要去度量的话，会考核很多维度，比如千行代码 bug 率、圈复杂度、破窗效应。整体上是一件好事，可以把所有人的水平拉齐，无论你做什么，你写的代码或者别人写的代码，再给其他人看都是一样的，而不是说这个人写的代码有自己的特色，其他人根本没法读，这是一个很大的问题。我们在努力解决这方面的问题，现在看应该是比之前好了非常多了。

我们可能也算是一线大厂，但其实大家的水平也是参差不齐的，如果能通过一些方法把他拉到一个线上去，也是好事。

主持人：了解，我觉得我非常同意你的观点。从管理层面来说，老板希望能看到大家的效率在哪里，包括能有一个标准，大家都遵循这个标准，都能把效率提上去。这里我想补充一个我个人的理解，为什么我认为度量是必须的。因为我是做 DevOps 的 ，但在银行里面，我们做 IT 又不做业务，做 DevOps 又更多的是对 IT 的改进，很多人就觉得这个是不是总是低优先级，对吧？所以有的时候，如果没有度量，或者甚至不把它公开化，那你到底写了多少代码，你做了多少工作量，这些事情不公开说的话，大家都不会重视，就更不放你去做 DevOps 了。

嘉宾 Edwin：其实我在上一家公司待了快 10 年，也参与了这个过程。我很认同刚刚说的，度量的出发点是好的，就是想通过这个去拉齐一些能力水平，但其实现状是，落地并不好，原因在于就是无脑地去推进这件事情。 坦白讲，每个业务的情况是不一样的，每个业务的现状也是不一样的，无脑地去拉到一个线上去其实根本就不现实。举个例子，具体哪个业务我就不提了，我离开那段时间，有些团队为了把数据做好，疯狂地去做数据，已经到了这种程度。 我觉得这个问题出在决策层，他没有看到落地的时候大家遇到的实际问题是什么。那这些团队为什么要去做这些数据？是因为每一个月，所有的业务数据都会被拿来一起排名，这就很恶心了。排名在尾部的数据一定会被 diss 对吧，是不是你们不行，为什么别人能做到你们做不到？那这种方式的牵引一定会导致大家去做数据，但实际上 DevOps 不是去做数据，出发点应该是，这个决策者知道这里面的问题是什么，去优化你的问题，我只要能证明我比以前好了，我觉得就够了，而不是说我去为了这个数据去卷。为什么？第一个，你的数据准不准确？我们先假设它是准确的，但每个业务的现状是不一样的，你的业务是在一个平稳期，我的业务是在冲刺期，大家拿到一个线上去比没有意义的。

所以我认为度量是有价值的，可以让事情变好，但不能把它作为一个考核。一旦作为考核去排名竞争，这个事情的落地就会变味儿。我最近在看《驱动力》，那本书说自驱力很重要，但当你把这个指标去量化的时候，它就不是自驱力，就变成人性本恶的一个东西了。我们本应该是人性本善的，说你就是能把这个事情做好，你看今年你们的状态，如果是一个平稳期的业务，那可能我们的方式就是不一样，对吧，是一个冲刺期的业务，那可能你会有自己的选择，而不是全部拉到一条线上去比较。坦白讲，业务的成功与否，技术在这里面有支撑性作用，但没有决定性的作用。

那段时间我感受蛮深的，因为那会儿我也是一个业务的负责人，就特别讨厌这件事情。会上各种 diss，你看你们业务怎么那么差，数据那么差，你们是不是不行？哪怕我们也会在会上去解释，但也很无力。

所以我觉得出发点是好的，但实际上落地的时候，决策者没有下场去写代码，他没有去感受真实问题。

主持人：我觉得这位老师说得非常好，核心问题就是一个，度量要不要作为 KPI 对吧？很敏感的问题。很多老板都喜欢横向对比，哪个团队做得好，哪个团队做得不好，不知道是不是我当老板以后也会喜欢这样子。但是这个问题一旦变成 KPI 就变味儿了，是不是大家就是在做数字游戏。

嘉宾 Todd：我其实很赞同刚刚那位 Edwin 老师的意见，就是这个指标一定是自己看的。其实在敏捷理念里面也是这样，我一个小团队自己把最真实的数据体现出来，然后通过自驱去自我迭代，去提高交付的吞吐量。但这个数据一旦变成了一个给老板看的东西，那么它一定会变味儿，大家为了升职加薪，一定会去美化这个数据，那么它就失去了意义，这件事情就会变成一个无用功。我既待过看重数据的公司，又待过不看重数据的公司，我个人觉得从研发效率来讲的话，个人的研发效率真的是天差地别，这个具体的数值可能不太方便透露，但是两个团队的研发同学的精神面貌可以说是完全不一样的。

嘉宾 Scott：请教一个问题，我比较好奇，有度量的和没度量的，研发的精神面貌是怎么样的？到底有没有影响业务的发展？

嘉宾 Todd：这个精神面貌确实没有办法度量，但是我觉得就仅从开心和不开心来说的话，我觉得很明显能看出来，你度量的时候是不开心的，写代码是不愉快的，你不度量的时候可以很愉快地纯粹地去做这件事情。至于有没有影响业务发展，我个人感觉，对于一线开发的同学来说，他根本不 care 你业务增不增长。你如果要看指标，OK，那我 care 的就是这个指标。你如果是要看代码，那我 care 的就是我的代码。大家都不是傻子，你要什么，你一定会得到什么，是这样的。

嘉宾 Scott：我突然想到一个例子，假如我们现在发现了一个 bug，我们如果要度量的话，肯定分增量和之前的存量。但是这个代码在存量代码里边，但是你要改了它，它可能就变成增量代码了，因为你新提交了。就是说，你发现一个之前就有的老 bug，但它不是你的代码，你也不敢改。因为改了之后，千行代码 bug 率等等各种指标都要再来一遍。一想到因为改这个 bug 将带来的巨大工作量，你想，算了，不改了。但是，这个 bug 现在天天都在影响用户的使用，怎么办？

嘉宾 Todd：我们以前有完全几乎一模一样的例子，那个指标统计非常的扯，历史 bug。我发现了一个历史 bug，我想去把它给改了，但是我去改的时候必须是以那个 bug fix 的分支去提，那么它会记我一个 bug。我主动发现一个历史 bug，想把它修复了，它还要记我一个 bug，你说怎么会有人主动去做这件事情呢？

嘉宾 Scott：对，所以刚刚 Edwin 说的话我特别赞同。就像管理大师德鲁克说的，管理的本质就是激发人的善意。如果你真的激发他的善意，他能自驱地去做这件事情的话，其实你度不度量他，他都会把事情做好的。他知道怎么样把这件事情给做好，他也知道怎么样去真正去做帮助用户产出价值的事情，而不是为了那个指标。

主持人：咱们这个话题我觉得非常好。让我想起前两天跟我们一个从日本 Google 过来的同事聊，他说他在日本 Google 很轻松，老板可能也无所谓，反正你把活干完就可以，爱怎么玩怎么玩。这就让我想起当年自己在前司很卷的场景。感觉国内外的互联网，对咱们研发的信任程度好像并不是特别一样。

主持人：所以现在最核心的问题抛出来了，度量到底适不适合做 KPI 考核？不做的话，没有压力就没有动力，度量做太重的话，员工又不会开心，大家有没有比较好的方式去平衡这两个东西？

嘉宾 Josh：我觉得在有些公司，最大一个问题就是把度量卡太死了，比如单元测试覆盖率全部都要 80%，但是我一个新业务，你要求我这个单元测试覆盖率有什么用呢？我只要功能正常就行了。而且你这样子会让我的业务跑得很慢，这是一个问题。但有一些老业务，他就有理由去要求这个单元测试覆盖率。我认为对于不同的业务，应该有不同的考量，在某些情况下度量跟 KPI 挂钩是 OK 的。但是我们大多情况下是把这个东西作为一个观测指标，比如说你的 bug 率，我们还有个指标叫做交付率，比如说两周一个迭代，那你这两周的需求交付率是多少，完成率又是多少，大概是这么一回事。所以这一块的话，我觉得还是要看业务，比较成熟的业务的话，你有这要求那要求，我觉得没有问题，不然那种国民级应用的某个核心业务抖一下的话，可能这个影响面就太大了。但是对一些创新型的业务，或者你业务量级没那么大，你就没必要全部一刀切，你要求单元测试覆盖率这个干嘛呢？直接测试用例过了不就行了？我大概是这么个观点。

主持人：好，谢谢。就像您说的，咱们具体情况具体分析。

嘉宾 Josh：对，但是你的那个度量指标其实是可以公开出来的，但是不一定要把它作为考核指标。比如说，我们的需求交互指标其实是有公开的。但它不作为我们的考核指标，而是一个观察指标。

嘉宾 Cherry：像我们公司都会讲这个数字，就是代码覆盖率，这个我们不怎么 care，我前面说的那四个指标我们都有谈。但是我们谈的时候，我们也说这个不是 KPI 来的，而是 OKR。OKR 往往都会设很高的，因为越是高，你的 Performance 会更好，但是它是不设入 KPI 的，就算有些团队没有达到，他们的绩效也不会受到影响。我们经常会做这种沟通，但是其实也很难让每个人都明白这个不会影响你的绩效，大家还是会有担心，对于这种情况大家有没有什么办法？我觉得指标还是要有的，因为就算你自己看，你也要有一个可以前后对比的东西。我也完全同意这不应该是个 KPI 考核，因为我们想达到的目的是找到那个优化的点去优化。那怎么能让大家又有数据，又不用担心 KPI 的问题？这个怎么解决？

主持人：相当于说，考试不排名了，但是考试还是得有成绩。

嘉宾 Cherry：对。

嘉宾 Josh ：我们的做法是有一些东西你是不能碰的，有个东西叫红线，比如说出了个安全问题，那就是会影响你的考核。但是其他的问题，比如说你的代码规范，就相当于是一个加分项，它不是一个惩戒，大概是这么个思路。这可能跟这个团队的文化很有相关性，有些东西老板会明确告诉你不行，但其他你做得好的话，我们会去表扬，比如说你质量做得好，我们会有一个 XXX 之星之类的奖项，但是如果你出了个故障，搞了个安全事故什么的，那你肯定会被通话批评，一句话来说就是奖惩结合。

那些本来是锦上添花的事情，比如你的代码写得好不好，那实际上对你产品的业务影响其实是没有的。你希望大家代码写得好，以后做交接等各方面的事情的效率更高，你就要去鼓励这种行为。但你的底线就是不要出问题。

主持人：但是我了解刚刚 Cherry 老师那个想法，就是说还是看老板的重视程度，你说你觉得他重视还是不重视呢？

嘉宾 Josh：那你就出一个明文规范，比如说我们出个事故，奖惩是怎么样的，其实都是有规章制度的。

主持人：我觉得这也是个方法，大家谁还有什么建议吗？就关于这个问题。

嘉宾 Luke：我这边有一点点不一样的想法。前面大家讨论研发效能的时候只把关注点放在研发这一块，但其实我想说的是，我们在做研发效能的时候，应该是把产品和业务价值带进去，就是我们做这个事情的时候，应该是运营、产品、研发、测试一整个团队在做，那应该是一起去考核的，而不仅仅是考核研发，比如说研发的周期怎么样。我们应该看带来的价值，比如给用户带来了多少价值，给公司带来多少收入，是吧。所以在这个角度来看的话，我觉得大家奔着这个目标的话，那些度量数据就非常有意义了。我这个月或者这个 Q 或者这半年给用户带来多大价值？我是不是比别的团队带来价值少？那我怎么去看这个少在哪里、什么原因？那我们团队就会自己拿数据去分析总结。当然，这个数据本来应该是给团队做总结的一个依据，而不是一个考核，这个我是赞成的。

主持人：您这个观点我觉得非常好，就是我们经常提出比如说 DevOps 也好，研发效能也好，肯定要跟业务是有直接关系，不过您能不能再说得具体一点？因为其实我也经常会面临这个问题，就是说我们做 DevOps 如何去量化它对业务的真实好处。尤其我觉得在互联网可能还好一点，因为互联网我们经常做 IT 产品对吧，比如说你做 DevOps，你发布的速度快，我首先抢占市场对吧，可能这个影响会比较明显一点。但像我们在传统行业，我们本身 IT 不是业务，怎么能更好去量化这个对业务的价值呢？

嘉宾 Luke：我自己既负责研发效能，也负责一块业务，这也是我一直在思考的一个问题。前期大家是在做一些基础设施，但其实很难衡量基础设施给业务带来什么价值，而且还是逼着业务去往基础设施上迁，这是很痛苦的事情。我之前的公司前几年也在做这些事情，去年开始有了考核，大家才慢慢开始看数据。

我也在想，每次向老板汇报的时候，要怎么汇报我这个系统给业务带来的价值，因为老板只看这个，他不会看其他的。特别是研发，他特别难去讲清楚这件事情，不像运营和产品，带来多少收入增长是很直观的。前期的话，我们是自上而下往下去推的，就是从上一直强推，把这个系统推下去。但在推的过程中，也像前司一样，遇到很多痛点，因为下面反馈的声音很大，每个业务团队的现状是不一样的。所以我其实还想听一下大家有什么经验可以给我们一些参考。

嘉宾 Tom：我觉得你刚才讲得非常好。首先，为什么出现这个情况？为什么要出现度量这件事情？原因就在于大家的目标没有拉齐，比如说，您这边是做 DevOps 的对吧，那你的领导怎么考核你们？他肯定会想，你们到底有没有效率或者是什么指标的提升，对吧？他首先就要把指标给拎出来，通过指标去衡量。但是我觉得确实可能做这块的老板应该和业务方的老板拉齐一个共同目标，关注这个共同目标的提升，比如说在时长，在 CTR 那些业务上的价值的增量。

接下来我们再来排查问题，这个也能解决刚才那个同学说的问题，比如说我是个新业务对吧。我现在开了 10 个新业务，我给你们一个月时间，看能不能做出来一些东西，我可以所有东西都不考核，因为这个时候我考量的是这个业务能不能露出头来，它露出的话，那接下来是它能不能野蛮增长，它应该考量的是这个，所以应该是一切以业务目标为准。

但如果说这业务已经非常成熟了，我发现又欠了很多技术债，那我觉得这时候应该把考核放在那些技术债上面。像抖音、微信、支付宝这么大的产品，要是出现了一个 bug 或者怎么样，影响的用户面和那个价值大家谁都背不起，所以他只能去检查，把底层的代码都铺垫得非常好。所以我觉得它应该是一个 Guideline，要根据业务发展的不同阶段来使用。为了把这个业务给搞起来，做 DevOps 的老板和业务的老板都应该背着这个业务的目标。

再举个例子，现在大家都知道这个 Feeds 信息流的大盘一定是跌的，但如果说你要在跌的过程当中还能保持你的量不变或者还微微增长，就说明大家是做了很多事情的。这个只是说我们从业务的角度上是可以做这件事情的，但从研发的研发效能角度或 DevOps 的角度，其实我的建议跟刚才那位同学说的还是挺类似的，还是要从业务的价值来看。

嘉宾 Luke ：其实我还一直有个疑问，因为一般我们做业务汇报的时候，比如半年或者年终汇报的时候，我要向老板汇报说我们做了哪些事情带来多少好处是吧，我们收入增长多少，但实际上可能你这半年做的不止这些事情，还有些失败的事情，比如做了没有什么效果或者效果反而不好，这种事情是不是应该也是我们工作的一部分，它验证了我做这个事情是错的，这其实也是价值。

嘉宾 Mike：我刚听到一个观点，所以这里想表达一下。技术研发是否要去背业务的指标，这个点我是打个问号的。 因为业务的指标应该是通过运营和产品他们去决策，专业的事情应该交给他们专业去做。除非我们是做技术类的中间件类的，这些除外。如果我们是做业务研发的话，我觉得业务的价值应该交由他们去判断。研发效能输出的结果应该是怎么样去保证或者推进我们整个研发团队向更好的方向去走，怎么样识别出来我们这个团队目前在哪个环节是比较弱的，要去怎么样调整研发的资源，去补充也好，或者是调整哪一块的能力补充上来。

主持人：您说的这个也非常正确，就是度量的目的到底是为了获得以业务为主的驱动力，还是说要以提高人的能力为驱动力对吧？

嘉宾 Luke：在研发要不要跟业务一起背这个指标这个问题上，我补充一点点吧。因为我自己也是做研发的，我个人是倾向于跟业务一起去背。为什么呢？在座的老师应该很多都是研发负责人，我不知道大家有没有这样的感受，本来是应该产品运营背这个指标，这个是毫无异议的，是不是？但实际上有些产品在把需求提给研发的时候，他根本没有考虑清楚。 那产品无脑地推了，研发就无脑地接了，然后就无脑地不停地做不停地做。然后他丢个功能上去，根本不考虑用户的感受，也不去看后来的数据，我在前后两家公司都见过这样的产品。我个人是比较看重这个东西，你提过来的东西，我不管你是对还是错的，至少要有对业务价值的度量，如果没有度量，你这个需求就不要做了，因为做的没有意义，就像我没有目标地往前走了一步，那一步没有任何意义。所以我个人是倾向于至少研发 Leader ，特别是做业务研发的，当然做平台的另说了，这些 Leader 们要去背这个 KPI，要一起去看这个东西。团队的战斗力提升上来的话，产品功能做得越多，价值可能也带来越多。

主持人：就是说我们作为 Team Leader 需要承担更多的责任，要去了解业务，但是作为一个程序员，他可能只需要写好自己代码就可以了，每个不同角色和感触还是不一样的。

嘉宾 Simon：我看大家一直在去聊一个事，就是度量的问题，但我认为度量是没有任何意义的。我认为做研发效能是因为要做可观测，它不是为了度量而度量的。 为啥呢？因为一旦说一个指标或者说一件事给立下了，那如果说拿它去度量的话，那它必定是反人类的。不管说业务指标也好，或者说技术指标也好，尤其是业务指标这一块的话，它跟外部用户是息息相关的，这个是我持有的一个观点，所以说整个研发效能来说，我更倾向于可观测性。

嘉宾 James：刚才听到几位老师关于度量的一些激烈的讨论，我也想分享一下。我之前是一直在硅谷工作，我上一家公司是在 Facebook，所以我也想分享一下当时 Facebook 是怎么做的。

Facebook 确实也是有研发效能这方面的度量的，包括每一位同学提交了多少行代码，做了多少个 Code Review ，你的写的代码的单元测试覆盖量是怎么样的。有一些度量数据的话，每半年评估的时候是真的会看的，比如说每位研发同学写了多少代码，但是他在看的时候，不至于说完全按照你写的代码数量给你做一个就是 12345 的给你排名，而是有一个三倍原则。我举个例子，我们每一位工程师同学，每半年写一万行代码，只要你处于这样一个大致的阈值上，他们都认为你这个代码量是合格的。但是如果你超过了三倍，比如说平均值是 1 万行，你写的超过 3 万行，或者小于 1/3 的话，那就可以认为你是两边的 outlier 了，对这个 outlier，他们可能在评估的时候会给你做一个加成，或者是给你做一个负面的反馈，但是他不会给你做很定量的排名。

对于普通指标的话，Facebook 更多的是根据每个组不同的情况去看。比如说，我们有一个 10% 时间的原则，每一位工程师，他可能每半年要拿花 10% 的时间来提高整个组的研发效能。但至于这个 10% 的时间做什么是由你们自己决定的。可能会有高阶工程师或者其他同学自发组织研发来讨论，做一些调查，如果认为这半年整个组的单元测试覆盖量可能比较低，要把这个问题解决，那可能这半年的主题就是做这个。

评估的话，Facebook 有一个维度叫研发效能维度，这个维度跟普通的业务指标，比如说 impact 的是平行的，它更多的是看你有没有做一些事情，一般不会特别量化。只要你做了这个东西一般都是没什么问题的。当然如果你做得特别多特别好的话，可能你在这个维度上就会得一个比较高的分。但是它可能更多就是一个相对定性的标准，不是完全通过指标来做衡量的。

主持人：这位老师讲了很多方法，我觉得非常好，尤其我感觉 Facebook 非常相信正态分布是吧。

嘉宾 Pony：我很同意刚才那位老师的一些说法，我觉得可以补充一些。我认为研发效能度量应该是可以自动化而且是客观的，我们不应该去度量一些主观的。比如说需求的预计工时，预计是人预计出来的，你实际完成也是人填上去的，这种本身就有很大的主观性，你即使不干这个需求，你可能这个时间也是拿去做别的事情了，所以这种其实度量我觉得是没有意义的。但一些可以量化的指标，比如说什么 bug 数量，写了多少行代码，你的覆盖率是多少，这种的话我也觉得不应该是作为一个排名，不应该作为一个 List，然后挑最下面的去找他们的责任。而是说我们应该定一个底线的阀值，如果你的 bug 超过了那个数量，或者说你写的代码确实太少了，覆盖率太低了，你可能就会有点危险，可能就是找你了解一下是不是有什么情况导致了你这个阀值没有通过，然后对于一些比较优秀的同学会有奖励，而不应该按照这个排名去把你的 KPI 去作为一个衡量指标。

主持人：谢谢各位，到目前，我们可以默认达成一个一致，就是度量是有用的，但是具体情况具体分析。还有的老师也讲了一些方法和一些度量指标，比如一些人力指标。人力指标也是老板经常用的指标，我投那么多钱，到底产出多少价值，这是我之前所在的一个企业里的老板经常衡量的一个数据，不过后来也被喊停了。那在度量指标这块，各位老师有没有什么想法？比如说你觉得哪些度量指标在某些场景下相对公平或者没有那么公平？

嘉宾 Robin：这个我这边说一下，之前我们团队做研发效能的时候也趟过不少坑。

第一个定的指标，其实是需求的交付速度，就是从一个需求真正到研发人员手上，从第一次宣讲到你最后完成上线，它就算的是一个交付速度，它是以天为颗粒度的。很多传统公司可能就几周或者月尾交付，但是如果在效能底下就全部变成天。第二个指标就是很多公司都在用的就是线上的 bug 率，千行 bug 率或者这类的，这个可能也是一个比较硬核的指标，因为涉及到整个产品。其实还有几个隐含的指标，比如说，高阶的肯定是考核你的代码 CR，什么架构的考核 AR 之类的。日常的话可能考虑更多的就是覆盖率和代码的自动化测试通过的情况，不过这两个其实不是强制的。但真正强制考核的是前面所说的线上千行 bug 率和需求的交付速度。

但是这里面带来一个问题就是需求交付速度是可以作弊的。 我可以把需求拆得很小，比如一个需求原来要花一周的时间做，我填的是一周，我自己一天一天的做，也没什么问题。但如果你要按照天来考核我的话，我就把这个需求拆得非常非常细，我拆成 0.5 天就能交付一个小的 Feature，这样就带来一个负面的效果，就是直接管理成本的上升，另外一个就是你在线上去发布的时候，其实你就发布了一个需求，但实际上你的工单里能看到二十几个东西。

主持人：这位老师刚刚提到一个很好的问题，作弊问题。技术人想作弊那还不容易？那这样度量就变成了数字游戏，覆盖率、发布成功率、发布次数这些都挺容易作弊。那么我们还有什么比较好的指标，大家认为可以比较公平地反映这个效能，它又没有那么容易作弊的？

嘉宾 Bruce：前面我们讨论了一个话题，研发要不要背业务指标。我们有的时候看这个东西和效能没什么太大的关系，但它是衡量效能最好的一个方法，就是向用户去看。比如像刚才说的千行 bug 率，或者是每天写多少行代码或者之类的，这些更多的是我们内部的一些指标，内部的指标有可能是个内耗，但也有可能它是失败的或者是成功的，这些数据没办法反映我们这个团队组织的效能。团队组织的效能，我的理解是我们给用户交付足够多的高质量的需求。

举个简单的例子，一个研发，不管他每周或者每个月写了多少行代码，假如这个特性组交付的需求代码质量都非常高，需求理解得都非常好，有可能他这个特性交付出去，客户二次开发的需求就非常少。再比如像市场端，他要去探索新需求，那新需求可能来得也不是非常及时，那个时候它的代码量肯定会少。包括刚才说的通过自动化去构建它的这个质量体系，那还是会有一个平衡的问题。如果我们过多关注于质量，那我们对外交付的需求就会变少是吧，它总是有一个平衡点。

那我觉得这个标准应该是满足客户的需求，这个需求是从向外的一个视角去看，而不是就聚焦在内部的一个视角，内部视角很难评判。晚场讨论开始前，主办方抛出了一个话题，说有些需求简单，有些需求很难，要怎么公平地度量，如果我们最终是以面向客户的视角去看待这个需求的话，我觉得就是统一。

主持人：因为每个需求都不一样，或者每个业务的需求都不一样，我怎么判断出我这个团队对业务支持得好还是不好呢？

嘉宾 Bruce：就是你这个需求交付出去，对你这个产品或者组织产生了价值，那价值怎么反映呢？就是你挣的钱能不能养活你这个组织。我举个简单例子，假如一个组织很牛逼，全是大牛，全是 Google 过来的一帮大神，算法什么的，整个架构很牛逼，但是你做的产品卖不出去，那你这个效能就是 0，这是我的一个评判。假如我要是老板的话，就是这个组织就是个 0。

主持人：然而现实生活中团队肯定是参差不齐的，团队并不是每个人能力都很强，但其实 DevOps 还有一个目标就是提高个人能力，对吧？

嘉宾 Bruce：我更多的觉得 DevOps 就是一个思想，就是怎么快速地把需求交付出去，工具支撑什么的只是其中的一些手段。没有 DevOps 之前大家做的也是这些事，只是当时没有把这些事情串联起来。我们的最终目的就是交付需求，敏捷为什么从瀑布往敏捷去转，那也是需求交付慢了，满足不了市场的变化。为什么现在要 DevOps 也是因为我们的这个工具流或者工具箱不足以支撑我们更多更高更快地把需求交付给客户，所以我们需要更多的这种工具协助我们去交付这个需求。如果我们把这个目标又合计到原先那个内耗的数据指标上，我觉得就是已经脱离了这个 DevOps 或者敏捷的原意了。

主持人：敏捷和 DevOps 很多时候都强调要以业务为价值，这个肯定是的。

嘉宾 Scott：基于刚才他讲的，其实我有个建议。这上面存在一线员工和老板的目标不一致的冲突，所以我觉得这上面应该分两种。第一种就是底线思维。首先，大家写的代码可以相互看得懂，也就是说代码规范这事情一定要落地，这是非常底线的东西。刚刚 Facebook 回来的老师介绍了三倍原则，如果你的写的代码都小于 1/3 的指标数值了，那这也是个问题。第二种，最简单的，以钱来衡量，看看这件事是不是值得花钱做，新业务就野蛮生长吧，先增长起来再说。

主持人：  

对，不同的角色或者在公司不同的阶段，咱们需要考虑的东西肯定也是不一样的。

主持人：  

好的，时间也差不多了，我们今天的讨论以各位老师的自我介绍开始，最后就以总结为结束吧，每个老师，咱们每个人花十秒钟说一下你对这个度量的总结或者你的观点好么？

嘉宾 Simon：听到各位大佬的发言，我觉得业务导向是一个很重要的点，然后，不要内耗。

嘉宾 Pony：我的观点就是可以量化，可以自动化，然后不要内耗，不要排名。

嘉宾 Bob：我的观点就是这个东西还是要用工程师文化作为牵引，不要弄成 KPI 作为度量。

嘉宾 Scott：业务增长创造价值是第一要素。

嘉宾 Frank：我的观点是第一性原理思考，就是业务要增长，员工要发展，然后我们朝这两个目标去引导度量指标。

嘉宾 James：我的观点是，这个度量是要有的，但是要聪明地、灵活地去运用。

嘉宾 Mike：我的感觉是业务应该是第一的，度量其实更多是给个人的提升，不应该是拿来衡量的 KPI 这种事情。

嘉宾 Bob：我的观点其实是度量可以有，但是我们之所以会遇到反弹，是因为我们有一些地方没有达到价值的统一。我们可以挑一些公认的指标，比如刚刚说的千行代码 bug 率，加上业务的复杂度可能会更好一点。推行这些指标的时候要跟员工说明，我们是为了提高大家自己的能力，而不是为了考核大家，这样子的话可能推下去的时候会更好一点。在真正实际落到实处的时候，也要尽可能以提醒或者说辅助他去找工作习惯上的问题为主。这样子多了之后，他就会感觉到这个工具其实是来帮助提升自己的个人水平的，就不会那么抵触了。

嘉宾 Simon：我的观点就是以人为本，不要卷。

嘉宾 Luke：我的观点是，所有员工不管是运营产品也好，还是研发也好，都是应该为用户创造价值，而度量只是我们的一个工具、一个方法而已。

嘉宾 Frank：我直接分享我的做法，刚刚有老师提到了一个情况，我又希望你找出 bug，你找出来，我又记你一笔。那这怎么办呢？我的做法是，有 bug 就表示是团队组织流程的问题，也许是流程不够，也许是测试不够，这一种 bug 应该记在团队上，记在主管上，让整个团队去背负那些对个人来说不合理的指标。但是个人的指标呢，我希望你能够找出解决方案来，怎么精进，怎么去做提升，然后配套一些团队内部的个人激励，来达成一些对外沟通必须的指标。

主持人：非常好，除了吐槽，今天我们还看到了一些 Solution。

嘉宾 Mike：我的观点就是，研发一些东西不要影响到线上业务，不要因为技术缺陷而导致业务停滞不前，影响到业务，然后我们通过研发效能来激发整个团队的技术成就感。

嘉宾 Cherry：我也是赞成以业务那个角度去度量，度量的话还是以底线为准，不要做惩罚。

主持人：对，不要做惩罚，那可不可以有激励呢？

嘉宾 Cherry：当然。

嘉宾 Evan：我是后面中途过来的，我的观点是这个度量还是得有的，但是它确实不好做。其次，我觉得要做的话，需要大家一起过来商量，定好一个标准，这个标准不仅是要为了公司好，还是为了所有员工都好，这样就会觉得度量就不算是很坑。

嘉宾 Robin：这个巨坑，不管坑大还是小，我觉得最关键都要驱动业务。如果我们研发的技术不能驱动我们的业务，不能帮我们的业务去增长，这个坑是没有意义的。

嘉宾 Bob：我觉得这个的度量也是要以业务为驱动的，但是也要加上一种员工的自驱动，这个是我的观点。

嘉宾 Mike：我和刚刚这位老师的想法是一样的，应该以业务驱动，然后当然员工个人也是要有自己的想法喽。

嘉宾 Cherry：我觉得其实最重要是先拿到数据，先把数据可视化出来。度量为什么很重要，是你老板想用这个度量去推动什么，这个动因是很重要的。

嘉宾 Robin：第一个我还是赞同大家的，以业务价值为导向。第二个，一定还是要有度量，但度量数据肯定主要是 follow 整个团队的技术方向，为业务提供增长。第三个，效能其实是一个系统功能，它涉及到人、流程、工具的协同，所以我觉得这个东西国内确实到现在都很坑。

嘉宾 Josh：把度量作为一种观测指标，从这里面找出研发效能到底存在什么问题才是度量的意义，不然就有点把手段变成目的了。

主持人：好，谢谢各位。我稍微总结一下大家的观点，如果不对，大家给我指出。第一，大家都觉得度量肯定是要有的，偶尔有一两位不认同的，我觉得也是有一定道理的。第二，我们可能需要具体情况具体分析，度量也是要以业务为驱动为主，最终还是要得看到业务价值。第三，以人为本，不能搞得大家不开心，搞得大家去抵制度量。可能每个角色站的位置不同，看度量的本质也不同，用法也是不同的，但我们不能把度量变成一个错误的事情。

没有来到 QCon 广州现场的伙伴不要遗憾，9 月 17-18 日，QCon 将在北京富力万丽酒店继续带来精彩内容。QCon 北京站内容涵盖前端新基建与前沿技术、WebAssembly 的落地进展、Rust 实战与语言实现、数据湖存储底座、资效平衡的架构设计、云原生微服务架构新趋势、云原生时代的可观测技术落地、测试环境治理、云原生架构变革、AI 基础架构、开源运营、分布式数据库、下一代大数据系统、业务安全合规、工程师成长实践、研发效能提升、DevOps、移动生态、基础设施运维……来自华为、腾讯、百度、阿里、蚂蚁、火山引擎、网易、美团、快手、小红书、涛思、OPPO、大疆、德邦、华泰证券、PingCAP、OpenResty、Second State、DCloud 等国内外一线大咖分享 100+ 精彩演讲，点击底部【阅读原文】直达大会官网。

大会门票优惠倒计时中，组团购票享更多折扣，感兴趣的同学联系票务经理：15600537884（电话同微信）。