一家 DevEx 初创公司 Quotient 利用 AI 来识别哪些生产力指标对组织的扩展很重要，以及如何将数据转化为优先事项。
译自 How Do You Measure Developer Experience?，作者 Jennifer Riggins。
无论是在经济紧缩时期还是其他时期，寻求规模化的公司始终在如何吸引和留住技术人才的同时实现紧急业务目标方面发挥创造力。
随着开发者体验、平台工程和生产力已成为各种规模组织的优先事项，一家初创公司专注于没有时间或预算聘用 DevEx 研究人员的公司——那些可能没有时间阅读最新研究和不认为 DORA 指标满足其需求的公司。Quotient 成立于 2022 年，利用系统数据和每月三分钟的开发者调查相结合，构建工具以提高工程团队的生产力。它利用人工智能来发现需要改进的优先领域，并将其与基于研究的建议操作相结合。目标是帮助用户从最佳工程文化中学习。
The New Stack 独家采访了 Lizzie Matusov，Quotient 的联合创始人兼首席执行官，讨论了以研究为导向的工程领导力和高效工程团队的心理学——当然，还有如何衡量这一切。
Matusov 说：“在这样的市场中，公司专注于如何利用与之前相同甚至更少的资源来创造更多收入。” “因此，他们求助于开发者生产力来实现这一目标。”
她补充说，虽然宣扬像 Spotify、Microsoft和对于那些组织来说，“非常需要清晰、全面地了解生产力，并授权工程团队采取正确的行动。”Quotient 在较小的工程组织中找到了自己的利基市场，在这些组织中，工程管理层刚刚建立。虽然开发者生产力对他们的公司很重要，但他们正在竞相进入市场，并且通常没有预算来组建一个成熟的生产力工程团队来编写和分析详尽的季度调查数据。
Matusov 说，对于这些初创公司来说，工程和产品可以占到公司预算的 70% 以上，因此消除瓶颈可能会产生巨大影响。
这不仅仅是衡量开发者的观点。而是关于你如何利用这些信息。
Matusov 说：“传统上，作为市场的开发者生产力一直围绕共享仪表板，然后要求团队成为如何分析和操作数据的专家。”然后，工程领导层 专注于单一指标，例如速度，因为这样更容易理解。
她说：“虽然有吸引力，但事实证明，专注于单一指标会导致生产力下降。” “例如，在不考虑开发者体验的情况下专注于速度可能会导致团队交付稳定性较差的软件或错误的客户价值，同时 增加倦怠。这些维度都没有包含在单一指标中。”
谷歌将率先承认，当他们只关注四个关键指标：部署频率、变更前置时间、变更失败率和失败交付恢复时间时，大多数工程团队 错误地执行 DORA 指标。
但 Matusov 认为，这是因为收集和分析年度 DORA 报告、SPACE 框架、DevEx 指标 等几十个指标会让人不知所措。
她说：“开发者生产力是一个独特的领域，因为你需要足够的高质量信息来展示团队正在发生的事情，以及如何将信息转化为行动的可操作摘要。” “在过去几年中，我们从软件变化的方式中学到的是，简单性和分析对于在软件工具中提供价值至关重要。”
这是生成式人工智能可以证明有用的一个领域：它使我们能够比没有它时更快地浏览和语境化信息。
Quotient 从开发人员系统和开发人员调查中收集数据，以全面了解团队的生产力。然后，Matusov 说，它利用人工智能“提取大量指标，并将其转化为供团队采取行动的高信号子集”。该工具随后输出三项内容：
- 开发人员感知的摘要，指出团队层面的关键推动因素。
- 开发人员体验的指标视图。任何工程师都可以查看所有结果，而 Quotient 会突出显示它推荐的每个团队的重中之重。
- 团队采取的基于研究的建议操作。
该产品还利用人工智能来帮助分析月度结果以及持续的系统数据。
在当代开发人员体验中，很少强迫开发人员做任何事，这就是采用率是平台工程和 DevEx 成功的关键指标的原因。
Quotient 以超过 80% 的平均调查响应率为荣，Matusov 将其归功于“工具的数据匿名化、聚合且对团队透明的文化”。
此外，根据开发人员的响应采取行动时，会创建一个正反馈循环，鼓励更多开发人员参与。响应开发人员调查时交付的内部营销活动（如演示、路线图共享和新功能发布）有助于提高未来的调查响应率。
Matusov 说， Quotient 部分由创始人作为个人贡献者的经历推动，他们发现自己的工作在开发人员生产力数据中被不公平或错误地表示，并且“在领导工程师执行层面，对团队中发生的事情以及我们如何采取行动没有一个清晰的认识。”
对于组织来说，使用现有工具跟踪技术问题通常更容易。通常，非技术问题更难回答。
有关开发人员工作效率的一些最有趣的数据是开发人员对自己的工作的感受。所谓的“情感指标”可能与系统指标一样有洞察力，例如：使用这些工具，您感觉工作效率如何？您认为是什么阻碍了您的发展？
例如，情商包括心理安全措施，团队与心理学家、组织行为专家 Amy Edmondson 合作，将她的心理安全量表调整到软件开发环境中。
Matusov 说：“如果工程师对自己不同的想法感到不舒服”， “那么对他们作为一个团队用试验和错误得出正确解决方案以及构建高质量的软件的速度有巨大的影响”。
心理安全考量包括：
- 该团队的人乐于分享信息，包括不起作用的内容以及起作用的内容。
- 开发人员对自己的工作有何感想？
- 开发人员对他们一起工作的团队有何感想？
由于开发人员体验本质上是社会技术性的，因此指标的组合非常关键。Quotient 结合了来自开发人员系统和视角的数据，包括有关团队如何使用流行协作工具（包括 GitHub、Jira 和 Slack）的数据。此团队级数据包括：
- 团队如何分配代码审查期？
- 团队的平均代码审阅复杂度如何？
- 团队花费最多时间处理哪些类型的代码问题？
Quotient 随后会将该数据与每月的开发者调查相结合。Matusov 表示，两组数字均采用 SPACE 开发者生产力框架，该框架的合著者 Jenna Butler 担任 Quotient 公司的关键顾问。
技术债通常是团队肩上的一块重担，直到它被消除才会被注意到。它对整个组织都有影响。
在 4 月份 TNS VoxPop 调查中，当被问及“您发货速度最慢的软件的最大障碍是什么？”时，迄今为止参与者中最大一部分（43%）表示“复杂的代码库和技术债务”。
技术债务是另一个瓶颈，不仅仅影响一个团队。
“Quotient 行动的基石之一是，较小、迭代的行动会为团队带来巨大的生产力提升，”Matusov 说，“我们不会建议团队立即偿还技术债务——这并不是他们作为团队可以立即控制的事情——我们为团队提供了合适的工具，让他们直接掌控自己的生产力。”
Quotient 的一项建议是编目和沟通技术债务。“这样，我们让团队有机会找出技术债务中最大的驱动因素，以及如何对其进行优先级排序，”Matusov 说。“现在团队有了这些信息，团队层面更有可能采取措施来改善他们的处境。”
技术债务是业务影响优先级的明确示例之一。为客户创造价值的压力很大。但处理技术债务会对截止日期产生影响，而截止日期是由工程和产品共同协商制定的。
据 Matusov 说，Quotient 的一位新客户看到团队自主权和技术债务的影响得到了显著改善。它们之间有什么关系？她说，随着技术债务的减少，“团队不再需要为技术债务而争吵，这意味着他们有更多机会去做他们认为重要的事情。这对生产力至关重要。”
“我们根本不会在平台上的任何地方报告工程师的个人数据，”Matusov 说，尽管启用了团队级别的报告。
“我们非常坚持认为，在单个平台上同时提高生产力和个人绩效很难，而不会在过程中破坏信任。而信任是我们所做工作的核心。”
毕竟，这也是 DevOps 的全部意义所在，其重点是消除团队流程的障碍。麦肯锡去年发布的臭名昭著的开发者生产力框架中没有体现这一点，该框架强调编写代码行。最近的开发者生产力研究包括来自 SPACE 和 DevEx 指标支持 Quotient 对团队的关注。
如果个人希望提供其他匿名信息，该产品还包含自由文本字段。
当然，“团队”仍然是一个模糊的术语。Quotient 与每位客户的工程领导合作，定义团队的含义。有时它是一个 5 到 9 人的 scrum 团队，但在 Matusov 合作的另一家公司，它是一个完整的 AI 团队，即使它分散在整个组织中，也有独特的工作方式。
然后，当组织寻求解锁收益以帮助其快速扩展——她称之为“1 + 1 = 5”时——Quotient 为领导层提供了全局视图，可用于推动早期平台工程计划。该工具包括组织层面的见解和建议的行动，并得到行业和学术界的研究所支持。
在所有开发者生产力工具和调查中，文档仍然是一个瓶颈——开发者总是希望文档更多更好，但不想花时间来编写文档。当文档不可避免地成为优先事项时，Quotient 建议转向持续文档文化。
“团队面临的挑战是文档是他们最关心的领域，”Matusov 认为，因为“团队内部有一种文化，即在编写所有文档之前等待产品完成，这是很正常的。我们都经历过这种情况。”
但她说，如果你的团队采用持续文档文化，“你将在执行的每项任务或编写的每张工单中编写文档，而不是在项目结束时，那时这将是一项为期两周的巨大工作。”
结果是痛苦减少。但以文档为驱动的生产力提升可能会付出代价。
“关于如何错误地使用有关开发者行为的数据并可能利用这些数据损害团队的多样性和影响多样性，有大量研究，”Matusov 警告说。
例如，2023 年 Google DevOps 研究与评估小组 (DORA) 研究——也称为加速 DevOps 报告——发现，总体而言，文档质量较高的团队的表现优于文档质量较低的团队。
“这很好；它提高了生产力。然而，他们还注意到一个趋势，即在文档得到改进的团队中，他们的代表性不足的群体也报告了更高的负担，”她说，这意味着女性和少数群体团队成员承担了比同龄人更多的文档编制责任。
“这强调了以高度信任、全面方式衡量开发人员体验的重要性。如果您错过了这些重要信号，您可能会无意中损害团队的整体生产力。”
随着行业在释放开发人员生产力方面取得重大胜利，重要的是，这不会以某些团队成员承担更多工作负担为代价。解决此问题的简单方法可能是将任务定义为“已完成”，如果已编制文档，并使该标准适用于将软件部署到生产环境的每个人。
心理安全、技术债务和工作分配是三个示例领域，需要对工程组织的开发人员体验有细致入微的了解，以便进行改进，从而提升团队的整体生产力。
“开发人员生产力的魔力在于，当您专注于赋能团队并与其向客户交付高价值解决方案的目标保持一致时，每个人都会受益，”Matusov 说。“工程师、团队文化和客户都将从提高的生产力中获得巨大价值。”