谷歌如何解锁并衡量开发者的生产力 [译]
![谷歌如何解锁并衡量开发者的生产力 [译]](https://cdn.thenewstack.io/media/2023/08/051a9f44-developer-productivity-1024x576.jpeg)
探究谷歌是如何运用混合方法研究、日志记录等手段来评估开发者生产力的。
在快速增长的阶段暂缓之际，工程团队面临着用更少资源完成更多任务的挑战。即便是科技巨头谷歌，也不例外，他们在去年一月裁减了 6% 的员工。无论身处何处，客户预算的紧缩都在促使人们更快地发布具有差异化特性的产品。
在这个背景下，提高软件开发过程中一个重大开支——即人力资源——的生产力变得尤为关键。
开发者生产力研究旨在衡量工程师在特定时间内完成既定工作量的能力。这一领域的研究不仅关注结果，还着眼于影响结果的社会技术因素。该研究越来越多地尝试评估开发者的体验，因为有证据表明优秀的开发者体验（DevEx）能促进生产力。
毕竟，软件开发本质上是一种创造性工作。任何旨在提升开发者生产力的努力都应着重于人与计算机以及人与人之间的互动，涉及人员、流程和技术。这比想象中更为复杂，因为人类的体验很少是简单的多选题。
同时，开发者生产力研究也是一个新兴领域，通常很难量化开发者的整体体验。
Humanitec 是您内部开发平台的核心平台编排工具。它帮助平台团队通过创建开发者的“黄金路径”来消除瓶颈。开发者可以自助获取他们需要的技术来部署和运营应用，从而提升生产力和效率。
了解更多
HUMANITEC 的最新动态
[平台编排：行业变革者？ | Humanitec
2023 年 12 月 18 日
2023 年 12 月 18 日
2023 年 11 月 23 日
在工程效能提升播客的最新一期中，主持人 Abi Noda 采访了 Ciera Jaspan 和 Collin Green，他们是 Google 工程生产力研究团队的领头人。在 Google，数以万计的工程师的工程生产力取决于“实现高效流畅的工程操作和优秀的产品输出”。
本文回顾了工程师、用户体验（UX）研究人员和心理学家们的最新研究和心得，这些研究和心得致力于评估和增强 Google 的开发者体验及其生产力。
团队构成：成员概览
谷歌工程生产力团队拥有大约 2000 名工程师，主要任务是提升开发工具和流程的效率。在这个大团队中，有一个较小的分支专注于工程生产力研究，这不单是关于“如何做”，更涉及“为什么要做”、“何时做”、“做什么”以及“投入多少”。
该团队采用混合研究方法，同时进行定量和定性研究。团队成员构成多样，一半是工程师，另一半是用户体验研究员（user experience researchers），队伍中不乏有从事过行为经济学家（behavioral economists）、社会心理学家（social psychologists）、工业 - 组织心理学家（industrial-organizational psychologists）甚至公共卫生领域工作的人员。
Jaspan 表示，社会科学背景为研究提供了必要的视角。日志分析作为开发者生产力研究的常用起点，只能展示部分情况。“这种分析能反映开发者的行为模式，但无法揭示他们的动机、他们对此的感受、他们的行为是否正确或是否存在改进空间。它仅提供一组数据，但这些数据本身并不足以解释全部，”她在播客中说。“只有结合定性研究，理解行为及其随环境变化的动态，才能全面解读这些现象。”
这就是为什么生产力研究团队大约五年前首次聘请 UX 研究员，以设计更有效的调查问卷。通过 UX 专家与工程师的合作，他们不仅优化了调查内容，还改进了调查的时机和方式。例如，这种合作促成了体验采样，使调查能够在开发者进行构建操作时同步进行。工程师们凭借自身经验和技术解决方案，有效扩展了 UX 研究的范围。
Green 评论说：“直接接触这些深耕于各自领域、业界顶尖的专家，为我们的行为研究方法增添了强大的力量。”“工程师的领域专业知识、技术可扩展性，与社会科学家的行为研究方法多样性、对偏见、工作方式、调查反馈和访谈注意事项的深刻理解相结合，为 UX 研究创造了独特的谷歌式方法。UX 团队发现了无回应偏差，而工程师则因为发现某些事情看起来不对劲，从而揭露了上游的漏洞。”
提升开发者生产力：一个组织范围内的共同目标
这个团队最初服务的客户是负责整个组织开发工具的内部开发团队。他们的目标是协助这个团队改进基础设施工具、流程和最佳实践。
Green 表示：“比如，当他们想要了解什么因素能提升开发者的生产力，以及如何进一步提升时，我们的数据和研究是他们理解和测量这些因素的重要资源之一。”
生产力研究团队还与包括运营、房地产和工作空间、企业工程（他们为所有谷歌员工，而不仅仅是工程师，创建工具）等其他团队合作，影响整体开发者体验。当然，开发者生产力的研究成果也能惠及其他非技术团队，前提是保持跨公司的有效沟通。
Green 说：“所以，当你关注工程生产力时，你其实是关注了谷歌大部分员工。因此，我们的发现引起了广泛关注。”
谷歌工程生产力团队也在不同开发团队间起到桥梁作用。Jaspan 说：“公司规模庞大。人们从事的开发类型各异。负责开发工具的团队可能并不了解所有不同类型的工作。”
Green 将这种情况描述为“数据完善的实验场”，这里汇集了对这些问题有实际经验的工程师。
速度、便捷性与质量是生产力的驱动力
假设你拥有像谷歌这样的工程预算，你会选择测量哪些方面呢？
随着平台化工程的兴起和跨组织工具的合并，追踪技术开发者的经验变得更加简单。但挑战在于，这些技术对开发者本身以及围绕这些经验的人员和流程产生的影响难以量化。没有任何单一的测量方法能全面捕捉这些影响。
开发者生产力研究团队的 Jaspan 表示，他们遵循这样一个理念：不存在某个单一指标能完全衡量开发者的生产力。她解释说，团队通过以下三个相交的维度来进行综合评估：
- 速度
- 便捷性
- 质量
例如，Green 曾经半开玩笑地提出，为了强调一个观点，他认为取消代码审查将是提高生产力的快速方法——当然，这一提议遭到了普遍的反对，因为尽管这样做可能加快发布的速度和便捷性，却会牺牲代码质量。事实上，团队的研究也证实了高质量的代码能够提升开发者的生产力。
关于速度，他们不仅测量日志，还关注工程师对自己工作速度的感知，同时进行日记式研究和访谈。Jaspan 指出：“我们不仅采用多种测量方法，还确保这些方法之间能够相互验证。”
混合方法研究确认数据真实性
为了更深入地了解 Google 软件开发的行为模式，研究团队进行了一项跨工具日志研究，收集了来自多个开发工具的日志数据。同时，他们还开展了日记式研究，工程师们每隔几分钟就会记录他们的工作内容。这两种方法的对比旨在验证数据日志的准确性。由于每个工程师的工作方式和感知各有不同，这就好比比较苹果和橘子，因此研究中采用了互评者可靠性来衡量两种研究方法之间的一致性。
Green 表示：“我们认为存在某些无法直接观测到的真实情况，除非我们直接坐在开发者旁边，这很可能会干扰到他们。因此，我们比较这两种方法，看看它们是否都在揭示同一现实。”
数据日志研究可以在不打扰工程师的情况下大规模地进行，而日记研究则最多只能同时由 50 名工程师进行，且可能会引起不适。
Green 进一步解释说：“一旦我们确信两种方法提供的是相同的信息，我们就会更多地采用这种可扩展的方法。”
技术债务 (Technical Debt) 与工程满意度调查
Google 自 2018 年起采用了一种新的测量工具——每季度进行一次的工程满意度调查，针对约三分之一的工程师团队。Green 坦言，最初高层对于这种以“个人观点”为主的调查持保留态度。2020 年疫情封锁期间，调查首次显示了生产力的先升后降，这反映了人们在家独自工作的现实。
研究已表明，技术债务 (technical debt) 对开发者士气有负面影响，并且会减慢开发速度。因此，调查早期便聚焦于两个问题，探究 技术债务对生产力的影响：
- 你遇到的技术债务主要由哪些原因引起？
- 你认为什么样的措施可以有效解决这些技术债务？
经过多年的调研，Jaspan 和 Green 的团队综合分析了各种反馈，归纳出十大影响工程生产力的技术债务类别：
- 需要迁移或迁移正在进行。
- 难以找到、缺失或不完整的项目和/或 API 文档。
- 测试质量低或覆盖不全。
- 代码设计质量差。
- 未清理的死代码或废弃代码。
- 代码库陈旧，未跟上时代变化。
- 团队缺乏必要技能。
- 不稳定、频繁变动或易引发回滚的依赖关系。
- 执行不佳或中止的迁移，可能导致维护两个版本。
- 需要更新、迁移或维护的发布流程。
工程师可以根据实际情况选择一个或多个选项。这些数据帮助揭示了不同领域工程师（如机器学习工程师与后端工程师）面临的技术债务问题及其解决方法的差异。此外，通过沿组织架构的数据分析，能够展示和比较各部门在解决这些技术债务方面的进展。
这篇关于技术债问题的论文指出，基于调查的测量方式是一种滞后反应——它只在技术债问题严重到影响工程师工作时才显现出来。即便谷歌团队探索了 117 种度量方法，他们仍未找到方法来预判技术债什么时候会开始影响生产力。
团队也新增了四个问题，关注团队是如何处理这些债务的，目标是寻求持续改善。
随着这项调查对整个组织越来越重要，工程副总裁们开始提出各自的问题。这一阶段的调查虽有帮助，但随后必须进行精简。现在，每季度都有不同的用户体验研究者和工程师，以及团队反馈来共同负责这项调查。格林承认，调查内容依然相当繁杂。
不论您的组织规模或预算大小，都建议您投入自动化和可度量的研究，以及观察性和体验性研究的结合，来深入理解开发者体验及其对生产力的影响。
请记住，随着团队和代码的变化，度量标准也会随之改变。正如贾斯潘所言：“我们知道没有单一的开发者生产力度量标准，因此我们尝试采用多种不同的研究方法来观察：这些方法是否指向一致的结果？它们是否揭示出相同的现象？或者是否存在不一致之处？如果有，我们就需要进一步深入探究，弄清楚实际发生了什么。”