筆者按：我們曾經從教科書上、從專家的講座裡獲得的「系統工程」種種教誨，有很大部分可能已經失效了。那些東西是從上個世紀五、六十年代阿波羅登月計劃開始發展起來的，這套方法論創造了我們現在看到的波音、空客、登月、航母等巨型工程。然而，用埃隆馬斯克的話說：「現在是21世紀！」
文末有重大福利：《SpaceX內部講義之系統工程》
在最近SpaceX Falcon Heavy（獵鷹重型）成功發射後，我一直苦苦思考：一個成立初只有幾十個人，到2008年才500人，一直到現在有4000多人的民營公司，如何支撐起如此龐大的系統工程？要知道，無論是美國，還是中國，都有數十萬計的人在龐大的、由政府直接幹預的機構裡從事著這樣的事業。
查閱了一些文獻，我驚訝的發現：我們曾經從教科書上、從專家的講座裡獲得的「系統工程」種種教誨，有很大部分可能已經失效，或者需要我們重新審視。那些東西是從上個世紀五、六十年代阿波羅登月計劃開始發展起來的，這套方法論創造了我們現在看到的波音、空客、登月、航母等巨型工程。然而，用埃隆馬斯克的話說：「現在是21世紀！」
一、時代變了
如果讓你從頭開始研製波音747，你會翻開一本講述系統工程的經典教材，它會向你講述波音公司1960年如何啟動這個項目，以及1969年如何成功交付的。你會驚嘆在那樣一個年代，9年即可交付，這簡直就是一個奇蹟。在這種情緒的帶動下，你也許會照搬了書上說的那套波音公司的方法論。
然而，時代變了。現在距離1960年將近60年過去了！
SpaceX對系統工程的描述中，有一句提綱挈領的話值得深思：「A Traditional Discipline in a Non-traditional Organization」（新組織中的舊學科）。
馬斯克一直對團隊強調一個詞，叫「21th Century Infrastructure」（21世紀基礎設施）。有哪些？我們可以羅列一下：
新的溝通效率、新的資源獲取效率、新的協作關係、新工具、新工藝、新技術，等等。
由於複雜系統是永恆存在的，所以這些新的東西不會否定「系統工程」這門學科的存在。所以，SpaceX顛覆的不是系統工程，而是傳統系統工程中的諸多理念。
二、過度的「前期設計」
傳統的系統工程告訴我們，在前期設計中暴露儘可能多的風險，以降低錯誤成本。這種教誨讓我們現在很多大型項目在前期設計上大量地耗費時間和精力，以至於遲遲不去實踐。我們越來越信奉「一次成功」這樣的口號，這聽起來很節約成本，然而在時間和人力可以與資本兌換的時代，在試錯成本上，我們是否應該尋找新的平衡點？
↑考慮資金成本的傳統模型
↑SpaceX考慮綜合成本的新模型
SpaceX更強調每一次完整迭代之後產生的「經驗」，他們認為，基於更先進的工具和更優化的供應鏈協作關係，這種走完多次「設計、開發、測試」流程所需要的成本已經大大低於上個世紀；而每一次完整迭代之後產生的經驗，實際上是降低了項目的整體成本。
三、由需求層次驅動的迭代設計
「迭代設計」是我們經常提到的，在迭代設計中，我們強調快速將產品原型呈現給用戶，然後再做迭代，這種迭代的目的是為了優化產品的需求。為了能夠使用戶提出更多的建議，我們在每一次迭代中往往傾向於儘可能挖掘原型的需求縱深，以儘可能減少迭代次數。
而SpaceX認為：迭代的核心目的是為了獲取經驗，根據人類認知的規律，需求縱深的挖掘應該在迭代的過程中進行，也就是「由需求層次驅動迭代」。
筆者的理解是：剛開始更關註上層關鍵需求，對於下層的需求，可以先不關注，先採用既有的或者是成本較低的方案實現，等上層的關鍵需求都實現之後，再將下層需求的實現進行逐步迭代。我們看下面兩張圖就能明白了：
傳統的V模型
（筆者註：傳統V模型的左側，在前期就將需求從Level 2推演到Level 4，這就是我們通常說的「需求分析」）
SpaceX的V模型——第一輪迭代
我們發現，SpaceX的V模型中，第一輪迭代時沒有出現Level 3和Level 4層次的需求，但是十分強調Key Design Parameters（關鍵設計參數），也就是說，對於那些lower level requirements（即Level 3和Level 4的需求），等關鍵需求被滿足和驗證之後，再逐步迭代實現。
設計實例：
以發動機控制為例，在Level 2 Requirements階段是這樣的：
但是到了Lower Level Requirements階段時，變成了這樣：
四、實現低層次需求的能力
這是一個十分關鍵的概念，我想重點說一下。
SpaceX的原文描述是：ability to trade lower level requirements，所以有技術類文章把它翻譯成「交易低層次需求的能力」，並詮釋為：與用戶交易，勸說用戶那些不重要的需求就放棄吧；與轉包者交易，希望對方既快且經濟地交出產品。雖然這話說得沒錯，但這是基於錯誤理解的翻譯，我查閱了SpaceX很多文章，沒有發現SpaceX具有將這種lower level requirements向用戶進行交易的能力和行為。
筆者的理解是：一般總體單位只關注頂層需求（Level 2），對於低層次的Level 3和Level 4需求往往通過外協的方式進行分包；而SpaceX則不認同這一觀點，要知道，一支火箭70%乾重（硬體）的設備都是由SpaceX自己設計的。
我們從下面的兩張圖中可以發現：
↑傳統的總體單位分包模式（圖中A是Tier-1總體單位，其他字母表示Tier-2和Tier-3的供應商）
↑SpaceX的總體分包模式
顯而易見的是，SpaceX把我們認為該給供應商的幹的大部分活兒，自己都幹完了。當然，他只是自己設計。
五、「創新力」與「規範、過程」之間的矛盾
在一個龐大的系統工程中，管理者試圖通過嚴格的規範和過程管理來實現對項目的控制。很多項目團隊甚至大量引進位造型企業的一套過程管理方法。
SpaceX一直在尋求一種平衡，為了使團隊保有創新能力，他們一直嘗試著精簡組織架構、省略更多的規範、去除不必要的過程管理，SpaceX將系統工程的管理建立在每個員工的「責任心」基礎之上，這是SpaceX的核心理念，「想正確、高效地完成任務，任何現有的過程管理都無法取代責任心」。
這給管理提出一個新的要求，過去，我們從流水線上總結出「用制度替代人性「的管理要義；今天，在需要發揮每個人創新力的時代，我們是否應該反其道而行之，」用人性替代制度「？
實際上，上文提到的每一個點，都是值得深入研究的，我們不確定SpaceX是如何具體實踐這些理念的，但我們應該思考新的理念並且大膽實踐。
獲取《SpaceX內部講義之系統工程》，請關注下方公眾號後，點擊「發現福利」。
關注本公眾號
掌握「軟體定義」和軍工行業科技動態
還有更多驚喜哦