在大多数企业里，提升生产力的剧本总是惊人地相似：购买更贵的工具、聘请更贵的顾问、进行更复杂的重组，以及现在的——引入 AI。然而，尽管投入巨大，摩擦依然存在：优先级模糊、会议泛滥、信息孤岛、工具割裂。
Atlassian 的专家指出，当我们还在为这些问题头疼时，软件工程团队其实已经找到了一把钥匙：DevEx（开发者体验）。
许多人误以为 DevEx 就是给程序员提供零食、游戏室和弹性工时。错了。
DevEx 的本质是消除摩擦。它的诞生不是为了讨好工程师，而是为了解决工程限制。它的核心目标是：降低认知负荷，让高价值工作顺畅流动。
如果把这套逻辑剥离开来，你会发现 DevEx 解决的是所有知识工作者的通用痛点：
目的流 (Purpose Flow)：知道为什么要做这件事。
工作流(Work Flow)：从想法到完成，中间没有无意义的阻碍。
知识流 (Knowledge Flow)：不需要求人就能找到需要的信息。
智能流 (Intelligence Flow)：用 AI 处理低价值任务。
软件团队之所以高效，是因为他们建立了一套支持上述“流”的仪式和系统：
文档化：他们痛恨口口相传，崇尚文档和代码注释（知识流）。
透明化：所有人都能在 Jira/看板上看到任务状态，减少了“对了，那件事怎么样了”的低效会议（工作流）。
自动化：CI/CD 流水线自动处理集成和部署，而不是靠人肉上传（智能流）。
反观市场、HR 或财务团队，往往缺乏这种“默认公开、默认自动化”的系统，导致大量时间浪费在协调和信息搬运上。
作为领导者，你不需要让财务人员学写代码，但你可以让企业学习软件团队的“设计思维”。
1、告别“偶然的复杂性”
很多企业的流程是“长”出来的，而不是“设计”出来的。安全部门加一道审批，合规部门加一个检查，最后变成了一个没人想要但谁也动不了的庞大系统。
行动：像设计产品一样设计你的工作系统。主动审查流程，砍掉那些为了“以防万一”而设立的低价值卡点。
2、把 AI 当作队友，而不是工具
不要只是把 AI 作为一个聊天机器人挂在旁边。像软件团队把 AI 嵌入代码编辑器一样，把 AI 嵌入到业务流程的核心，让它自动处理报销分类、简历筛选或合同比对。
生产力从来不是一个“人”的问题，而是一个“系统”的问题。获胜的组织不是拥有最勤奋员工的组织，而是拥有设计得最好的工作系统的组织。
DevEx 是这套系统的蓝图。现在，是时候把它交给全公司的每一位知识工作者了。
每个人都在购买生产力工具，但工作依然艰难——DevEx 证明了设计“工作方式”比单纯“努力工作”更重要。
领导者们正大量投入资金帮助团队提升生产力。然而，很少有人能解释到底是什么在拖慢他们的脚步。
对提升企业生产力的追求通常包括购买生产力工具、更新运营模式、聘请顾问，当然还有人工智能。尽管投入巨大，问题依然未解，从董事会会议室到茶水间，这种无力感无处不在。
与此同时，组织中的一部分人已经学会了如何更快地交付更高质量的工作。软件团队是世界上最高效的团队之一。这并非因为他们更聪明或技术更强，而是因为他们学会了设计工作发生的方式，而不仅仅是工作本身。
开发者体验 (DevEx)为企业如何更清晰地运作并更快交付高质量结果提供了一份蓝图。
在大多数组织中，你会发现相同的模式反复出现：
团队对优先级缺乏清晰认知，导致精力浪费在错误的事情上。
工作通过会议来协调，使进展缓慢且繁琐。
信息被锁在邮件、个人大脑或私人频道中。
工具之间缺乏集成，只能靠人工在多个地方翻译和重建信息。
领导者缺乏数据来做出明智决策。
这些都是组织工作系统中内嵌的摩擦现象；它们是员工体验问题。
这些挑战无处不在，但软件团队通过重新设计工作体验（而不仅仅是流程）来应对这些挑战。DevEx 的出现正是为了应对软件开发者面临的摩擦积累。其目标是减少不必要的摩擦，使开发者能够以更低的认知负担轻松完成高质量的工作。
DevEx 并非诞生于工程文化；它诞生于工程限制。同样的原则适用于每一个团队。
DevEx 常被误解为讨好开发者，给他们乒乓球桌和披萨来诱惑他们更努力工作。事实并非如此。
当你剥离表象，DevEx 解决的是拖慢每一位知识工作者的普遍问题：
2.1 目的与背景 (Purpose & context)：开发者若不了解什么重要、为什么重要以及成功是什么样子，就无法有效构建软件。这是良好开发者体验的输入要素。市场营销、人力资源和财务团队都面临同样的模糊性问题。
2.2 工作可见性与协调 (Work visibility and coordination)：软件团队创建了工作的共享可见性，因此工作能在更少的交接和实时互动中取得进展。它减少了来回拉锯、会议、不必要的依赖和等待时间。这些问题对业务型团队来说更为严重，因为他们没有像工程团队那样的共享工具。
2.3 知识的可获得性与获取 (Knowledge availability and access)：软件团队在文档、决策日志和信息自助服务方面投入巨大。这对速度、团队学习和创新至关重要；没有这些，团队就会淹没在信息债务中。这是大多数组织中最大的绩效杀手之一。
当你观察专注于 DevEx 如何帮助软件团队时，结论显而易见：DevEx 是企业绩效的蓝图。软件团队只是先行一步采用了它。
专注于改进 DevEx 之所以有效，是因为它优化了交付工作的团队的工作方式。四个“流”决定了任何组织的绩效表现：
3.1 目的流 (Purpose flow)：团队知道什么重要、为什么重要，以及他们的工作如何与结果相关联。
3.2 工作流(Work flow)：团队在将工作从构思推向完成的过程中，经历的摩擦最小化。
3.3 知识流 (Knowledge flow)：团队可以在需要的时间获取所需信息，无需向他人索取。
3.4 智能流 (Intelligence flow)：利用 AI 减少低价值任务和摩擦。
“工程团队拥有一套明确的‘仪式’和系统机制来支撑这些工作流，而大多数业务团队却不具备。颇具讽刺意味的是，这种工作方式上的‘错位’，恰恰是技术与业务团队在协作交汇时产生摩擦的根源之一。”
在 Atlassian，我们每天都能看到这些仪式和系统的益处。当团队默认拥有共享的上下文和开放的知识时，协调开销就会降低。决策更快，质量提升，团队不再依赖会议来保持一致。这并非工程领域独有；这是一种普遍的高绩效模式。
在我合作过的所有公司中，从银行到科技公司，再到现在的赛车行业，有一个共同的事实依然存在：当工作系统自然生长时，摩擦也会随之增加。
多年前我在一家大型银行工作时第一次清楚地看到这一点。我当时负责重新设计工作系统，目标是提升软件交付的速度和质量。
软件团队的工作理论上很简单：把一个想法转化为代码，并安全地将代码部署到生产环境。但软件团队并非孤立运作。他们必须应对由负责网络安全、金融犯罪、风险、变革管理和架构的治理团队提供的需求，每个团队都在试图优化其合理的预期结果。
随着时间的推移，新法规和要求不断引入，每个治理团队都在交付路径中增加了自己的检查点和审查。单独来看，每个要求都非常合理。但合在一起，它们创造了一个没有人会有意设计的工作系统。每个团队都在为自己的结果优化，而不是为整个系统的结果优化。
结果，优先级变得模糊，工作进展如蜗牛般缓慢，每个人花在会议上协调流程的时间比实际交付工作的时间还多。
这不是人的问题，而是善意规则的堆积让大家的工作变得更难。这是一个系统问题。
在重新设计过程中，我们从“偶然的复杂性”转向了“有意设计的流程”。我们将软件团队的体验置于优先位置，并制定了一套关于工作应如何进行的清晰原则。治理并未消失；我们有意地整合了它，创造了透明度，而不是被动地层层叠加需求。
当我们把工作系统当作需要设计而非继承的东西时，一切都开始加速。团队有了更高的清晰度，交接减少了，团队终于有了空间专注于重要的事情。为了保持系统良好运作，我们不断审查工作系统，寻找改善成果的机会。
这段经历塑造了我今天看待企业生产力的方式。
从那时起，我与竞相发布内容的市场团队、打造员工体验的人力资源团队、规划周期的财务团队以及处理复杂交付的运营团队合作过。每个团队都想加快节奏。每种类型的团队都会遇到同样的系统性障碍。问题从来不是人，而是工作方式的设计。
持续表现优异的团队不需要对抗系统；他们依赖于有意设计的工作系统。
改善工作系统并不总是需要一个正式规划的转型项目。小规模的干预可能对组织绩效的四个流产生巨大的影响。
以下是四个简明扼要的行动，帮助你开始改善工作系统：
了解你当前的工作系统：向团队询问如何改进工作方式。没有人比那些正在努力工作的人更了解什么在阻碍工作。了解今天的工作流，以便明天改进它。
减轻认知负荷：简化并连接工具和流程。大多数企业组织中的团队都在应对不必要的步骤、上下文切换和决策税。
解锁知识：从以会议和邮件驱动，转变为建立共享和自助知识的文化。能够在需要时获取所需信息，无需向他人索取，是高绩效的基础。
把 AI 当作队友：AI 创造额外能力并减少手工劳动。把它嵌入你的工作系统，而不是事后才想起的附加品。
DevEx 向我们展示了当我们有意设计工作体验时的可能性。下一个前沿是将这些原则应用于整个企业。
生产力不是运营模式的问题，而是系统问题。DevEx 给了我们解决这个问题的蓝图。获胜的组织不会是那些拥有最勤奋员工的组织，而是那些设计工作最出色的组织。
作者：Andrew Boyagio（安德鲁·博亚吉）
译者：木青 编审：@lex
原文链接：https://www.cio.com/article/4122240/developer-experience-is-a-blueprint-for-enterprise-productivity.html
