写代码容易，交付软件产品依然很难

为什么更快的代码很少意味着更快的交付，以及应该管理什么

2026年10月4日 · 6分钟阅读

所有领导工程团队的人都面临同一个永恒的挑战：如何以更快的速度为客户交付更多价值？无论你是创始人、产品负责人还是工程负责人，这都是绕不开的问题。

在AI正在彻底改变软件构建方式的当下，这一挑战比以往任何时候都更加紧迫。然而，我们似乎正身处一个悖论之中。我们手头拥有令人难以置信的工具，它们能在几分钟内完成过去需要数天才能完成的任务——更快的编码、更快的原型设计，几乎一切都更快了。

即便在这样的背景下，速度上的提升往往并不能转化为价值交付上的同等提升，因为速度会带来意想不到的后果。它可能制造更多问题，导致质量下降；也可能造成方向不一致，让人们各自朝不同方向奔跑；还可能导致浅层决策，因为每个人都在忙着让智能体持续运转。

归根结底，每当流程发生改变，瓶颈就会转移。如果你不清楚瓶颈转移到了哪里，努力很可能就会付诸东流。

虽然这是一个AI出现之前的例子，但在过去的一个职位上，我曾带领一个只有10名工程师的小型初创团队。产品在其市场中是不断增长的领导者，团队也拥有极速交付的文化。

如果你当时在这个团队里，就会明显感觉到我们正在以某种方式付出代价。工程师们不断寻找更快完成工作的办法，往往在某个层面上走了捷径，哪怕并非有意为之。但公司领导层看不到这一点，因为从他们的角度来看，价值确实在被交付。

直到我有了机会把这一点说清楚。我们计划交付一个重大功能，公司希望4周内完成，从工程角度来看这是一个非常紧张的时间表。结果就造成了下图所示的情况。

我们统计了每周处理的缺陷和任务数量，可以清楚地看到，第1至4周的交付冲刺期（我们“成功”发布了该功能）导致了之后两周几乎全在修复缺陷。这种压力并没有带来更快的交付，反而带来了更差的客户体验。

这背后的理论很简单。交付一个功能的价值流不仅仅关乎交付代码。它始于理解需求、塑造解决方案、将其与其他方案一起排定优先级，然后通过设计和工程来执行，同时不引入任何意外变更，比如缺陷或对系统其他部分行为的改变。而每一步都为系统提供反馈回路，验证上一步。例如，用户研究访谈无需构建就能验证设计，代码审查无需部署就能验证正确性。

然而在实践中，要让这条价值流高效运转并不简单。不同的人会有不同的激励和观点。随着产品成长，其复杂性也随之增加，从而引入更大的问题暴露面。而一家真实的公司并不是一次只构建一个功能，而是同时构建许多功能，这意味着有多个想法和变更在并发推进。

像 AI 那样对所有这些环节施加更多速度，并不一定会让它更快，在许多情况下反而会使其更慢。而这正是许多团队所看到的。代码变更或原型以闪电般的速度产出，但最终结果——也就是客户通过使用新功能获得价值——却不尽如人意。

下一个显而易见的步骤是投入更多 AI（或 token）来解决这个问题。如果产品开发速度更快意味着原型更快，那就创建一个评估或 A/B 测试来决定哪个是最好的。如果更快的代码变更产生了更多 bug，那就让一个 agent 在它们产生时修复它们。问题在于这并不划算。每个 bug 修复都意味着代码的又一次变更，并带来引入更多问题的风险。总体而言，更多的变动和选项只会让系统更加复杂，而这种复杂性终将在某个时刻付出代价，即使那个时刻最终落在被产品中繁多选项和持续变化压得喘不过气的客户身上。

这才是更深层的问题：让系统的一部分变快可能会压垮其余部分，实际上抵消了反馈回路。这正是一些团队目前在代码审查中看到的情况。审查者收到的请求超出了他们能处理的数量，于是他们不看就批准了。审查在纸面上仍然进行，但它不再能发现任何问题。

前进的方向，尤其是在一切都在变化的时候，是端到端地理解价值流，并一次解决一个瓶颈。

这就是上面那个故事的结论。我把那张图表展示给 CEO，解释说要求更快的交付并没有给我们带来速度优势，因为我们随后要花时间修复之后出现的问题。除了速度之外，它还让客户体验更差，因为他们不得不应对这些问题，而这会影响真实的业务结果。那次对话之后，我们开始在每周的领导层同步会上定期查看同样的数据，以确保质量没有被牺牲。我们最终为团队建立了一个更可持续的流程，也为公司及其客户带来了更成功的结果。

如果你想这样做，应该从哪里开始？我认为有三条原则可以让你达到好得多的状态：

首先，以客户价值而非软件来定义你团队的成果。在实践中，这意味着根据业务结果来定义项目，使团队与公司保持一致。你还应该通过用户故事以客户价值来定义工作项，这样就能清楚地表明目标是成果，而不是拉取请求的数量。

其次，理解并管理你团队的端到端流程。一旦你有了成果，你就可以据此管理你的团队及其执行。实际的做法是，你应该关注每个变更/功能到达生产所需的时间，并据此进行调整。例如，如果规划比开发耗时更长，团队就应该专注于让规划更快，而不是运行更多的编码 agent。目标是缩短每个功能从想法到客户价值的周期时间，而不是让每个人在自己的角色内都忙个不停。

最后，要考虑团队生产力，而不是个人生产力。这与上文相关，但值得强调，因为激励机制常常会误导人们。如果一名工程师能同时运行 100 个 agent，却意味着为下游其他人制造了 100 倍的工作量、延长了交付周期，那就毫无意义。产品和设计决策也是如此。目标是让团队尽可能快地交付，而不是让每个人各自尽可能快。

如果你做到了以上几点，那么你就是在把团队当作一个系统来管理。一旦做到这一点，你就可以在系统内进行实验。也许跳过代码审查是合理的，也许不是。这取决于你的具体情况。但只要你心中装着结果，就能评估这一点并做出明智的决定。