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