技术绩效考量：你们可能都做错了

欢迎来到通向卓越之路！我们或许都陷入了这样的困境，我们努力成为卓越的企业，我们进行绩效考量，并在此过程中找到正确的OKR、KPI或ABC。

但这可能是一件很困难的事情，特别是当我们所在的组织非常复杂并从技术幽灵（Ghosts of Technology Past）和管理幽灵（Ghosts of Management Past）中继承了它们的衡量指标。

虽然不存在一个万能的衡量指标，但仍然有一些可遵循的指南，以及一些可以避免的常见错误。我们在与Jez Humble和Gene Kim共同撰写的新书“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”中概述了什么才是好的衡量指标。这两个规则非常简单，可以帮助我们理解我们在进行绩效考量时所犯下的惊人错误。

两个简单的衡量指南

使用专注于结果而不是输出的衡量指标。
使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。

仅此而已。软件开发绩效考量中的很多问题通常是因为采用了不遵循上述两个准则的衡量指标。衡量指标形成了我们的激励机制，继而影响我们的行，所以我们需要使用正确的衡量指标。

常见的不良衡量指标

大多数软件绩效考量都把注意力放在了生产力上，他们通常忽略上述的两个指导原则。或许我有一点幸灾乐祸的意思，不过，先让我们从“不应该做什么”开始讲：

代码行数。一直以来，我们试图使用代码行数来衡量生产力。有些公司甚至要求开发人员记录每周承诺的代码行数（Apple Lisa团队的管理层发现将代码行数作为衡量生产力的指标是毫无意义的，这里是他们的故事）。如果1000行代和10行代码都能解决同一个问题，我当然喜欢后者。奖励开发人员编写额外的代码只会让软件变得更加臃肿，这会带来更高的维护成本和变更成本。那么另一个极端呢？最小化代码行数也不行。虽然有时候可以用一行代码来完成一个任务，但这样的代码别人不好理解，所以很难维护。理想情况下，我们应该奖励开发人员用最少的代码来解决业务问题——如果我们可以在不编写代码或删除代码的情况下解决问题（或许是通过修改业务流程），那就更好了。

将代码行数作为生产力衡量指标违反了我们的指导原则，因为这样关注的是产出而非成果。它只衡量了人们做了什么（代码行数）——通常是因为这样做更容易——但通常忽略了真正的目标，因为目标难以表达和衡量。但目标不是我们应该真正关心的吗？

速度。将速度作为衡量指标是源自敏捷运动——问题被分解为故事（story）点数，然后开发人员为故事点数分配相应的工作量。在截止工作时，完成的故事点数就是团队的速度。但是，这只是团队的容量规划工具。使用速度作为生产力衡量指标有几个不足。首先，速度是一种依赖于团队的度量，具有相对性。团队通常具有不同的背景，所以在团队间进行速度比较并不合适。其次，当速度被用作生产力衡量标准时，团队很可能会做出一些与事实不符的事情：他们会夸大他们的估算，并想尽可能多地完成故事点数，疏于与其他团队合作（这可能会降低他们自己的速度并加快其他团队的速度，反而会让他们看起来很糟糕）。这不仅会破坏速度原本的意义，还会抑制团队之间的协作。

将速度作为生产力衡量指标也违反了我们的指导原则，因为它更关注局部指标而非全局指标。为了优化自己的速度，团队通常不会与其他团队合作。这通常会导致组织采用次优的解决方案，因为他们没有关注全局指标。

利用率。很多组织将利用率作为生产力的衡量指标。不幸的是，数学在这里不起作用。疲于处理待办事项列表的人都应该能够理解我将要描述的内容：一旦利用率超过一定水平，就没有多余的容量用于容纳计划外的工作、计划的变更或改进工作。这导致完成工作的时间变长。数学中的队列理论告诉我们，当利用率接近100％时，交付周期就接近于无穷大——换句话说，一旦达到非常高的利用水平，团队就需要指数级的时间来完成任务。由于交付周期——衡量完成工作的速度——不会与其他指标一样存在某些弊端，因此我们可以通过管理利用率以一种相对经济的方式做出平衡。

将利用率作为生产力衡量指标违反了我们的指导原则，因为它侧重于产出而非结果。它还侧重于个人而非局。这让我们看起好像在压榨员工，实际上，我们正把自己推向无法完成任何工作的境地。

技术考量的正面例子

事情还是有它好的一面。我们确实有一些很好的例子，可以用来说明如何衡量技术的生产力，我将在这里概述其中的一些。

软件。”Accelerate“一书把我们在软件开发和交付方面使用的度量叫作软件交付绩效。它可以分为两个类别，每个类别包含两项指标：

节奏:
- 交付周期：从提交代码到代码在生产环境中成功运行所需的时间。
- 部署频率：团队部署代码的频率。
稳定性
- 恢复服务的时间：当服务发生服务事故（例如计划外中断、服务损害）时，恢复服务通常需要多长时间。
- 变更失败率：他们对主要应用程序或服务做出的变更有多少（百分比）会导致服务降级或随后需要进行修复（例如导致服务受损或中断，需要修补程序、回滚或补丁）。

这些衡量指标遵循我们的指导原则，因为它们既是面向结果的指标又是全局的指标——也就是说，它们专注于让软件对组织和客户产生价值，而不是把注意力放在无法给整体目标带来帮助的局部问题上。我们发现节奏和稳定性可以放在一起实现，高绩效企业在两个方面都表现良好。

我们的研究发现，通过关注这些指标可以提升组织绩效，高绩效企业可成倍实现盈利能力、生产力和市场份额，以及效率和客户满意度。

数据库。另一个很好的例子是数据库性能的考量。做到这一点其实不容易，因为我们经常会陷入细节之中：数据输入、数据输出、数据安全、我们的遥测是什么样的、我们选择什么样的聚合等等。所有这些都要求我们对数据和数据库有充分的了解。但是，如果我们想要考量数据库性能，我们应该退后一步，看看全局的衡量标准和结果。

这就是为什么我会喜欢Laine Campbell和Charity Majors在”Database Reliability Engineering“一书中提出的的指导原则。他们在关于操作可视性的章节中指出了两个关键问题：你的服务是否在运行？消费者是否感到痛苦？他们非常巧妙地解释说，“端到端检查是你工具库中最强大的工具，因为它们最能反映你的客户体验”。

我喜欢他们给出的明确的指导原则并专注于这些指标，因为在这种情况下，你可以通过将数据库和开发团队聚集在一起来产生价值并确保交付高质量的软件（应用程序和数据库代码）。顺便说一下，专注于这些指标也有助于将数据库纳入到你的技术和产品的价值对话中。如果你的客户感到痛苦，因为你的跨职能开发团队在开发应用程序时忽略了你的数据库团队，他们只能手动部署数据库变更，以便跟上应用程序的更新速度，那么这就到了一起坐下来解决问题的时候了。

质量。关注质量对于所有的组织来说都很重要，但这也是最难的指标之一。为什么？这是因为，用软件质量专家Jerry Weinberg的话说，“质量对某些人来说就是价值”【1】。众所周知，不同的组织有不同的环境，提供不同的职能和服务不同的人。

但是，“质量”——无论在什么样的背景下——通常都是一种良好的生产力衡量标准，因为它侧重于全局指标和结果。我们通常会考虑我们的最终用户或客户，或者我们产品的最终状态。在我们的研究中，我们发现了一个质量指标，也就是是返工或计划外工作所花时间的百分比，包括中断或修复工作、紧急软件部署和补丁、响应紧急审计文档请求等等。我们发现，在新工作、计划外工作或返工以及其他工作上花费的时间在高绩效者和低绩效者之间存在显著差异。换句话说，高绩效者要提升质量，因此必须花更少的时间来修复错误。看看下图。

640?wx_fmt=jpeg

通过专注于这两件事——全局指标和结果——你就可以很好地设计出可以帮助你取得成功的重要指标。

当你专注于全局成果（如质量）时，生产力就会随之而来。其他一些人也发现了这一点。John Seddon说得很好：“矛盾的是，当管理者关注生产力时，很少能实现长期改善。而当他们关注质量时，生产力反而会不断提升。“

关于作者

640?wx_fmt=jpeg Nicole Forsgren 是一位IT影响力专家，指导领导者和技术专家如何释放技术变革的潜力。她是DevOps、IT采用和影响力以及知识管理方面的顾问、专家和研究员。她是DevOps Research and Assessment（DORA，与Gene Kim和Jez Humble合）的联合创始人、首席执行官兼首席科学家。她是ACM Queue编辑委员会成员，也是克莱姆森大学和佛罗里达国际大学的学术合作伙伴。Nicole拥有管理信息系统博士学位和会计硕士学位，已发表多篇期刊论文，并获得公共和私人研究资助（资助者包括NASA和NSF）。