再多的自发披萨派对也无法挽救生产文化失衡的团队文化。一方面，快速交付成果的压力会促使领导者努力推动团队采用有望提高效率的新工具和做法。然而，这种对生产力的关注有时会以牺牲团队士气和幸福感为代价。 

找到正确的平衡点至关重要；领导者必须确保在追求提高生产力的同时，营造一个优先考虑团队健康和文化的支持性环境。这种平衡不仅可以维持长期生产力，还可以培养积极、协作的工作氛围，从而留住顶尖人才并推动创新。

如果没有实时数据和主动开发方法，平衡这些指标和文化期望几乎是不可能的。

代码正确性、可维护性和可读性是成功程序员的三大指标，但它们也可以表明开发人员的生产力。衡量开发人员体验指标和其他指标有助于领导者同时量化团队的活动并更改或优先考虑某些结果。我们的开发人员生产力指南深入探讨了其缺陷，探索了开发人员蓬勃发展的框架，并揭示了所有团队的改进机会。

目录：

• 什么是开发人员生产力？

• 领导者在衡量生产力时遇到的常见陷阱

• 衡量开发人员生产力的两种现有方法

• 衡量生产力的新方法：Developer Thriving 框架

• 提高团队开发人员生产力的技巧

开发人员生产力衡量开发团队编写和交付与公司业务成果直接相关的熟练代码的能力。可以使用各种指标在任何时间范围内计算，重点关注实时团队生产力而非个人生产力。

为了衡量开发人员的生产力，领导者使用基于DevOps 研究和评估 (DORA) 指标构建的定性和定量数据组合。但是，他们还依赖 SPACE 框架来全面了解团队的能力和绩效。事实上， Pluralsight Flow 的开发人员成功实验室发现，组织可见性可以提高参与度和绩效，极大地影响开发人员的生产力和其他团队成果。

开发人员每天可以输出 100 行代码 — 但如果代码无用、有缺陷或不完整，那还有什么意义呢？开发人员的产出并不能反映出生产力的真实整体情况，因为产品创造量和实际增加值是完全不同的两码事。

开发人员的生产力需要衡量结果，而不是衡量产出。您的开发人员是否编写了 20 行可行且可维护的代码？如果是这样，那么这种高效的低产出大大超过了无效的高产出。团队可以在此基础上继续发展，推动他们取得更大的业务成功。

开发人员的生产力不应关注个人生产力（即每个员工的产出），而应衡量整个团队的体验。当团队层面解决痛点和挫折时，开发人员的生产力就会提高，优先考虑工作的整体组织和结构，而不是个人的细微差别。

不要跟踪提交次数和平均提交大小等单个指标，而是分析以下团队指标：

• 变更前置时间：提交的代码投入生产所需的时间

• 周期时间：工单有效状态和完成状态之间的平均时间

请记住在团队绩效的背景下解释这些指标的结果。虽然它们也可以衡量个人绩效，但如果不考虑团队工作的复杂性，开发人员的生产力将是不准确的。

领导者在衡量生产力时经常会遇到挑战，尤其是与“开发人员蓬勃发展”框架密切相关的两个衡量陷阱：

1. 优先考虑错误的指标：专注于生产力的表面定义，并激励或衡量错误的事物

2. 测量瘫痪：当领导者因开发人员生产力的复杂性和背景而不知所措时，导致缺乏指标测量

除了这些挑战之外，团队和领导者在衡量生产力时可能会遇到进展缓慢和其他陷阱。这些额外的陷阱包括：

• 工作流程效率低下：由于协作不力、手动流程以及工具缓慢或不充分而导致时间浪费和项目延误

• 范围蔓延：由于项目原始预期之外的额外项目请求和要求而缺乏重点

• 开发人员工作量：开发人员日程安排过于拥挤，导致项目延期或未完成，结果不佳 

• 技术债务：由于紧迫的期限、糟糕的评审和拥挤的代码库而导致的未优化的流程或软件解决方案以及糟糕的代码质量
• 上下文切换：由于项目规划不足和沟通不畅导致频繁中断或多任务请求

通常使用标准DevOps 指标来衡量开发人员的生产力。虽然这些指标可以成功支持生产力估算，但特定指标最适合深入了解团队生产力和绩效，包括 DORA 指标和 SPACE 框架。

用于分析工程和软件团队的DORA 指标被广泛视为跟踪开发人员生产力的标准。DORA 是同类中运行时间最长的软件交付和内部运营研究项目，专门用于跟踪： 

• 部署频率：选定时间范围内的软件分发次数 

• 变更前置时间：提交的代码投入生产所需的时间，这可能会影响生命周期的增长。

• 变更失败率：导致性能不理想或下降的部署占生产量的百分比
• 恢复服务的时间：中断事件发生与解决之间的时间量

SPACE 框架由 GitHub、维多利亚大学和微软研究院的研究人员设计，旨在让管理人员全面了解开发人员的生产力。该框架旨在消除生产力迷思，并深入了解开发团队的活动、需求和成功。 

该首字母缩略词的每个字母代表有效、完整地衡量内部生产力所必需的元素：

• 满意度：个人和团队对工作、团队和公司文化的满足感，可以通过员工满意度和倦怠感来衡量

• 绩效：业务和开发人员特定的工作成果，可以通过项目质量、可靠性、可维护性和服务健康状况来衡量

• 活动：开发人员在一天内采取的操作数量，可以通过拉取请求、提交和部署频率来衡量

• 沟通与协作：可通过内部访谈和入职评估来衡量团队或项目反馈和创意的质量

• 效率：开发人员或团队不间断地推进项目的能力，可以通过交接次数和流程间时间来衡量

开发人员蓬勃发展框架是一种旨在改善开发团队健康和效率的新方法。这个四因素框架由Pluralsight Flow 的开发人员成功实验室研究而成，是根据 15 小时内从 1,282 名开发人员收集的定性和定量数据开发的。 

开发者蓬勃发展框架跟踪衡量效率和满意度的四个关键因素或杠杆，从而提高开发人员的生产力。这些杠杆提供了对开发人员体验、环境、学习文化和策略的洞察，包括：

• 自主性：个人表达不同意见并与领导层公开讨论进度指标的能力

• 动机和自我效能：团队了解项目和目标进展、从事激情项目以及在具有挑战性的项目中获得支持的能力

• 学习文化：开发人员学习新技能并与团队分享发现的能力
• 支持和归属感：团队支持和接受与专业和个人经历相关的个人差异和需求

可见性是双向的。管理者需要愿意参与自上而下的可见性，将信息传递给其他领导或团队成员，然后由他们进一步传递信息。这种可见性应包括对项目和组织更新的洞察、指标跟踪以及对团队和个人的内部认可。 

另一方面，领导者也应该对自下而上的透明度持开放态度，这使得团队成员能够与上级就工作条件、项目问题、资源分配和其他组织需求进行对话。当两种形式的透明度都得到优先考虑时，组织可以获得以下好处：

• 更加自信和有动力的开发人员

• 提高团队进展的透明度

• 增强团队倡导方式 

• 更好的软件和项目决策

• 制定切合实际的目标并实现可控的期望

衡量开发人员生产力的最大挑战之一在于健康指标和虚荣指标之间的权衡。对于大多数开发团队来说，衡量生产力的指标经常被跟踪、存档和替换为新指标。这种指标的流失会增加虚荣指标的使用，这些指标通常更容易跟踪，而且能产生引人注目的结果。然而，虚荣指标通常优先考虑浅显的生产力指标，如产出和提交次数。 

当使用不合标准的指标来衡量开发人员的生产力时，就会产生效率误解和糟糕的开发人员体验。当测量侧重于个人跟踪而不是整体团队视角时，也会发生这种情况。为了保证准确的生产力跟踪，领导者需要将测量工作重点放在健康的团队指标上，这些指标优先考虑团队生产力和效率，而不是个人体验。 

健康指标

衡量标准主要集中于工作和项目成果，包括：

• 变更的准备时间

• 周期

• 创建可维护的代码

虚荣指标

测量重点关注个人的投入或产出，包括：

• 提交次数

• 工作时间

• 创建的代码行数

提高开发人员的工作效率对于增强团队健康和员工保留率至关重要。当与上述框架结合使用时，这六个改进技巧可以提高团队的工作效率。 

即使在开发人员生产力测量值较高的团队中，知识共享也至关重要。重视学习、创建内部反馈渠道并开展专门解决问题的讨论的团队会提高代码速度并减少团队障碍。知识共享还可以增强团队内部信任并改善多个团队之间的联系。

• 关键要点：考虑鼓励团队成员通过午餐学习和其他沟通渠道讨论反馈和行业知识。

生产力和其他关键业务成果依赖于<a href="https://www-pluralsight-com.translate.goog/blog/software-development/improve-the-developer-experience-to-speed-software-delivery?_x_tr_sl=en&_x_tr_tl=zh-CN&_x_tr_hl