开发者生产力是研发效能管理中的核心议题，也是一个复杂而微妙的问题。它对软件开发团队有着重要影响。清晰理解如何定义、衡量和预测开发者生产力，能够帮助组织、管理者和开发者更高质量、更高效率地构建软件。

开发者生产力一直是研究和实践中的重要议题。然而，尽管相关研究和行业经验已经积累了数十年，如何衡量甚至如何定义开发者生产力，依然是一个难题。与此同时，围绕这一话题的误解层出不穷。许多团队或管理者常常试图用简单指标来衡量开发者生产力，甚至希望用“一个关键指标”概括一切。

衡量生产力的一个重要来源是个人感知。1 这一点或许会让许多开发者产生共鸣：在高效工作日里，他们往往会觉得自己进入了“心流”状态。

人们也普遍认为，开发者生产力不仅对提升工程成果至关重要，也与开发者的福祉和满意度密切相关，因为生产力与满意度之间存在紧密联系。12,20

新冠疫情迫使全球大多数软件开发者居家办公，使开发者和管理者突然脱离以往熟悉的工作场所与团队协作环境。因此，如何同时保障软件系统的高效开发和开发者福祉，变得尤为重要。尽管这种变化出乎意料且令人遗憾，但它也构成了一次难得的“自然实验”，研究者可以借此研究、比较并理解不同工作环境下的开发者生产力。这场被迫发生的工作中断，以及未来向远程与现场混合办公模式的转变，都进一步加速了人们对开发者生产力和福祉的理解需求。与此同时，人们也越来越意识到：以高效、公平的方式开展这项工作至关重要。

本文将讨论关于开发者生产力的几个常见误区，并介绍用于衡量开发者生产力的 SPACE 框架。揭示这些误区最重要的意义在于：生产力不能被简化为单一维度，更不能被简化为单一指标。正是这些误区的普遍存在，以及破除它们的必要性，促使我们提出了一个实用的多维框架。因为只有考察一组相互关联的指标，我们才能真正理解并提升开发者生产力。

这个框架被称为 SPACE，涵盖了开发者生产力的几个关键维度：满意度与幸福感、绩效、活动、沟通与协作，以及效率与流动。通过多维度地认识和衡量生产力，团队和组织可以更好地理解个人与团队的工作方式，从而做出更明智的研发管理决策。

本文将展示如何在实践中使用这一框架理解生产力，以及为什么这一框架能够帮助团队更好地理解开发者生产力，建立更有指导意义的衡量标准，并有可能对工程成果和开发者福祉产生积极影响。

关于开发者生产力的常见误区

多年来，关于开发者生产力的误解一直存在。理解这些误解，有助于我们更准确地衡量生产力，也能避免在研发效能管理中使用错误指标。

误区一：生产力完全取决于开发者的活动量

这是最常见的误区之一，也很容易带来不良后果，并引发开发者的不满。

开发活动量增加可能有很多原因。工作时间变长，可能意味着开发者不得不“硬扛”低效系统或糟糕计划，以便赶上既定发布时间。另一方面，活动量增加也可能反映工程系统得到了改进，开发者获得了高效完成工作所需的工具；或者团队成员之间的协作与沟通变得更顺畅，从而更好地解决了变更和代码审查中的障碍。

单凭活动指标无法揭示真实情况，因此绝不应单独使用这些指标来奖励或惩罚开发者。即便是拉取请求数量、提交次数或代码审查次数等看似简单的指标，也容易受到数据缺失和测量误差的影响。同时，报告这些指标的系统往往无法体现结对编程、头脑风暴等协作方式带来的价值。最后，开发者为了赶上截止日期，常常会灵活调整工作时间，这也使得某些活动指标很难直接用于评估生产力。

误区二：生产力只关乎个人表现

个人表现固然重要，但一个人对团队成功的贡献，同样是衡量生产力时不可忽视的部分。衡量开发者、团队和组织三个层面的绩效指标都非常重要。

这类似于团队运动：成功既取决于队员的个人表现，也取决于团队的整体成绩。如果开发者只追求个人效率，就可能损害团队生产力。代码审查、值班轮换、工程系统的开发和维护等更偏团队导向的活动，对于维护代码库和产品或服务质量至关重要。

关键在于，要在个人、团队和组织生产力之间找到合适的平衡，并理解其中可能存在的权衡取舍。

误区三：单一生产力指标就能说明一切

关于开发者生产力，一个常见误解是：它可以被归结为一个通用指标，这个“唯一重要的指标”既能评估团队整体表现，也能用来比较组织内部甚至行业内不同团队的水平。

事实并非如此。生产力涵盖工作的多个重要维度，并且深受工作环境影响。脱离具体情境，用单一指标判断生产力，很容易得出片面甚至错误的结论。

误区四：生产力指标只对管理者有用

开发者经常抱怨生产力指标没有什么用。这种反感，往往来自领导者或管理者对指标的滥用。的确，如果生产力指标被不恰当地衡量和实施，就会在组织内部造成不合理的使用方式。

生产力指标被滥用固然令人失望，但也需要注意：开发者其实已经发现，追踪自身生产力是有价值的——无论是出于个人成长目的，还是为了更好地与他人沟通。

开发者生产力因人而异。因此，开发者可以利用相关信息更深入地理解自己的工作方式，从而更好地掌控时间、精力和工作安排。例如，研究表明，高生产力与工作满意度和幸福感密切相关。1,2,20 提升生产力，也意味着在开发者日常工作中增加成就感，减少挫败感。

误区五：生产力只关乎工程系统和开发工具

开发工具和工作流程确实会显著影响开发者生产力，但环境、文化等人为因素同样至关重要。

很多时候，维护健康工作环境和团队文化所需要的关键工作，对组织中的许多人来说可能是“隐形的”，也很难通过传统生产力指标体现出来。士气建设、指导辅导、知识共享等工作，对营造高效工作环境至关重要，却常常没有被纳入衡量范围。事实上，这些提升团队整体生产力的“隐形工作”，其重要性并不亚于那些更常见、更容易量化的指标。21

SPACE 框架：如何理解开发者生产力

生产力不只关乎个人，也不只关乎工程系统；它不能只用单一指标或活动数据来衡量；它也并非只有管理者才关心。

SPACE 框架的提出，正是为了捕捉生产力的不同维度。否则，上述种种误解仍会持续存在。该框架提供了一种更宽广、更理性的方式来思考生产力，并指导我们谨慎选择指标。它不仅帮助我们理解这些指标的意义，也提醒我们看到这些指标在被单独使用，或被置于错误情境中使用时的局限性。

满意度与幸福感

满意度是指开发者对工作、团队、工具或文化的满意程度；幸福感则是指开发者的身心健康状况、幸福程度，以及工作对他们产生的影响。

衡量满意度和幸福感有助于理解生产力，20 甚至可能有助于预测生产力。15 例如，生产力与满意度之间存在相关性，满意度可能成为生产力的领先指标；而满意度和敬业度下降，则可能预示着即将到来的职业倦怠和生产力下降。13

例如，疫情期间许多地区强制居家办公后，一些生产力指标出现了上升，例如代码提交次数增加、拉取请求合并速度变快。然而，定性数据表明，一些人的身心健康却受到了影响。这凸显了采用平衡指标的重要性：虽然某些活动指标看起来不错，但满意度相关指标描绘出了一幅更完整的图景——生产力因人而异，一些开发者正在面临职业倦怠。

为了应对这种情况，一些大型组织的软件团队实施了“心理健康日”，本质上就是提供休息日，帮助员工避免职业倦怠并改善身心健康。

显然，满意度与幸福感是生产力的重要维度。这些特征通常最适合通过调查问卷来衡量。为了评估满意度，可以衡量以下方面：

• 员工满意度：员工的满意程度，以及他们是否愿意向他人推荐自己的团队。
• 开发者效率感：开发者是否拥有完成工作所需的工具和资源。
• 职业倦怠：由过度且长期的工作压力引发的精疲力竭状态。

绩效

绩效是系统或流程产生的结果。软件开发者的绩效很难量化，因为个人贡献与产品结果之间往往难以直接关联。

编写大量代码的开发者，未必能写出高质量代码。高质量代码，也未必一定能为客户创造价值。令客户满意的功能，也未必总能带来积极的业务结果。即便某位开发者的贡献与业务结果存在相关性，这也未必能准确反映其绩效，因为他可能只是被分配到了影响较小的任务，而没有选择更有意义工作的自主权。

此外，软件通常是许多开发者共同贡献的结果，这进一步增加了评估单个开发者绩效的难度。在许多公司和组织中，软件是由团队而不是个人构建的。

因此，绩效评估通常最好关注结果，而不是单纯关注产出。对软件开发者绩效最简单的理解可以是：开发者编写的代码，是否可靠地完成了它预期完成的功能？

以下是一些可用于衡量绩效的指标示例：

• 质量：可靠性、无故障运行情况、持续的服务健康状态。
• 影响：客户满意度、客户采纳率、客户留存率、功能使用率、成本降低。

活动

活动是指在执行工作过程中完成的操作或产出的数量。如果能够正确衡量开发者活动，它可以为理解开发者生产力、工程系统和团队效率提供有价值但有限的信息。

由于开发者执行的活动复杂且多样，因此很难完整衡量或量化他们的活动。事实上，几乎不可能全面衡量跨工程系统和环境的所有开发者活动。不过，一个设计良好的工程系统，可以帮助组织在软件开发生命周期的不同阶段捕获活动指标，并在规模化场景下量化部分开发活动。

以下是一些相对容易衡量和量化的开发者活动：

• 设计与编码：设计文档、规范、工作项、拉取请求、提交和代码审查的数量。
• 持续集成与部署：构建、测试、部署或发布的次数，以及基础设施利用情况。
• 运维活动：事件或问题的数量、规模，以及按严重程度、值班参与情况和事件缓解措施划分的分布情况。

这些指标可以作为衡量部分可控开发活动的参考点。但由于它们具有已知局限，绝不应单独用于判断个人或团队生产力。它们只能作为初始模板，并应根据组织需求和开发环境进行定制。

如前所述，许多对软件开发至关重要的活动是难以衡量的，例如参加团队会议、参与头脑风暴、在其他团队成员遇到问题时提供帮助，以及提供架构指导等。

沟通与协作

沟通与协作涵盖个人和团队如何交流、协调与共同工作。

软件开发是一项协作性和创造性工作，依赖团队内部以及团队之间广泛而有效的沟通、协调和协作。高效团队能够有效贡献并整合彼此的工作，这依赖于高度透明的信息，以及对团队成员活动和任务优先级的清晰理解。

此外，信息在团队内部和团队之间的流动方式，也会影响文档的可用性和可查找性，而这些文档又会影响团队能否有效协调和整合工作。多元化和包容性的团队往往拥有更高绩效。更高效的团队会聚焦于正确的问题，更有可能成功集思广益，并从多个备选方案中选择更优解决方案。

那些有助于团队达成目标，或提升其他团队成员效率的工作，可能会牺牲个人效率和进入心流状态的能力，从而降低个人积极性和满意度。然而，有效协作也可以减少某些个人活动，例如不必要的代码审查和返工；提升系统绩效，例如更快合并请求以避免错误并提高质量；并帮助团队维持生产力，降低职业倦怠风险。反过来，如果协作处理不当，也可能增加职业倦怠。

然而，一些难以衡量的因素会让团队生产力和团队成员期望的理解与衡量变得复杂，例如隐形工作，21 以及协调和规划团队任务所需的沟通工作。18

尽管如此，以下指标仍可用于衡量沟通、协作和协调：

• 文档和专业知识的可发现性。
• 工作融入流程的速度。
• 对团队成员工作的评审质量。
• 显示谁与谁相连、如何相连的网络指标。
• 新成员的入职时间和入职体验。

效率与流动

最后，效率与流动体现的是：个人或系统能否以最小干扰和最少延迟完成工作或取得进展。这既包括团队内部活动和跨团队活动的协调程度，也包括工作能否持续向前推进。

一些研究将生产力与在尽可能减少干扰或中断的情况下完成复杂任务的能力联系起来。2 许多开发者在谈到工作中的“心流”状态时，也认同这种生产力概念。或者说，他们深知找到并优化这种状态有多么困难。许多书籍和讨论都探讨过如何以可控方式进入这种积极状态。4

为了提升个人效率，也就是更容易进入心流状态，设定边界以保持专注至关重要。例如，预留一段不被打扰的专注时间。个人效率通常可以通过不间断专注时间，或在创造价值的应用程序中花费的时间来衡量。例如，开发者在集成开发环境中花费的时间，通常会被视为一种“高效”时间。

在团队和系统层面，效率与价值流图密切相关。价值流图描绘了软件从构思、创建到交付给最终客户所经历的各个步骤。为了优化价值流，最大限度地减少延迟和交接环节至关重要。

DORA，即 DevOps 研究与评估框架，引入了多个用于监控团队内部流程的指标。9 例如，部署频率衡量组织成功发布到生产环境的频率；变更交付周期则衡量变更从提交到进入生产环境所需的时间。

除了系统内部的变更流动之外，知识和信息的流动也至关重要。效率与流动的某些方面可能难以衡量，但通常可以识别并消除价值流中的低效环节。那些没有为客户或用户创造价值的活动，通常被称为软件开发中的浪费。19 例如，重复劳动、由于工作未正确完成而导致的返工，或耗时的重复性活动。

以下是一些可用于衡量效率与流动维度的指标示例：

• 流程中的交接次数，以及不同团队之间的交接次数。
• 能否保持专注并完成工作的能力。
• 干扰情况：数量、持续时间、间隔，以及对开发工作和流程的影响。
• 系统层面的时间指标：总时间、增值时间、等待时间。

效率与 SPACE 的所有维度都相关。研究发现，个人、团队和系统层面的效率，都与更高满意度呈正相关。然而，更高效率也可能对其他因素产生负面影响。例如，最大化流程速度可能会降低系统质量，并增加客户可见缺陷的数量。通过减少干扰来优化个人效率，也可能削弱协作能力，阻碍他人工作，并降低团队头脑风暴的效果。

SPACE 框架如何落地

为了说明 SPACE 框架，图 1 列出了覆盖五个维度的具体指标。该图提供了个人、团队或小组，以及系统层面的指标示例。

接下来，我们将围绕这些指标展开三点简要讨论。首先，以代码审查为例，展示一组覆盖 SPACE 框架所有维度的指标，具体取决于它们如何被定义，以及使用了哪些代理指标。其次，针对框架中的两个特定维度——活动、效率与流动——提供更多示例。最后，讨论如何使用该框架：如何组合指标以全面理解开发者生产力，以及在使用过程中需要注意什么。

文末侧栏展示了如何利用该框架理解事件管理中的生产力。

用代码审查理解 SPACE 框架

让我们以代码审查为例。它可以展示一组指标如何覆盖 SPACE 框架的五个维度，具体取决于框架如何构建以及指标如何选择。

• 满意度：关于代码审查的感知指标，可以揭示开发者如何看待这项工作。例如，代码审查是否提供了学习机会、指导机会，或改进代码库的机会。这一点很重要。因为如果某些开发者觉得自己被分配了过多代码审查任务，以至于用于其他工作的时间被压缩，那么每位开发者承担的代码审查次数，可能反映的不是生产力，而是不满情绪。
• 绩效：代码审查速度反映审查完成的快慢。由于它既能反映个人完成审查的速度，也能反映团队层面的限制，因此它既是个人层面指标，也是团队层面指标。例如，某个人可以在收到审查任务后一小时内完成审查，但团队可能规定所有审查任务至少开放 24 小时，以便所有团队成员都能看到拟议变更。
• 活动：已完成代码审查次数是一个独立指标，用于衡量在给定时间范围内完成的审查数量，以及这些审查对最终产品的贡献。
• 沟通与协作：代码审查本身就是开发者通过代码进行协作的一种方式。对代码审查质量或周全程度的衡量或评分，是评估协作和沟通水平的一个很好的定性指标。
• 效率与流动：代码审查固然重要，但如果它中断工作流程，或因为延迟造成系统瓶颈，就会带来挑战。同样，等待代码审查也会影响开发者的后续工作。如果团队能够集中处理代码审查，既不打断开发者的编码时间，也不降低系统吞吐量，就能更高效地交付代码。因此，衡量代码审查时间对个人、团队和系统效率与流动的影响至关重要。这既可以通过感知指标衡量，也可以通过遥测指标衡量，例如捕捉完成审查所需时间，以及中断发生的时间和频率。

我们还可以进一步考察两个维度：活动，以及效率与流动。

在这个例子中，活动指标是个人层面的指标，包括提交次数、编码时间，以及完成的代码审查次数。编码时间既可以衡量总时长，也可以观察一天中不同时段的分布。这些指标最能描述直接为最终产品做出贡献的工作，但也需要认识到：工作模式和行为会受到开发者所在团队和环境的影响。

效率与流动则涉及更广泛的指标。自我报告的生产力指标最好在个人层面进行衡量。直接询问开发者所在团队的生产力水平，容易出现盲点；而询问开发者本人是否感觉工作高效，或是否能够在干扰最小的情况下完成工作，则是一个有用信号。

你还可以衡量工作在系统中的流动情况，无论这些工作是代码、文档还是其他项目，并收集耗时、交接次数、延迟和错误等指标，以反映软件交付流程。这些指标属于系统级指标，因为它们反映的是工作项在整个工作流程或系统中的流转过程。

如何使用 SPACE 框架衡量开发者生产力

为了衡量开发者生产力，团队和领导者，甚至个人，都应该从框架的多个维度收集多个指标。我们建议至少选择三个维度。

例如，如果你已经在衡量提交次数这种活动指标，就不要只是把拉取请求数量和编码时间也加到指标仪表盘中，因为它们仍然都属于活动指标。这些指标可以帮助你更完整地衡量生产力的活动维度，但如果想真正理解生产力，至少还需要从另外两个不同维度中各增加一个指标。例如，可以加入生产力感知指标，以及拉取请求合并时间。

在实践中，团队可以借助 PingCode 这类智能化研发管理工具，将目标、需求、任务、代码、测试、发布和知识沉淀等研发全流程数据连接起来，减少指标采集中的割裂感。这样做的价值不在于堆叠更多数据，而在于帮助团队把活动、协作、效率和结果放在同一个上下文中观察，从而更接近 SPACE 框架所强调的多维度衡量。

另一项建议是：至少纳入一项感知测量，例如调查数据。通过纳入人们对自身体验的感知，可以更全面地理解生产力。很多时候，感知数据能够提供比单纯通过系统行为监测获得的信息更准确、更完整的洞察。10

纳入多个维度和多种测量类型的指标，往往会造成指标之间的冲突。这是有意为之。因为平衡视角能够更真实地反映工作和系统中的实际情况。这种更平衡的视角，有助于团队成员做出更明智的决策和权衡。否则，他们可能会过于关注工作的某个方面，而忽视整个系统。

例如，故事点数是敏捷开发流程中常用的一种团队进度指标。如果只用故事点数评估团队，团队成员就会专注于优化自己的故事点数，从而忽视那些对其他开发者进度和公司发展至关重要、却不容易被看见的工作，例如与其他团队协作，或为未来的开发者进行培训。

此外，如果领导者只用故事点数衡量进度，却不询问开发者是否能够快速有效地工作，就无法发现哪些环节出了问题，也无法判断团队是否正在依赖各种变通方案，并因此疲惫不堪。同样，他们也无法发现哪些创新做法真正有效，能够帮助其他陷入困难的团队。

这引出了一个关于指标及其对团队和组织影响的重要观点：指标会传递重要信号。理解一个组织重视什么，一个间接方法就是观察它衡量什么，因为指标通常反映组织价值观，并会影响人们的行为和反应。

例如，一家公司如果关注员工健康、福祉和留任率，就很可能会在生产力指标中纳入满意度与幸福感维度。由此可以推论，增加或减少某些指标，也会影响行为，因为这同样是在传递重要信号。

例如，一个团队如果只用“生产力 = 代码行数”来衡量生产力，那么它与另一个用“生产力 = 代码行数 + 代码审查质量 + 客户满意度”来衡量生产力的团队，会有很大差异。

在后一种情况下，团队保留了一个可能存在问题但已根深蒂固的生产力和产出指标，同时也引导人们重新理解生产力：它既重视团队合作，也就是认真细致的代码审查；也重视最终用户，也就是客户满意度。

指标会塑造行为。因此，仅仅新增并重视两个指标，就可能帮助团队和组织发生改变。这也是为什么必须从框架的多个维度获取信息：这样才能在团队和系统层面带来更好的结果。在这个例子中，随着团队持续改进和迭代，他们可以进一步用提交次数等指标，替代代码行数这类更容易误导人的活动指标。

使用 SPACE 框架时需要注意什么

过多指标可能导致混乱，并削弱改进动力。并非所有维度都必须被纳入，框架才能发挥作用。

例如，如果开发者和团队面对一长串指标和改进目标，可能会觉得目标遥不可及。因此，衡量生产力的一个好方法，是从至少三个维度中选择少量指标。这些指标应有助于形成整体视角，同时又足以激发改进动力。

任何衡量范式都应谨慎使用，因为没有任何指标能够完美代表整体情况。有些指标效果不佳，是因为它们只是存在噪声的近似值。图 1 中列举了一些例子。

员工留任率常被用来衡量员工满意度。然而，它所反映的远不止满意度，还可能反映薪酬、晋升机会、团队问题，甚至伴侣工作调动等因素。在团队层面，一些管理者可能为了维护自己的留任率，而阻止员工内部流动。即便留任率确实能够反映满意度，它也是一个滞后指标。团队往往要等到为时已晚时，才意识到问题已经发生。

我们曾在其他文章中讨论过故事点数的局限性。9 它可能促使团队只关注自己的工作，而忽视重要项目中的跨团队协作。

团队和组织应重视开发者隐私，只报告团队或小组层面的匿名汇总结果。在某些国家或地区，报告个人生产力甚至是不合法的。

不过，个人层面的生产力分析可能对开发者本人有帮助。例如，此前研究表明，开发者的典型工作时间会受到开发阶段影响，而且开发者可能在一天中的某些时段效率更高。14 开发者可以选择参与此类分析，从而获得有价值的洞察，用于优化自己的日常工作并管理精力。

最后，任何衡量范式都应检查是否存在偏差和规范性影响。这些外部因素可能改变或影响测量结果。下面列举几个例子，但并不完整。因此，鼓励所有团队主动查找并思考数据中可能存在的外部影响因素。

• 同行评审与性别：研究表明，女性在代码评审中更容易收到负面评价，而收到正面评价的可能性较低。16 因此，任何关于评审流程满意度的分析，都应在具体环境中考察这一因素。即使你的组织或团队内部不存在这些模式，开发者也可能受到更广泛科技行业环境的影响。务必将这些因素纳入考虑。
• 指标标准化：团队应谨慎使用任何用于标准化时间的方法，尤其是在处理较长时间段时。例如，查看一整年的指标，可能会对休育儿假的员工造成不利影响。
• 感知测量：团队和组织应注意并尊重文化规范。有些文化天然倾向于给出较高的感知评分，有些文化则倾向于给出较低评分。这并不意味着感知测量不可信，而是意味着来自不同文化背景的测量结果会有不同基线，因此不应直接相互比较。

SPACE 与 SRE：事件管理框架

SPACE 框架与站点可靠性工程师，即 SRE，以及他们在事件管理方面的工作密切相关。当服务不可用，或未按服务级别协议 SLA 的规定运行时，就会发生事件。事件成因多种多样，例如网络问题、基础设施问题、硬件故障、代码错误或配置问题等。

根据事件造成的影响程度，通常会为其分配一个严重级别，其中 1 级为最高级别。整个组织面向客户的系统中断，与只有一小部分内部用户受到电子邮件收发延迟影响，处理方式显然截然不同。

以下是一些与事件管理相关的常见误解。

误区一：个人解决的事件数量最重要

与软件开发生命周期中的许多其他活动一样，事件管理也是一项团队活动。

如果某项服务频繁中断，且恢复时间过长，就会给开发和维护该服务的整个团队带来负面影响。知识共享、编写故障排查指南以帮助其他团队成员、指导初级成员和新成员、妥善交接任务，以及合理分配或重新分配任务等更偏团队导向的活动，都是事件管理的重要组成部分。

误区二：孤立观察某个指标就能了解一切

理解指标时必须结合上下文。例如，事件数量、事件解决所需时间、1 级事件与 4 级事件的数量和解决时间对比，以及其他有助于理解事件和改进系统及团队响应方式的因素，都需要综合考虑。因此，不存在“唯一重要的指标”。

误区三：只有管理层才关心事件数量和 SLA 达成情况

随着 DevOps 兴起，开发者如今也参与运维工作。如果事件数量多、严重程度高，事件管理作为运维的一部分，就会占用开发者大量时间和精力。

对于管理层和高管而言，保障 SLA、减少事件数量、缩短解决时间固然重要；但对于参与事件管理流程的开发者而言，这些事情同样至关重要。

误区四：有效的事件管理只在于改进系统和工具

更好的监控系统、工单系统、案例路由系统、日志分析系统等，确实能提升开发者工作效率。工具、指南和工作流程对效率有巨大影响，但环境和工作文化中的人为因素同样至关重要。

指导团队新成员、提升团队士气，也非常重要。如果开发者在新冠疫情期间居家办公时，经常在夜间被紧急呼叫处理 1 级严重事件，那么这些“隐形”因素对提升他们的工作效率就尤其重要。

事件管理是一个复杂过程，涉及多个利益相关者执行多项个人和团队活动，并依赖不同工具和系统支持。因此，确定能够捕捉生产力各个维度的指标至关重要。

• 满意度：SRE 对事件管理流程、升级机制、路由机制和值班轮换的满意度，是需要掌握的关键指标。尤其是因为 SRE 职业倦怠是一个重要问题。
• 绩效：这些指标侧重于系统可靠性，例如监控系统能否在问题影响客户并演变为安全事件之前，更快地检测和标记问题。MTTR，即平均恢复时间，可以包括总体 MTTR，也可以按严重程度划分。
• 活动：监控系统发现的问题数量、创建的事件数量、已解决事件数量，以及这些事件按严重程度划分的分布情况。
• 沟通与协作：参与事件解决的人员、他们来自多少个团队，以及他们在事件发生期间如何沟通。事件解决文档会概述事件处理步骤；这可以通过完整性衡量，例如是否输入了解决数据，也可以通过快速质量评分衡量，例如点赞或点踩。团队还可以增加一个指标，用于衡量参考这些指南和文档后被解决的事件占比。
• 效率与流动：事件交接、事件分配或重新分配，以及事件在分配给正确个人或团队之前必须经过的跳转次数。

为什么开发者生产力衡量现在很重要

开发者生产力不只是个人活跃程度，也不只是支撑软件交付的工程系统效率；它无法用单一指标或单一维度来衡量。

我们提出 SPACE 框架，正是为了捕捉生产力的不同维度。否则，关于生产力的普遍且可能有害的误解仍会持续存在。

SPACE 框架提供了一种方法，帮助我们以更宏观的视角，系统而有逻辑地思考生产力问题，并谨慎选择与目标相关的平衡指标。同时，它也帮助我们看到这些指标在单独使用或被置于错误情境中使用时的局限性。

这一框架有助于揭示那些并不总是显而易见的权衡取舍，也能帮助我们考虑那些不易察觉的工作，以及由指标衡量本身带来的额外工作量。例如，如果只用开发者未完成的工作，或对整体流程和效率造成的干扰来衡量活动，就可能反而增加不必要的负担。

如今，全面理解和衡量开发者生产力的需求从未如此迫切。新冠疫情扰乱了工作方式，迫使人们突然转向居家办公，也让许多人开始质疑疫情对生产力的影响，并提出如何理解和衡量这种变化的问题。

随着世界逐渐进入“新常态”，SPACE 框架捕捉了未来变革提出和实施过程中需要考虑的重要生产力维度。该框架旨在帮助个人、团队和组织识别能够全面呈现生产力的相关指标，从而围绕开发者生产力和研发效能改进展开更深入的讨论，并设计出更具影响力的解决方案。