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