开发人员生产力——如何衡量

人类本质上是认知守财奴，我们倾向于以简单且最省力的方式解决复杂的问题。这就是我们一直在通过采用最简单的可用方法来衡量“开发人员生产力”的方法。

当您听到“开发人员生产力”时第一个想到的是什么？

我敢打赌这是负面的，毫无疑问这在开发团队中几乎是一个禁忌，因为领导者常常担心谈论这个问题会让团队认为他们受到微观管理或缺乏信任。两个原因：

1. 开发人员生产力的方式被工程领导者滥用，并且正如我们所说的那样。

2. “开发人员生产力”不是一个公式，我们不会在不确定性中茁壮成长，因此我们选择要么走最简单的道路，要么远离这条道路。

试想一下：每年在开发团队上花费数十亿美元，如果有一种万能的方法来衡量开发人员的生产力，那它还会是一个谜吗？或者你会读这个博客吗？

PS：如果您阅读此博客的目的是衡量您最有生产力的开发人员或获得一个有助于您晋升和解雇开发人员的数字，请转身离开，因为您会感到失望。

那么我们是否应该尝试衡量开发人员的生产力？

是的，一点没错！！因为开发人员的生产力不仅在于提高工程成果，还在于确保团队的满意度和福祉。通常，生产力指标还有助于发现开发流程中的瓶颈以及团队工作环境和文化的挑战。

最成功的篮球教练之一菲尔·杰克逊 (Phil Jackson) 精彩地阐述了这一点：

“团队的力量在于每个成员。每个成员的力量就是团队的力量。” — 菲尔·杰克逊

在开发团队的背景下，每个团队的成功都取决于每个开发人员都发挥出最佳水平并不断为团队的成功做出贡献。

好的，现在我应该如何衡量开发人员的生产力？

两个基本支柱可最大限度地提高衡量开发人员生产力的成功机会。

1. 永远不要将生产力降低到单一指标

衡量开发人员的生产力很困难，因为我们试图衡量参与逻辑和创造性任务的人。而我们作为认知守财奴，试图将生产力降低到一个指标——让我明确指出，这种模式将会失败。

相反，尝试跨多个维度捕捉生产力并利用诸如SPACE 框架之类的东西（S-满意度和幸福感，P-绩效，A-活动，C-沟通和协作，E-效率和流程）可以帮助开发人员团队以正确的方式衡量开发人员的生产力。

2. 与团队沟通

有一个非常普遍的误区：开发人员的生产力只适合管理者。这与事实相差甚远。研究表明，开发人员和管理人员对开发人员生产力的看法存在显着差异。大多数开发人员将更高的生产力与更高的活动联系起来，而大多数经理将生产力与绩效和效率联系起来。

只有当开发团队就生产力对他们意味着什么以及他们追踪生产力的真正意图是什么时，这种看法之间的明显差异才能消除。这有助于澄清为什么这很重要以及我们应该如何衡量它，并且还消除了大多数开发团队的保留意见。这是决定我们评价的数字吗？或者我们这样做是因为领导层不相信我们能完成工作？

要做的事

1. 使用 SPACE 框架跨多个维度跟踪开发人员的生产力。
2. 与整个团队沟通意图。
3. 使用生产力衡量标准来确定需要改进的领域并消除瓶颈。

不该做的

1. 将生产力降低到单一指标。
2. 制定秘密措施来跟踪生产力。
3. 使用指标作为决定评估的唯一指标。

开发人员生产力指标

现在让我们看看一些跨空间维度跟踪的开发人员生产力指标。

开发人员生产力指标：

满意度和幸福感

一个高度满意的团队就是一个高生产力的团队。这是健康团队和工作文化的最大指标之一。然而，满意度是一个抽象的概念，如果有人问你“你有多满意？”，就忘记衡量标准吧。我相信在回答这个问题之前您会思考几分钟，满意对您意味着什么以及如何量化这一点。我们知道用数字来捕捉这一方面是极其困难的。因此，您在这里看到的是代理指标，它们试图最好地捕获开发人员满意度和幸福感的不同方面。

• 工作完成： 每当我们完成一项任务时，我们的大脑就会释放多巴胺，这使我们在任务完成后立即感到满足和动力。因此，与承诺的工作相比，工作完成率较高将使开发人员感到非常满意，因为他/她能够及时完成承诺的工作并为团队的成功做出贡献。
• 加班： 加班≠更高的生产力；事实上，情况恰恰相反，加班是导致开发人员倦怠并损害他们福祉的最大因素之一。跟踪额外的工作时间，例如周末或深夜的工作时间，可以帮助您了解开发人员在当前的工作环境中是否快乐并表现良好。
  • 忙碌不是取得成就的手段，而是取得成就的障碍
    ——Alex Soojung-Kim Pang
    
• 脱离： 不满和倦怠的最常见指标是脱离团队和团队活动。衡量开发人员敬业程度的方法之一是测量开发人员对团队活动（如代码审查）的一般响应时间的变化，或者团队会议中交互或出席的减少。
• 开发人员调查： 通常，在确定最佳生产力指标时，我们会忘记最明显的方法，即通过运行和分析开发人员满意度调查来询问您的团队并了解团队的情绪。问诸如“您满意吗？”之类的问题。（评分 1-5）”是理解这一点的最糟糕的方式。但是，可能还有其他问题可以帮助您以不同的方式和维度捕获类似的信息。
• 任期： 跟踪整个团队满意度的好方法，您可以查看开发团队中成员的平均任期。考虑到开发人员趋势的性质，合适的任期范围可以是 12 至 18 个月之间。任何更低的值肯定会引起人们的担忧。

表现

衡量开发人员和开发团队绩效的最佳方法是衡量结果而不是输出。这些指标帮助我们捕捉开发人员所做工作的质量方面。对于任何开发人员来说，理想的结果都是“开发返工最少的功能，确保及时交付和最大程度的客户满意度”。

• 返工： 当开发人员需要纠正其拉取请求或经常将任务从 QA 返回给开发人员进行错误修复时，这清楚地表明所完成的工作质量未达到预期标准。如此反复，最终导致功能开发周期延长。这个想法并不是零修正，而且返工通常也是由于需求的变化而导致的；然而，如果一个开发人员在相同的团队限制下面临着比其他人异常高的问题，那么这绝对是性能差距的迹象。
• 及时交付： 每个工程和业务领导者关心的一个结果是交付的可预测性，因为客户沟通的许多其他业务决策通常依赖于这些交付日期。为了在整个工程流程中具有可预测性，每个开发人员也吸收这种品质是绝对重要的。衡量这一点的一种方法是查看开发人员在开发冲刺/迭代中提交的任务完成了多少。
• 客户满意度： 一致认为，这是为任何组织带来价值的最重要的结果，因此对于开发团队来说也必须如此。客户满意度可能意味着应用程序商店获得更好的评论，或者 API 服务具有更高的正常运行时间和更快的响应时间，或者对于平台团队来说，它可能意味着其他团队使用的内部库的易用性和报告的错误最少。尽管客户满意度不仅由工程团队驱动，但将其作为绩效指标可以使开发团队与他们正在构建的产品的真实用户保持联系，并帮助他们专注于正确的事情。

活动

活动维度本身就广泛等同于开发人员的生产力，因为它是最容易跟踪的维度。然而，仅凭活动永远无法真正衡量开发人员的生产力。结合 SDLC 流程不同领域的其他维度来跟踪活动指标将帮助您确定开发人员的真正瓶颈和需要改进的领域。

• 已解决的任务： 此阶段的活动有助于确定开发人员对开发任务做出贡献的频率和程度。鉴于开发任务始终被规划为项目管理工具上的任务、用户故事或子任务，查看已解决的总任务有助于了解开发人员在开发周期的这一部分中的参与情况。
• 审查拉取请求： 通常只有技术主管或开发团队的经理才有责任审查变更/拉取请求，这是一个明显的反模式。鼓励每个开发人员审查越来越多的同行代码有助于消除审查瓶颈。这个指标将是一个很好的方法来确定开发人员是否为团队的审查负载做出了贡献。
• 部署频率： 团队将更改部署到生产系统的次数可以帮助您了解开发过程的速度方面。这也是 DORA 指标之一，研究表明 DORA 指标还与客户满意度甚至组织的盈利能力具有高度相关性，这使其成为跟踪开发团队生产力活动维度的绝佳衡量标准。

沟通与协作

在任何开发团队中，最终成果（无论是功能、服务、应用程序还是增强功能）始终是团队努力的结果。良好的沟通和协作是建立高效开发团队的基础。在衡量开发人员生产力时纳入这一维度可以促进透明度和信息共享的文化。一些有助于捕捉这一点的生产力指标是：

• PR 等待时间和周期时间： 如果开发团队具有良好的协作，则可以清楚地反映在他们的审核过程中，因为这可能是最瓶颈的开发过程，因为它取决于贡献者与审核者的有效沟通，反之亦然。有助于跟踪开发人员协作程度的指标是测量该开发人员在分配拉取请求后开始审查拉取请求所需的时间。接下来，测量拉取请求的平均周期时间有助于了解贡献者的沟通技巧。
• 共同工作的成员数量： 开发团队通常存在知识孤岛和开发人员小组，这些开发人员只相互交互，而不与团队的其他成员交互；这是另一种经典的反模式。衡量开发人员与其他团队成员的沟通程度和沟通程度是衡量此维度的好方法。
• 新成员的入职时间： 每当新开发人员加入团队时，他们都会经历初始学习曲线，了解业务环境，熟悉技术堆栈，并且通常还会获得代码演练的帮助。开发人员自加入以来做出第一个有影响力的更改所需的时间是衡量开发团队沟通方面的一个重要生产力指标。作为一个拥有良好文档实践的团队，愿意花精力帮助新加入者的开发人员将使新开发人员能够尽快做出有影响力的更改。一个值得努力的良好基准是新开发人员的第一个生产成果是在前 30 天内。

效率和流程

这就是开发者经常谈论的“进入流程”的维度。这里的指标有助于了解开发周期中有多少次中断以及任务从开始到结束的流程有多顺利。频繁的中断不仅会影响开发人员的工作效率，还会导致压力和疲劳程度增加。

• 不间断的开发时间： 对于开发人员来说，每天有足够的不间断的时间进入流程并投入时间进行开发活动绝对重要。其中最大的障碍就是团队会议。通常，为了鼓励更长的开发时间，团队会采用不开会的工作日或采用可以安排团队会议的严格时间段。较长的不间断开发时间并不一定表明开发人员的生产力较高。然而，可以肯定的是，如果开发人员没有足够的不间断时间，就无法实现开发所需的流程。
• 提交提前期： 开发周期中更多的中断、更多的交接以及过于频繁地重新打开任务都是开发任务效率和流程不佳的指标。提交交付时间可以准确地捕捉到这一点，因为它衡量的是更改对最终用户产生影响所需的总时间。相对较高的提交前置时间（CLT）肯定意味着开发团队的效率和流程的下降。CLT 也是 DORA 指标之一。更多相关信息请参见此处。
• 平均进行中 (WIP) 工单： 上下文切换无疑是生产力杀手。同时做更多的事情总是意味着需要更多的时间来完成所有事情，并且还会导致不必要的精神疲惫。
  • 两个并行任务 — 20% 因上下文切换而丢失。
  • 三个并行任务 — 40% 因上下文切换而丢失。
  • — 杰拉尔德·M·温伯格

WIP 票证完美地记录了开发人员正在并行处理的任务数量。跟踪此生产力指标并尝试使其始终小于三个任务对于您的开发团队来说是一个很好的开始实践。

变革参与

当您查看提高开发人员生产力的指标时，帮助您推动变革的行动将是开发流程的变化。衡量开发人员对团队正在推动的变革的参与程度有助于了解每个人为纠正团队流程所付出的努力。每个流程变更都可以有一个与之相关的指标，用于捕获流程的遵循情况，并且跟踪这些指标的排行榜可以帮助您进行游戏化并了解哪些开发人员对流程变更计划做出了良好的贡献。

这就是大家！

我们看到开发人员的生产力通常被误解为单一指标或易于跟踪的指标，而不是实际重要的指标。我们跟踪开发人员的生产力并从 SPACE 等框架中汲取灵感，采取全面的方法来提高开发人员的生产力，这一点绝对至关重要。最好从几个指标开始，但至少从三个维度选择这些指标很重要。我们已经讨论了详尽的维度列表以及每个维度中的许多指标，现在您和您的团队需要找出最有影响力的正确维度和正确指标。

以上是开发人员生产力——如何衡量的详细内容。更多信息请关注PHP中文网其他相关文章！