译者 | 布加迪

审校 | 重楼

技术已融入了现代工作场所的方方面面。运营成本、安全、通信、员工满意度和客户群都离不开技术的影子。精明的CIO知道高绩效的IT组织和高绩效的业务之间存在直接关联。

作为技术领导者，您需要能够衡量团队的进展有多快、他们是否朝着正确的方向前进。如果不衡量，就无从改善。

一、从之前衡量方法的缺陷中汲取教训

试图衡量技术团队的交付情况很棘手。团队是个体的集合。以IT组织为例，这些个体在执行不同的复杂任务。多年来，软件开发团队的经理们尝试了许多方法来衡量工作效率，其中大多数方法存在这两个基本缺陷：

1. 注重产出而不是结果。

2. 强调个人而不是团队。

这些有缺陷的方法产生了几个反模式，它们不仅未能提供有意义的工作效率衡量指标，还导致团队士气低落。

代码行数

也许最知名也是最讨厌的衡量开发人员工作效率的做法是计算代码行数。开发人员编写的代码行数与开发人员向组织交付的总价值之间几乎没有什么关联。

事实上，就编写的代码行数奖励开发人员会导致代码臃肿，并最终导致更高的维护成本。

速度

鉴于敏捷方法在软件开发界很流行，一些敏捷教练可能会推荐使用速度作为衡量团队工作效率的一种方法。团队速度而不是单个贡献者速度是规划工作负载的一个有用的度量指标。

然而作为衡量工作效率的指标，速度不尽如人意。将速度等同于工作效率只会导致开发人员夸大估计，从而不仅错误表述了团队的效果，还可能使该度量指标在容量规划中的有用性荡然无存。

利用率

在许多咨询机构，开发人员的利用率（即他们花在代码上的时间）被用作工作效率的代名词。这存在双重缺陷，因为我们都知道努力并不总是意味着结果，因为这种度量方法激励项目经理保持开发人员处于100%的利用率。

在数学中，队列理论告诉我们，当利用率达到100%时，交付时间接近无穷大。这是由于利用率为100%的资源没有能力来创新、改进或改变。

二、采用数据驱动的方法来衡量软件交付

2018年，Nicole Forsgren、Jez Humble和Gene Kim发表了《Accelerate》一书，其中包括对来自2000多个不同组织的23000多份回复所作的聚类分析。他们在数据中发现了四个共同的特征，这些特征有助于将软件开发团队划分为高绩效、中绩效或低绩效：

• 变更的交付时间：从提交代码到生产环境中运行需要多长时间？
• 部署频次：您的团队向实时客户群交付软件更新的频次是多少？
• 平均恢复时间：生产环境中检测到故障后，您的团队需要多长时间才能恢复服务？
• 变更失败率：对生产环境的变更随后需要补救的百分比是多少？

三、考虑影响团队表现的其他因素

除了严格基于代码的度量指标外，还有几个文化因素有助于评估软件团队的表现。

• 团队成员积极寻求信息。
• 不会因为传递坏消息而受到惩罚。
• 责任共同承担。
• 跨职能部门的协作得到奖励。
• 失败被视为改进的机会。
• 新想法总是受到欢迎。

四、留出时间来评估绩效数据

一旦您知道了哪些指标可以表明团队的绩效，作为CIO您必须留出时间和资源来构建一个仪表板来衡量。所需的数据很可能不会来自单单一个地方，因此您需要从多个数据源捕获和转换数据，然后使用Tableau或PowerBI之类的自定义可视化工具来呈现。

最好从简单的入手，逐渐扩展到能获得最大价值的地方。您通常可以从版本控制系统和代码管道上的API获得所需的大部分定量数据。至于更多的定性度量，可以考虑使用季度调查。

五、根据绩效数据实施变更

到头来，如果组织没有持续地审查数据并使用数据来修正业务方向，那么收集数据和度量指标（即便只是一小部分）也纯属浪费精力。

作为一家组织，应当留出时间来定期审查度量指标，收集宝贵信息，并基于数据实施变更，这是成为一家高绩效IT企业的最快途径。

原文标题：5 tips for measuring developer productivity，作者：William J. Francis