写点什么

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

2021 年 2 月 24 日

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

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


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


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

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


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


  • 代码行数——这可能是最古老的一种指标,但如今几乎没有人把它当回事。把代码行数作为衡量指标只会让代码变得臃肿,而且开发者只会专注于完成简单的任务;

  • 提交次数——这样会鼓励开发者将代码提交分解为多个部分。同样,开发者会更关注简单的任务,避免去解决复杂的问题;

  • 完成任务的数量——这样会导致任务被分割成更小的子任务。每一个问题,即使是小问题,都是作为任务提交的。这也会促使你走捷径,以最快的速度完成任务;

  • 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

2021 年 2 月 24 日 14:291737
用户头像

发布了 107 篇内容, 共 20.7 次阅读, 收获喜欢 245 次。

关注

评论 1 条评论

发布
用户头像
现在开发已经可以量化了,因为开发过程采用的是 SQL+搭积木的快速开发方式:https://wuyuan.io 由此相应的需求分析内容和后续迭代维护也都基本可以量化了
2021 年 02 月 24 日 22:12
回复
没有更多了
发现更多内容

编程经典案例之函数

顿晓

函数式编程

智能膜切机,解决手机贴膜行业难题

Geek_116789

飞天茅台超卖事故:Redis分布式锁请慎用!

程序员生活志

redis 分布式

数据人必须知道的SQL概念(A—Z)

大唐小生

sql 数据 职场成长

你问我答:微服务治理应该如何去做?

博云技术社区

微服务 PaaS API 容器云 博云

英特尔®AI计算盒参考设计发布 加速智能边缘崛起

最新动态

什么?不写代码也能做功能开发! -RUOYI 教程二

Java_若依框架教程

Java 无代码开发 若依

Android |《看完不忘系列》之okhttp

哈利迪

android

程序的机器级表示-算术与逻辑运算

引花眠

计算机基础

ARTS打卡 第10周

引花眠

ARTS 打卡计划

系统设计系列之如何设计一个短链服务

看山

架构 面试 分布式 架构设计 短链服务

<<前端进阶篇>> PDF 出炉了 — 「阿宝哥」,精心准备的 6 万多字 170 页的前端进阶资料

阿宝哥

前端 前端进阶 前端教程

技术管理者带团队的几个实用技巧

Phoenix

团队管理 企业文化 团队 价值观

Newbe.Claptrap 框架如何实现多级生命周期控制?

newbe36524

架构 微服务 微服务架构 .net core ASP.NET Core

架构师训练营第八章-作业1

A Matt

初识分布式:MIT 6.284系列(一)

Kerwin

分布式 MIT 28天写作

JVM系列之:JIT中的Virtual Call

程序那些事

Java JVM JIT

《深度工作》学习笔记(3)

石云升

学习 深度工作 工作哲学

谈一谈webpack打包

林浩

Java webpack 前端进阶训练营

手写一个重入锁

诸葛小猿

synchronized CAS 重入锁 compareAndSwap ReentrantLock

老哥,您看我这篇Java集合,还有机会评优吗?

cxuan

Java 后端

云小课 | IPv4枯了,IPv6来了

华为云开发者社区

IP 公有云 虚拟私有云 华为云 虚拟化

在人工智能时代追逐的“后浪”

华为云开发者社区

AI 开发者 技术社区 程序员成长 华为云

N皇后问题的回溯法实现(C++)

老王同学

计算机网络基础(十一)---网络层-OSPF协议

书旅

计算机网络 网络 协议栈 OSPF

实用!一键生成数据库文档,堪称数据库界的Swagger

程序员内点事

Java MySQL

基于 Golang的侵入式 Opentracing实现全链路追踪 ----实践篇

是老郭啊

财务分析与主要的模型

松子(李博源)

创业公司技术体系建设-APM

星际行者

APM

授人以渔:stm32资料查询技巧

华为云开发者社区

架构 armv8 芯片 华为云 二进制

微软苏州集体抵制来自阿里、华为的跳槽者:请停止你的“奋斗逼”行为!网友:看到 955 不加班的公司名单,我酸了

程序员生活志

加班 程序员生活 996

Hummer 轻量级跨端技术框架详解及实战

Hummer 轻量级跨端技术框架详解及实战

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