科技公司使用的开发者生产力指标

深入研究谷歌、领英、Peloton、Amplitude、Intercom、Notion、Postman等10多家科技公司使用的开发者生产力指标。

译自 Measuring Developer Productivity: Real-World Examples。作者 GERGELY OROSZ 和 ABI NODA 。

去年，《务实工程师》中最受欢迎的文章是我与肯特·贝克（Kent Beck）合著的“测量开发者生产力？对麦肯锡的回应”，这显然让许多读者感兴趣!

有一种批评意见是，肯特和我提供了考虑开发者生产力的框架，但我们没有提供一个遵循的蓝图来解决如何衡量开发者。

然而，这是有意为之，因为——像许多复杂的问题一样——答案从“这取决于”开始。但是，我一直在困扰没有更多关于应该测量哪些指标的具体答案，尤其是因为这份简报介绍了领英和优步如何跟踪开发者效率。

因此，我联系了一位在这个领域拥有近十年经验的人。Abi Noda 是广为引用的白皮书DevEx: a new way to measure developer productivity的合著者之一——与DORA和SPACE的创建者一起。他还是开发者生产力工具Pull Panda的联合创始人兼前任首席执行官，在GitHub负责软件交付测量，并且是开发者洞察平台DX的首席执行官兼联合创始人。Abi 还撰写了Engineering Enablement新闻简报。为了透明起见，我是DX的投资者和顾问。

在他的工作中，Abi 曾采访过17家知名科技公司负责测量开发者生产力的团队。在本文中，我们关注一些公司的选择；从最大到中型创业公司。

在本期中，我们将介绍:

1. 17家科技公司的开发者生产力指标
2. 谷歌: 一家大型科技公司
3. 领英: 另一家大型科技公司
4. Peloton: 一家中型科技公司
5. 创业公司和较小的公司
6. 有趣的发现
7. 如何选择自己的指标进行测量

有了这些，就由Abi来了。

最近关于如何测量开发者生产力的争论不少。这无疑是一个复杂的问题: 软件工程是知识型工作，所以甚至“生产力”的含义就是一个棘手的问题。然后，你开始考虑可能有害或可能被滥用的指标，很明显，这种讨论很容易变得混乱或吹毛求疵。

但是有一个更简单的方法。许多公司都有专门的团队，专注于使开发者更容易交付高质量的软件。你可能已经听说过它们: 它们通常被称为开发者生产力(DevProd)或开发者体验(DevEx)团队。如果我们不去讨论如何测量生产力，而是看看这些团队实际上在测量什么，会怎么样呢？

关于这些团队的事实是，他们需要开发者生产力指标来完成自己的工作。为了确定正确的项目优先级，他们需要能够测量工程团队的生产力和制约它们的因素。他们还需要指标来跟踪和展示他们的工作是否确实起到了作用。通过学习这些团队使用哪些指标，我认为我们可以对哪些指标真正有用有很多了解。

为了弄清楚这一点，我联系了17家领先的科技公司，询问他们的开发者生产力功能或团队使用哪些指标。下面是各个公司在出版时使用的开发者生产力指标概述。以下是他们共享的内容:

用于测量各种科技公司开发者生产力的指标

你可以看到使用的指标范围很广，包括:

• 交付难易度(Amplitude、GoodRx、Intercom、Postman、Lattice)
• 实验速度(Etsy)
• 服务/应用稳定性(DoorDash)
• SPACE 指标(微软)
• 每个工程师的每周专注时间(Uber)

每家公司都有自己量身定制的方法来测量其工程组织的效率。为了这篇文章，我按大小顺序选择了四家公司，并对每一家进行深入探讨:

• 谷歌(员工人数超过100，000)
• 领英(员工人数超过10，000)
• Peloton(员工人数超过1，000但远低于10，000)
• 创业公司(工程师人数在100至1，000之间)，类似于Notion、Postman、Intercom、Amplitude、GoodRx和Lattice

如果您有兴趣了解更多关于上表中定义的指标，可以获取一份详细报告直接发送到您的收件箱。

我经常把谷歌作为衡量开发者生产力的模型。尽管如此，许多人还是认为复制谷歌的投资级别是难以达到的(“我们不是谷歌”)。虽然谷歌捕获的一些指标对大多数公司来说确实无可达成，但我相信任何规模的组织都可以采用谷歌的整体理念和方法。

谷歌的开发者智能团队是一个专门的单位，致力于测量开发者生产力并为领导者提供见解。例如，他们帮助内部工具团队了解开发者如何使用他们的工具，是否对工具感到满意，以及工具的速度、可靠性或直观性如何。他们还与高管合作，了解他们组织的生产力。

无论是在测量一个工具、流程还是团队，谷歌的开发者智能团队都坚信没有单一指标可以捕捉生产力。相反，他们从速度、易用性和质量三个维度来看生产力。这些存在紧张关系，有助于凸显潜在的权衡。

举个例子，考虑测量代码审查过程。该团队对每个维度捕获指标:

• 速度: 代码审查完成需要多长时间？
• 易用性: 开发者参与代码审查流程的难易程度如何？
• 质量: 从代码审查中获得的反馈质量如何？

当然，具体使用的指标会因测量对象的不同而有所不同。但是三个核心维度保持不变。

**谷歌使用定性和定量测量来计算指标。**它依靠这种组合来提供尽可能完整的图像:

“我们将使用日志来测量速度。我们还将测量人们对自己认为正在进行的速度的看法。我们还将通过日记研究和访谈来跟进，以确保所有内容都一致匹配。我们正在谈论混合方法。”

——开发者智能团队技术负责人Ciera Jaspan

谷歌使用的许多指标是通过行为方法捕获的:

“技术债务是我们遇到的一件很难找到好的客观指标来告诉你数量、位置以及是否存在问题的事情。调查可以帮助您测量您不知道如何客观测量的事物。它还可以帮助您测量在原则上不可客观测量的事物。”

——开发者智能UX研究负责人Collin Green

领英拥有超过10，000名员工，并在微软内独立运营。与谷歌一样，它也有一个专门的开发者洞察团队，负责测量开发者生产力和满意度，并向组织其他部分传递见解。这个团队隶属于更广泛的开发者生产力与幸福组织，专注于减少关键开发者活动的阻力并改进他们使用的内部工具。

《务实工程师》以前介绍过领英测量开发者生产力的方法。我将简要回顾领英使用的三个渠道来捕获指标:

• 季度调查: 开发者洞察团队使用季度调查来评估一系列工具、流程和活动的开发者体验。它包括大约30个问题，开发者在大约10分钟内回答。该调查是通过开发者洞察团队开发和维护的专有平台提供的，允许根据从实时反馈和指标系统收集的数据高度自定义和个性化调查问题。
• 实时反馈系统: 为了在季度调查之间捕获反馈，领英开发了一个实时反馈系统，它跟踪开发者在开发工具中执行的事件和操作，并根据特定触发器发送针对性调查。该系统使用智能调节机制，以避免压倒性地要求开发者提供反馈。
• 基于系统的指标: 领英还使用系统数据计算指标，为构建时间和部署频率等提供高精度测量。开发者洞察团队维护一个全局系统，用于摄入和分析这些数据，他们称之为开发者洞察中心(或iHub)。该系统允许领英的各个团队创建自定义仪表板和定制指标以满足他们的需求。

之前《务实工程师》关于领英的文章没有涵盖的是领英使用的具体指标。这里是该公司关注的示例:

• 开发者净用户满意度(NSAT) 测量开发者对领英开发系统的整体满意度。它每季度测量一次。
• 开发者构建时间(P50和P90) 以秒为单位测量开发者在开发期间等待本地构建完成所花费的时间。
• 代码审查者响应时间(P50和P90) 以工作时间测量代码审查者响应作者每次代码审查更新所需的时间。
• 提交后CI速度(P50和P90) 以分钟为单位测量每个提交通过持续集成(CI)流水线所需的时间。
• CI确定性与测试脆弱性相反。它是测试套件结果有效且不是脆弱的可能性。
• 部署成功率测量部署到生产环境的成功率。

与谷歌一样，领英的开发者洞察团队在每个领域都考察定性和定量指标。例如，对于构建时间，他们将构建所需时间的客观测量与开发者对其构建的满意度进行比较:

“即使定量指标表明每个人的构建都是fantastic，如果开发者说‘我讨厌我的构建’，你可能应该倾听这一点。”

—— 开发者洞察平台高级技术负责人Grant Jenks

上面的定量指标通常使用中位数计算。然而，使用中位数值时的一个挑战是，即使异常指标改善，指标也不会变动。在一种情况下，领英团队将过长的前端构建时间从25秒减少到3秒。这是一个很大的胜利!但是，由于数据的分布曲线，改进并没有实质性地改变中位数。

Winsorized 均值是一种识别异常指标改进的方法。Winsorized 均值是通过用接近中间值的数字替换高端和低端值来计算的。Grant Jenks 是这样解释这种方法的:

“Winsorized 均值所做的就是: 弄清楚你的99百分位，而不是丢弃所有高于99百分位的数据点，将它们裁剪。所以，如果你的99百分位是100秒，而你有一个110秒的数据点，你划掉110并写下100，现在你计算你的Winsorized均值，结果是一个更有用的数字。”

开发者体验指数是一个领英为团队提供的特殊指标。这是一个根据许多不同指标计算的综合分数，如前面列出的指标。

Grant 一般建议不要使用这样的复合分数，因为开发和校准它们非常复杂。正如他所说:

“我们不会随时间跟踪开发者体验指数。我们保留随时更改聚合和权重的权利。我们告诉人们永远不要把这个指标放到OKR中。”

更多详情，请参阅Abi对领英的播客采访。

Peloton 雇用大约3，000-4，000名员工，所以虽然是一家大公司，但与领英相比要小得多。Peloton 的测量方法始于通过开发者体验调查获取定性洞察。后来，他们开始将这些数据与定量指标配对，以获得更全面的图像。

Peloton 通过关注四个关键领域来衡量生产力:参与度、速度、质量和稳定性。这里是一些使用的指标:

• 参与度: 开发者满意度评分
• 速度: 所有新员工的第1次和第10次PR的时间、交付周期、部署频率
• 质量: % PR行数低于250行、行覆盖率、故障率变化
• 稳定性: 恢复服务时间

许多这些指标都是通过Peloton的技术赋能和开发者体验团队的开发者体验调查来衡量的，该团队是其产品运营组织的一部分。技术赋能和开发者体验团队还负责分析调查结果，并与整个组织的领导者分享结果。

下面是技术学习和洞察负责人Thansha Sadacharam如何解释他们调查计划的根基:

“我非常强烈地认为，我认为我们的许多工程师也非常欣赏这一点，工程师不是机器人，而是人。仅仅看数字或看某些关键指标不能驱动整个故事。所以对我们来说，一个真正全面了解整个开发者体验的调查非常重要。”

调查每年进行两次。它发送给大约一半开发者的随机样本。通过这种方法，个别开发者每年只需要参与一次调查，最大限度地减少填写调查所花费的总时间，而仍然提供统计上具有代表性的一组数据结果。

更多内容，请查看Abi对Thansha Sadacharam的采访。

开发者生产力名单上有几家创业公司: Notion、Postman、Amplitude、GoodRx、Intercom和Lattice。这些公司的工程团队规模在100至1，000之间。这些创业公司许多都关注测量“可移动指标”。一个可移动指标是开发者生产力团队可以通过其工作对其产生积极或消极影响来“移动”的指标。可移动指标对于开发者生产力团队来展示自己的影响很有帮助。

这些公司测量的共同点如下:

1. 交付难易度(可移动)。大多数这些公司都测量交付的难易度;这是一个开发者觉得完成工作有多难或多容易的定性指标。

几位DevProd领导者表示，他们将此指标用作其工作的“北极星”，因为他们团队的目标是让开发者的生活更轻松。由于这一指标相当容易移动，它在展示影响方面也很有用。从理论的角度来看，该指标还捕获了开发者体验的关键方面，例如认知负载和反馈循环。

2. 参与度。大多数这些公司还跟踪参与度，这是开发者对其工作的兴奋和激励程度的测量。虽然参与度通常在人力资源参与度调查中进行测量，但DevProd团队也提到关注参与度的原因:

• 开发者参与度和生产力密切相关。换句话说，“开心的开发者是有生产力的开发者”，因此开发者参与度可以看作是生产力的一个指标。
• 测量参与度的一个真正好处是抵消其他强调速度的指标。更快地交付软件固然好，但不能以开发者幸福感下降为代价。

3. 时间损失(可移动)。GoodRx和Postman关注平均时间损失。这是开发者由于工作环境障碍而损失时间的百分比。这个指标类似于交付的难易度，因为它为DevProd团队提供了一个可直接影响的可移动指标。

这个指标可以转换为美元:一个主要的好处!这使时间损失对业务领导者来说很容易理解。例如，如果一个工程薪资成本为1000万美元的组织通过一项举措将时间损失从20%降低到10%，这相当于100万美元的节省。

4. 变更失败率。这是DORA研究计划的四个关键指标之一。它是一个由几家公司(包括Amplitude和Lattice)追踪的顶级指标。DORA团队将变更失败率定义如下:

“进入生产或释放给用户的变更导致服务质量下降(例如，导致服务损坏或服务中断)的百分比，随后需要修复(例如，需要热修复、回滚、修复或补丁)。”

Lattice将变更失败率测量为PagerDuty事件数除以部署次数。Amplitude将其测量为 P0(优先级为零)次数除以生产部署次数。P0计数通过PagerDuty获得，部署计数来自其持续交付服务Spinnaker。

在查看17家科技公司如何评估工程生产力后，我注意到一些有趣的发现:

选择性使用DORA和SPACE指标

我原以为来自DORA和SPACE的指标会出现更频繁，因为它们通常被视为“行业标准”。但只有一家公司微软提到全 面拥抱其中一个框架，这也说得通，因为他们是SPACE框架的作者。

对于其他公司，这些框架的一些单个指标仅被提及为更广泛、更全面的测量策略的组成部分。

广泛采用定性指标

所有公司一致表示，它们使用定性和定量指标。例如，Intercom、Postman和Peloton都将开发者参与度作为一个指标。包括Atlassian、Lattice和Spotify在内的公司也依赖自我报告的指标。

这强调了顶级公司开发者生产力测量方法的显著转变。5年前，这些公司中大多数可能仅专注于定量指标。我们最近的ACM论文提供了一种利用定性指标来测量开发者体验的框架。更多信息，请查看文章《测量开发者生产力的新方法——来自DORA和SPACE的创造者》。

高度关注“专注时间”

让我惊讶的是，许多公司将“专注时间”作为顶级指标进行跟踪。尽管研究表明“深度工作”是开发者生产力的一个重要因素，但我没有想到会发现如此多的关注。Stripe和Uber分享了特定的指标，例如“充足专注时间的天数”和“每个工程师的每周专注时间”，而其他公司提到了将其作为开发者调查计划中要测量的主题。《务实工程师》以前介绍过优步如何测量工程生产力。

独特的指标

不同开发者生产力团队测量的内容有很大一部分重叠。但也有一些值得关注的独特指标:

• 采用率(DoorDash、GoodRx和Spotify)。活跃使用产品或服务的开发者数量。Spotify的版本是开发者采用其Golden Standards的测量。
• 每个工程师生成的设计文档数量(Uber)。在开始有意义的工作之前，工程师为非平凡项目编写设计文档——其思想是尽早获得反馈并最终减少完成项目所需的时间。他们的指标跟踪开发者遵循此做法的频率。
• 实验速度(Etsy)。前CTO Mike Fisher(他撰写了科技简报Fish Food for Thought)说，在Etsy，每个团队都会设计并运行自己的实验，以评估用户对新功能的反应。这种实践是他们的工程文化的核心部分，促进了学习文化并帮助团队保持关注客户。Etsy开发了一个内部的实验平台来跟踪这些实验的进展。指标包括每周启动的实验数量、已停止的实验数量以及具有正面命中率的实验数量。相关背景是，最终目标是测量学习速度。
• 开发者CSAT/NSAT(Chime和领英)。领英测量开发者NSAT(净用户满意度)，它跟踪开发者对其开发系统的整体满意度。报告中列出的另一个指标是开发者使用的工具和服务的客户满意度(CSAT)评分。CSAT是通过季度开发者调查获得的。这些指标不同:CSAT指标关注特定工具，而领英的NSAT测量开发者对所有工具的整体满意度。而且，CSAT指标计算为积极响应的百分比，而领英的指标是满意响应的百分比减去不满意响应的百分比。

我总是推荐借鉴谷歌的目标、信号、指标(GSM)框架，以帮助指导指标选择。团队经常在思考他们实际想要了解或跟踪的内容之前就跳到指标上。GSM框架可以帮助团队确定目标是什么，然后从这个目标反向工作来选择服务于此目的的指标。

谷歌开发者智能团队的Ciera Jaspan解释了GSM流程在谷歌中的使用方式:

“我们总是鼓励人们遵循目标、信号、指标的方法。我们先请他们写下目标。你对速度的目标是什么?你对易用性的目标是什么?你对质量的目标是什么?首先把这些写下来，然后问自己:‘有什么信号可以让你知道你已经实现了你的目标?’不管它们是否可以测量。

信号不是指标。如果你已经实现了你的目标，世界会是什么样子?在这一点上，试图弄清楚哪些是正确的指标。”

从定义章程开始。你的DevProd团队存在的原因是什么?以下是一些DevProd团队章程的例子:

• 谷歌: “使开发者能够快速轻松地交付出色的产品。”
• Slack: “使所有工程师的开发体验无缝流畅”
• Stripe: “使软件工程更轻松。”

从你的目标反向工作来定义顶级指标。如果你想让开发者更轻松地交付高质量的软件，你的团队将如何知道你是否做到了这一点?你可能希望寻找以下信号:

• 开发者交付软件的难易程度
• 开发者交付软件的速度
• 所交付软件的质量

对于每个类别，定义指标以帮助跟踪进展。例如:

• 速度 = 感知交付速度，感知生产力
• 易用性 = 交付难易度，部署交付时间，构建失败率
• 质量 = 事故频率，感知软件质量

这些指标应该与本文中讨论的许多指标类似。

使用类似的顶级指标使你的DevProd团队传达你的工作价值和影响。有了正确的指标，你可以使你团队内外的每个人保持一致。

操作指标是你想要与特定项目或目标关键结果(OKR)相关联的那些指标。操作指标被许多DevProd团队在顶级指标之外使用。

操作指标包括:

• 开发者对特定工具的满意度
• 某项特定服务的采用率
• 开发者工作流程的细致测量。
• 等等其他!

我希望有一个好的通用解决方案，但现实是没有的。重要的是:选择你的团队能够且确实能控制的指标。避免目标超出你控制范围的高级关键指标。

如果你是CTO、VPE或工程总监，那么你的范围几乎肯定比本文中讨论的开发者生产力的定义更广泛。当我与正在确定指标的工程领导交谈时，他们经常被CEO或领导团队要求提供指标。

在这种情况下，我的最佳建议是重新定义问题。你的领导团队想要的与找出完美的生产力指标无关，而是更多地与对你对工程投资的管理有信心。

为了展示良好的管理，考虑选择属于以下三 个存储桶的指标:

向公司领导团队呈现的工程指标的三个存储桶

1. 业务影响。你应该报告当前或计划的项目，以及解决以下问题的数据:

• 为什么这些是现在要建立的正确事物?
• 这个项目如何给企业带来收入，或者以其他方式支持其目标?
• 这个项目是否按计划进行或延迟?

这种类型的报告通常被视为产品团队的责任。尽管如此，只有工程部门才能代表正在进行的所有项目的完整集合。一个很好的例子是一个数据库迁移项目，不太可能在产品团队的路线图上。

2. 系统性能。工程组织生产软件，因此利益相关者将要了解这些系统的健康状况和性能。你需要回答以下问题:

• 我们的工程系统是否快速、可靠?
• 我们的基础设施是否安全、维护良好?
• 用户对所使用的服务是否满意?

在此报告有用的指标包括正常运行时间、事件次数和产品NPS分数。如果你有一个专门的基础设施或UXR团队，他们可能正在捕捉属于此存储桶的指标。

3. 工程效率。利益相关者想知道工程组织的效率如何，以及如何改进。本文的重点主要放在这里，所以你可以应用我们从DevProd职能如何测量事物中学到的知识。

这里是 Gergely。谢谢你 Abi，对开发者生产力指标进行了深入探讨。

最大的科技公司已经在测量开发者生产力，这并不奇怪。让我比较惊讶的是，像Lattice和GoodRx这样的工程团队规模在几百人左右的公司也在做这件事。

在所有这些公司中，测量定性和定量指标的组合都是常见的。他们都测量几件事，而这些指标通常捕获不同的领域。例如，Stripe测量:

• 每天具有足够专注时间的平均天数(定性和定量)
• 每个开发者每周的PR数量(定量)

这两项测量都提供了不同的生产力视角，并有助于预测问题。如果Stripe只测量每周每个开发者的PR数量，他们可能会看到一个团队每周每个开发者交付10个PR，这令人振奋。但是，如果他们看到该团队没有充足的专注时间天数怎么办?那个团队可能非常接近Burnout，这时他们的PR数量可能会下降。

从每个公司使用的广泛测量中获取灵感。调查中的大多数企业至少测量5-6个不同的指标。他们关注的重点有很大差异，这在很大程度上取决于自己的优先事项和工程文化。

对Abi关于如何选择自己的指标的建议，我再次强调:从你想要解决的问题开始。它是消除交付障碍，通过让开发者保持幸福和满意来保留开发者，提高所交付软件的质量，还是其他目标?然后从那里反向工作!