從康威定律和技術(shù)債看研發(fā)之痛
所謂康威定律
有一位叫康威的人，提出一個(gè)觀點(diǎn)：設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。其實(shí)，這里的系統(tǒng)并不局限于軟件領(lǐng)域的系統(tǒng)?？低?duì)其定律又做了具體解讀：
- 組織溝通方式會(huì)通過(guò)系統(tǒng)設(shè)計(jì)表達(dá)出來(lái)。
- 時(shí)間再多一件事情也不可能做得***，但總有時(shí)間做完一件事情。
- 線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。
- 大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。
組織溝通方式會(huì)通過(guò)系統(tǒng)設(shè)計(jì)表達(dá)出來(lái)，溝通成本隨著團(tuán)隊(duì)成員的增加而以幾何級(jí)數(shù)增加。線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性，這句話說(shuō)白一點(diǎn)就是，你需要構(gòu)建什么樣的系統(tǒng)，就搭建什么樣的組織結(jié)構(gòu)。下面我們會(huì)融合案例來(lái)看看這些逃不過(guò)的原則。
所謂技術(shù)債務(wù)
技術(shù)債務(wù)是由Ward Cunningham在1992年的報(bào)告中創(chuàng)造的一個(gè)比喻，被定義為當(dāng)我們有意或無(wú)意地做了錯(cuò)誤的或不理想的技術(shù)決策所累積的債務(wù)。它和金融債務(wù)非常相似。一個(gè)人貸款了就會(huì)產(chǎn)生債務(wù)。如果他定期還款，那么所創(chuàng)建的債務(wù)是可以接受的，不會(huì)產(chǎn)生進(jìn)一步的問(wèn)題。但是，如果他不還款，就會(huì)以利息作為懲罰，并隨著不還款次數(shù)的增加而增加。如果這個(gè)人很長(zhǎng)一段時(shí)間不能支付任何款項(xiàng)，那么應(yīng)計(jì)利息使得他更難以償還債務(wù)。在極端情況下，該人不得不宣布自己破產(chǎn)。
為了快速做業(yè)務(wù)，采取簡(jiǎn)單粗暴的方案是大家表示支持的。臨時(shí)方案的毛病不在于這2個(gè)月臨時(shí)了，而在于這個(gè)臨時(shí)上線之后，再無(wú)人管了，俗稱“有人生、沒(méi)人養(yǎng)”。1年如果做5個(gè)臨時(shí)方案，就等于欠了5筆債務(wù)。欠債并不可怕，怕的是沒(méi)有償還計(jì)劃，或者借口沒(méi)有時(shí)間，或者借口等業(yè)務(wù)不那么高速發(fā)展的時(shí)候。吊詭的是好的業(yè)務(wù)一定是永遠(yuǎn)都沒(méi)有時(shí)間的，而差的業(yè)務(wù)確實(shí)不用發(fā)展了，因?yàn)楸幌戮€了，或者整個(gè)公司close了。So，珍惜高速發(fā)展的業(yè)務(wù)，記得去更換引擎，償還債務(wù)，欠的，遲早要還的。有關(guān)技術(shù)債，推薦當(dāng)當(dāng)史大官人在周評(píng)比中名列前茅的文章：當(dāng)技術(shù)宅遇到技術(shù)債，我個(gè)人覺(jué)得是這方面有調(diào)皮有調(diào)性的好文章。
以三個(gè)case來(lái)看看研發(fā)活動(dòng)之痛
一次接入效率優(yōu)化
以真實(shí)的X業(yè)務(wù)為例，在去年年中的時(shí)候，一個(gè)全新模式的業(yè)務(wù)接入需要多達(dá)10天，歷經(jīng)17個(gè)環(huán)節(jié)，8個(gè)團(tuán)隊(duì)。如下圖所示。
我們確定了幾個(gè)策略以期帶來(lái)改變：
- 減少協(xié)同
- 減少環(huán)節(jié)
- 提升效率
為什么要減少協(xié)同呢?我們前面講過(guò)，組織溝通方式會(huì)通過(guò)系統(tǒng)設(shè)計(jì)表達(dá)出來(lái)，溝通成本隨著團(tuán)隊(duì)成員的增加而以幾何級(jí)數(shù)增加。關(guān)于溝通成本，人月神話給出了很簡(jiǎn)潔的答案：溝通成本 = n(n-1)/2，n=項(xiàng)目成員。如果按一個(gè)團(tuán)隊(duì)1個(gè)成員作為接口人參與跨團(tuán)隊(duì)協(xié)同，那么8個(gè)團(tuán)隊(duì)的溝通可能就達(dá)到87/2=28;而3個(gè)團(tuán)隊(duì)的溝通值算下來(lái)是32/2=3。
為什么要減少環(huán)節(jié)呢?環(huán)節(jié)越多，涉及的組織和團(tuán)隊(duì)就越多;減少組織協(xié)同必然要減少環(huán)節(jié)。有報(bào)道說(shuō)某市一家工廠的一個(gè)基建項(xiàng)目，在申報(bào)過(guò)程中，一共蓋了745個(gè)公章。流程如此繁瑣，必然會(huì)影響辦事效率。軟件研發(fā)亦是如此。
我們?cè)賮?lái)看一下提升效率!減少環(huán)節(jié)，減少協(xié)同，自然效率就高了;有哪些減少協(xié)同的方式呢?
我們來(lái)看一些例子：如果一個(gè)團(tuán)隊(duì)有3個(gè)team在協(xié)作，而每個(gè)team都是前端、后端、測(cè)試職責(zé)分明，那么需要協(xié)同的環(huán)節(jié)必然就會(huì)很多。比如team1后端開發(fā)交付測(cè)試、team1后端進(jìn)行驗(yàn)收測(cè)試、team1和team2進(jìn)行功能聯(lián)調(diào)等等。
如果嘗試進(jìn)行能力合并，就是全棧型團(tuán)隊(duì)，那么可能的模式就變成下圖所示：
全功能團(tuán)隊(duì)雖然也有編寫代碼、單元測(cè)試、接口測(cè)試、集成測(cè)試等環(huán)節(jié);但跨越組織的溝通已經(jīng)減少了很多。
我們?cè)賴L試一種變化，因?yàn)樵O(shè)計(jì)系統(tǒng)的組織，等于組織內(nèi)和組織間的溝通結(jié)果。
這個(gè)組織溝通圖背后的架構(gòu)關(guān)系可以如下示意：
總結(jié)：組織關(guān)系和架構(gòu)息息相關(guān);溝通成本往往由于組織協(xié)同方太多造成;應(yīng)該從外部視角來(lái)組合組織關(guān)系;嘗試通過(guò)抽象、構(gòu)建通用組件來(lái)嘗試達(dá)到能力復(fù)用;嘗試對(duì)于用戶或者內(nèi)部客戶提供統(tǒng)一受理界面。
重復(fù)的輪子
軟件開發(fā)領(lǐng)域有一個(gè)流行的原則：DRY，全稱是Don’t Repeat Yourself，我們一般翻譯為：不要重復(fù)造輪子。關(guān)于要不要造輪子，有一篇非常精彩的文章：使用開源項(xiàng)目的正確姿勢(shì)，都是血和淚的總結(jié)!
我們拋開其他，嘗試聊聊輪子與組織的關(guān)系。首先，如果是同一個(gè)boss下面，已經(jīng)有一個(gè)輪子了，兄弟團(tuán)隊(duì)用還是不用?如果不用，boss肯定要跟你算賬!盡管你背后在罵這廝做得有多爛，你還得用。如果是不同組織的輪子呢?就不一定了，如果是一個(gè)業(yè)務(wù)研發(fā)型團(tuán)隊(duì)，是沒(méi)有時(shí)間去造中間件輪子的了，但是可以搞些common-tools之類，這些也可以作為創(chuàng)新產(chǎn)出去交差。而且我們是絕對(duì)對(duì)同類產(chǎn)品表示嫉妒的，要千方百計(jì)證明對(duì)方很low，我解決了***難題。當(dāng)然另外一個(gè)團(tuán)隊(duì)也是這樣向老板匯報(bào)的。最終這些輪子越來(lái)越多，很難推廣，也無(wú)法解決全部問(wèn)題，因?yàn)閱?wèn)題域很廣，沒(méi)有銀彈。
我們以下面這個(gè)案例來(lái)說(shuō)一下。如下圖所示：
- 提需求給基礎(chǔ)平臺(tái)
- 自己做能力升級(jí)
- 找找有沒(méi)有別的輪子
方案1是***的，專業(yè)的事情交給專業(yè)團(tuán)隊(duì);方案2是不得已而為之;方案3是折中解決方案。也就是方案3優(yōu)于方案2，但我們習(xí)慣于做方案2，造一個(gè)輪子，因此形成了鄙視鏈。
你需要構(gòu)建什么樣的系統(tǒng)，就搭建什么樣的組織結(jié)構(gòu);這句話有一種逆向作用力。為了滿足xx領(lǐng)域的監(jiān)控能力，我們?cè)诨A(chǔ)平臺(tái)的基礎(chǔ)上引入了xx實(shí)時(shí)計(jì)算，xx指標(biāo)管理，xx模型;那么我們成立了一個(gè)團(tuán)隊(duì)A來(lái)做這事;做著做著，我們就形成了一種認(rèn)知，團(tuán)隊(duì)A就是解決這個(gè)問(wèn)題了，而且我們很強(qiáng)大;我們致力于解決更多的類似問(wèn)題;后來(lái)我們發(fā)現(xiàn)團(tuán)隊(duì)B、團(tuán)隊(duì)C也是通過(guò)自然生長(zhǎng)解決類似問(wèn)題的。那么問(wèn)題來(lái)了，從公司角度看，A、B、C做的事情應(yīng)該合并;從各具體組織看，會(huì)不斷證明別的團(tuán)隊(duì)做的會(huì)滿足不了我的需求，我是應(yīng)該留下來(lái)的團(tuán)隊(duì)。
總結(jié)：你要什么樣的系統(tǒng)，要搭建什么樣的組織結(jié)構(gòu);一旦搭建了這樣的組織結(jié)構(gòu)，可能帶來(lái)逆向作用力，從而導(dǎo)致重復(fù)建設(shè)、效率低下、部門墻，且最終可能都沒(méi)有對(duì)一個(gè)問(wèn)題域打穿，給合作伙伴或者客戶提供了非一站式的解決方案，陷入各自為政。
在提出解法前，我拋些原則：協(xié)同、賦能、動(dòng)態(tài)組織。首先明確一個(gè)動(dòng)態(tài)組織的概念，組織是為業(yè)務(wù)或者某些目標(biāo)服務(wù)的，組織應(yīng)該具備靈活性、動(dòng)態(tài)性。一個(gè)長(zhǎng)期穩(wěn)定的組織，可能沒(méi)有活力，或者沒(méi)有尋找新的挑戰(zhàn)空間。其次，協(xié)同原則，意思就是孤膽英雄不能成事已然是IT界的共識(shí)了，孤膽團(tuán)隊(duì)同樣難以成事。經(jīng)常有人講站在巨人的肩膀上，登高望遠(yuǎn)。所以一個(gè)組織要明確自己的目標(biāo)，而且明確多少事是協(xié)同哪些干系方去拿到;一定有很多不用自己做的事情，笨不是理由，沒(méi)看清楚會(huì)讓團(tuán)隊(duì)泥足深陷。賦能，是基于協(xié)同這個(gè)共識(shí)來(lái)的，中間件團(tuán)隊(duì)要賦能業(yè)務(wù)研發(fā)團(tuán)隊(duì)自不必說(shuō)，業(yè)務(wù)研發(fā)團(tuán)隊(duì)之間也可以相互賦能。那些共性問(wèn)題，沒(méi)有必要重復(fù)造輪子。這里引入了一個(gè)非常關(guān)鍵的因素，就是考核!團(tuán)隊(duì)A的主管如何看待A這個(gè)團(tuán)隊(duì)，他可能就把某工具做成當(dāng)目標(biāo)，其實(shí)團(tuán)隊(duì)A的主管的主管的目標(biāo)是達(dá)成5秒的異常檢測(cè)能力，他并不關(guān)注監(jiān)控的一部分能力是誰(shuí)提供的。OK，基于以上的討論，可以給出一些解法，但不限于此。
如上圖所示，中間件團(tuán)隊(duì)可以把監(jiān)控平臺(tái)做成內(nèi)部開源模式，是完全開放，還是提供基礎(chǔ)能力層，開放層這樣具體的細(xì)節(jié)且不討論，其他業(yè)務(wù)團(tuán)隊(duì)都可以貢獻(xiàn)代碼，業(yè)務(wù)團(tuán)隊(duì)的優(yōu)勢(shì)是離業(yè)務(wù)場(chǎng)景很近，有具體的場(chǎng)景驅(qū)動(dòng);這樣還可以解決A、B、C團(tuán)隊(duì)的優(yōu)先級(jí)問(wèn)題，全部List給中間件團(tuán)隊(duì)，不知道猴年馬月了。
如上圖所示，業(yè)務(wù)團(tuán)隊(duì)A和中間件團(tuán)隊(duì)可以持續(xù)共建某些基礎(chǔ)能力，可能業(yè)務(wù)團(tuán)隊(duì)A是需要賦能的大戶，而且所需要的成本很高，故長(zhǎng)期共建?；谖覀冋f(shuō)的協(xié)同、賦能、動(dòng)態(tài)組織原則，業(yè)務(wù)團(tuán)隊(duì)A在完成使命后可以在對(duì)應(yīng)的組織內(nèi)重新確定新的目標(biāo)。同時(shí)，賦能原則，共建的成果，可以為業(yè)務(wù)團(tuán)隊(duì)B、C服務(wù)。對(duì)于業(yè)務(wù)團(tuán)隊(duì)B而言，可能投入1-2個(gè)人，搞上2個(gè)月自己的需求就滿足了，那么他們就撤出。
平臺(tái)發(fā)展vs業(yè)務(wù)發(fā)展
最近陳康賢寫了一篇談演進(jìn)式架構(gòu)的文章，我記得大致是對(duì)于成熟的業(yè)務(wù)領(lǐng)域可以采用平臺(tái)式架構(gòu)。我非常認(rèn)同。之前也有一些大咖提出架構(gòu)是演進(jìn)出來(lái)的，而不是設(shè)計(jì)出來(lái)的?？傮w來(lái)講，演進(jìn)是必須的，前期設(shè)計(jì)做多少合適是值得探討的。我個(gè)人的一個(gè)衡量標(biāo)準(zhǔn)是對(duì)于方案A、B進(jìn)行評(píng)估，如果方案B可以更通用，而付出的成本在可接受范圍內(nèi)，優(yōu)先選擇方案B。不做BDUF是大家的共識(shí)，而藝術(shù)在對(duì)于“度”的把握。
許多人都會(huì)面臨一個(gè)問(wèn)題就是平臺(tái)發(fā)展vs業(yè)務(wù)發(fā)展。按理說(shuō)平臺(tái)應(yīng)該隨著業(yè)務(wù)一起發(fā)展，但是如果每個(gè)需求都是堆砌式地上線，那么就是構(gòu)建了一個(gè)一個(gè)的煙囪。我們期望的是在一段時(shí)間后，相似度高的、同類型需求可以擁有快得多的上線能力。
關(guān)于平臺(tái)發(fā)展和支持業(yè)務(wù)，以及不同場(chǎng)景不同階段的業(yè)務(wù)架構(gòu)原則我有幾個(gè)觀點(diǎn)。
- 架構(gòu)方案和業(yè)務(wù)形態(tài)息息相關(guān)。
- 架構(gòu)是演進(jìn)的、發(fā)展的;架構(gòu)沒(méi)有***，只有適合。
- 技術(shù)債要做清償計(jì)劃。
- 不要在下雨天去補(bǔ)屋頂。
架構(gòu)方案和業(yè)務(wù)形態(tài)息息相關(guān)
我之前親身經(jīng)歷了一條產(chǎn)品線，完全是試錯(cuò)型的產(chǎn)品線。我們?cè)谠O(shè)計(jì)之初，對(duì)于模型共同層做了抽象，后來(lái)五花八門的產(chǎn)品長(zhǎng)在上面，公共的內(nèi)容越來(lái)越少，反而導(dǎo)致了系統(tǒng)調(diào)用鏈路增加;代碼編寫的復(fù)雜度增加。1年后，這條產(chǎn)品線全線關(guān)閉!從這個(gè)case來(lái)看，最適合的就是滿足業(yè)務(wù)快速試錯(cuò)，可能煙囪式架構(gòu)是最合適的;甚至產(chǎn)品之間有一些代碼重復(fù)，但各team各司其職，是最快反應(yīng)，是最小的研發(fā)響應(yīng)單元。對(duì)應(yīng)到康威定律的組織和架構(gòu)關(guān)系，也是依賴最少的組織，溝通成本***。
如上圖所示，煙囪型架構(gòu)在不確定產(chǎn)品線的試錯(cuò)有優(yōu)勢(shì)，對(duì)應(yīng)的組織構(gòu)架也應(yīng)以簡(jiǎn)單、快速響應(yīng)為特征。
架構(gòu)是演進(jìn)的、發(fā)展的;架構(gòu)沒(méi)有***，只有適合
我再舉一個(gè)例子來(lái)說(shuō)架構(gòu)演進(jìn)這事。隨著業(yè)務(wù)發(fā)展，上了規(guī)模，類似的訴求會(huì)凸顯，因此沉淀為越來(lái)越多的平臺(tái)。如下圖示意：
除了需求相似性、平臺(tái)要求相似性導(dǎo)致的架構(gòu)發(fā)展以外，還可能有，我們對(duì)領(lǐng)域本質(zhì)認(rèn)知的升級(jí)。比如在支付寶淵源的發(fā)展過(guò)程中，我們先后使用過(guò)紅包、實(shí)時(shí)優(yōu)惠、商戶優(yōu)惠券等產(chǎn)品。這是煙囪式架構(gòu)發(fā)展下的產(chǎn)物。下圖示意為一個(gè)紅包產(chǎn)品的展示。
行業(yè)也有其他類似券的東東，如下圖所示：
如果簡(jiǎn)單地看，券和紅包是兩類東西。但是，我們?cè)诋a(chǎn)品上形成了如下定義，就可以視作一類東西，則可以對(duì)它們進(jìn)行統(tǒng)一的抽象和管理。
券定義：
- 是一種票據(jù)，作為券發(fā)行方和擁有方之間的憑證，具有一定的價(jià)值和法律效應(yīng)。
相關(guān)干系方：
- 券的發(fā)放方(提供權(quán)益)
- 券的擁有方(享受權(quán)益)
- 劵的發(fā)放工具(是券發(fā)行方向擁有方發(fā)放券憑證的工具)
券形式：
- 以介質(zhì)分類：紙質(zhì)券、電子券
- 以使用方式分類：入場(chǎng)券、禮品券、提貨券、代金券、紅包、打折卡、滿減卡等
可以把券作為基礎(chǔ)產(chǎn)品，在業(yè)務(wù)形態(tài)上可以包裝為打折卡，滿減卡等用戶感知的產(chǎn)品或者是營(yíng)銷工具。
技術(shù)債要做清償計(jì)劃
前一段，參與了一個(gè)關(guān)于技術(shù)債務(wù)的討論。技術(shù)債務(wù)確實(shí)一個(gè)惹人討厭的東西，業(yè)務(wù)逼著你跑，你不跑不行，可能跑著就累死了;你停下來(lái)歇會(huì)兒，搞搞技術(shù)改造，又可能被業(yè)務(wù)壓力壓死了，反正都是死!關(guān)于技術(shù)債務(wù)我提了4個(gè)觀點(diǎn)：
- 由于技術(shù)人員水平不行，意識(shí)不夠，所以越寫越爛。
- developer都有一顆積極向上的紅心，但是他們不知道如何做才是好的。
- 上行下效，沒(méi)有靠譜的Leader，架構(gòu)師，大家都是懶惰的，不想去還債。
- 有華為的朋友表示，永遠(yuǎn)的業(yè)務(wù)壓力，我沒(méi)時(shí)間;其實(shí)所有公司都一樣滴，趕著交付，哪有時(shí)間去清償。
關(guān)于債務(wù)清償，也總結(jié)了務(wù)實(shí)接地氣的幾個(gè)思路：
- 構(gòu)建質(zhì)量保障體系，讓我有勇氣動(dòng)手動(dòng)刀。比如接口測(cè)試、單元測(cè)試，通過(guò)CI持續(xù)反饋，這樣我有50%的勇氣來(lái)做重構(gòu)。
- 對(duì)于遺留系統(tǒng)，沒(méi)出問(wèn)題的地方，你不要?jiǎng)铀?。出?wèn)題的，修復(fù)并補(bǔ)充測(cè)試代碼。如果更進(jìn)一步，對(duì)于高危的功能和模塊可以做定向增強(qiáng)。
- 招募優(yōu)秀的工程師，好的作風(fēng)和習(xí)慣可以影響整個(gè)團(tuán)隊(duì)。
- 抓住痛得不行的時(shí)候大作文章。平常說(shuō)持續(xù)集成，可能團(tuán)隊(duì)成員沒(méi)有感受到好處，出bug了，再回顧看看;copy-paste代碼總有一天不能滿足更復(fù)雜的需求，這樣從心理認(rèn)同上，大家覺(jué)得必須重寫了。抓住這樣的機(jī)會(huì)，構(gòu)建品質(zhì)高一些的代碼和質(zhì)量防線。改變一個(gè)人是非常難的，抓住這樣的機(jī)會(huì)很重要!
不要在下雨天去補(bǔ)屋頂
馬老師有一金句：不要在下雨天去補(bǔ)屋頂。做軟件研發(fā)，做架構(gòu)也是一樣的。當(dāng)一些重點(diǎn)戰(zhàn)役型項(xiàng)目讓你喘不過(guò)氣的時(shí)候，你去做理想架構(gòu)無(wú)異于找死。這里一個(gè)觀點(diǎn)就是技術(shù)、架構(gòu)始終為業(yè)務(wù)，為商業(yè)服務(wù)。無(wú)論從走出舒適區(qū)，還是從架構(gòu)發(fā)展來(lái)講，一定要找準(zhǔn)時(shí)機(jī)來(lái)做架構(gòu)升級(jí)。這個(gè)升級(jí)是基于對(duì)業(yè)務(wù)本質(zhì)的不斷認(rèn)知，否則就是南轅北轍。我們團(tuán)隊(duì)曾在一次重要架構(gòu)改造的過(guò)程中，架構(gòu)方案確定比新業(yè)務(wù)來(lái)臨早了3個(gè)月，這樣剛好通過(guò)一個(gè)小業(yè)務(wù)的切換，快速上線。然后在戰(zhàn)役打響的第二個(gè)月新架構(gòu)派上用場(chǎng)，3個(gè)月的時(shí)差足以改變?cè)S多東西。
因此，我們要記住，不要在下雨天去補(bǔ)屋頂!補(bǔ)屋頂包括償還技術(shù)債務(wù)，包括架構(gòu)的升級(jí)改造!
總結(jié)一下：康威定律及其推論告訴我們，要什么事情，設(shè)定什么樣的組織結(jié)構(gòu);同時(shí)做不同的事情，要允許動(dòng)態(tài)彈性組織結(jié)構(gòu)，不要被組織束縛;再進(jìn)一步，跨越組織，立足協(xié)同、賦能可以做出更大的組織成效;技術(shù)債務(wù)這事不要等到下雨天才償還，做業(yè)務(wù)和平臺(tái)架構(gòu)發(fā)展平衡的藝術(shù)取決于在一定時(shí)間和環(huán)境下的目標(biāo)，技術(shù)人員不要永遠(yuǎn)處于被驅(qū)動(dòng)的狀態(tài)!研發(fā)之痛，是一個(gè)復(fù)雜的調(diào)試性問(wèn)題，沒(méi)有銀彈!
【本文來(lái)自51CTO專欄作者張開濤的微信公眾號(hào)(開濤的博客)，公眾號(hào)id: kaitao-1234567】
