开发速度不是瓶颈

原文：Development Speed Is Not a Bottleneck

作者：Pawel Brodzinski

关于“Vibe Coding（凭感觉编程）”的讨论，很大一部分都围绕着开发速度，但实际上，开发速度从来都不是产品成功的关键制约因素。

“Pawel，你错了。就算没有任何技术背景，你也可以‘凭感觉编程’，打造出一款成功的产品。我这儿就有一个例子。”

我很喜欢这个挑战，尤其是它还引述了一个信源。我本以为简短回复一下就行，没想到最后写成了一个系列文章。

这篇文章是本系列的最后一篇（至少在写这篇文章时我是这么想的），我将聚焦于产品管理层面，或者说，只谈其中的一个方面。

很多人认为，交付功能（或笼统地说，“开发”）的速度是产品发展的瓶颈。这其实是一种误解。

说到底，这正是“凭感觉编程”(vibe coding) 工具所承诺的：我们能帮你把它做出来，根本不需要任何工程师团队。实际上，最初那个挑战的措辞也是这个意思：

“我正在和一些人合作，也见过其他人，他们只用 AI 就创建了实实在在的科技业务，并将其规模扩大到百万美元以上，而这期间，他们一个软件工程师都没雇佣。”

那么，让我们来好好剖析一下。

原型 vs. 产品

如果只是做产品原型 (prototyping)，我非常赞成“凭感觉编程”。它是一个绝佳的工具，能帮助我们验证脑海中的想法是否真的受人欢迎。但关于原型，你首先要明白一点：它们是一次性的。

即使我们验证成功，证明想法行得通（这种情况大概十次里才会发生一次），这个原型也依然是一次性的。

制作原型的核心思路，就是用质量换取快速、廉价的结果。原型可以出故障，可以有 bug，甚至可以很丑。重点在于：它能把你的想法传达到位。

相反，一款真正的产品，必须能够长期、可持续地交付它所承诺的价值。糟糕的用户体验？我会换个替代品。Bug 太烦人？我会彻底弃用。产品完全崩溃了？我凭什么要用它，更别说为它付钱了。

质量必须过关。否则，顾客来得快，去得也快，这不是一个可持续的产品策略。当然，我们仍然希望快速、低成本地开发产品，但在某种程度上，质量是没得商量的。归根结底，我们需要这东西能长期稳定运行。

成功产品之路

大多数成功的数字产品是如何诞生的？你可以随便想一个例子，试着反向推导它的发展路径。你能看到一条清晰的路线，从一个里程碑走向另一个，每一步都是前面所有步骤的必然结果吗？

比如亚马逊，它洞察到在线图书销售是互联网时代的爆点，然后，就顺理成章地进军音乐、视频和其他行业，同时在非美国市场推出服务？

接着，引入第三方卖家一定是合乎逻辑的下一步，对吧？然后是建立全球最大的云基础设施、自家的电子阅读器和视频流媒体业务……好吧，说到这里，我们都知道自己是在强行给这些点连线了。

亚马逊尝试了无数事情，才最终找到了今天这些核心的“现金牛”业务。见鬼，即使是对于他们的根基业务——在线市场，众所周知，他们也一直在同时进行着数千个实验。事实上，他们整个开发文化就是围绕着快速实验来设计的。

换句话说，我们永远无法预先知道什么东西在产品中会起作用。我们不断尝试，看看什么有效，就坚持下去，什么无效，就果断放弃。

Gmail 的案例

Paul Buchheit 因在短短几小时内创建了 Gmail 的第一个原型而闻名。后来他又用同样的方法做出了 AdSense。而这一切都发生在那个所有代码都得一个字一个字手敲的年代。

没错，我们谈论的是谷歌两款重量级产品。然而，如果你仔细阅读背后的故事，就会发现这根本不是按部就班执行计划的结果。

“在 Gmail 发布前的 2.5 年开发过程中，我们犯了很多错误。”

“到发布时，我们重写了大约六次前端和三次后端。”

“我当时就是写代码、发布功能，然后观察反响。通常，最终每个人（包括我自己）都会讨厌我们做出来的东西（尤其是我的点子），但我们总能从经验中学到些什么，并迅速转向其他想法。”

Paul Buchheit

换句话说，他们探索了无数的死胡同，验证它们行不通，然后继续前进。你不可能预先知道答案。

这个道理，对产品功能适用，对整个产品也适用

同样的模式不仅适用于产品功能，也适用于整个产品。我们可以继续用谷歌作为例子。它以整理全球信息的使命而闻名，旗下拥有搜索、Gmail、Google Workspace 等众多产品。

除了搜索业务，其中许多产品都源于实验。上面提到的 Gmail 和 AdSense 就是两个显著的例子。

然而，每一个经受住时间考验的产品创意背后，都有十几个失败的创意。而每一个失败的创意背后，可能还有十倍数量甚至从未公开发布过的点子。

我个人曾经非常喜欢并使用 Google Reader、Google Talk 和 Picasa，它们每一个的关闭都让我心碎。还有一些产品，虽然我一直是活跃用户直到它们悲惨地终结，但我并没有为之流泪。

可能每个人都还记得谷歌那些最惨痛的失败：Buzz、Google+ 和 Google Wave。

到 2024 年底，谷歌墓地里躺着的产品名单已经有近 300 个了。这可不是一份满是“本垒打”的成绩单，对吧？而这还是一家从初创公司角度看，拥有无限能力的公司。

凭借谷歌拥有的所有工程力量，任何这些产品的开发速度都可以被设定得任意高。虽然没有官方信息，但有传言称，仅 Google+ 一个项目，谷歌就投入了数百名工程师。

如果开发速度就是一切，那么在任何细分市场，赢得产品竞赛的永远都将是行业巨头。毕竟，他们可以利用现有的收入来源、客户基础等资源，投入他们想要的任何工程火力。

但我们都知道，事情并非如此。

真正的瓶颈是“验证”

产品开发的本质，是持续的探索。首先，我们旨在验证 (validate) 我们的想法，然后转向验证每一个改动是否让我们更接近目标——无论是增长、收入、留存还是其他什么。

问题在于，验证需要时间。Leah Tharin 分享了她在拥有数千万用户的产品上工作的故事，她是这样说的：

*“尽管我们有巨大的流量，但团队的瓶颈在于为我们的大多数实验等待统计显著性 (statistical significance)。 (...) 如果我们修改主网站或最主要工具上的文案，实验结果在几小时内就能达到统计显著性。但如果是一个更复杂的、针对高价值客户的漏斗下游改动呢？**那就要等几周，有时甚至几个月。*唉。”

Leah Tharin

几周，有时甚至几个月。这还只是为了知道一个改动是好是坏，还是根本没效果。

让我们来做一个思想实验：假设他们能将开发的成本和时间缩减 10 倍。他们会增长得更快吗？除了那些登陆页面上最简单的微调，他们仍然需要等待才能知道结果。

而且，他们也不可能把实验的数量增加十倍。当然，技术上是可行的。但这会让数据指标乱成一锅粥。

“所以，我们同时运行了这 27 个旨在提高留存率的实验，数据显示留存率好了一周，然后又回到了原来的水平。这到底说明了这些实验的什么问题？”

如果你关注真正重要的东西（增长、收入、留存），就会发现，知道“该做什么”才是最常见的瓶颈。而我们无法一开始就可靠地知道什么会奏效。

另一个瓶颈是“沟通”

但如果我们确实明确知道要做什么呢？毕竟，这是项目工作的基本模式。我们定义范围，谈好报酬，然后开干！

在这种情况下，我们可以很方便地忽略一个事实：我们可能正在开发一个完全错误的东西。或者，运气好的话，我们遇到的是少数几种情况：要么是做一个直接的替代项目，要么是自动化现有的业务，这时我们对想法的可取性、可行性和技术实现性会有更好的初步理解。

即便如此，决定这类项目成败的，也不是开发速度。

在 Lunar Logic，当我们为从未合作过的客户估算工作量时，我们总是给出一个很宽的范围。这个范围还不如我们希望的那么宽，因为说实话，我们最想说的是“这可能用不了 1 个月，也可能超过 1 个季度。”即便如此，这个范围对许多潜在客户来说还是宽得令人不舒服。

而这还是在技术不确定性有限的工作中。

为什么我们的估算会如此离谱？我们不能就用我们常吹嘘的 20 年经验，直截了当地告诉客户要花多少钱吗？不，我们不能。我们还不知道合作会是什么样子，而单单这一个因素对实际成本的影响，就比任何与项目范围直接相关的事情都要大。

糟糕的沟通会产生返工 (rework)。沟通质量的低劣，导致工作量增加多达 100% 的情况并不少见。

这还不算开发那些完全不必要的功能所带来的浪费。如果你回过头来看这样一个项目，真正能增加价值的工作可能只占总工作量的百分之几。

而加快开发速度只会加剧这个问题。*返工的成本不是线性累积的。*一旦你开始对返工的部分再进行返工，它就像复利一样，只不过是反向的。你自己算算这会对成本造成什么影响吧。

编码速度从来都不是瓶颈

丹尼尔·卡尼曼 (Daniel Kahneman) 在其开创性著作《思考，快与慢》中解释了许多精辟的观察，其中之一如下：

“这就是直觉启发法的本质：当面对一个困难的问题时，我们通常会转而回答一个更简单的问题，而且往往没有注意到这种替换。”

丹尼尔·卡尼曼

我们下意识地回避解决难题，方法是找一个相似但更容易解决的问题来代替。然后，我们假装后者的答案就是前者的答案。

我们用同样的方式来回答关于成功产品开发的问题。我们对于什么能让产品成功知之甚少。然而，我们清楚地看到，开发工作是耗费精力最大的部分。将一个想法变成一个产品需要大量的时间和金钱。

所以我们专注于开发速度。突然之间，我们有了一个简单的答案。我们可以让它更快。怎么做？很简单。用 AI。

很抱歉要打破你的幻想。**代码不等于产品。由此推论，更多的代码也不等于更好的产品。**通常，情况恰恰相反。

编码速度从来都不是瓶颈。即使在我们没有 AI 这个捷径的时候，也不是。

“凭感觉编程”与产品开发

如果我们回到产品开发的语境中，“凭感觉编程”向我们承诺两件事：

  • 我们会很快得到代码。

  • 我们不需要雇佣昂贵的技术专家。

这两点都忽略了“编码速度从来都不是瓶颈”这一事实。它们都在回答那个简单的问题，而不是那个困难的问题。

更糟糕的是，我们为了让自己远离对代码的理解而付出的代价，是更多的返工。是的，我知道，我们也可以把返工外包给 AI 智能体 (AI Agent)，但我们仍然需要去驱动它。然后所有这些返工都会堆积起来。还记得那个反向复利吗？

说到底，把“凭感觉编程”作为打造成功产品的主要策略，就像是解决了一个小问题，却让真正的主要问题变得更加棘手。

原文链接：https://pawelbrodzinski.substack.com/p/development-speed-is-not-a-bottleneck

See all posts