Google 如何借助平台工程进一步释放开发人员生产力

本文链接：https://blog.csdn.net/PE_community/article/details/132898761

作者｜Jennifer Riggins

翻译｜平台工程技术社区

链接｜https://thenewstack.io/how-google-unlocks-and-measures-developer-productivity/

在追求快速增长的时代，企业试图使用更少的资源做更多的事情。因此，对于科技企业来说释放软件开发最大开支之一——开发人员的生产力，比以往任何时候都更加重要。开发人员生产力衡量工程师在给定时间内完成一定量工作的能力。越来越多研究尝试衡量开发者体验（DevEx），并发现良好的 DevEx 能够有效提高生产力。

软件开发首先是创造性的工作，这也意味着任何提高开发人员生产力的努力都应该集中在人员、流程和技术之间的人与计算机和人与人的交互上。但这并不是一件容易的事。同时开发人员生产力研究也是一个新兴话题，因为开发人员的体验通常很难衡量。

在这篇文章中，我们将结合软件工程师、用户体验（UX）研究人员和心理学家的研究结果，聊聊 Google 是如何衡量和增强开发人员的体验和生产力的。

1. 团队设置：成员构成

Google 的工程生产力团队拥有约 2,000 名工程师，主要致力于提高开发人员工具和流程的效率，其中有一个小团队专注于工程生产力研究。团队同时进行定量和定性研究，团队中大约一半是工程师还有一半是用户体验研究人员，有意思的是这些成员以前担任过行为经济学家、社会心理学家、工业组织心理学家，甚至还有来自公共卫生部门的人员。

Google 生产力研究小组负责人 Jaspan 说，社会科学提供了必要的背景。开发者生产力研究通常从日志分析开始，但日志分析并不能体现开发者是怎样的感受，或者他们工作的好坏以及是否有改进空间。因此需要进行定性研究（qualitative research）进行更全面的了解，了解研究的行为以及这些行为如何随着时间的推移而变化。

因此，生产力研究团队在五年前聘请了第一位用户体验研究员，来帮助设计更好的调查问卷。然后，通过将用户体验人员与工程师配对，进而优化调查内容、调查时间和方式。例如，这种配对实现了体验取样，在开发人员运行构建时进行调查。工程师可以帮助提供第一手经验和技术解决方案，从而扩大用户体验研究的范围。

能够直接接触到深谙此道并在各自领域处于顶尖地位的专家，对于行为研究方法来说无疑是一种强大的助力。来自工程方面的专业领域知识、技术技能，再加上各种行为研究方法，以及社会科学家对偏见、人们的工作方式、调查回答或访谈中应注意的事项等问题的处理能力，这些因素以一种谷歌独有的方式结合在一起，共同推动用户体验研究。

2. 提升开发人员生产力是整个组织的目标

生产力研究小组迎来的第一批合作团队，也就是为整个企业构建开发人员工具的开发团队，研究小组的目标是帮助他们改进基础设施工具、流程和最佳实践。在开发团队想要知道如何提升开发人员生产力，以及什么因素能够使开发人员更有成效时，我们的数据和研究能够帮助他们衡量和了解这些信息。

生产力研究团队还与其他团队合作，包括运营、地产与办公场所部门、工程部门（为所有 Google 员工而不仅仅是工程师创建工具）以及其他可以影响整体开发人员体验的团队。当然，从提升开发人员生产力中积累的经验也可以使其他非技术团队受益。也就是说当我们再关注开发人员的生产力时，实际也在关注绝大部分谷歌员工。

Google 工程生产力团队还充当不同开发团队之间的桥梁。正如 Jaspan 所说，“公司真的很大，不同团队正在进行不同类型的开发，构建工具的人可能并不知道这些工作分别是什么类型。所有的数据为研究提供了良好资源，研究小组也与对当前问题具有实际经验的工程师进行配对。

3. 生产力指标：速度、舒适度、工作质量

随着平台工程的兴起和跨组织工具的整合，跟踪技术开发人员的体验较之前变得更加容易。不过想要明确平台工程对于用户的影响以及围绕该体验的人员和流程的影响依旧是一项挑战，因为任何单一的测量都无法捕捉到这一点。Jaspan 表示，开发人员生产力研究团队秉持一个理念：没有任何单一指标可以独立提高开发人员的生产力。因此在团队中，我们对以下三个方面进行研究和测量：

速度
舒适度
代码质量

举个极端的例子，如果想要快速提高开发生产力，那么取消代码审查是最快的方法。当然这个是不现实的，因为这样虽然提高了发布的速度和易用性，但降低了代码的质量。并且研究小组的另一个研究发现，代码质量可以提高开发人员的工作效率[1]。对于速度，根据开发人员日志进行测量，同时也测量开发人员对自己的速度的感知以及记录研究和单独访谈。通过多种途径和方式，确保列出的三个方面相互验证。

4. 混合方法研究验证数据

为了更深入地研究 Google 的软件开发行为，该团队进行了跨工具日志研究，从多个开发人员工具中提取日志。他们还进行了一项日记研究（diary study），工程师每隔几分钟就写下他们正在做的事情。他们对两者进行了比较，以建立对数据日志的信心。由于每个工程师的工作方式和对自己工作的看法不同，因此对待同一事件出现天差地别的观点，因此他们应用所谓的交互者可靠性来计算两项研究之间的一致性。

数据日志研究可以在不打扰开发人员的情况下执行，但日记研究一次只能最多由50名开发者完成，如此反复可能使他们变得厌烦。不过研究小组表示，如果找到了充分的依据证明这两个研究方法能够得到相同的结论，就可以采用可扩展的方法继续研究。

5. 技术债务和工程满意度调查

自 2018 年以来，谷歌的另一个强大衡量工具是开发者满意度季度调查，每次调查约三分之一的开发人员。起初高管们对这一衡量标准持保留态度，认为这只是开发者们主观的意见，不具备太多参考价值。在 2020 年 lockdown 期间，调查首先显示生产力有所上升，但随后在下一个季度出现大幅下降，因为人们经常在家中独处。

同时研究小组还发现，技术债务会对开发人员工作态度产生负面影响，并降低开发速度。调查早期就技术债务对生产力的影响提出了两个问题：

您遇到的技术债务的根本原因是什么？
哪些缓解措施适合解决这种技术债务？

根据多年调研，研究小组确定了以下10类可能阻碍开发生产力的技术债务：

需要迁移或正在进行迁移。
有关项目和/或 API 的文档很难找到、缺失或不完整。
测试质量或覆盖率较差。
代码质量设计得不好。
无效和/或废弃的代码尚未被删除。
代码库已经退化或者跟不上不断变化的标准。
团队缺乏必要的专业知识。
依赖关系不稳定、快速变化或触发回滚。
迁移执行不力或被放弃，可能导致维护两个版本。
发布流程需要更新、迁移或维护。

开发人员可以选择任何或所有选项。由此产生的数据揭示了不同受众（例如机器学习工程师与后端工程师）所需的不同技术债务干预措施。他们还按照组织结构对数据进行分析，以显示和比较处理技术债务的进展情况。

关于这个技术债务问题的论文[2]承认，基于调查的干预措施是一个滞后指标，因为只有当技术债务变得严重到足以阻碍工程师时，它才会作为一个真正的问题出现。然而，在探索了 117 个指标之后，Google 团队尚未确定并预测技术债务何时会阻碍生产力。

为了寻求持续改进，研究小组还添加了四个关于团队如何管理债务的问题。随着这项调查对整个组织变得越来越重要，工程副总裁开始提出自己的问题，这在一段时间内很有帮助，但随后调查必须重新精简。现在每个季度都有不同的用户体验研究人员负责调查，并得到不同开发人员的支持以及团队反馈。不可否认的是，这项调查规模依旧十分庞大。

无论您的组织规模（和预算）有多大，我们都鼓励您投资于自动化和可衡量的、观察性和体验式研究的组合，以了解您的开发人员体验以及它支持或阻碍的生产力。

请记住，指标会随着团队和代码的变化而变化。正如 Jaspan 所说，“我们知道开发人员的生产力没有单一的衡量标准，因此我们尝试使用所有这些不同的研究方法来看看：它们是否都一致？他们是否告诉我们同样的事情正在发生？在这种情况下，我们需要更深入地挖掘，找出到底发生了什么。”