开发者效率不仅难以衡量，还高度依赖于每个组织的文化和开发体验，Atlassian的敏捷和DevOps布道者团队负责人Andrew Boyagi表示。
“开发者比任何其他行业都热爱他们的工作。” - 这句话打动了我。译自 Measure Developer Joy， Not Productivity， Says Atlassian Lead 。
你正在错误地评估开发者效率，根据Atlassian敏捷和DevOps布道者团队负责人Andrew Boyagi的说法。
毫无疑问，过去一年随着团队和预算的收缩，重新聚焦提升开发者效率。的确，技术行业长期以来一直试图评估开发者效率，但组织经常在试图与其他组织建立基准时失误。
同样值得注意的是，2023年提升开发者效率的动力似乎缺乏前几年关注开发者倦怠和幸福的担忧。
这是错误的做法。10月发布的第9届年度DevOps状态报告中，Google的DevOps研究和评估团队(DORA)采访了近3000名技术从业者。今年的报告着眼于评估三个结果:
- 组织绩效: 为客户和社区创造价值。
- 团队绩效: 赋能团队进行创新和协作。
- 员工幸福: 减少疲惫，提高满意度和/或效率。
结果非常明确: 文化至关重要。具体来说，根据报告，一个培育积极组织文化(基于高度信任和信息流动)的高绩效组织，其绩效提升30%，效率和工作满意度大幅提高，同时疲惫减少。
开心的员工更有效率，这是经过长期验证的。因此Boyagi认为应关注开发体验(DevEx)，而不是效率。下面解释这意味着什么，以及如何确定在你的组织中该如何做到这一点。
“我与其他公司的高管交谈时，他们非常关注衡量开发者效率，但鲜少有人谈及实际帮助开发者提升效率。” Boyagi 对The New Stack说。
工程本质上是一门科学，所以我们知道如果不进行评估就无法改进。但是我们评估的必须是重要的方面。
“开发者比任何其他行业都热爱他们的工作。”他说，这凸显了他们指导其他开发者、在YouTube、Discord和LinkedIn上分享持续学习的行为，以及仅去年一年就贡献了4.13亿开源代码的行为。
“而且他们也不是不想提高效率。”他补充说，“所以出现了这样的情况:他们热爱自己的工作，想提高效率，觉得自己效率不高，然后管理者还想评估效率。”
因此，如果开心的开发者更有效率，Boyagi认为，那么开发者效率就成为开发者快乐的副产品，组成部分是:
- 开发者体验: 工程师对工具和框架的感受。
- 工程文化: 他们完成工作的方式和领导的支持方式——组织独特的个性。
甚至 Atlassian CTO Rajeev Rajan也认为开发者快乐是释放开发者效率的关键。他在公司博客文章中写道，快乐可以通过三个方面来评估:
- 提供出色的工具。
- 赋能团队。
- 培育出色的工程文化。
鉴于这种独特性的重要性，Boyagi说，你可以购买与高绩效公司相同的工具。但是你不能“像他们那样去做，因为行不通。事实上，如果你试图照搬，情况可能会变得更糟。”
“你不会得到一套可以普遍适用于每个组织的指标，因为效率是开发者体验和工程文化的副产品。它们对一个组织来说是如此独特，不可能只采用一套标准指标并应用。”
—— Andrew Boyagi， Atlassian
那么，当高层管理面临展示其最大运营支出结果的压力时，科技公司该怎么办？
首先，Boyagi建议，改变你的问题。不要问“我该如何提高开发者效率？”或“我该如何评估开发者效率？”，而要问“我该如何让开发者更快乐？”和“我该如何帮助开发者更有效率？”
这些问题可以帮助对话朝更有用的方向发展: “我认为每个公司都必须踏上适合自己的旅程，在效率方面做合适的事。但我不认为评估是我们应讨论的事情。”
首先，因为知识工作者的效率一直是最难评估的。其次，他补充说，我们需要从其他公司获取灵感，而不是复制他们的做法。
Boyagi并不建议你试图复制Atlassian的做法。但可以随意从其DevEx策略以及谷歌、Netflix、领英和Spotify等其他高绩效组织中获取灵感和借鉴。
Atlassian为每个工程师提供每月一次5分钟的匿名调查，以及每周一次团队CheckOps。CheckOps类似回顾会——进展顺利的方面？可以改进的方面？我们该如何改进？—— 在Atlassian开发者体验平台Compass内进行。每个团队在Compass中查看自己的记分卡和统计数据，以反思本周情况。此外，每个团队达成内部共识，回答一个具体问题:本周团队感觉如何？
CheckOps供每个团队反思一周所发生的事情，而匿名工程师调查则为整个组织提供脉搏。
Atlassian还根据Boyagi的说法从DORA(失败率变化、失败部署恢复时间、部署频率和交付时间)和SPACE 指标(影响DevEx的社会技术因素)“获取灵感”。尽管存在普遍的误解，但它们都不是开发者效率指标，而是Atlassian在评估公司整体开发者体验时考虑的不同角度。
有趣的是，故事点数——完成一项工作所需的总体努力的估计值，在建议的SPACE指标中可以找到——是与Atlassian产品Jira最相关的软件开发指标之一，也许是最有争议和最容易被滥用的指标。
“故事点数也是一种估计。”Boyagi说，“在我看来，它们不是效率指标。但是，像任何事情一样，在某些场景下，故事点数是有效的估计工具。这取决于组织，取决于场景。没有指标我可以说每个人都应该采用，因为没有什么真正普遍适用。”
Atlassian发现一个特别有用的指标是开发者花在寻找文档上的时间。在大多数工程组织中，寻找信息是破坏开发者工作流的一个大挫折来源。
事实上，根据去年的Stack Overflow开发者调查，所有受访者中有62%的人表示他们每天花30分钟以上搜索问题或解决方案；25%的人花费超过1小时。在一个50人的团队中，这相当于每周“损失”的时间超过300小时。
“发生了向云的转变。开发者现在必须做的事情太多了。我们的看法是，开发者需要一个工具来浏览他们拥有的所有信息，并在技术栈中进行协作。”Boyagi说。“这不仅仅是一个技术问题。如果只是一个可以解决一切的工具，那么就很简单，但这也是一个协作问题。”
Atlassian首先建立Compass以收回这些“损失”的时间并减少认知负荷。通过一个URL，它帮助解决了组织中的常见困惑，比如谁负责哪个组件，它的作用是什么，上下游依赖关系是什么，需要什么文档等。
Compass现在在内部采用率达到90%；10月份，它对外正式发布。
“Compass中的所有信息都存储在标准化的位置。”Boyagi说，“这真正赋能开发者自主工作。它提高了他们的速度。”
世界500强企业中的75%和约125，000家科技公司使用Atlassian的开发者产品。尽管如此，Boyagi说，Atlassian并没有使用其工具来评估客户的开发者体验；“开发者体验对组织来说非常独特，不是其他人可以替你测量的。”
相反，Atlassian团队收集客户反馈，然后提供工具帮助其客户改善自己的开发者体验。
Atlassian的开发者体验平台Compass集成了开发者必备的GitHub、GitLab、Jira、Bitbucket、CircleCI、LaunchDarkly、Snyk和PagerDuty，以收集关于开发者将想法投入生产的指标，评估是否:
- 平台易于构建。
- 拉取请求(PR)周期时间短。
- 开放PR数量不高。
- 构建时间短可以快速进行开发迭代。
- 单元测试覆盖率高。
今年平台工程受欢迎的主要原因之一是开发者对可扩展性的需求。考虑到这一点，Compass也建立在开放的工具链和公共API之上，以便每个组织或工程团队可以根据自己独特的开发者体验对其进行定制。其他组织也在该平台上构建自己的应用程序。
“它消除了软件团队需要查看30多个其他工具以找到所需信息的需要。”Boyagi说。
他举了开发者需要使用监控或日志工具来检查应用程序运行状况的例子。
“仅此而已，开发者就必须拥有该工具的登录信息，知道如何使用该工具，知道它的工作原理，在工具中找到他们正在查找的软件组件，以浏览层级结构。”他说，“他们找到所需信息后，又切换到另一个屏幕:我一开始在查找什么来着？我为什么需要这些信息？”
相反，Compass允许组织将所有这些数据导入，开发者可以在其中直接查找软件组件，减少认知负载并提升开发者体验。
Atlassian鼓励其工程师将10%的时间用于解决使他们的工作变糟的问题并改进这些问题。这可以包括扩展内部Compass实例，从而也可以帮助其他团队更轻松工作。
对于博登(Boden)、Dropbox和肯德基(KFC)英国和爱尔兰等Compass客户来说，按需治理也是一个受欢迎的使用案例。目前，大多数组织通过会议进行治理，Boyagi说，工程团队必须证明自己已经满足了标准才能获得发布批准。
“它不能确保高质量的生产结果。”他说，“它很慢，对所有参与者来说都很令人沮丧。”
相反，Compass包含记分卡，治理团队可以使用它们来分发他们的要求，如服务准备情况。这意味着每个人一开始就非常清楚要求，要求会自动更新。
“最好的部分是，你实际上不必再开会了。”Boyagi说，“因为在那些会议上，向从未交付过软件的人解释你做了什么通常没有帮助。你可以说任何事，反正他们也不真正理解你在说什么，对吧？”
相反，Boyagi继续说，治理团队可以根据开发团队是否未能或即将未能满足要求来过滤记分卡。然后，他们可以联系该团队，帮助他们重回正轨。“这是一个非常不同的场景，”他说，“而不是‘来告诉我你做了什么’。”
通过帮助工程团队感觉每个人都希望他们成功，你就能提高开发者的乐趣并改善开发者体验。