所謂康威定律

　　有一位叫康威的人，提出一個觀點：設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。其實，這裡的系統並不侷限於軟體領域的系統。康威對其定律又做了具體解讀：

• 組織溝通方式會通過系統設計表達出來。

• 時間再多一件事情也不可能做得完美，但總有時間做完一件事情。

• 線型系統和線型組織架構間有潛在的異質同態特性。

• 大的系統組織總是比小系統更傾向於分解。

　　組織溝通方式會通過系統設計表達出來，溝通成本隨著團隊成員的增加而以幾何級數增加。線型系統和線型組織架構間有潛在的異質同態特性，這句話說白一點就是，你需要構建什麼樣的系統，就搭建什麼樣的組織結構。下面我們會融合案例來看看這些逃不過的原則。

　　所謂技術債務

　　技術債務是由Ward Cunningham在1992年的報告中創造的一個比喻，被定義為當我們有意或無意地做了錯誤的或不理想的技術決策所累積的債務。它和金融債務非常相似。一個人貸款了就會產生債務。如果他定期還款，那麼所建立的債務是可以接受的，不會產生進一步的問題。但是，如果他不還款，就會以利息作為懲罰，並隨著不還款次數的增加而增加。如果這個人很長一段時間不能支付任何款項，那麼應計利息使得他更難以償還債務。在極端情況下，該人不得不宣佈自己破產。

　　為了快速做業務，採取簡單粗暴的方案是大家表示支援的。臨時方案的毛病不在於這2個月臨時了，而在於這個臨時上線之後，再無人管了，俗稱“有人生、沒人養”。1年如果做5個臨時方案，就等於欠了5筆債務。欠債並不可怕，怕的是沒有償還計劃，或者藉口沒有時間，或者藉口等業務不那麼高速發展的時候。弔詭的是好的業務一定是永遠都沒有時間的，而差的業務確實不用發展了，因為被下線了，或者整個公司close了。So，珍惜高速發展的業務，記得去更換引擎，償還債務，欠的，遲早要還的。有關技術債，推薦噹噹史大官人在周評比中名列前茅的文章：當技術宅遇到技術債，我個人覺得是這方面有調皮有調性的好文章。

　　以三個case來看看研發活動之痛一次接入效率優化

　　以真實的X業務為例，在去年年中的時候，一個全新模式的業務接入需要多達10天，歷經17個環節，8個團隊。如下圖所示。

　　我們確定了幾個策略以期帶來改變：

• 減少協同

• 減少環節

• 提升效率

　　為什麼要減少協同呢？我們前面講過，組織溝通方式會通過系統設計表達出來，溝通成本隨著團隊成員的增加而以幾何級數增加。關於溝通成本，人月神話給出了很簡潔的答案：溝通成本 = n(n-1)/2，n=專案成員。如果按一個團隊1個成員作為介面人蔘與跨團隊協同，那麼8個團隊的溝通可能就達到87/2=28；而3個團隊的溝通值算下來是32/2=3。

　　為什麼要減少環節呢？環節越多，涉及的組織和團隊就越多；減少組織協同必然要減少環節。有報道說某市一家工廠的一個基建專案，在申報過程中，一共蓋了745個公章。流程如此繁瑣，必然會影響辦事效率。軟體研發亦是如此。

　　我們再來看一下提升效率！減少環節，減少協同，自然效率就高了；有哪些減少協同的方式呢？

　　我們來看一些例子：如果一個團隊有3個team在協作，而每個team都是前端、後端、測試職責分明，那麼需要協同的環節必然就會很多。比如team1後端開發交付測試、team1後端進行驗收測試、team1和team2進行功能聯調等等。

　　如果嘗試進行能力合併，就是全棧型團隊，那麼可能的模式就變成下圖所示：

　　全功能團隊雖然也有編寫程式碼、單元測試、介面測試、整合測試等環節；但跨越組織的溝通已經減少了很多。

　　我們再嘗試一種變化，因為設計系統的組織，等於組織內和組織間的溝通結果。

　　這個組織溝通圖背後的架構關係可以如下示意：

　　總結：組織關係和架構息息相關；溝通成本往往由於組織協同方太多造成；應該從外部視角來組合組織關係；嘗試通過抽象、構建通用元件來嘗試達到能力複用；嘗試對於使用者或者內部客戶提供統一受理介面。

　　重複的輪子

　　軟體開發領域有一個流行的原則：DRY，全稱是Don’t Repeat Yourself，我們一般翻譯為：不要重複造輪子。關於要不要造輪子，有一篇非常精彩的文章：使用開源專案的正確姿勢，都是血和淚的總結！

　　我們拋開其他，嘗試聊聊輪子與組織的關係。首先，如果是同一個boss下面，已經有一個輪子了，兄弟團隊用還是不用？如果不用，boss肯定要跟你算賬！儘管你背後在罵這廝做得有多爛，你還得用。如果是不同組織的輪子呢？就不一定了，如果是一個業務研發型團隊，是沒有時間去造中介軟體輪子的了，但是可以搞些common-tools之類，這些也可以作為創新產出去交差。而且我們是絕對對同類產品表示嫉妒的，要千方百計證明對方很low，我解決了世界級難題。當然另外一個團隊也是這樣向老闆彙報的。最終這些輪子越來越多，很難推廣，也無法解決全部問題，因為問題域很廣，沒有銀彈。

　　我們以下面這個案例來說一下。如下圖所示：

1. 提需求給基礎平臺

2. 自己做能力升級

3. 找找有沒有別的輪子

　　方案1是最好的，專業的事情交給專業團隊；方案2是不得已而為之；方案3是折中解決方案。也就是方案3優於方案2，但我們習慣於做方案2，造一個輪子，因此形成了鄙視鏈。

　　你需要構建什麼樣的系統，就搭建什麼樣的組織結構；這句話有一種逆向作用力。為了滿足xx領域的監控能力，我們在基礎平臺的基礎上引入了xx實時計算，xx指標管理，xx模型；那麼我們成立了一個團隊A來做這事；做著做著，我們就形成了一種認知，團隊A就是解決這個問題了，而且我們很強大；我們致力於解決更多的類似問題；後來我們發現團隊B、團隊C也是通過自然生長解決類似問題的。那麼問題來了，從公司角度看，A、B、C做的事情應該合併；從各具體組織看，會不斷證明別的團隊做的會滿足不了我的需求，我是應該留下來的團隊。

　　總結：你要什麼樣的系統，要搭建什麼樣的組織結構；一旦搭建了這樣的組織結構，可能帶來逆向作用力，從而導致重複建設、效率低下、部門牆，且最終可能都沒有對一個問題域打穿，給合作伙伴或者客戶提供了非一站式的解決方案，陷入各自為政。

　　在提出解法前，我拋些原則：協同、賦能、動態組織。首先明確一個動態組織的概念，組織是為業務或者某些目標服務的，組織應該具備靈活性、動態性。一個長期穩定的組織，可能沒有活力，或者沒有尋找新的挑戰空間。其次，協同原則，意思就是孤膽英雄不能成事已然是IT界的共識了，孤膽團隊同樣難以成事。經常有人講站在巨人的肩膀上，登高望遠。所以一個組織要明確自己的目標，而且明確多少事是協同哪些干係方去拿到；一定有很多不用自己做的事情，笨不是理由，沒看清楚會讓團隊泥足深陷。賦能，是基於協同這個共識來的，中介軟體團隊要賦能業務研發團隊自不必說，業務研發團隊之間也可以相互賦能。那些共性問題，沒有必要重複造輪子。這裡引入了一個非常關鍵的因素，就是考核！團隊A的主管如何看待A這個團隊，他可能就把某工具做成當目標，其實團隊A的主管的主管的目標是達成5秒的異常檢測能力，他並不關注監控的一部分能力是誰提供的。OK，基於以上的討論，可以給出一些解法，但不限於此。

　　如上圖所示，中介軟體團隊可以把監控平臺做成內部開源模式，是完全開放，還是提供基礎能力層，開放層這樣具體的細節且不討論，其他業務團隊都可以貢獻程式碼，業務團隊的優勢是離業務場景很近，有具體的場景驅動；這樣還可以解決A、B、C團隊的優先順序問題，全部List給中介軟體團隊，不知道猴年馬月了。

　　如上圖所示，業務團隊A和中介軟體團隊可以持續共建某些基礎能力，可能業務團隊A是需要賦能的大戶，而且所需要的成本很高，故長期共建。基於我們說的協同、賦能、動態組織原則，業務團隊A在完成使命後可以在對應的組織內重新確定新的目標。同時，賦能原則，共建的成果，可以為業務團隊B、C服務。對於業務團隊B而言，可能投入1-2個人，搞上2個月自己的需求就滿足了，那麼他們就撤出。

　　平臺發展vs業務發展

　　最近陳康賢寫了一篇談演進式架構的文章，我記得大致是對於成熟的業務領域可以採用平臺式架構。我非常認同。之前也有一些大咖提出架構是演進出來的，而不是設計出來的。總體來講，演進是必須的，前期設計做多少合適是值得探討的。我個人的一個衡量標準是對於方案A、B進行評估，如果方案B可以更通用，而付出的成本在可接受範圍內，優先選擇方案B。不做BDUF是大家的共識，而藝術在對於“度”的把握。

　　許多人都會面臨一個問題就是平臺發展vs業務發展。按理說平臺應該隨著業務一起發展，但是如果每個需求都是堆砌式地上線，那麼就是構建了一個一個的煙囪。我們期望的是在一段時間後，相似度高的、同類型需求可以擁有快得多的上線能力。

　　關於平臺發展和支援業務，以及不同場景不同階段的業務架構原則我有幾個觀點。

1. 架構方案和業務形態息息相關。

2. 架構是演進的、發展的；架構沒有最好，只有適合。

3. 技術債要做清償計劃。

4. 不要在下雨天去補屋頂。

　　架構方案和業務形態息息相關

　　我之前親身經歷了一條產品線，完全是試錯型的產品線。我們在設計之初，對於模型共同層做了抽象，後來五花八門的產品長在上面，公共的內容越來越少，反而導致了系統呼叫鏈路增加；程式碼編寫的複雜度增加。1年後，這條產品線全線關閉！從這個case來看，最適合的就是滿足業務快速試錯，可能煙囪式架構是最合適的；甚至產品之間有一些程式碼重複，但各team各司其職，是最快反應，是最小的研發響應單元。對應到康威定律的組織和架構關係，也是依賴最少的組織，溝通成本最低。

　　如上圖所示，煙囪型架構在不確定產品線的試錯有優勢，對應的組織構架也應以簡單、快速響應為特徵。

　　架構是演進的、發展的；架構沒有最好，只有適合。

　　我再舉一個例子來說架構演進這事。隨著業務發展，上了規模，類似的訴求會凸顯，因此沉澱為越來越多的平臺。如下圖示意：

　　除了需求相似性、平臺要求相似性導致的架構發展以外，還可能有，我們對領域本質認知的升級。比如在支付寶淵源的發展過程中，我們先後使用過紅包、實時優惠、商戶優惠券等產品。這是煙囪式架構發展下的產物。下圖示意為一個紅包產品的展示。

　　行業也有其他類似券的東東，如下圖所示：

　　如果簡單地看，券和紅包是兩類東西。但是，我們在產品上形成了如下定義，就可以視作一類東西，則可以對它們進行統一的抽象和管理。

　　券定義：

• 是一種票據，作為券發行方和擁有方之間的憑證，具有一定的價值和法律效應。

　　相關干係方：

• 券的發放方（提供權益）

• 券的擁有方（享受權益）

• 劵的發放工具（是券發行方向擁有方發放券憑證的工具）

　　券形式：

• 以介質分類：紙質券、電子券

• 以使用方式分類：入場券、禮品券、提貨券、代金券、紅包、打折卡、滿減卡等

　　可以把券作為基礎產品，在業務形態上可以包裝為打折卡，滿減卡等使用者感知的產品或者是營銷工具。

　　技術債要做清償計劃

　　前一段，參與了一個關於技術債務的討論。技術債務確實一個惹人討厭的東西，業務逼著你跑，你不跑不行，可能跑著就累死了；你停下來歇會兒，搞搞技術改造，又可能被業務壓力壓死了，反正都是死！關於技術債務我提了4個觀點：

• 由於技術人員水平不行，意識不夠，所以越寫越爛。

• developer都有一顆積極向上的紅心，但是他們不知道如何做才是好的。

• 上行下效，沒有靠譜的Leader，架構師，大家都是懶惰的，不想去還債。

• 有華為的朋友表示，永遠的業務壓力，我沒時間；其實所有公司都一樣滴，趕著交付，哪有時間去清償。

　　關於債務清償，也總結了務實接地氣的幾個思路：

• 構建質量保障體系，讓我有勇氣動手動刀。比如介面測試、單元測試，通過CI持續反饋，這樣我有50%的勇氣來做重構。

• 對於遺留系統，沒出問題的地方，你不要動它。出問題的，修復並補充測試程式碼。如果更進一步，對於高危的功能和模組可以做定向增強。

• 招募優秀的工程師，好的作風和習慣可以影響整個團隊。

• 抓住痛得不行的時候大作文章。平常說持續整合，可能團隊成員沒有感受到好處，出bug了，再回顧看看；copy-paste程式碼總有一天不能滿足更復雜的需求，這樣從心理認同上，大家覺得必須重寫了。抓住這樣的機會，構建品質高一些的程式碼和質量防線。改變一個人是非常難的，抓住這樣的機會很重要！

　　不要在下雨天去補屋頂

　　馬老師有一金句：不要在下雨天去補屋頂。做軟體研發，做架構也是一樣的。當一些重點戰役型專案讓你喘不過氣的時候，你去做理想架構無異於找死。這裡一個觀點就是技術、架構始終為業務，為商業服務。無論從走出舒適區，還是從架構發展來講，一定要找準時機來做架構升級。這個升級是基於對業務本質的不斷認知，否則就是南轅北轍。我們團隊曾在一次重要架構改造的過程中，架構方案確定比新業務來臨早了3個月，這樣剛好通過一個小業務的切換，快速上線。然後在戰役打響的第二個月新架構派上用場，3個月的時差足以改變許多東西。

　　因此，我們要記住，不要在下雨天去補屋頂！補屋頂包括償還技術債務，包括架構的升級改造！

　　總結一下：康威定律及其推論告訴我們，要什麼事情，設定什麼樣的組織結構；同時做不同的事情，要允許動態彈性組織結構，不要被組織束縛；再進一步，跨越組織，立足協同、賦能可以做出更大的組織成效；技術債務這事不要等到下雨天才償還，做業務和平臺架構發展平衡的藝術取決於在一定時間和環境下的目標，技術人員不要永遠處於被驅動的狀態！研發之痛，是一個複雜的除錯性問題，沒有銀彈！

　　推薦gitchat平臺，該平臺由謝工發起，難得的做內容精品的良心產品！

　　作者公眾號：流浪不是我的初衷

　　安利一個活動，由中生代技術&iTechPlus發起的年度大會。20+話題，6大主題。乾貨專家悉數到場。本通道優惠碼：youjun,享受折上折。