代码写得更快了，文档几分钟就能生成，一些原本需要专业人员处理的任务，现在也能交给 AI 助手。
但把视角从个人拉到整个企业，一个问题就出现了：
为什么员工的效率提高了，企业交付产品、推动转型的速度，却未必同步提升？
不妨设想一个项目：开发人员用 AI 提前完成了功能，却发现需求还在等确认，验收标准尚未明确，出了问题由谁负责也没有说清楚。
开发环节省下了时间，项目仍然在等待。
这个假设场景，体现了英国埃克塞特大学数字经济教授、前 IBM 软件集团欧洲首席技术官 Alan Brown 讨论的一个问题：AI 带来了真实的能力提升，但组织未必具备将这些能力转化为成果的条件。
他在《Making AI Work：What Scrum Gets Right and Organizations Get Wrong》一文中，从 Scrum 的实践出发，讨论了这个问题。
AI 的质量，要在持续使用中检验
Scrum 是一种应对复杂产品开发的协作框架。它强调透明、检视和适应，也就是让工作和结果可见，通过实践检验判断，再根据反馈调整行动。
Alan 认为，这恰好也是 AI 驱动的开发所需要的。
因为 AI 系统具有概率性。同样的提示，在不同上下文、不同用户手中，可能产生不同结果。
因此，质量不能只看某一次输出是否达标，还需要持续评估系统在不同情境下的整体表现。
换成更容易理解的话：一次演示表现出色，不代表系统已经可靠。还需要了解，它通常表现如何，在哪些情况下容易出错，各类错误出现得有多频繁，又会产生什么影响。
对于 AI，持续检验和调整，是交付过程中的实际需要。
然而，Alan 指出，许多组织仍然在尚未真正理解技术能力之前，就确定固定范围、明确工期和成功指标，随后要求团队按计划交付。
他的概括很直接：工具是新的，错误却是老一套。
一次演示之外，还要检验不同情境下的表现。
有些问题，团队无法独自解决
如果 AI 需要不断试验，那么让团队多迭代几轮，是否就能解决问题？
Alan 提醒读者，即使团队把一轮 Sprint，也就是一段短周期的开发迭代，执行得很好，最终仍然可能达不到目标。
因为有些必要条件，只能由组织提供。
什么样的 AI 输出可以接受？ 企业需要明确标准，并能够解释判断的依据。
AI 参与决策时，责任如何安排？ 组织需要建立能够应对不确定性的治理机制。
为什么要做这个 AI 功能？ 产品战略需要区分真正服务用户的功能，以及仅仅因为技术可用才被加进产品的功能。
这些问题都会影响团队能交付什么，却很难靠团队内部调整任务来解决。
Alan 在与敏捷实践者交流时发现，团队往往能够在具体任务上尝试 AI 工具，但当他们想将 AI 真正融入产品时，就会遇到组织层面的阻力。
领导层没有明确目标，治理机制没有跟上新的能力和风险，团队却已经被要求加快速度。
他用一个形象的比喻描述这种处境：组织要求团队在一片尚无人绘制地图的地形上快速前进。
团队的工作方式，也需要更新
文章并没有把所有问题都归结为组织。
Alan 同时指出，Scrum 的基础仍然可靠，但具体实践也需要演进。
AI 正以不同方式进入产品交付：帮助团队整理会议，通过代码生成参与开发，以智能体的形式承担部分任务，或者直接成为产品本身。
这些情境，对团队提出的要求并不相同。
用 AI 整理会议，与向用户交付一个 AI 产品，需要回答的问题显然不同。
当输出质量具有概率性时，“完成”的标准是什么？当团队中包含 AI 智能体时，如何安排工作、促进协作？AI 又会怎样影响待办事项和资源管理？
这些问题，目前还没有成熟的统一答案。
Alan 的意思是，既然 Scrum 主张根据反馈调整，那么 Scrum 的实践本身，也应该接受检验。
组织承担自身的责任，团队持续改进工作方式，这两件事需要一起推进。
接下来，企业要改变什么？
Alan 提出了三个方向。
第一，成为有判断力的购买者。
企业需要更现实地理解自己希望从 AI 中获得什么，不能供应商提供什么，就被动接受什么。
先想清楚要解决的问题，才能判断哪些能力值得购买、哪些投入有必要。对自身需求和价值的判断，需要由企业自己完成。
第二，让产品负责人具备 AI 素养。
对 AI 功能作出价值判断，属于产品决策。
如果产品负责人无法评估其中的取舍，这些决定就可能落到不合适的人手中，并受到不合适的激励影响。
产品负责人需要理解 AI 的能力与局限，才能参与判断哪些功能值得做、哪些风险可以接受。
第三，把组织条件纳入复盘。
团队需要检视这一轮工作是否顺利，也需要追问：组织是否提供了负责任、有效地使用 AI 所需的条件？
Alan 认为，团队往往早已知道答案，只是很少有机会说出来。
如果复盘只讨论团队内部的问题，那些超出团队权限的障碍，就很难得到解决。
说明性假设：执行提速之后，项目还需要决策与协作。
从个人提效，到组织价值
个人完成任务更快，并不意味着企业就能更快创造价值。决策和协作能否跟上，同样影响最终成果。
回到开头的假设项目。AI 帮开发人员省下了时间，但如果需求、验收和责任安排没有跟上，项目仍然可能停在等待中。
因此，企业在关注员工是否熟练使用 AI 的同时，也需要检查：工作究竟停在哪个环节？哪些决定尚未作出？谁有权推动问题解决？
沿着 Alan 的分析进一步看，评估 AI 的应用价值，需要从单项任务延伸到整个交付过程。除了生成了多少代码、多少文档，更应关注这些产出是否帮助团队更快交付、帮助用户更好地解决问题。
这也意味着，试验、检验和调整的要求，需要同样应用于组织的管理方式。
当企业要求团队用 AI 加速时，也需要明确：为了让这份速度产生价值，组织应当作出哪些改变？
参考资料： Alan Brown 《Making AI Work：What Scrum Gets Right and Organizations Get Wrong》