极客时间已完结课程限时免费阅读

02 | 效能度量：效果不好甚至有副作用，怎么回事？

02 | 效能度量：效果不好甚至有副作用，怎么回事？-极客时间

02 | 效能度量：效果不好甚至有副作用，怎么回事？

2019-08-26 葛俊 来自北京
《研发效率破局之道》
课程介绍

讲述：葛俊

时长14:27大小13.23M

你好，我是葛俊。今天，我来和你聊聊研发效能的度量。
在和技术管理者，尤其是高层管理者聊起研发效能的时候，常常提起效能的度量这个话题。管理学大师彼得 · 德鲁克（Peter Drucker）曾经说过，“一个事物，你如果无法度量它，就无法管理它”（If you can’t measure it, you can’t manage it）。要想提高研发效能，自然要首先解决效能的度量的问题。
在软件研发过程中，数据驱动的手段被大量采用，比如说通过使用漏斗指标和 A/B 测试，用数据来指导产品的方向。按理说，软件开发行业是数据驱动的高手，用数据驱动来理解研发效能应该早被研究透了啊。
但事实上，效能的度量却是一个出了名的难题，至今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此，绝大部分软件公司在使用研发效能度量这个工具时，不但没有起到正向作用，还伤害了产出和团队氛围。
所以，在今天这篇文章中，我就与你一起看看研发效能度量到底是什么、常见错误，以及度量困难的原因。

研发效能度量的定义和作用

首先，我来介绍一下效能度量的定义和作用。
研发效能的度量代表一组可量化的数据或参数，用来跟踪和评估开发过程的“健康”状况。 换句话说，研发效能的度量，从应用程序开发的生命周期中获取数据，并使用这些数据来衡量软件开发人员的工作效率。我们希望通过这样的度量，能够根据客观的数据而不是个人的主观意见去决策，从而实现以下几点：
跟踪团队的表现、提高团队的绩效。通过确定研发效能指标，公司可以明确团队和成员的工作预期，从而使得开发人员能够目标性更清晰地投入研发。同时，这些生产指标可以作为“晴雨表”，帮助团队定位影响工作效率的不良因素，从而帮助团队消除这些因素，最终达到团队更快乐、绩效更高的目的。
提高项目计划的精确度。团队负责人可以通过度量来估算一个需求端到端的成本，包括收集成本、设计系统成本、开发测试成本，以及运维成本等，来了解每项活动在项目总成本中的占比，从而更好地确定这些活动的优先级。同时，我们可以了解哪些步骤有较大风险和不确定性，从而提高预测项目进展的精准度。
了解流程是否高效，寻找需要改进的关键领域。我们可以衡量进行每项研发活动所需的时间，并估算其对质量和生产效率的影响，然后比较成本和收益，最终确定哪些步骤是高效的，以及哪些步骤是需要改善的。我们还可以对不同的实践进行 A/B 测试，以此来选择更好的方法。
提高团队绩效、提高计划精确度，以及寻找关键的待改进领域，这三个因素的结合有助于简化工作流程，发现瓶颈，帮助团队持续改善现有产品的生命周期，从而更高效地生产出质量更好的产品。

效能度量的错误案例

因为上述作用，绝大多数公司都非常重视研发效能的度量，并且基本上所有公司都或多或少地采用了度量。但遗憾的是，能够将其用好的公司少之又少，而且我见到的公司中还存在大量误用的情况。
接下来，我与你分享一些真实案例，我们一起来看看它们错在哪里，以及可以如何调整。

案例 1：全公司范围内推行一套效能度量指标

某大型公司为了提高效能，专门成立了一个不小的团队，通过详细调研，制定了一组研发效能度量指标，并引入和开发了相应的工具。客观来讲，这些度量方式的质量很高。
准备就绪后，这个公司找了几个团队做试点，把这些效能度量数据作为参考提供给它们使用。三四个月下来，试点效果不错，这几个团队的产出速度有了一定的提高。于是，公司高层决定在全公司范围内推行这套方案。
但，随着大范围的推广，一些团队发现，它们的研发流程跟试点团队差别较大，需要花费相当多的时间去收集度量数据，受益却不明显，甚至是得不偿失。
更极端的情况是，有一个团队的开发环境和这套效能度量工具的环境差别实在太大，所以不得不专门为这个工具部署了一个环境。然后每周六，他们就要到这个环境里，为度量系统提供数据，还常常被迫提供一些“假数据”，以满足度量系统的需求。
因此，这些团队觉得这套方案并不适合自己，公司内逐步出现了些许反对声音。但是，公司推进这套流程的态度非常强硬，为了顺利推进，还把这套流程与团队绩效绑定到了一起。一旦某个团队的指标未能达到要求，就直接实行绩效扣分。由此，效能度量的负面作用逐渐凸显。大量团队为了好的绩效，而被迫去玩数字游戏。
全公司范围推行这套方案的一年多，可以说是怨声载道。明明是一套高质量的度量系统，却阻碍了团队业务的发展，并严重伤害了员工的积极性。直至最后这个实际情况被反馈到一位高管那里，这套度量系统才被完全取缔。

案例 2：一个中型公司推行质量方面的指标

一个 500 人左右的公司，公司的组织架构按照职能进行水平划分，并没有进行矩阵式管理。为了提高公司的产品质量，QA 团队提出了一组软件质量方面的度量指标，包括 Bug 严重性定义、每一个发布里不同级别的 Bug 的未解决率，以及上线的一些质量流程。QA 团队得到了公司高层的支持，强制推行这些指标。
这些指标针对的主要是开发活动，但开发团队却认为，这些度量用处不大。他们认为，公司研发过程中的真正问题在于产品定义变化过快，常常是在冲刺开始后还不断更改需求。这就导致开发和测试团队即使拼命加班还常常错过发布日期，产品的 Bug 也不少。所以，开发团队提出，真正应该度量的是产品需求的稳定性。但是，公司高层认为需求变化是为了满足用户需求，所以没有批准开发团队的这个要求。
结果是，研发人员觉得公司效能度量只是用来束缚他们的，根本不能帮助他们工作，于是工作积极性下降，离职率上升。同时，产品质量也并没有因为这些度量指标的推行而提高。直到我写下这篇文章的时候，这个公司还是这个情况。

案例 3：某创业公司聚焦度量开发、测试、上线准确度等指标

一个由 10 多个人组成的、拿到了 Pre-A 投资的创业公司，正处在研发产品寻找市场吻合度的阶段。掌权的 CEO 和产品副总坚信数据驱动，于是对研发流程定义了严格的度量和指标，比如 App 上线周期准时率、Bug 的关闭速度、性能参数，等等。
整个团队很专业，也很敬业。他们花了很多精力去严格完成这些度量指标，做到了绝大部分情况下准时、高质量地上线产品。但是，CEO 和产品副总并不是产品专家，只关注了开发过程中的数据，却没有收集其他步骤的数据去快速试错和寻找产品方向。
结果就是，虽然产品的每一个发布都很准时，质量也非常高，但因为公司在寻找市场需求吻合度方面动作迟缓，导致用户增长缓慢。因此，一年半以后，资金耗尽，投资人失去信心，公司倒闭。
这 3 个案例只是不同规模公司的几个典型场景，类似的失败案例数不胜数。那么，上面这些案例的问题出在什么地方？效能度量为什么这么难？

效能度量被大量误用，问题究竟出在哪儿？

研发效能难以度量的最根本原因在于，软件开发工作是一项创造性很强的知识性工作，非常复杂且伴随有大量不确定因素。
比如，软件产品的需求变化很快，需求文档的更新常常滞后于工程实现，甚至有的敏捷方法论提倡完全抛弃需求文档。
又比如，软件产品的实现方式有很大的不确定性。一个相同的功能，可以采用多种语言、框架、平台，使用各种不同的研发流程生产出来。在这种情况下，我们很难通过度量来衡量这些不同研发方法和中间过程的优劣。
面对这样的一个复杂系统，我们不可能覆盖其全部参数。而如果这时，研发人员的利益和这个度量结果相关，那么他就很可能会通过“做数字”来欺骗度量系统。
关于这个主题，美国著名学者罗伯特 · 奥斯汀（Robert Austin）写过一本书，叫作《衡量和管理组织绩效》(Measuring and Managing Performance in Organizations) 。他在这本书中给出的结论是，如果你不能度量一个事物的所有方面，那就不要去度量它。否则，你将得到“做数字”的欺骗行为。
这里有一组有名的 Dilbert 漫画，讲的是一个公司宣布使用 Bug 修复数量做度量，每修复一个 Bug 奖励 10 美元，消息一出，开发人员欢呼雀跃。一个程序员当场表示，当天下午就要给自己写出一辆汽车，因为他很容易就可以写出很多简单的 Bug，然后马上去修复它们。
通过这个例子，我想要和你说明的重点是：度量与绩效挂钩，结果是指标上去了，却没给软件产品带来任何好处。
备注：图片来自https://dilbert.com/strip/1995-11-13
而我刚刚和你举的大型公司全公司范围内推行一套度量指标的案例，正是犯了度量与绩效挂钩的错误，这种情况下，很容易出现“做数字”的不良行为。这也是使用度量时最常见的错误，我们一定要留意。
研发效能难以度量的第二个原因，和上面提到的根本原因相关，但有其特殊性。很多公司有竖井（silo）存在，所以常常会把注意力放到某一两个竖井上，进行局部优化。但是，局部优化并不代表全局优化，甚至会让全局恶化。
上面那个中型公司推行质量方面指标的案例，就是在进行局部优化，不但没能提高产品质量，反而导致员工积极性受损，同时影响了团队之间的关系。
这样的问题，在按职能划分团队的公司很容易出现。因为在这样的组织划分下，更容易出现竖井，自然就更容易按照竖井来考虑小团队的表现。如果你的公司基于职能划分，一定要多加留意。
研发效能难以度量的第三个原因在于，度量指标一般用来度量软件产品的生产过程和产品质量，但是公司真正需要关注的是产品能否解决用户问题，也就是说能否产生用户价值。技术产品输出和用户价值输出之间的沟壑难以打通。
上面案例中那家创业公司聚焦度量开发测试指标，就是犯了这样的错误。产品质量再好，发布再准时，如果没有用户价值也是白费工夫。
当然了，研发效能难以度量还有一些其他原因，比如：
度量数据的收集难易程度不同，人们倾向拿容易收集的数据去关联效率，但事实上难以收集的数据对度量可能才真正有用。比如说代码行数容易衡量，但是用处很小。相比之下，产品用户价值的度量要困难得多，但用处却大得多。
软件开发和实践有一个滞后效应。比如，在团队中引入代码审查，在刚开始实行的时候，总体效率会出现短时间的下降，一两个月后才会逐步显现正面效果。那么，你现在要怎么度量它才好呢？

总结

在今天的分享中，我给出了效能度量的定义及作用，列举了三个典型的失败案例，并通过这几个例子和你详细分析了度量困难的几个主要原因。
研发效能的度量一直以来都是个难题，很多业界大佬也都发表过“研发效率不可度量”的观点。比如，马丁 · 福勒（Martin Fowler）在一篇叫作“无法衡量生产效率” (CannotMeasureProductivity) 的文章中指出：这是我认为我们必须承认无知的地方。
周思博（Joel Spolsky）在一篇名为“飙高音”（做到最好，Hitting the High Notes）的文章中写到，衡量程序员的工作效率相当困难，原因如下：
几乎任何你能想到的指标（比如，调测过的代码行数、功能点、命令行参数的个数）都很容易被“做数字”；
我们极少要求两个程序员做完全相同的事情，所以很难获取大型项目的有价值度量数据作为参考。
那是不是说在研发软件时，我们就不能使用度量效能的方法来指导工作了呢？如果是的话，这对于软件团队管理者而言，将会是一个难以接受的事实。
这个问题的答案，我们就留到下一篇文章再揭晓吧，敬请期待。

思考题

你在工作中有没有经历过研发效能度量的失败案例？如果有的话，你觉得失败的原因是什么？关于度量谜题怎么解决，你有没有什么建议？
感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 5

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01 | 效能模型：如何系统地理解研发效能？
下一篇
03 | 效能度量：如何选对指标与方法，真正提升效能？
 写留言

精选留言(27)

  • 陈大宏
    2019-08-27
    代码行数和 bug 数量这两个无聊的指标。居然都在公司的绩效考核中出现了。无语。

    作者回复: 根本原因是：不知道怎么样度量开发人员的绩效。就是用了这两个指标作为Proxy。

    共 7 条评论
    13
  • 囧囧冰淇淋
    2019-08-26
    1.研发效能的定义和作用 研发效能的度量，从应用程序开发的生命中期中获取数据，并使用这些数据来衡量软件开发人员的工作效率。 主要为实现三点： 1.跟踪团队的表现、提高团队的绩效。 2.提高项目计划的准确度。 3.了解流程是否高效，寻找需要改进的关键领域。 达到度量目的：简化流程、发现瓶颈、帮助团队改善产品生命周期、更高效地产出质量更好的产品。 理解：关注团队的表现，团队的成长；关注项目的准确性，不要经常走弯路；关注流程的高效，实现迅速，也方便新人快速加入。 工作都是人去做的，首先关注人、团队，而不是数字。关注人，给予团队支持和信心，即使走错路了，大家会一起想办法一起努力。关注数字，人和团队就可能发生数字造假或者数字失效，比如案例1和3。 个人碰见的数字造假： 客服团队造假。某天，老板想优化下客户服务，从客服下手，根据行业标准定出了一个指标，询单转化率、回复率、回复时长、未回复数，这些指标再分解成工资。老板十分鸡贼，算了下认为这可以提高客服工资，店铺转化也可以提升，双赢。然而客服团队一算，只有达到一个高标准，才会比以前工资高，只有平均就比以前差几百。客服们很抱怨，但当面也说不赢老板，于是发明了过墙梯：对于回复率呢，以前一句话说完，拆成2-3句。回复时长使用表情大法，先来一个表情缩短时间。最后客户服务没有优化，转化率也没提升，客服团队怨声载道，当时能力有限，感觉也对不起他们。
    展开

    作者回复: 你认真学习，不断追求进步的样子真是棒！！ 你讲的客服例子很有意思。我记得以前好像是亚马逊还是哪个公司的客服也出现过类似的事情。

    共 4 条评论
    11
  • 西西弗与卡夫卡
    2019-08-26
    写的很好，有点等不急，好想催更

    作者回复: 多谢支持！后面有问题建议欢迎啊 😀

    5
  • stefli
    2019-08-27
    我们目前是基于scrum的软件数据来粗略跟踪一些执行过程数据。包括：每个迭代的周期数据，估算与实际登记数据，线下和线上Bug数据，Bug分类数据，团队成员任务及估算、实际工时等。从这里也能看出一些信息： 1. 估算与实际操作之间耗时是否匹配，准确度是多少，基本在70-80之间，除了造假数据。造假的化可以拿每日登记情况进行粗略判断 2. 每个职级团队成员的大致行为，比如单位用时产生的Bug数量，每个迭代的平均任务数，Bug等，包括大致每个任务的平均估算时间。有的大概在3-6小时一个任务，拆分越小越容易把控进度。有的团队平均是8小时一个，时间会比较“充裕“ 3. 随着质量团队和研发团队质量意识的提高，月度Bug或线上Bug有减少，质量在提升。临界点尚未得到，到时再观察任务数、估算等数据 总的来说，数据可以来自多方面，至于如何去用，还需要更多的研究和分析
    展开

    作者回复: 我的经验是这些数据可以用作参考，帮助团队改进，但是不要跟绩效直接挂钩。 “随着质量团队和研发团队质量意识的提高，月度Bug或线上Bug有减少，质量在提升。”这个就是度量可以用来参考，它显示出来一个趋势。👍👍 （不过要注意单个指标有的时候可能不全面。比如bug减少，会不是因为功能减少等其他原因？当然这只是随便的一个例子。）

    4
  • 菜头
    2019-12-27
    能效=有效工作/单位时间+偏差 有效工作可以是用户故事点衡量的任务（需求，架构，开发，测试等） 单位时间单位为人日（根据能力，有些人可以是5小时，有些人可以是10小时） 偏差可以是 用户价值，生产品质等 完美。哈哈

    作者回复: 👍👍👍

    3
  • 🌀Pick Monster ...
    2019-08-27
    我们公司现在受制于客户，每月要求1000行代码量达标，我作为基层管理，主要代码都有团队成员编写，而我除了客户对接，需求分析和算法设计之外则主要编写关键点和优化点代码，每个月代码量都无法达标，给领导各种解释啊。而且公司严管外网访问，我作为团队首领也是没有外网权限，只能有手机查看需要的资料。这样的开发环境很难高效开发。

    作者回复: > 每个月代码量都无法达标，给领导各种解释啊 领导能理解吗？1000行代码量是客户要求的吗？如果你能说服你领导你的工作提供了足够的价值，问题只是客户那边不理解的话，那就比较好办。说服客户，或者可以把一行分成两行写。如果你不能说服你的领导，就比较麻烦了。 > 只能有手机查看需要的资料。这样的开发环境很难高效开发。 这个的确是麻烦。可以花点时间研究一下手机上学习的工具。同步手机和电脑的工具应该是比较有用。比如：Pocket(https://getpocket.com)用来记住感兴趣的URL，Evernote，Mac Note，OneNote，等等用来记笔记，讯飞输入法可以记录有声笔记，等等。

    共 4 条评论
    3
  • 荒野之望
    2019-09-24
    度量如果是基于成功OKR的，会发生什么？

    作者回复: OKR的使用。也有一个重要的原则是不要把它的度量和绩效强挂钩。 我的理解，OKR更是一个目标对齐的工具。

    共 2 条评论
    2
  • Anders
    2019-09-02
    请教老师：实际工作中有的「需求」简单改几字就可以交付花个几分钟，有的「需求」要修改很多地方，耗时可能上月，这时如何评价效能？假如有的尽是前一类需求，有的团队都是后一种，组织层面如何公平的来度量不同团队的效能？

    作者回复: 这种情况，如果指望客观的数据是行不通的。我的经验是只能考管理者主观的判断。组织层面必须要能够给做脏活累活的团队足够的认可。

    2
  • 仙女的猪
    2019-08-27
    指定流程、标准、考核指标以及选择适合的工具，搭配好了可以爆发出巨大的效能 只可惜很多时候，是自上而下的管理，不懂基层真正需要什么，而做了错误的决策，导致一系列问题

    作者回复: 这种情况，如果管理者心态开放，能接受改变和改进，还有一些办法，比如在底层做出一些东西，让管理者看到能解决关注的问题，会有一些正面的效果。如果管理者自认为自己懂，那就比较难了。

    2
  • 有学识的兔子
    2019-09-03
    常见研发效能度量失败的案例应该归属量化的绩效考核，为了追求较好的绩效指标，采取以绩效指标为目的的工作方式，导致忽视了本职工作，也间接伤害了那些以团队利益为出发工作的员工。 对于度量，没有经验，但个人觉得团队度量会比个人度量更好一些，促进团队的成长，也促进了个人发展，同时增加一些个人奖项，激励某方面能力突出的员工。

    作者回复: > ...但个人觉得团队度量会比个人度量更好一些，促进团队的成长 说的非常对！

    1
  • 大河
    2019-09-03
    尝试在前端团队中推行Code Review，每个项目分配一名同事和一名主管负责审核，主管还是比较负责，能够提出一些问题，另一名同事则比较敷衍，整体的Review效果并不理想，但如果强制要求每次Review必须提出问题，又有点过于死板，不知道有没有比较好的方式方法，可以借鉴

    作者回复: 后面会有两篇文章专门讨论代码审查。敬请期待 ：） 针对你的描述，我觉得比较有效的代码审查不应该是集中式的，而应该是p2p的。也就是说，开发人员之间互相审查，而不是有专门的人来审查。

    1
  • 张普
    2019-08-29
    接手前人的代码，不断补坑，bug修复的多，没有新需求

    作者回复: 我的一个好朋友，在Google工作10年，技术过硬。关于维护别人的代码，他推荐这本书： 英文版： Working Effectively with Legacy Code https://book.douban.com/subject/1428943// 中文版： 修改代码的艺术 https://book.douban.com/subject/2248759/

    1
  • 寒光
    2019-08-26
    大概的准确胜过精确的错误，放任不管，让团队自由发挥，如果是BAT这种大厂的自有研发人员，OKR当然没问题，反之，就肯定行不通。期待接下来的课程。

    作者回复: 肯定不能放任不管。如果工作跟团队方向不对，产出达不到预期，Facebook这些公司砍人是很果断的。专栏最后一个模块，我会介绍一些绩效考评相关的内容。

    1
  • ヾ(◍°∇°◍)ﾉﾞ
    2019-08-26
    问题复杂之后方法需要使用完全不一样的工具了，比如今天的深度学习使用了完全不同于传统算法的办法，虽然说可解释差，但是还是有一些好和坏的准则的。就像现在提倡okr而不是kpi，鼓励共同成长，相互尊重，分享收益等都是很积极的应对措施，还有更用心的过程控制不可缺少

    作者回复: 👍👍

    1
  • 葫芦娃
    2023-02-06 来自上海
    效能度量：在研发过程中，通过数据来反映开发人员效率，而非主观意愿。 作用： 1.提高团队表现，提高团队效率 2.提高项目计划的准确度 3.了解流程是否高效，寻找需要改进的领域 为什么难以度量？ 根本原因：软件开发本就是一个高创造性的知识性活动，伴随着复杂性和不确定性 具体原因： 1.度量和绩效挂钩，很容易变成“做数字”游戏 2.如果只做局部度量，强逼局部来解决全局的问题，会给局部带来反作用 3.度量数据只能度量开发效率和质量，但不能解决用户问题，不能产生用户价值 4.度量数据难以考虑全面，并且有效数据获取难度特别大。
    展开
  • 葫芦娃
    2023-02-06 来自上海
    代码行数是最没有用的度量指标，甚至是反向度量指标 当一个复杂系统，因为设计方案不合理，随着一个次次迭代，系统最终变成一个到一个高耦合、低内聚的状态，这时候会发现，更改一个地方就影响巨大，要写大量的代码填各种不可预料的漏洞。 所以，我通常认为代码行数在某些情况下是技术方案不完善引起的。
    展开
  • Geek_PM
    2022-11-19 来自河南
    我们公司的效能组居然在收集代码行数，代码提交频次，这些就很容易造成造数据问题，本身团队都在努力提高代码质量，但是现在下面开发都不知道怎么搞了，本身软件开发一个功能，有写几行代码搞定的，也有需要写上百行代码的，这能说代码行数多就算高水平开发？
  • 阿甘
    2022-04-01
    What you measure is what you get.
  • Geek_d2f150
    2020-07-31
    我们现在就有修复bug进行奖励的措施。严重bug修复奖励100米，超时未修复要通报，现在每个迭代bug回顾会议都加入了领奖环节，写出严重bug变成一件挺开心的事情。

    作者回复: 艺术源于生活而高于生活

  • 桥墨
    2019-10-27
    那到底该如何考核程序员，效能组成员呢

    作者回复: 在Facebook度量开发人员东公司的贡献度（impact）。具体度量主要是采用360度绩效考评系统。我在最后一模块“管理和文化”中会介绍。