GenAI 将成为解锁开发团队生产力的关键趋势

2023 年人们越来越注重开发人员的工作效率。这是因为在云计算工具复杂性不断增加的时候，技术人员却容易遭遇裁员，而且不幸的是，该状况还在继续。团队需要用更少的资源做更多的事情。而由此产生的工作量和认知负荷已接近难以承受的程度。

这就催生了平台工程这一社会技术学科，开发人员支持团队致力于改善内部开发人员客户的工作生活——因为无论宏观经济环境如何，大量数据都表明，快乐的员工生产力更高。

开发人员为提高生产力所做出的努力旨在提高通过高质量代码交付业务价值的速度。2024年这种消除软件交付障碍的工作将会持续并不断深入。

01 平台工程的崛起

平台工程是 2023 年软件开发领域和 The New Stack 的热门话题。

顾名思义，平台工程是一种支架——通常以内部开发人员平台和团队的形式出现。 它提供了一个足够强大的基础，使组织内的大多数开发团队都能可靠、安全地在此基础上进行构建。

开发团队固然可以选择不采用平台工程团队搭建的框架，但这意味着他们偏离了平台工程团队为提高生产力而铺设 golden path，因此无法保证获得相同水平的支持和正常运行时间。

与以往自上而下的强制性平台实施不同，平台团队将内部开发人员同事视为客户，采用平台即产品的思维方式。这更多地是通过明显提高团队的工作效率来打造客户愿意使用的产品

Syntasso 的首席工程师 Abby Bangser 就将平台工程定义为旨在抽象成软件开发生命周期（SDLC）中 “无差别但并非不重要” 的工作的团队和技术。DX 开发人员体验平台最近发布了一份开发人员生产力团队常见类型列表，与上述观点不谋而合：

• 开发人员工具：构建、测试、部署。

• 启用和内部支持：编纂工作流程并提供支持。

• 前端平台：用户界面组件、网络框架、搜索。

• 后端平台：身份验证、网络网关、应用程序接口。

• 基础设施：Terraform、日志、Kubernetes、可观察性、云服务。

• 可靠性：事故管理和网站可靠性工程。

• 安全性：安全标准和风险管理。

• 数据：数据工程、仓储、访问。

在 DevOps 时代，SDLC 包含许多重要工作，这些工作可能会分散开发团队的主要精力——为最终用户带来不同的价值。平台团队汇集了部分或全部的开发人员生产力功能，可以将许多重要工作标准化和自动化，让开发人员更快地感受到生产力和影响力。

但是，需要注意的是：平台团队从不缺少功能请求，因此它需要优先考虑有助于减少摩擦和提高大多数内部开发人员工作效率的各种改进。这使得入门工作尤具挑战性。

Team Topologies 是 Manuel Pais 和 Matthew Skelton 针对现代、可持续的团队结构而提出的一种流行方法，主张从最薄弱的可行平台入手，即能够提供早期胜利的东西。这通常从文档或可发现性开始并由此发展。

这也不仅仅是一种趋势。平台工程作为提高开发人员工作效率的首选策略，正得到越来越多的投资。

Port 公司刚刚发布的问卷调查显示，拥有 150 名或以上开发人员的企业中的 100 名工程领导者是了解他们的平台和门户计划的。

研究还发现，85% 的公司已经开始实施或正在计划实施 IDP，而 99% 的受访者至少已经开始了他们的平台工程之旅。

最值得注意的调查结果可能是，53% 的受访者表示他们是从 2023 年才开始 IDP 这一历程的，这意味着 2024 年这些平台将可能逐渐趋于成熟。

02 支持开发人员的生产力

The New Stack 今年研究的一个问题是开发人员生产力或平台工程团队的规模。毕竟，在初创公司，每个开发人员都可能在为平台做贡献，只是没有把它作为自己的全职工作而已。他们正在接受这样的理念：看到问题，解决问题，规模化。

在过去一年的采访中，除 Netflix 的开发人员生产力占 15%的启用角色外，大多数赋能团队在工程组织中所占的比例都不到 10%。

DX 的最新报告是关于 “开发人员生产力团队规模” 的。他们在对 40 个团队的访谈中发现，拥有 1000 名以下开发人员的公司将大约 19% 的人员编制分配给了集中式开发人员生产力团队。

在工程师人数超过 10,000 人的公司中，约有 11% 的人从事跨组织工程技术促进工作。

毫无疑问，与支持整体工程一样，开发人员的生产力也是一项成本高昂的工作。但是，一旦开始运行，就应该为整个组织节省时间和金钱。从逻辑上讲，一个成功的平台团队的工作应该比其规模成倍扩大。

未来一年，团队规模是否会随着平台的普及而增长，或者平台的成熟度是否能让较小的团队为更大的工程师群体提供支持，都将有可能让我们有更多的了解。

03 指标之争仍在继续

OpsLevel 的 DevRel Fernando Villalba 最近在 LinkedIn 上表示，使开发人员或团队富有成效的因素因团队而异，因季度而异，甚至因个人而异，而试图强加准确的指标是徒劳的。

尽管如此，无法衡量的东西还是不能被改进。在这个痴迷于提高生产力的年代，衡量开发人员的生产力一直是每个人的心头大事。事实上，很多优秀的框架都是为此而生。

然后，麦肯锡框架就建立在行业标准 DORA 和 SPACE 框架的基础上，但它的目标是创建自己的框架，集中于开发人员生产力的狭义定义，即开发人员提供的最大价值是构建、编码和测试。

这也是开发人员不信任生产率指标的部分原因。

Extreme Programming 的创始人 Kent Beck 表示，很少有组织会围绕这些指标的动机提出并回答关键问题，这加剧了他们的疑虑：

• 谁在询问？

• 他们与被测量者之间的权力关系是什么？

• 询问的目的是什么？根据数据会改变哪些决策？

• 被测量者将采取哪些应对措施？

• 这些对策将如何影响管理者的目标？投资者？客户？

• 我们用什么单位来衡量？这些单位与其他人关心的单位（如利润）有什么关系？

Beck 声称，在得到这些问题的真实答案之前，将无法对衡量开发人员生产力的任何尝试发表评论。

2023 年发布的其他生产力衡量框架采用了更为复杂的社会技术视角。其中包括，早在今年 5 月，计算机大师协会（ACM）就发布了 DevEx: What Actually Drives Productivity 并表态，生产力来自开发人员的经验，以及以下因素的混合体：

• 流程状态：开发人员专注工作，进入 “状态”。

• 反馈回路：开发人员完成工作所需的时间与等待的时间。

• 认知负荷：开发人员需要了解多少知识才能更快地完成专注的工作。

这些 DevEx 指标扩展了 2021 年 SPACE 开发人员生产力框架的研究和建议，该框架提供了 25 个社会技术因素来衡量。

谷歌于 12 月在 IEEE 上发布的最新报告也旨在衡量行为，以提高生产力。该模型以开发人员的观点为基础，涵盖三个方面：

• 开发人员流程

• 专注时间

• 摩擦

也许是间接引用了麦肯锡的框架，报告写道 “与代码行数或多轮审核等其他衡量生产力的指标不同，我们定义的流程和摩擦指标是以人的判断为基础的，而不是根据正在使用的某些工具或正在采取的某些行动做出的假设”。

其中认定，他们对谷歌工程师的研究是基于主观体验——工作日结束后的日记，然后是访谈——然后是基于日志的数据，他们对第一种数据进行了验证。

报告建议，不要只依赖于容易收集的指标，比如构建数量。更重要的是，要衡量开发人员是觉得自己达到了流程状态，还是陷入了令人沮丧的问题，尽管这并不简单。

2023 年早些时候，Syntasso 的联合创始人兼首席运营官 Paula Kennedy 告诉我们，在开始平台工程路线图规划时，先看看 Jira 上最常出现的票据是什么——这是共享摩擦和挫折的信号。

谷歌最近的一项研究也开始让开发人员自己定义和识别摩擦——他们何时遇到摩擦、他们在做什么以及他们是如何解决的。

在谷歌，最常见的摩擦是构建和测试延迟、测试不稳定以及持续集成失败导致代码更改受阻等问题。在您的组织中，情况可能会截然不同，这就使得日记练习更有价值，而且计划性更低。

无论您在 2024 年以何种方式衡量开发人员的生产力，所有的道路都必须以与开发人员交流为起点和终点。而且要明白，每个工程组织的情况至少都会有些不同。

也许你应该以不同的方式来进行整个讨论。用 Atlassian 高级技术布道师 Andrew Boyagi 的话来说，就是要把问题从 “我们应该如何衡量开发人员的生产力？”转到 “我们如何帮助开发人员提高生产力？”。

04 GenAI：新一代开发人员生产力

随着开发人员生产力的提高， GenAI 也如雨后春笋般崛起。2024 年，人工智能将继续成为重要的生产力助手。

虽然平台工程旨在为团队提供支持，但早期的 GenAI 成果大多是针对个人的。从自动任务审批到人工智能配对编程，个人任务用例将是持续采用的关键。就像平台工程一样，人工智能协助解决最大的摩擦和挫折是关键所在。例如，当开发人员一直希望有更好的文档，但又不想编写时。

事实上，Google Cloud 发布的 2023 State of DevOps Report 中发现，高质量文档对组织绩效的影响估计要高出 12.8 倍。

这就是为什么在新的一年里，像 Joggr 这样以案例为中心的人工智能工具（它希望利用人工智能在集成开发环境中构建和更新内部知识库）将会与大牌工具一起大受欢迎的原因。

请记住，并非所有的生成式人工智能都是一样的。ChatGPT 生成的代码有 52% 的时间是不准确的，但它的回复却很有说服力。

随着公众不断训练这些大型语言模型，它们将继续提高准确性，但工程组织必须制定并传达生成式人工智能政策，以确保员工不会将敏感数据倾倒到公共数据库中。

这不仅是因为声誉风险，还因为您的团队正在迅速习惯使用这些人工智能辅助工具，不会轻易放弃使用权。

05

为开发人员提供情境和 Copilot

开发人员正在迅速采用像 GitHub Copilot 这样的工具（92% 的美国开发人员在该工具推出的头六个月内使用了它）。便利性——以及开发人员对人工智能工具将提高他们工作效率的看法——将决定他们是否愿意尝试使用人工智能工具。

例如，85% 的开发团队已经在 GitHub 上工作，因此已经集成到他们软件仓库中的 Copilot 意味着更少的上下文切换。谷歌刚刚发布了面向开发人员的 Duet AI，现在要了解其采用率还为时过早，但它能在谷歌套件的技术和协作开发体验中提供自然语言辅助的想法很有吸引力。

同样在 12 月，Atlassian 发布了嵌入 Jira 和 Confluence 的人工智能。2024 年，我们很可能会在其他软件开发生命周期中看到类似的人工智能产品。

但是，chatbot 不仅能在哪些方面提供帮助，它们还能提供背景信息。高级版本的 GenAI 产品不仅更安全，因为它们通常不会在私人数据上训练公共模型，而且根据贵公司的具体政策训练出来的模型也更有用。

2024 年的 GenAI 用例将迅速超越个人需求，覆盖更多的 SDLC。

DX 首席技术官 Laura Tacho 预计，2024 年最令人兴奋的 GenAI 升级之一是提取应用程序生命周期的书面历史：“当你有一个已有 n 年历史的应用程序时，你就会有 n 个拉请求、Jira 票据、Notion 或 Confluence 中的设计文档”。

她还表示，开发人员可以在所有这些东西上训练一个模型，当团队成员入职、开始一个新项目、调试某些东西时，也许出现了故障，AI 可以成为一种非常有效的方式，以更快的速度连接到他们需要的信息。

但是，与麦肯锡现在声名狼藉的生产力观点形成鲜明对比的是，Tacho 认为，一旦提高生产率，则其中大部分都在编码任务本身之外，因为编码并不是开发人员花费时间的100%。这意味着 AI 和开发人员生产力的交叉点在2024年将继续重叠。

裁员可能仍在继续，但大多数组织仍在寻找技术人才。缩短入职时间将继续成为生产力团队的目标，而人工智能将日益成为这一努力的重要工具。