作者 | 云昭
不管在哪个领域，团队想要高效运转，取得成功，最重要的是，让团队有一个与上下文语境相适应的“方向”，而在软件开发领域，KPI则充当着“北极星”，使团队朝着正确的方向前进。
软件开发KPI经常与指标相混淆。指标是代表一个事实的数字，而KPI是对一个组织很重要的事情。注意：选择KPI而不评估其给团队带来的影响，往往弊大于利。例如，“代码行（LOC）”可以是一个度量，但绝不应该是软件开发团队的“KPI”。
软件开发的KPI只有设置正确的度量，才能有助于确保打造一支高绩效、高效的工程团队，从某种程度上看，这才是一支团队真正的竞争优势。“高绩效”和“高效”的定义往往因业务性质和许多其他因素而异。找出这些关键绩效指标有助于区分重要因素和噪音。
在本文中，我们将介绍如何为团队选择KPI，并列出其他工程团队行之有效的9个软件开发KPI。
一、那些危险的KPI
“赛马”、“LOC”、“编码天数”……你应该不惜一切代价避免以下这些指标。它们往往对开发团队弊大于利。
1.有效编码天数
这个指标绝不代表个人所做工作的质量。每个人的工作模式都可能不同——有些人可能需要三天时间来理解需求，并逻辑地规划出具体需要做什么，然后在一天内完成实际任务。假设每个团队成员都应该每天编写代码，这是一个毫无根据的假设。团队还有很多其他的工作，比如评审、设计、测试、发布、规划、整理和帮助初级团队成员等等。将编码天数作为KPI进行跟踪会使所有其他功能变得无用。而不是你想在一个高绩效团队中灌输的正确文化。
2.代码行
毫无疑问，这个古老的指标是跟踪工程团队生产力/产出的最差方法。跟踪像LOC这样的KPI表明，对于一项任务，如果一个团队使用100行智能代码，则比1000行错误代码更糟糕。任何软件开发团队都不应将LOC作为KPI。
3.冲刺速度（Velocity）
另一个非常常用的度量是速度（Velocity）。速度可以很好地指示完成了多少计划任务，也有助于未来的冲刺计划。但从来不是团队生产力或效率的指标。当使用“Velocity”用于推动开发人员和比较团队时，它会成为一个危险的KPI。即使在同一个组织中，两个团队也可能有非常不同的评估标准，作为团队生产力的KPI，这种机制往往埋下危险的种子。团队成员往往会为了完成KPI而使得工作变形，最后的结果适得其反。
4.与其他程序员相比较
许多管理者经常会犯一个错误：将软件开发KPI与以“开发人员生产力”为名跟踪个人的指标混为一谈。前者应该代表团队或项目的整体状态，而不是个人。最重要的是，将一个开发人员与另一个进行比较，对于团队的生产力而言，有百害而无一利。记住：这些KPI是为了促使团队成员提高工程效率做出贡献，而不要感到受到威胁。
二、五条原则
1.始终考虑团队效率，而不是开发人员效率
软件开发本质上是一个团队概念，从长远来看，在个人层面制定KPI去跟踪是行不通的。
2.KPI不应是定量的
它应该更多地关注你工作的质量层面。例如，跟踪“提交次数”不能成为KPI，但“客户满意度”就能很好地反应出团队产出的质量，是一个不错的候选指标。
3.首先确定重要流程，然后选择KPI
KPI是对工程团队至关重要的绩效指标，所以首先要确定重要的流程，然后找出有助于实现这一目标的KPI。需要考虑的一些工程过程包括：规划、执行、代码质量、部署周期、测试、团队健康和用户满意度。
4.永远不要“复制粘贴”KPI
记住，组织的性质、文化和发展方向，对于选择正确的KPI非常重要。最好的方法是从别人做什么和不做什么中学习，但千万不要因为这对他们有用就复制他们。
5.要团队相信KPI的重要性
你在决定什么样的软件开发KPI对的团队很重要时，还需要确定优先级，并告诉团队这对我们很重要。拥有错误的KPI比没有KPI更糟糕。
三、行之有效的9个KPI
这些是我们看到的一些KPI，对于软件开发团队来说非常有效。（顺序不表示重要性或有效性。）
1.团队上手时间
新团队成员开始为团队交付做出有意义贡献所需的时间。这有助于理解团队的学习曲线有多大，也表明团队在教育新成员有关团队架构、技术堆栈和开发实践方面的效率有多高。数字越小，表示学习曲线越小，新成员可以开始快速做出贡献，从而影响团队的整体生产力以及新成员的满意度。
2.测试有效性
这可以通过几个指标的组合来衡量，比如在非生产环境与生产环境中发现的bug的比率、在非产品环境中测试的用户场景的百分比以及测试分支覆盖率。此KPI的主要目的应该是确保团队在投入使用之前测试更改的措施是有效的，并且生产缺陷的开销不会降低团队的速度。
3.有效开发
进行了多少代码更改，并不重要，重要的是代码的有效性。这里的有效性是是指，当团队在添加新更改的同时不继续添加代码债务时，需要最少的返工。返工有时也反映出要求的不明确，或经常需要进行特别改进。跟踪代码有效性的另一个很好的衡量标准是，开发的代码对客户产生影响的百分比是多少。将此作为KPI进行跟踪有助于树立有效工作比更多工作更重要的观念。
4.客户满意度
开发团队的所有工作最终都会为用户提供新的功能或更好的体验。衡量最终用户满意度是一个很好的衡量标准，可以表明团队是否以正确的心态工作。
跟踪这一点的几种方法可以是测量功能的使用频率，也可以来自新功能发布后的反馈调查。根据产品类型和组织提供的客户支持、客户报告错误的频率、客户请求的交付速度等指标，在衡量满意度方面也起着重要作用。
管理者可以通过查看特性请求的周期时间（从整理到生产部署）来跟踪特性请求的速度。
另一个非常有效的指标是NPS（Net Promoter Score，净促销得分），它是一个最终用户向其他人推荐产品的可能性的得分。通常可以使用客户调查和反馈表跟踪这一点。
5.周期时长（Cycle Time）
这是一种广泛使用的KPI，是交付速度的明确指标。周期时长主要帮助了解团队的敏捷性，以及管理者应该在哪些领域花费精力。例如，如果在登台环境中进行测试所需的时间超过了开发项目，则意味着需要考虑如何优化或者自动化测试框架。
跟踪周期时长的最佳方法是从开始（计划）到实现（生产部署）。绘制开发过程全貌的周期时间示例如下：
从计划部署到生产部署的真实工程周期
将周期时间作为KPI进行跟踪有助于了解不同流程的效率。有时，不同阶段的周期可能不能精确到分钟，但比较视图和不同流程之间的整体分割，可以帮助你优化正确的区域。
6.生产稳定性和可观测性
没有一个系统是完美的，软件开发中的错误是不可避免的。我们需要接受这样一个事实：即完善开发过程无济于事。拥有适当的可观测性机制，将影响降至最低，是解决这一问题的最佳方法。关注过程的速度和稳定性是关键（也是DORA度量思想的核心）。帮助了解稳定性的一些软件开发KPI包括：
（1）CFR（更改失败率）：导致生产缺陷的部署百分比，有助于了解团队修复缺陷的开销发生的频率。
（2）MTTD（平均检测时间）：在生产中识别缺陷所需的平均时间-这代表了监控和可观察性机制的有效性。
（3）MTTR（平均恢复时间）：检测到生产缺陷后修复生产缺陷所需的平均时间，表征着团队找出并修复问题的速度，以最大限度地减少对最终用户的影响。
7.团队健康和满意度
维珍创始人Richard Branson曾说：“照顾好你的员工，他们也会照顾好你。”后疫情时代，团队成员都有待从倦怠中恢复，这比以往任何时候都更重要。确保团队不会筋疲力尽，并对他们自身所做的工作感到满意，这是拥有一个高效团队的根本支柱。有助于跟踪这一情况的一些指标包括：
（1）每个人都希望开发新功能和最新技术：如果你的团队不断致力于解决现有系统的bug和维护，势必会引起团队成员的不满。
（2）开发经验-测试系统的：行更改是否太难了？为开发人员配备快速测试更改或运行小型POC的工具和灵活性对于拥有一个更快乐的团队至关重要。
（3）花在会议上的时间与实际工作的时间：软件开发团队经常面临“会议疲劳”，他们在会议上花费的时间比工作效率高，这会导致倦怠和上下文切换，而这通常是可以避免的。了解团队参加会议的次数或他们在会议上花费的时间百分比可以帮助了解团队对会议的态度。
8.文件和知识共享
想要让软件开发团队有效地工作，在整个团队中广泛地共享知识是必不可少的。它可以是代码文档、组件规范或设计文档的形式。在很多情形中人们往往担心团队成员的外流。但问题在于，某个团队成员要“活水”或跳槽到另一个团队或组织，这都是时间长短的问题。零减员根本就是是不可能的。
所以，解决这一问题的最佳方法是减少团队中的知识孤岛，这样即使团队成员决定离开“演出”也可以继续。涵盖这一方面的工程KPI包括：
（1）记录的代码库百分比。组件图或API规范的更新频率，是表示代码/设计文档实践的几个指标。
（2）新加入者理解系统所需的会议次数。大量的会议意味着没有足够的文档作为新团队成员的自助服务。
（3）只有一个团队成员知道的代码库的百分比。（百分比越高=团队中的知识库越多）
9.任务规划和可预测性
哪些任务需要完成，何时完成，以及谁来完成，这些都是计划项目时需要回答的关键问题。并非所有团队成员都必须参与决策，但是，团队需要以可预见的方式为组织的发展而努力。以下是一些有效的KPI：
工作分解结构：项目管理完全基于你如何将任务分解为更易于管理的任务，这有助于明确需要做什么，并更好地估计可能需要的时间。
可预测性：这表示在一个时间范围内完成的承诺工作的百分比。有很多事情可能会影响可预测性，比如临时请求或生产错误。
WIP计数：可以同时处理几件事情固然好，但同时处理太多事情是不可取的。通过查看开发团队的这一点，可以了解规划过程的健全性。
通过过程来选择对您的团队至关重要的正确软件开发KPI可能会稍微耗时，但如果有正确的心态，从长远来看，这是非常有用的。正确的绩效指标，将在动荡时期为你的工程团队指引方向，并帮助确保朝着正确的方向前进。
