谷歌如何解锁并衡量开发者的生产力 [译]

谷歌如何解锁并衡量开发者的生产力 [译]

💡 原文中文,约4500字,阅读约需11分钟。
📝

内容提要

谷歌工程生产力团队约2000人,由工程师与用户体验研究员、社会心理学家等组成,采用定量与定性结合的混合方法研究开发者生产力,通过日志分析、日记研究、访谈和季度工程满意度调查相互验证数据。研究认为生产力由速度、便捷性和质量三个维度构成,不存在单一指标;调查归纳出技术债务等十大影响因素,并强调度量标准需随团队与代码变化而调整。

🔎

延伸解读

混合方法:让数据与体验相互印证

谷歌团队强调,日志分析只能反映行为模式,无法解释动机与感受。他们通过日志研究、日记研究、访谈和季度调查相互验证,确保不同方法指向同一现实。这种设计承认开发者体验的复杂性,避免单一数据源误导决策。对于希望借鉴的团队,关键不是照搬工具,而是建立多源数据交叉检验的意识,并在可扩展的日志方法与深入的定性方法之间找到平衡。

生产力没有单一指标:速度、便捷与质量的权衡

文章明确指出,不存在某个单一指标能完全衡量开发者生产力。谷歌从速度、便捷性和质量三个相交维度综合评估,并以取消代码审查为例说明:只追求速度会牺牲质量,而高质量代码反而能提升生产力。这提醒读者,任何试图用单一数字(如提交量、代码行数)管理生产力的做法都可能扭曲行为。更合理的做法是结合主观感知与客观日志,关注维度间的相互制约。

技术债务的度量是滞后指标,但调查能揭示组织差异

谷歌自2018年起每季度开展工程满意度调查,早期聚焦技术债务的影响,并归纳出十大类别,如文档缺失、测试质量低、代码设计差等。文章指出,基于调查的测量是滞后反应,即便探索了117种度量方法,仍未找到预判技术债务何时影响生产力的方法。不过,调查数据能揭示不同领域工程师面临的问题差异,并沿组织架构比较各部门解决进展,为持续改善提供依据。

度量标准需随团队与代码变化而调整

文章最后提醒,随着团队和代码的变化,度量标准也会随之改变。谷歌团队没有固定一套指标,而是持续用多种研究方法观察结果是否一致,若出现不一致便深入探究。这一态度对任何组织都有参考价值:开发者生产力研究不是一次性项目,而应建立反馈循环,定期审视度量方法是否仍能反映真实情况,避免指标僵化后脱离实际工作。

❓

Q&A

谷歌工程生产力团队是如何构成的?

谷歌工程生产力团队约有2000名工程师,其中有一个专注于生产力研究的分支,成员一半是工程师,另一半是用户体验研究员,还包括行为经济学家、社会心理学家、工业-组织心理学家甚至公共卫生领域背景的人员。

谷歌为什么采用混合研究方法研究开发者生产力?

因为日志分析只能反映行为模式,无法揭示动机、感受或改进空间,需要结合定性研究(如访谈、日记研究)来理解行为及其动态,并通过多种方法相互验证数据真实性。

谷歌认为开发者生产力由哪些维度构成?

谷歌认为不存在单一指标,生产力由速度、便捷性和质量三个相交的维度综合评估。例如取消代码审查虽能提高速度和便捷性,但会牺牲质量,而高质量代码反而能提升生产力。

谷歌如何验证日志数据与工程师实际感知的一致性?

团队进行跨工具日志研究,同时开展日记式研究(工程师每隔几分钟记录工作内容),通过互评者可靠性衡量两种方法的一致性,确认后更多采用可扩展的日志方法。

谷歌的工程满意度调查发现了哪些影响生产力的技术债务类别?

调查归纳出十大技术债务类别,包括:需要迁移或迁移进行中、文档难以找到或不完整、测试质量低、代码设计差、死代码未清理、代码库陈旧、团队缺乏技能、依赖不稳定、迁移执行不佳、发布流程需更新等。

谷歌的工程满意度调查是如何演变的?

自2018年起每季度对约三分之一工程师团队进行调查,最初高层对主观调查持保留态度,但2020年疫情封锁期间调查首次显示生产力先升后降。早期聚焦技术债务问题,后新增四个问题关注团队处理债务的方式,随着组织重视,工程副总裁开始提出各自问题,调查内容虽繁杂但需精简。

谷歌团队对开发者生产力度量标准有什么建议?

建议投入自动化和可度量的研究,结合观察性和体验性研究来深入理解开发者体验;同时强调度量标准需随团队和代码变化而调整,没有单一度量标准,应使用多种研究方法观察结果是否一致。

🏷️

标签

➡️

继续阅读