吹爆了的东西，炸了。这帮人很开心。

本文来自微信公众号： 歪睿老哥 ，作者：歪睿老哥

SpaceX的测试场上，火箭爆炸是常事。

炸了就炸了。

工程师们不沮丧，反而很高兴。

因为炸了意味着他们又发现了一个问题。

这听起来很反直觉。

谁会喜欢炸东西？

但Space X就这么干了。

这事儿的源头，其实是一条很不起眼的NASA报告。

报告里提到商业载人航天计划的两个参与者——SpaceX和波音在硬件开发哲学上完全不同。

波音走的是传统路子：先花大量时间做工程研究和分析，把设计彻底成熟化，然后再开始造硬件、做测试。

SpaceX不走这条路。他们快速迭代，建、测、学、改。不断修改，直到设计成熟。

NASA的原话说得还挺客气，两种方法各有优劣。

但这句话背后的意思，其实只有一个：SpaceX赢了。

为什么？因为他们走的是迭代这条路。

波音那套方法，叫线性方法。也有人叫瀑布流。

先定目标，然后一步步往下走：提需求、做设计、做子系统的资格测试，最后把结构、推进、航电这些大块头组装在一起。

在开始造硬件之前，要花费数年时间做工程。因为一旦开始建造，修改设计和需求会非常耗时且昂贵。

这条路，叫确定性路径。

你要先想清楚所有事情，再动手。

这叫量好再切。你想想看，这种思路是不是很普遍？

大部分公司、大部分项目、大部分人的工作方式，都是这样。

先做规划，再执行。先把需求搞清楚。先把PPT写好。

但问题在于，很多事情，你根本没法在开始之前就搞清楚。

尤其是那些站在创新边界上的事情。

我想过很久，过去一百年里最有影响力的技术，是怎么出来的。

不是大公司里几百号人花了十亿美金砸出来的。

基本都是小团队，一群爱捣鼓的人，靠迭代干出来的。

莱特兄弟就是最好的例子。

两个开自行车行的，造了一架飞机。飞不起来。

再造一架。还是飞不起来。

再造。再飞不起来。

再造。

直到最后，飞起来了。

这就是迭代。快速原型、测试、失败、适应。

早期所有的飞机制造商、国防公司，都是这么干出来的。马丁·玛丽埃塔、洛克希德、诺斯罗普·格鲁曼。

小团队，自学成才，靠迭代、失败和学习，造出了当时最复杂的机器。

你可能会想，人命关天的事情，怎么能"快速失败"？

SpaceX自己也回答了这个问题。

同一家公司，两个完全不同的部分。

测试场上那群人，追求运营卓越、零风险。因为上面有人命，还有很多很多钱。在那儿炸东西不是好主意。

但公司另一部分人，完全相反。他们认为，不在测试场上炸东西，说明你推的边界还不够。

关键是炸得多快。

这两拨人不是「这帮人是做创新的，那帮人只是打杂的」。

他们在互相学习。

造猛禽发动机和星舰的人，得知道GFC插头插哪儿、下火箭该用什么材料。

而正在跑现有火箭的人，能学到新材料和渐进式升级。

创新，但风险最小化。

这才是最妙的地方。

以上是我看到的一篇英文长文《Take the Iterative Path》

作者是Max Olson，写了一个叫FutureBlind的博客。

讲的就是SpaceX和波音在硬件开发上的两种哲学。

他提到了一个很有意思的东西。

叫OODA循环。

OODA循环是军事家约翰·博伊德提出的。四个词：观察、判断、决策、行动。

看到发生了什么。根据环境调整自己的认知。

决定下一步做什么。

行动。然后回到观察，看行动的结果。

闭环。

快速闭环。

博伊德说，赢的关键是敏捷——应对外部世界变化而快速改变自己认知框架的能力。

这话原本是讲空战的。

但放到商业和工程里，也一样对。

tight feedback loops，紧密的反馈回路，带来高频率的创新和适应。

Elon Musk说过一句话，我特别喜欢。

他说："重要的是每年有多少创新。不是脱离时间的创新。

你的创新率是多少，这才是重要的。"

注意，他说的是「创新率」，不是「创新总量」。

你一年能迭代多少回，比你憋一个大招重要得多。

SpaceX是怎么做到硬件迭代的？

硬件不像软件，你不能按Ctrl+S就撤回。你炸了就是炸了。

但他们想了几个办法。

第一个，备件管够。

有充足的备件和备份，你就能反复尝试。出了新问题？造新的。反正有材料。

他们大量用3D打印。需要新零件？自己打一个。不用等供应链。

第二个，模拟。

能算出来的就不用真做。用CAD和仿真软件，把整机做出来跑模拟。如果模拟里就炸了，那太好了。在电脑里炸，比在现场炸便宜多了。

SpaceX在这块投入巨大。他们不只是用CATIA做零件设计，还做了端到端的3D建模系统。整机装配都可以模拟。而且软件要快——工程师不能等。

第三个，探路者。

制造业里有个概念叫pathfinder。造一个早期的版本，你知道它会失败或者不够好。但你造它，是为了看问题出在哪儿、怎么做得更好。

就像开枪时先打一颗试射弹。不指望命中，看弹着点，然后调整瞄准。

我读到这儿，脑子里突然冒出一个画面。

从前写代码的时候，也喜欢先画架构图。画三天。画五张图。画完觉得思路清楚了。

然后开始写。写了两天。发现架构有问题。

删掉重画。

又写了两天。又发现有问题。

再删。

很多人会觉得这个过程浪费时间。明明可以直接上手写的。

但我觉得，这不是浪费时间。这是在迭代。

只不过迭代的不是实物，是脑子里的模型。

SpaceX在电脑里炸火箭，程序员在脑子里炸代码。本质上是一样的。

但迭代这条路，不是说你"想迭代"就能迭代的。

有一个前提：你足够灵活，失败的成本够低。

这就是为什么迭代在软件行业如此普遍。改一行代码的成本几乎为零。

但在硬件领域——在造飞机、造火箭、造汽车的领域——迭代一直被认为是"不靠谱"的。

SpaceX证明，这不是不可能的。

他们把失败的成本降到了足够低。用备件、用模拟、用探路者。

把「物理定律」能接受的最小代价，压缩到了极限。

还有一个细节，我觉得很有意思。

Max Olson在文章里引用了F-117隐身战斗机项目的一段故事。

项目后来由Ben Rich领导。他们建一架梯子让工程师爬进座舱。

梯子是哪儿来的？

当地建材市场。

50块钱。

不需要按军事规格设计梯子。不需要花几千块钱专门定制。

直接用。

这听起来很粗糙。但恰恰是这种粗糙，让复杂创新能够跑起来。

你想想，一架人类历史上最神秘的战斗机，工程师坐的梯子是从Home Depot买的。

我其实一直在想，迭代的本质是什么。

后来我想明白了。

迭代，是拿你的想法去撞现实。

确定性路径，是你在脑子里把现实模拟出来。然后按你的模拟去执行。

但你的模拟，和现实之间，永远有差距。

迭代的好处，就是尽快让这种差距暴露出来。

越快暴露，越快修正。越快修正，最终结果越接近现实。

确定性路径的问题也在这儿。你以为你把现实想清楚了，但其实你只是把你的偏见想清楚了。

NASA的那份报告说，两种方法各有优劣。

但迭代这种方法，有一个确定性路径永远追不上的优势：它跑出的结果，是更好适应真实世界的。

这玩意，放在写代码上是真理。放在创业上是真理。放在做产品上是真理。

甚至放在写文章上，也是真理。

我先打了一个草稿。草稿很差。

但没关系。迭代嘛。改一遍。再改一遍。再改一遍。

每次改，都是拿想法去撞现实。读者就是现实。

吹爆了的东西，炸了。这帮人很开心。

因为他们知道，炸了的这一次，比上一次更接近正确答案。

这就够了。