最近要多帶一個架構團隊做一個新版本，我寫一些基本邏輯來給團隊建第一層策略建模，以便我們后面的討論有基礎，由于這種問題是普適的，也不會涉及什么具體的保密問題，所以我公開來寫。

架構是一個充滿了自由度的工作，是一個最不適合用過去的成功指導下一波策略設計的領域，無論你過去的領域和這個領域有多相像，你過去的成功經驗都只能拿來參考，不適合用來拷貝。

因為即使是完全相同的領域，時間已經不同了，行業生態，技術發展已經不同了，你面對的人不同了，業務的瓶頸已經不同了，生態的各個利益體的投資已經不同了，成熟的領域人員可能減少，當初的績優股可能已經失敗，你面對的是一個新的領域，我們做架構，永遠不能被過去的“定義”，左右了我們的判斷。所以，做新的架構設計，你可以參考過去的成功pattern，但你的分析，必須建立在現在的條件上，不能離開對現在問題的調查，直接打算使用過去的模式。

這是我對我們進行產品戰略設計的第一個建議。

架構設計是一個非常微妙的設計領域，它是完全建立在形而上的邏輯上的，它是抽象的，非具象的。但這種抽象必須要以可以實施為底線，否則就淪為紙上談兵了。所謂高以下為基，貴以賤為本。所以，我們不要出現“架構上我們應該如何如何，但我們現在人力不足啊”這樣的思維角度，這是廢話，架構就是建立在準備實施這個角度上的，你不能把架構設計和實施隔離，說一堆“我們要如何如何，只是某某條件不成熟?！边@樣的鬼話，如果某某條件不成熟，你就不該做出這個設計來浪費我們的時間。

架構設計是實施團隊的一部分，沒有獨立于實施的架構設計。架構設計90%的工作是輔助實施團隊實施架構戰略和挑戰架構戰略，不是實施之外的獨立設計。把人分離出來是為了保證投入，不是為了讓這個團隊成為實施團隊的競爭者。

但反過來說，你不能說我們現在只有多少多少人，我們就做一個基于現在有多少人的方案，因為事情是變化的，在架構設計初期，給你很多的人，你也用不了，人力多了是個累贅，看在財報上每個月花出去的錢就讓人害怕，但如果你的設計只是現在有多少人，那后面開始展開了，你根本就發展不了。沒有準備，未來有可能給你補人你也接收不了。如果人力不是這樣從小到多的一個變化過程，我們也不需要架構設計，架構設計必須可以響應這種人力，資源，市場等各方面的變化。

所以，我們從一開始就做好了做這種多步的策略的打算，考慮整體目標的時候，要用整個市場域的機會作為我們發展的上限，在實施的時候，要考慮好怎么一步步增強投資者和市場的信心，從而可以有序擴大整個業務，不要用“我的架構沒有錯，錯的是市場，錯的是人力資源沒給夠人，錯的是……”來給自己做理由。架構設計包括對這些“別人的錯”的預判。架構設計和實施是和整個產品的所有其他力量（開發，銷售，維護，財務，法務等等）融合在一起的，沒有獨立于這些開發力量的架構設計。

這是第二個建議。

但對于這個建議，我有個直接的工作技巧可以分享。當我們確切落筆寫一個架構設計的時候，要考慮：以客戶為目標，以工程為準繩。

什么意思呢？就是說，你在架構設計的第一個部分，要明確說你打算賣一個什么樣的東西到市場上去，你的客戶打算買你的東西，這個決定的控制要素是什么？有這樣一個標準在最前面，我們中間的所有變化，遇到的障礙，我們都知道往哪里繞。也知道我們繞完了，應該繼續向什么方向走。

而在你的架構設計的最后一段，你要把你的所有設計落實為“版本”和“項目”。所有的人力管理，都是以項目為基礎的，因為項目有確切的目標和人力資源投入，而不是“小李你去幫幫他們”這種盡力而為的東西，架構策略一旦展開，所有人都會面對無限的要求，沒有確切的資源分割，凡是長遠的東西都會被忽略和放棄。所以，要把架構策略得以實施的希望建立在人力資源管理上，不要建立在“期望”，“正義”，“道德”，“道理”這些依賴上。所謂子非不辨也，老子忙起來誰都不認也。

當然，我這里說的項目，是廣義的項目，不一定是你流程中說的那個項目。

而項目，要輸出確切的版本，你有硬件，有軟件，有插件，這些都是有版本的，不要說什么做一個my-wonderful-app，里面支持這特性，那特性的。

你的軟件上了市場，遇到一堆的客戶，這些客戶的要求都會不一樣，你是用一個版本還是用多個版本去響應他們？產品是會有Bug的，是要有新特性開發的，修復Bug和增加新特性是會引入新的Bug的，所以，客戶可能可以接納升級你修復他的Bug的版本，可不一定肯接納你發布的修復其他人問題的版本的。

這樣，你在市場上就會有很多版本，這是天然的，版本一多，開發，測試，維護，管理的成本會大幅上升，這是一個重要的工程控制要素。你用my-wonderful-app這一個概念來考慮你的設計，你實施的時候就會怎么搞怎么不正常，因為你以為你開發的是my-wonderful-app，其實你開發的是my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition……你對人力和項目的預判都是錯誤的，當然執行不下去了。

所以，很多人其實不明白“開源交付”是個什么東西，開源交付其實是一種減少版本的方法，一個源代碼樹是可以編譯出很多二進制版本的，我給你源代碼，編譯產生多個版本的的維護成本就是你的了，很多人以為交付源代碼是對用戶友好，是為行業做貢獻——那得看客戶是想當你的競爭對手，還是想解決他的問題了。（但即使你用“源代碼交付”，如果是商業交付，你的測試還是需要落實到一組二進制版本上的，而且你必須很清楚，這些二進制版本都是會升級的，死版本支持的生態是死的生態）

但無論如何，架構設計一個基本的要求，高以下為基，不要離開你的工程成本想得天花亂墜，只要涉及工程，什么美好想法都得給我從天上掉下來。

第三個建議：調查和設計也是要結合起來的。架構設計初期，我們有無數的“未知”：競爭對手的戰略是什么？客戶的期望是什么？研究機構有什么新的突破？市場份額的預測是什么？國家政策的走向是什么？……

如果你要調查完這些東西才做決定，你就永遠都不用做了。所以，進行架構設計，要勇敢進行“猜”，“預判”，哪怕錯了，你也要“猜”，因為這是架構設計工作的基礎。你的決策要同時決策：使用猜這個結論和再調查一下，哪個投資收益比更低？然后就要去實施。我在這個專欄中經常強調“守弱”，其本質就是這個：架構本身就是一種猜，我們在猜的基礎上執行，如果你非要維護面子，在執行的時候收到當時猜錯了的反饋，你死要面子不肯調整，那這個架構執行就失敗了。

所以，做架構不能要面子，你眼中只能有產品的最后成功，到成功的時候，你坐在那里，旁邊的人說什么，你都可以冷冷看著他，由他講他的道理，你根本不用在乎。

這樣就要提到第四個建議了：你不要指望實施團隊會很喜歡你，你做的所有事情，都是為了未來讓他們“繞路”走，你的結論他們不會喜歡的。你可以用你所有的個人魅力去盡量soften這種沖突，你可以下去和他們一起分擔開發調試的壓力，讓他們沒有那么恨你，但你要知道，如果實施團隊很舒服，你的架構設計肯定變成在旁邊說胡話了，根本沒有設計效果。

所以，你決定來做架構了，就不要期望你有多nice。這是這個工作的特性，不能調和的。不要為了實施團隊的一般抱怨就去改變你的設計去迎合，否則產品失敗的時候，就沒有人跟你抱怨了。吾之所以有大患者，為吾有身，及吾無身，何患之有？你應該多聽實施團隊的抱怨，但你要分清楚哪些是真正在反饋問題，哪些只是你戰略實施的成本。

最后一個建議：架構團隊來自不同的領域，不要用“領域代表”看待自己。不要說我只是做芯片設計，我只是做安全的，我只是做內核的，我只是做數據庫的。架構團隊存在的目的，就是為了設計那些多個模塊互相甩鍋的Gap，然后所有模塊和協同起來，達到最優的效率。你盡然進來架構組了，你就不是某個模塊的“甩鍋代表”，你就是整個產品。

大部分投資者都是不懂技術的，就算他們來自技術背景，他們對你實施的這個技術也是外行，因為細節只是我們知道，否則他就不用你來做了，他自己做就好了。這些人決策的方式就是“多方確認”。

如果架構組自己都達不成共識，各說各話，那怎么說服投資人（其實包括準備用你的客戶），所以，架構組每個人都應該對整個架構策略都很熟悉。我不要求做芯片的人就會寫程序，但我需要做芯片的人知道軟件部分的構架要求，在解決方案中所處的地位。你不要告訴我你只懂UEFI，不懂Kernel是怎么做的，我需要你知道ACPI表那些信息是給Kernel的哪個模塊看的，你不是在做實施，等著別人給要求，你是那個負責知道少給一張EINJ表，Kernel會不會起不來的人。

推廣起來說，作為一個產品的架構團隊，你也不能只管“我的產品如何如何”，你必須從整個產業生態上開始設計。狼吃羊，羊吃草，你不能說你是狼，不管羊的死活。沒有羊了，狼也死了。做架構設計的人，必須知道狼可以吃多少羊，吃到什么時候就要開始收手了。

所以，對于一個產品的架構師，必須知道整個生態鏈是怎么運作的，要為了整個生態的平衡，不怕把自己部分自己的業務讓給其他產品，其他企業，也不怕自己背上別人不肯實施的業務，這樣你才會有掌控生態的力量。

大概就是這樣一些吧，再往下，就是具體業務怎么做的問題的。但當我們碰到困難的時候，不妨回頭來看看我們的總體思路，也許覺得無路走的時候又發現有路了，覺得很順利的時候，說不定就是危機的開始了。

編輯：黃飛