新的瓶颈
新的瓶颈
假设你的工程团队做对了一切：在AI编码工具的宇宙中导航，选择最适合的工具，让每个人都设置好并保持一致，目睹个人生产力飙升。工程师在更快地交付功能；演示令人印象深刻；领导层很高兴。
但也许，随着时间的推移，你意识到你的团队实际上并没有变快。也许冲刺速度大致相同，功能仍然在同样的地方卡住，回顾会浮现出同样的老抱怨。AI工具承诺的额外容量都去哪了？有什么东西在吸收它，但又很难确切指出是什么。
工具变了，工程师的工作方式变了，但围绕这些工作的流程（交接流程、准备完成和完成定义、循环参与、签核）却不一定随之演变。借助AI编码工具，企业是否升级了引擎却忘记关注道路？
当瓶颈转移时，你必须随之而动
著名的约束理论（Theory of Constraints）1是这样说的：每个系统都有一个约束，一旦你解决一个，另一个就会出现。改进约束并不能改善系统；它只会创造库存——工作堆积在下一个瓶颈面前。
这在制造业中很好理解，但在软件开发中应用得不够一致，我们往往将流程改进本身视为有价值的，而不是追问那些不愉快的问题：我们是否真的推动了进展？
当然，长期以来，代码生成是一个真实且合理的约束。编写好的软件需要时间。我们如此习惯的许多组织基础设施——敏捷、冲刺、故事点、速度跟踪——都是为了管理这一现实，提供可预测性和规划而设计的。
当然，AI显著缓解了那个瓶颈。如Intuit工程总监Eric Anderson在《代码领导者》近期一集节目2中所说，一行代码的增量成本现在“大约是我们在软件开发中所做的最便宜的事情。”
但大多数组织仍然在运行他们为管理旧约束而构建的流程。冲刺结构相同。交接模型、PRD模板、设计审查检查点——全部相同。当Anderson的团队最近进行季度规划时，他描述了一个逐渐醒悟的时刻：“我们说，不要那样做。让我们重新设想交付该路线图需要什么。”在审视团队的待办事项列表时，他意识到他们想得太小了。代码不会是困难的部分，那么时间到底会花在哪里？这是大多数工程组织还没有问的问题。
新瓶颈的真实面貌
新瓶颈不会自我宣告。它只是不断出现在同一个地方，一个冲刺接一个冲刺，并且被归咎于错误的原因。以下是它的样子。
构思与需求。 当代码便宜时，模糊或考虑不周的规格说明的成本就会上升。一个方向明确的AI代理会精准构建你所描述的内容。如果你描述的内容不够具体，你很快就会明白，而返工不会是AI的错。知道你到底想构建什么（以及为什么！）的纪律现在更加重要，而不是不那么重要。将发现和需求视为编码之前要打勾的框的组织，会在周期时间中感受到这种痛苦。
设计交接。 Eric提出了一个尖锐的问题：当UI迭代几乎不花成本时，“设计完成”到底意味着什么？传统的交接模式——在编写一行代码之前将完全完成的设计传给工程——在返工昂贵且耗时的情况下是有意义的，但这种权衡已经发生了转变。在许多情况下，等待完成的设计再开始构建只会增加延迟。
审查与判断。 更多的输出意味着更多的审查面。如果一位高级工程师现在要监督以前需要整个团队的工作，那么代码审查和架构监督就成为了瓶颈。这已经在广泛部署AI但没有改变审查、QA或技术签核工作方式的组织中可见。当产出翻倍但审查能力没有提升时，总得有所妥协。
跨职能协调。 这一点容易被忽视，因为它不会出现在工程指标中，但工程团队现在的速度往往远远超过产品、设计、法律和安全等部门的工作速度。这种不匹配会以已完成工作置于架子上等待签核流程的形式产生浪费，而这些流程从未设计为如此快速运行。当瓶颈位于团队外部时，它更难以发现和修复（但并非不可能——请继续阅读）。
为什么组织即使看到了也不修复
并不是工程领导不知道他们的流程过时了。很多人知道。但流程变革是困难的，其难度似乎比推出一个令人兴奋的新工具更令人生畏。
流程变革是跨职能的。你可以强制你的工程师采用新的编码工具，但你不能强制你的产品组织重写如何进行发现，或者让你的设计团队重新思考交接模型。这些对话需要跨不共享汇报线的职能的认同，并且需要具备足够组织地位的人同时推动所有方面。大多数工程领导可以推动他们自己的团队，但推动周围系统则是另一个问题。
旧流程感觉安全。敏捷本身是对瀑布模型失败的回应，但在许多组织中，敏捷已经僵化为其替代者的另一个版本。冲刺和仪式提供了舒适和可预测性，即使它们不再驱动速度。放弃熟悉的结构感觉有风险且不舒服，特别是当团队已经在吸收新工具带来的巨大变化时。
还没有人知道新流程是什么样子。这部分需要在关于AI和工程的对话中更坦诚。“我们不知道如何做好它，”Anderson解释说。“我们正在试验和学习。”当代码生成基本上免费时，没有既定的操作手册来运行一个软件团队。等待共识最佳实践出现再行动的组织假设这个领域会迅速收敛。但真的会吗？
重新调整的实际面貌
升级团队的工作方式不需要你一下子摧毁现有结构。相反，逐个功能、逐个检查点地审视你的流程，看看每个部分是否在解决一个仍然存在的问题。流程的某些部分会保持，但其他部分在你从另一个角度考虑时可能会看起来非常不同。
从一个问题开始，而不是一个框架。对于你当前流程的每个部分，问自己：这个设计是为了解决什么约束？这个约束还存在吗？两周的冲刺在计划成更小块以减少改变方向成本时是有意义的。现在还有意义吗？设计审查关口在工程时间成本更高时是有意义的。现在呢？当然，不是每个答案都是“否”，但在每个节点上问这个问题是值得的。
重新思考“准备好构建”意味着什么。传统的“就绪”定义——完整的规格、完成的设计、所有依赖已解决——是为了保护昂贵的工程时间而建立的。这已经不是我们生活的世界了。Anderson描述了Intuit正在转向一个模型，其中产品经理和工程师实时共同开发功能。