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

架構(gòu)是一個充滿了自由度的工作，是一個最不適合用過去的成功指導(dǎo)下一波策略設(shè)計的領(lǐng)域，無論你過去的領(lǐng)域和這個領(lǐng)域有多相像，你過去的成功經(jīng)驗都只能拿來參考，不適合用來拷貝。

因為即使是完全相同的領(lǐng)域，時間已經(jīng)不同了，行業(yè)生態(tài)，技術(shù)發(fā)展已經(jīng)不同了，你面對的人不同了，業(yè)務(wù)的瓶頸已經(jīng)不同了，生態(tài)的各個利益體的投資已經(jīng)不同了，成熟的領(lǐng)域人員可能減少，當(dāng)初的績優(yōu)股可能已經(jīng)失敗，你面對的是一個新的領(lǐng)域，我們做架構(gòu)，永遠(yuǎn)不能被過去的“定義”，左右了我們的判斷。所以，做新的架構(gòu)設(shè)計，你可以參考過去的成功pattern，但你的分析，必須建立在現(xiàn)在的條件上，不能離開對現(xiàn)在問題的調(diào)查，直接打算使用過去的模式。

這是我對我們進(jìn)行產(chǎn)品戰(zhàn)略設(shè)計的第一個建議。

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

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

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

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

這是第二個建議。

但對于這個建議，我有個直接的工作技巧可以分享。當(dāng)我們確切落筆寫一個架構(gòu)設(shè)計的時候，要考慮：以客戶為目標(biāo)，以工程為準(zhǔn)繩。

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

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

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

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

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

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

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

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

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

如果你要調(diào)查完這些東西才做決定，你就永遠(yuǎn)都不用做了。所以，進(jìn)行架構(gòu)設(shè)計，要勇敢進(jìn)行“猜”，“預(yù)判”，哪怕錯了，你也要“猜”，因為這是架構(gòu)設(shè)計工作的基礎(chǔ)。你的決策要同時決策：使用猜這個結(jié)論和再調(diào)查一下，哪個投資收益比更低？然后就要去實施。我在這個專欄中經(jīng)常強調(diào)“守弱”，其本質(zhì)就是這個：架構(gòu)本身就是一種猜，我們在猜的基礎(chǔ)上執(zhí)行，如果你非要維護(hù)面子，在執(zhí)行的時候收到當(dāng)時猜錯了的反饋，你死要面子不肯調(diào)整，那這個架構(gòu)執(zhí)行就失敗了。

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

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

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

最后一個建議：架構(gòu)團隊來自不同的領(lǐng)域，不要用“領(lǐng)域代表”看待自己。不要說我只是做芯片設(shè)計，我只是做安全的，我只是做內(nèi)核的，我只是做數(shù)據(jù)庫的。架構(gòu)團隊存在的目的，就是為了設(shè)計那些多個模塊互相甩鍋的Gap，然后所有模塊和協(xié)同起來，達(dá)到最優(yōu)的效率。你盡然進(jìn)來架構(gòu)組了，你就不是某個模塊的“甩鍋代表”，你就是整個產(chǎn)品。

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

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

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

所以，對于一個產(chǎn)品的架構(gòu)師，必須知道整個生態(tài)鏈?zhǔn)窃趺催\作的，要為了整個生態(tài)的平衡，不怕把自己部分自己的業(yè)務(wù)讓給其他產(chǎn)品，其他企業(yè)，也不怕自己背上別人不肯實施的業(yè)務(wù)，這樣你才會有掌控生態(tài)的力量。

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

編輯：黃飛