为什么说开发者指标是不可靠的?

如果你曾经管理过软件项目,你可能会问自己:我们团队如何才能更快地前进?现在前进的速度有多快?

面对这类问题,我们倾向于依赖指标。毕竟,我们在开发软件时经常并且已经成功地使用了指标。我们有性能、生产负载和运行时间指标,还有一些基于用户行为的指标,如转化率和留存率。这些指标不仅提供了可见性,更重要的是,它们创造了一个反馈循环。为了对一些东西加以改进,我们可以做出一个变更,并用指标来衡量改进的程度。开发者的智慧告诉我们,每一个软件性能优化都必须从指标开始。

既然指标如此有用,我们就不能把它们应用到软件开发速度中吗?既然更好的开发过程应该要给开发输出结果带来改进,那么输出结果指标应该就可以度量开发过程是否真正得到改进。那么,我们可以使用哪些指标呢?

在这方面,我们没有什么好的指标

开发速度是指单位时间内产出的工作量,所以我们需要同时衡量输出和时间。衡量时间很简单,但工作量如何衡量呢?工作量的衡量跟软件本身一样古老。多年来,有一件事一直亘古不变:每当我们决定用一个指标来衡量工作产出时,一些意想不到的事情就会出现。考虑以下这些例子:

  • 代码行数——这可能是最古老的一种指标,但如今几乎没有人把它当回事。把代码行数作为衡量指标只会让代码变得臃肿,而且开发者只会专注于完成简单的任务;
  • 提交次数——这样会鼓励开发者将代码提交分解为多个部分。同样,开发者会更关注简单的任务,避免去解决复杂的问题;
  • 完成任务的数量——这样会导致任务被分割成更小的子任务。每一个问题,即使是小问题,都是作为任务提交的。这也会促使你走捷径,以最快的速度完成任务;
  • bug 的数量或 bug 的百分比——这不是工作输出指标,而是工作质量指标。这样会阻止开发者做出变更,并让他们不愿意报告自己发现的 bug;
  • 工时或故事点数——当估算变成衡量团队表现的手段,那么很容易就可以猜到接下来会发生什么——夸大的估算;
  • ……

开发者很聪明,他们擅长解决复杂的问题。对于指定的指标,他们都会找到最简单的改进方法,但很可能与工作质量或期望的项目结果不相关。但这并不意味着开发者就一定会这么做,我认为这取决于具体环境以及动机有多强。但有一件事是确定的——开发者将意识到他们的生产力衡量方式与重要的事情是相脱节的。这不仅令人感到沮丧,也会让他们在做真正的工作时分心。

为什么会这样?

为什么指标对于软件产品如此有效,而对于开发者的输出却不适用呢?这是开发者的阴谋吗?实际上,如果你观察一下软件开发之外的领域,你会发现更多例子,它们可以说明指标适用于哪些方面以及不适应于哪些方面。

指标适用的地方:制造和销售。以杯子的制造和销售为例。你可以测量产量(比如每单位时间生产的杯子数量)和质量(无法通过质检的不合格杯子的百分比)。在销售方面,你可以衡量销售额和利润率。这些指标对管理来说都非常有用。例如,制造部门的目标可以是提高成功通过质检的杯子的百分比,同时保持较低的单位成本。销售主管的目标可以是增加销量或提高利润率。这些指标的改进对业务是有好处的,因此我们也可以将其作为相应部门效率的衡量标准。

指标不适用的地方:科学产出。科学家们通过论文来发布他们的研究结果。现在科学界也有了一些衡量工作产出和质量的指标:发表论文的数量、被引用的次数、研究结果的统计学显著性。我们可以说发表 10 篇论文的科学家创造的价值是发表 5 篇论文的科学家的两倍吗?这是不太可能的,因为研究成果的价值是有差别的。即使不使用这些数字,通常也很难说哪项研究成果更有价值。因为论文数量和引文次数造假在科学界是一个众所周知的问题,它们并不被认为是衡量工作效率的可靠指标。统计学显著性也有问题——P 值篡改(p-hacking)是一个广泛存在的问题。

两个关键标准

在任何情况下,有效的指标都应该符合两个重要的标准:

  1. 它们与价值直接相关;
  2. 这些价值具有一致性,即可以用可互换的单位来表示,并具有可数的数量。

让我们来看看上面的例子:

制造和销售的指标符合这两个标准。在杯子的例子中,价值用杯子来表示。因为是大批量生产,所以杯子是一样的。在销售的例子中,价值是以美元来衡量的。业务目标是赚钱,所以钱与业务价值具有直接的关系。因为一美元可以等价其他任何一样东西,所以基于金钱的指标可以衡量恒定的价值。

科学产出的指标不符合这两个标准。我们找不到一个可以直接衡量科学研究结果价值的指标。我们只有间接的指标,比如论文和引用的数量,但这些都可能被篡改。无论如何,这些指标也不具有一致性,因为所有出版物都不是由可互换单位组成的。

开发者指标不符合这两个标准

我们需要用什么来衡量开发者的输出?代码行数、提交次数、完成任务的数量、工时、故事点数……如果将这些指标与上述两个关键标准对照一下,你会发现:

  1. 它们都与价值没有直接关系。我们不会向客户交付代码行数、工时或故事点数。他们不关心我们提交了多少次代码或完成了多少任务;
  2. 所有这些衡量结果都不具有一致性。这一次提交并不等于另一次提交,这一行代码的价值与另一行代码的价值不一样,所有的任务也都是不一样的,工时和故事点数都是估算出来的,具有不准确性。

毫无疑问,这些指标都不能很好地发挥作用。

为什么我们没有与价值直接相关的开发者指标?同样的,我们也没有给科学家用的指标。开发者就像科学家一样,总是在创造新的东西。他们不会一遍又一遍地写同样的代码——那样没有意义。代码可以被重用——可以将它们提取到模块或库中,或者直接复制粘贴。每个开发者的工作都是独一无二的。即使他们解决了相似的问题,也都是在不同的环境中或使用新的方法解决的。

是否有新的研究发现?

当然,现在没有人会真的用代码行数来衡量开发者的输出,但应该会有一些新的研究发现,对吧?

2018 年出版的“Accelerate”一书呈现了对 2000 个不同规模的组织进行研究的结果。研究的目标是确定哪些指标可以用来区分高绩效和低绩效。他们的发现如下所示:

我们可以看到四个指标。接下来让我们来看看这些指标是如何与价值联系在一起的,以及它们是否具有一致性:

  • 部署频率——我可以理解为什么它会出现在这里。你越频繁地交付,交付过程就越可靠。高效的团队往往更频繁地发布代码。然而,相关性并不一定意味着因果关系。部署频率与客户价值并没有直接的关系。人们想要一个能够满足他们需求的产品,而不是一个尽可能频繁变化的产品。这个指标也不具备一致性,因为一个变更并不等于另一个变更。
  • 交付时间——满足客户请求的时间。这一点与价值更加靠近一些,但它不具备一致性,因为客户请求是不一样的,有些可能很简单,有些可能极具挑战性。
  • 平均恢复时间(MTTR)——发生故障后恢复的速度。当软件出现故障时,客户会不高兴,所以这个指标与价值是有关系的,但也有不好的地方。首先,它没有考虑到故障频率。如果软件经常出现故障并迅速恢复,尽管指标看起来不错,但客户仍然会不满意。第二,它不具备一致性,因为各种故障也是不一样的。如果是整个系统出现故障,那就很严重了。如果只是一个小功能不能正常工作,大多数客户可能不会注意到。
  • 变更故障率——导致故障变更的百分比。如果是用户自己安装的更新,那么这个指标确实与价值有关。如果用户在安装更新时体验不佳,他们就会害怕安装后续的更新。对于 SaaS 产品,这种关系就不那么直接了,因为客户不太关心服务为什么出现故障,可能是由于变更,可能是你的一个供应商出了问题,可能是服务无法处理负载,或者是服务受到了攻击。不管是什么原因,如果服务不正常,顾客都会不高兴。这个指标也不具备一致性,因为一个变更不等于另一个变更。有些变更是微不足道的,有些则可能很重要。

底线——所有四个指标都不具备一致性,而且并不总是与价值有直接关系。如果尽可能频繁地发布一些不重要的变更,那么除交付时间之外,其他指标看起来都不错。

至于交付时间,即使我们忽略了它不具备一致性的事实,将这个指标作为目标会导致我们优先考虑客户的简单请求,却忽略了客户没有说出的请求。这通常包括重构、测试和所有其他客户没有考虑到的改进。

这就是为什么我不推荐使用这些指标作为开发目标。

或许我们可以找到更好的指标?

你可能会说:等等,虽然我们还没有找到好的指标,但这并不意味着它们不存在,人们很聪明,他们会找到更好的方法。但我恐怕他们是找不到的。我们找不到好的开发者指标是有根本原因的。好的指标应该满足两个关键标准:

  1. 它们与价值直接相关;
  2. 它们具有一致性,即基于某些相等值的可数数量。

我们不能直接度量开发者的输出,因为他们的产出结果总是不一样的。每个任务和项目都有独特的要求,所以不存在重复的结果。如果没有重复的结果,就没有一个可靠的度量基础。我们所拥有的只是间接指标,这些指标并不总是与价值相关,将它们作为目标最终带来的伤害将大于好处。

无法被度量的东西可以得到改进吗?

指标很方便,因为它们为我们提供了一个反馈循环——你可以了解你做出的改变是否改进了某些东西。如果没有指标,反馈循环就不会那么简单了。有时候你甚至会觉得自己像瞎子一样。彼得·德鲁克有句名言:

如果你不能度量它,就不能管理它。

但这不是真理。根据德鲁克研究所的说法,彼得·德鲁克并没有幻想可以为所有事情找到一个度量标准。事实上,他从来没这么说过。并不是所有重要的东西都可以被度量,也不是所有被度量的东西都很重要。

没有好的指标并不意味着我们不能提高开发速度。有些公司的软件开发速度肯定比其他公司更快,而且不会因为速度更快而导致质量下降,因此,改进是可能的。

底线

你可以并且应该使用指标来改进软件产品。你可以考虑使用性能指标(如延迟或 CPU 负载)、可靠性指标(如正常运行时间)和用户行为指标(如转化率或留存率)。

但是,当你想要提高软件开发速度,不应该依赖指标,因为我们没有合适的可用指标。我们可以度量很多东西,但不幸的是,我们可以度量的所有东西都与价值没有直接联系,或者没有足够的价值一致性,或者两者都不具备。如果你基于这样的指标设定目标,就不会有什么好结果。

原文链接:

https://teamplify.com/blog/why-you-shouldnt-rely-on-developer-metrics/#isnt-there-anything-more-modern-based-on-research

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/Q9Z8AKy2rVD33hcujEKf
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券