架構(gòu)師成功溝通的三個(gè)關(guān)鍵
軟件架構(gòu)師們總是跟我說，他們的利益相關(guān)者并不關(guān)心他們的架構(gòu)。于是我問：你真的跟他們解釋清楚你的架構(gòu)了嗎？我得到的答案是：一年前我和他們討論過。因?yàn)榧軜?gòu)的重要性，架構(gòu)師們希望架構(gòu)知識(shí)能自行傳播。但問題是，這種自行傳播并不會(huì)發(fā)生。也許是因?yàn)椤爸匾氖虑椤苯?jīng)常被“緊急的事情”壓倒，也許是因?yàn)榧軜?gòu)本身存在一些復(fù)雜性。因此，進(jìn)行恰到好處的架構(gòu)溝通是架構(gòu)師的一項(xiàng)任務(wù)，但這件事情卻經(jīng)常被忽略。
這就提出了一個(gè)問題：架構(gòu)師應(yīng)該花多少時(shí)間在溝通上？Philippe Kruchten（一位著名的研究人員）在“軟件架構(gòu)師要做些什么”一文中給出了答案。
https://pkruchten.files.wordpress.com/2010/05/kruchten_2008_journal-of-systems-and-software.pdf
要想取得成功，一名軟件架構(gòu)師或軟件架構(gòu)團(tuán)隊(duì)，必須在外部關(guān)注點(diǎn)和內(nèi)部關(guān)注點(diǎn)之間取得某種微妙的平衡。外部關(guān)注點(diǎn)包括：傾聽客戶和用戶的聲音、關(guān)注技術(shù)的發(fā)展、規(guī)劃長期的愿景、推動(dòng)開發(fā)團(tuán)隊(duì)前進(jìn)。內(nèi)部關(guān)注點(diǎn)包括：花時(shí)間做出正確的設(shè)計(jì)決策，并加以驗(yàn)證和記錄。與這種平衡偏離太遠(yuǎn)的團(tuán)隊(duì)將會(huì)陷入一些陷阱，我們將這些陷阱叫作軟件架構(gòu)團(tuán)隊(duì)的反模式。
Kruchten 總結(jié)了架構(gòu)師的三種工作模式，大致可以映射成信息的輸入、處理和輸出。
內(nèi)部工作：這是架構(gòu)師的深層工作，本質(zhì)上就是思考和處理信息。如果是在一個(gè)架構(gòu)師團(tuán)隊(duì)中，這可能涉及到溝通。
內(nèi)部溝通：架構(gòu)師必須了解很廣泛的知識(shí)，包括去傾聽、閱讀和問問題。
對外溝通：在建立了新信息后，架構(gòu)師需要將它們傳播出去，包括文稿演示、寫文檔和提供支持。
Kruchten 認(rèn)為，這三者之間最理想的比例應(yīng)該是 50：25：25。所以架構(gòu)師只需要花一半的時(shí)間在架構(gòu)上，另一半花在了解當(dāng)前狀態(tài)以及傳播目標(biāo)狀態(tài)上。
如果這種平衡被打破，就會(huì)出現(xiàn)各種問題。
例如，一個(gè)完美主義者常常忽略外部溝通，Kruchten 將這種架構(gòu)稱為“鍍金”架構(gòu)。雖然做出的產(chǎn)品很棒，但一問世可能就過時(shí)了。
忽視內(nèi)部溝通和外部溝通的架構(gòu)師就像被關(guān)在“象牙塔”里。雖然做出來的產(chǎn)品可能可以在內(nèi)部保持一致，并且足夠漂亮，讓產(chǎn)品所有者沾沾自喜，但卻脫離了實(shí)際。學(xué)院派尤其容易掉到這個(gè)陷阱里。
如果架構(gòu)師忽視了內(nèi)部工作，那么架構(gòu)一致性缺失的問題就會(huì)在整個(gè)產(chǎn)品中表現(xiàn)出來。架構(gòu)的組成部分可能是經(jīng)過精心制作的，但不能很好地組合在一起。
太過關(guān)注外部溝通讓架構(gòu)師變成了顧問。雖然開發(fā)人員對架構(gòu)師提供的支持表示贊賞，但架構(gòu)背后卻缺乏具有凝聚力的思想。
在實(shí)踐當(dāng)中，架構(gòu)師們似乎不會(huì)太過關(guān)注內(nèi)部溝通。這樣的架構(gòu)師可能既不寫架構(gòu)文檔，也不為團(tuán)隊(duì)提供支持。因此，他們提供不了任何具有表面價(jià)值的產(chǎn)品，也無法長久生存下去。
讓我們回到最初問題：為什么人們對架構(gòu)不夠了解？假設(shè)有一個(gè)架構(gòu)，架構(gòu)師不是在“鍍金”，就是在“象牙塔”里。這兩種情況都缺乏對外溝通，所以應(yīng)該把更多的注意力放在這里。以下是一些對于我來說比較適用的想法。
我喜歡異步傳播，埃隆·馬斯克也是，所以我確信這種方式是有效的。
異步傳播的一大優(yōu)點(diǎn)是它具有比較好的傳播性。例如，對于電子郵件，你可以快速復(fù)制粘貼或轉(zhuǎn)發(fā)信息。實(shí)際上，書面信息在一般情況下來說具有很好的傳播性。其他媒體形式，如播客或視頻也具有傳播性，但我很少看到它們被用在軟件架構(gòu)當(dāng)中。
最常用的是圖表，但可惜的是，圖表的關(guān)注點(diǎn)過于極端。我見過很多很多的架構(gòu)圖，因?yàn)槿鄙傥淖纸忉尪屓穗y以理解。有些架構(gòu)圖其實(shí)很糟糕（例如使用了不一致的符號(hào)），但即使是好的架構(gòu)圖也需要有上下文信息。
優(yōu)秀的演講幻燈片都有相似點(diǎn)，它們都是為演示文稿而設(shè)計(jì)的。例如，喬布斯的演講就頗具傳奇色彩。
這張幻燈片上有三個(gè)圖標(biāo)，分別代表了三種相關(guān)的技術(shù)。在接下來的幾秒鐘里，喬布斯宣布將這三種技術(shù)融合在一起，變成了 iPhone?；脽羝菙⑹霰尘暗囊徊糠郑旧硎菦]有什么意義的。如果你設(shè)計(jì)的幻燈片本身可以作為講義使用，那么你的演示就會(huì)受到影響。
如果你記得要演示的內(nèi)容，那就可以把幻燈片作為提醒。同樣，我假設(shè)大多數(shù)架構(gòu)圖僅作為記憶輔助用途。要成為一種有效的溝通媒介，需要賦予它們更多的內(nèi)容。
異步傳播的一種方式是使用架構(gòu)決策記錄，我之前已經(jīng) 介紹 過了。決策記錄本身應(yīng)該是可理解的，因此你可以向人們提供它們的鏈接，讓他們自己去了解架構(gòu)，不需要向他們解釋。當(dāng)然，這并不是說你要把更多的時(shí)間花在對外溝通上，而是要更有效地利用這些時(shí)間。
在過去的兩年里，我每周都會(huì)給項(xiàng)目成員（大概有 250 人）發(fā)一份簡報(bào)。此外，還有其他幾十個(gè)人也會(huì)收到簡報(bào)，因?yàn)樗麄兠鞔_提出需要簡報(bào)。這說明至少有一半人不是我的目標(biāo)受眾，因?yàn)樗麄儾皇情_發(fā)人員。但是，即使是管理人員也很喜歡這樣，因?yàn)楹唸?bào)讓他們對項(xiàng)目中使用的技術(shù)有了一定的印象。我的部門主管就說：“請不要停止寫簡報(bào)！”
簡報(bào)包含了我一周內(nèi)處理的所有事情，這可能是一個(gè)我覺得還不夠?yàn)槿藗兯私獾男」ぞ?。它包含了新的架?gòu)決策記錄和即將到來的或正在進(jìn)行的活動(dòng)。
寫博客的經(jīng)驗(yàn)有助于寫好簡報(bào)。我在這個(gè)網(wǎng)站發(fā)表的最早一篇博文是在 2009 年寫的，但我在那之前的幾年就已經(jīng)寫過博客了。寫簡報(bào)最重要的是要堅(jiān)持始終如一。
我會(huì)用到一些有趣的圖片，它們在簡報(bào)中起到不同尋常的作用。很多人告訴我，他們最開始只是想看看這些有趣的圖片，到最后卻不知不覺地把整封郵件都看了。此外，一些人告訴我，看簡報(bào)是他們一周當(dāng)中最重要的事情。
寫科學(xué)論文對你也很有幫助。如果能得到同事的正確評價(jià)，你就可以訓(xùn)練自己寫出簡潔而正確的簡報(bào)。我的簡報(bào)只包含簡短的摘要，但也提供了大量鏈接，可以進(jìn)一步閱讀更詳細(xì)的資料。有時(shí)候我甚至?xí)低档刈鲆恍┳晕倚麄?，比如在簡?bào)中加入我的博客鏈接。
《Made to Stick》一書介紹了很多可以讓信息更容易被記住的方法，其中之一就是具象化。書中講述了在車間工作的工人和繪制圖紙的工程師這兩種角色之間的沖突，這與架構(gòu)師與開發(fā)人員之間的沖突非常相似。
工人在想，為什么你們不直接到車間來告訴我零件應(yīng)該怎么安裝？工程師在想，我該怎么做才能把圖紙做得更好？雙方是否應(yīng)該有更多的同理心，并在中間的某個(gè)位置達(dá)成共識(shí)？事實(shí)上不是這樣的。解決的辦法應(yīng)該是讓工程師改變他們的行為。為什么？正如 Bechky 指出的那樣，物理機(jī)器是最有效的溝通領(lǐng)域，每個(gè)人都能熟練地理解機(jī)器。因此，問題應(yīng)該放在機(jī)器層面解決。這個(gè)故事的寓意并不是要“把事情簡單化”。工人面臨復(fù)雜的問題，他們需要聰明的答案。這個(gè)故事的寓意是要找到一種“通用的語言”，一種每個(gè)人都能流利表達(dá)的語言。這種通用語言就是具象化。
這聽起來和我們最初的問題非常相似。開發(fā)人員可能會(huì)忽略架構(gòu)，因?yàn)榧軜?gòu)對于他們手頭要解決的問題來說不夠具象化。這本書建議的解決方案不是讓開發(fā)人員接受更好的培訓(xùn)，而是讓架構(gòu)師承擔(dān)起為具體的場景解釋架構(gòu)的職責(zé)。
我的簡報(bào)也強(qiáng)調(diào)了這一點(diǎn)。因?yàn)槲颐總€(gè)星期都需要挑選一些細(xì)節(jié)的東西放到簡報(bào)中。即使這些東西并不會(huì)與每個(gè)人都相關(guān)，但它們會(huì)促使我去解釋更廣泛的架構(gòu)背景。
抽象是專家們的“專屬品”，是對已廣為人知的具象概念的概括。但是，如果概念還沒有被很好地理解，進(jìn)行抽象就沒有意義。所以，架構(gòu)師應(yīng)該減少談?wù)摯蟮母庞[，至少應(yīng)該保持簡短。
要進(jìn)行具象化的溝通，架構(gòu)師需要做大量的工作。但請記住，這應(yīng)該只占用你 25% 的時(shí)間。你可以使用更具傳播性的異步傳播方式，正如我之前提出的第一個(gè)建議。
如果缺乏溝通，架構(gòu)師應(yīng)該承擔(dān)起這個(gè)職責(zé)。如果架構(gòu)師注意到人們對架構(gòu)不了解，他們必須改進(jìn)他們的外部溝通方式。對此，我有三點(diǎn)建議：
編寫良好的架構(gòu)決策記錄
定期撰寫簡報(bào)
針對具體的場景解釋架構(gòu)
還不過癮？試試它們
▲1.2 萬 Star！一款 Python 開發(fā)的架構(gòu)圖繪制工具