谷歌如何释放和衡量开发人员的生产力

快速增长暂时停滞，工程团队在有限资源下努力完成任务。科技巨头谷歌也未能幸免，去年一月份裁员了其员工总数的 6%。而不论身处何地，客户预算的紧缩都在推动对发布具有差异化特性的需求更加迫切。

在软件开发这个重要领域，提高开发软件的人类劳动力的生产率比以往任何时候都更为重要。

开发者生产力研究衡量工程师在一定时间内产出特定工作量的能力。这个领域不仅研究最终结果，还关注影响这些结果的社会技术因素。越来越多地，它也试图衡量开发者体验，因为已经证实开发者体验对生产力有着重要影响。

毕竟，软件开发首先是创造性的工作，意味着改善开发者生产力的任何努力都应该关注人与计算机、人与人之间的互动，涵盖人员、流程和技术。然而，这比你想象的更加困难，因为人的体验很少是多项选择题。

开发者生产力研究还是一个新兴的课题，因为通常很难衡量开发者的整体体验。

在最近的一期 “Engineering Enablement” 播客节目中，主持人 Abi Noda 采访了谷歌工程生产力研究团队的 Ciera Jaspan 和 Collin Green，他们共同致力于领导这个团队。在谷歌，数以万计的工程师的工程生产力归结为实现“无摩擦的工程和卓越的产品”。

在本文中，我们将反思谷歌的工程师、用户体验研究员和心理学家们的最新研究成果和经验教训，他们致力于衡量和提升开发者的体验和生产力。

谷歌工程生产力团队拥有约 2000 名工程师，致力于提升开发者工具和流程效益。团队内还有一支专注于研究工程生产力的小组，他们关注的不仅仅是“怎么做”，更多的是“为什么做”，“什么时候做”，“做多少”。

这是一个混合方法团队，既进行定量研究，也进行定性研究。团队中大约一半是工程师，另一半是用户体验研究员，他们来自行为经济学家、社会心理学家、产业组织心理学家甚至公共卫生领域。

Jaspan 指出，社会科学背景为团队提供了必要的背景。日志分析通常是工程生产力研究的一个常见起点，但它只呈现了部分信息。她在播客中表示：“它告诉你开发者做了什么，但未告诉你其动机和感受。它没有评估行为的优劣，也没有揭示改进空间。它只给了你一个数字，但你不能解释这个数字。除非你拥有更多定性的世界观，你了解行为以及这些行为随时间的变化，取决于你如何改变背景。”

因此，大约五年前，生产力研究团队首次聘请了第一位用户体验研究员，以协助设计更好的调查问卷。通过将用户体验研究员与工程师配对，他们优化了问题的内容、时间和方式。例如，这种配对使得体验抽样成为可能，将调查问卷融入开发者的构建过程中。工程师提供实践经验和技术解决方案，支持用户体验研究。

Green 表示：“直接接触那些在领域内非常深入且处于领域顶尖水平的专家，是行为研究方法中非常有力的补充。领域专业知识、来自工程领域的可扩展性和技术技能结合多样化的行为研究方法，以及对偏见、工作方式和调查回应或访谈注意事项的理解，这些社会科学家们共同为谷歌的用户体验研究提供了一种或许独特的方式。”用户体验研究员们揭示了非响应偏见，而工程师们则发现了上游问题，因为事情看起来不太对劲。

这个团队的首要客户是为整个组织构建开发工具的第一方开发团队。目标是帮助他们改进基础设施工具、流程和最佳实践。

“例如，当他们想要了解如何提高开发者生产力时，我们的数据和研究是他们寻找答案的地方之一，”Green 说道。

生产力研究团队还与运营、房地产和工作空间、公司工程等团队合作，这些团队为所有谷歌员工创建工具，而不仅仅是工程师，以及其他可能影响整体开发者体验的团队。当然，开发者生产力的体验也可能惠及其他非技术团队，前提是要进行跨公司的沟通。

“因此，当你关注工程生产力时，你实际上是关注了谷歌的一大部分人口，因此对我们的发现有广泛的兴趣，”Green 表示。

谷歌的工程生产力团队还充当着不同开发团队之间的桥梁。正如 Jaspan 所说：“公司非常大，人们在做不同类型的开发工作。构建工具的人可能不知道正在进行的所有不同类型的工作。”

所有这些都为 Green 所说的“形成良好数据的游乐场”提供了条件，配合具有实际问题经验的工程师。

那么，如果你拥有谷歌的工程预算，你会衡量什么呢？

随着平台工程的兴起和跨组织工具的整合，追踪技术开发者体验变得更加容易。然而，技术对人类用户的影响以及围绕这种体验的人员和流程仍然具有挑战性。没有单一的度量可以完全捕捉到这一点。

Jaspan 表示，开发者生产力研究团队坚持一个理念：没有单一的指标可以衡量开发者生产力。从这里开始，她解释道，团队通过三个交叉的维度进行三角定位：

• 速度

• 便利

• 质量

例如，Green 曾经以半开玩笑的方式提出，为了说明一个观点，最快提高生产力的方法可能是取消代码审查。当然，大家都抵制这个想法，因为虽然这样可以提高发布的速度和便利性，但会降低质量。而团队的研究已经证明，代码质量可以提高开发者的生产力。

在速度方面，他们确实会测量日志，但他们还会测量工程师对自己速度的感知，以及进行日记研究和访谈。Jaspan 说：“这既包括使用多种测量方法，也要确保它们彼此之间是相互验证的。”

为了更深入地研究谷歌的软件开发行为，团队进行了跨工具日志研究，从多个开发者工具中提取了日志。他们还进行了日记研究，在这个研究中，工程师每隔几分钟就写下他们在做什么。他们将这两种方法进行比较，以便在数据日志方面建立信心。由于每个工程师的工作和感知都不同，可能会出现类似“苹果和橙子”的情况，因此他们应用了称为“多评判者可靠性”的方法来计算这两个研究之间的一致性。

“我们假设在外面有一些真实情况，如果我们不坐在开发者旁边，可能无法直接观察到，”Green 说道，“因此，我们将这两个数据源结合起来，问：这两种视角是否在告诉我们同一个世界的信息？”

数据日志研究可以大规模被动进行，无需干扰工程师，而日记研究一次只能由最多 50 名工程师进行，并且可能会变得令人讨厌。

“一旦我们找到了足够的证据表明这两个数据源提供了相同的信息，我们就可以更加倚重可扩展的方法，”他解释道。

自 2018 年以来，谷歌另一个强大的测量工具是每季度进行的工程满意度调查，每次向大约三分之一的工程人员发送。Green 承认，最初高管们对这种测量有些犹豫，因为这只是“人们的意见”。在 2020 年的疫情封锁期间，这项调查首次显示出生产率的增长，随后在下一个季度出现了大幅下降，因为居家隔离常常会让人们感到孤单。

已经证明，技术债务会对开发者的士气产生负面影响，并减缓开发速度，因此不奇怪，早期的调查中就包含了两个关于技术债务对生产力影响的问题：

• 你遇到的技术债务的根本原因是什么？

• 什么措施适合修复这些技术债务？

多年来，Jaspan 和 Green 的团队对这些回答进行了整合，最终确定了可能妨碍工程生产力的 10 个技术债务类别：

• 需要迁移或正在进行迁移。

• 项目和 / 或 API 的文档难以找到，缺失或不完整。

• 测试质量或覆盖率较差。

• 代码质量设计不佳。

• 未删除已死亡和 / 或被放弃的代码。

• 代码库质量降低，未跟上变化的标准。

• 团队缺乏必要的专业知识。

• 依赖关系不稳定，变化迅速，或触发回滚。

• 迁移执行不佳或被放弃，可能导致维护两个版本。

• 需要更新、迁移或维护发布流程。

工程师可以选择任何一个或多个选项。产生的数据揭示了不同受众（如机器学习工程师与后端工程师）需要不同的技术债务干预措施。他们还根据组织线对数据进行切割，以显示和比较在克服技术债务方面的进展。

关于这个技术债务问题的论文承认，基于调查的度量是滞后指标，只有当技术债务严重到足以妨碍工程师时，才会显现出真正的问题。然而，在探索了 117 个度量指标之后，谷歌团队仍然没有找到并预测技术债务将在何时妨碍生产力。

他们还添加了四个问题，了解团队如何管理债务，以寻求持续改进。

随着这项调查对整个组织变得越来越重要，工程副总裁开始提出自己的问题。这在一段时间内是有帮助的，但随后调查必须被重新精简。现在，每个季度由不同的用户体验研究员负责调查，得到不同工程师的支持，同时伴随着团队的反馈。Green 承认，这项调查仍然相当“庞大”。

无论你的组织规模（和预算）如何，都鼓励你投资于自动化和可测量的、观察性和经验性的研究，以了解你的开发者体验以及它支持或妨碍的生产力。

请记住，随着团队和代码的变化，度量指标也会发生变化。正如 Jaspan 所说：“我们知道没有一个单一的度量可以衡量开发者生产力，因此我们尝试使用所有这些不同的研究方法来观察：它们是否都一致？它们是否在告诉我们发生了相同的事情？还是它们不一致？如果是这种情况，我们需要深入挖掘发生了什么。”

Jennifer Riggins 是一个文化与科技故事叙述者、记者、作家，以及活动和播客主持人，她致力于分享文化与技术交汇的故事，并解释我们正在构建的技术所带来的影响。自 2003 年以来，她一直从事写作工作，目前居住在伦敦。

原文链接：