本文来自微信公众号： 歪睿老哥 ，作者：歪睿老哥
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的那份报告说，两种方法各有优劣。
但迭代这种方法，有一个确定性路径永远追不上的优势：它跑出的结果，是更好适应真实世界的。
这玩意，放在写代码上是真理。放在创业上是真理。放在做产品上是真理。
甚至放在写文章上，也是真理。
我先打了一个草稿。草稿很差。
但没关系。迭代嘛。改一遍。再改一遍。再改一遍。
每次改，都是拿想法去撞现实。读者就是现实。
吹爆了的东西，炸了。这帮人很开心。
因为他们知道，炸了的这一次，比上一次更接近正确答案。
这就够了。