談?wù)劤绦騿T、技術(shù)主管和架構(gòu)師

在程序員從初級走向資深的過程中，會面臨兩個支路，一個叫「技術(shù)主管」，另一個則是「架構(gòu)師」。為什么這是兩條支路？因為現(xiàn)在回過來看，這兩條路從來都不是程序員的自然成長路徑，下面我們先從「技術(shù)主管」開始吧。

技術(shù)主管

技術(shù)主管，有些公司可能又叫「技術(shù)經(jīng)理」，英文一般是 Tech Leader 或簡稱 TL。在拉姆·查蘭 (Ram Charan) 那本《領(lǐng)導(dǎo)梯隊》中提到一個人的工作角色中至少有百分之五十以上的時間是花費在管理事務(wù)上，那么他的角色才算是一個經(jīng)理（Manager）。所以技術(shù)主管（經(jīng)理）類似產(chǎn)品經(jīng)理屬于以經(jīng)理命名卻是非經(jīng)理的角色。

「技術(shù)主管」是開發(fā)團(tuán)隊中的某位程序員需要對一起創(chuàng)建系統(tǒng)的整個開發(fā)團(tuán)隊負(fù)責(zé)時所承擔(dān)的角色。通常他既要對最終交付的軟件系統(tǒng)負(fù)責(zé)，另外也會像一個程序員一樣去開發(fā)實現(xiàn)系統(tǒng)。一個技術(shù)主管的 60% ～ 70% 的時間可能花在了開發(fā)任務(wù)分解分配、開發(fā)實踐、代碼審核和風(fēng)險識別上，而余下的 30% ～ 40% 的時間則花在為了保障系統(tǒng)按時交付所需的各種計劃、協(xié)作、溝通、管理上。和團(tuán)隊管理者不同的是，技術(shù)主管的大部分管理工作都是針對具體研發(fā)任務(wù)和技術(shù)事務(wù)的。

例如：在一個開發(fā)團(tuán)隊中經(jīng)常會碰到因為技術(shù)方案和實現(xiàn)細(xì)節(jié)方面的分歧，如果程序員無法自主友好的完成對不同技術(shù)意見的統(tǒng)一，這時候技術(shù)主管就需要介入去了解兩種不同意見所造成的沖突。對事不對人的去把問題搞清楚，分析各自方案的利弊，必要的時候甚至能夠提出第三種更好的技術(shù)方案，以幫助開發(fā)團(tuán)隊達(dá)成共識。

另一方面，技術(shù)主管即使在日常的開發(fā)實現(xiàn)中，重點的內(nèi)容一般也不是放在某個具體的功能實現(xiàn)上。在完成了具體的開發(fā)任務(wù)評估、分解并分配后，技術(shù)主管應(yīng)該負(fù)責(zé)設(shè)計整體代碼的結(jié)構(gòu)和規(guī)范、必要時引入能提高整個團(tuán)隊生產(chǎn)力的新工具，推廣代碼模板，總結(jié)最佳實踐。他需要經(jīng)常性的關(guān)注整個團(tuán)隊完成一項研發(fā)任務(wù)的水平和實際要求的水平的差距問題，讓團(tuán)隊不僅滿足及時的軟件系統(tǒng)交付，同時又得到成長。

現(xiàn)實中，一個開發(fā)團(tuán)隊中最優(yōu)秀的程序員容易被指定承擔(dān)技術(shù)主管的角色，但優(yōu)秀的程序員又很容易陷入到實現(xiàn)功能的細(xì)節(jié)中，滿足于完美的實現(xiàn)，優(yōu)雅簡潔的代碼。實際上，這樣優(yōu)秀的程序員轉(zhuǎn)入技術(shù)主管這個角色后，就很容易嘗試控制設(shè)計和代碼的實現(xiàn)，他們很難接受代碼不按照他們希望的方式去編寫，這個是他們作為優(yōu)秀程序員一直以來的工作習(xí)慣，長此以往他們自身很容易變成整個開發(fā)團(tuán)隊的瓶頸，而團(tuán)隊里的其他成員卻未能得到足夠的鍛煉和成長。

所以技術(shù)主管實際相比團(tuán)隊里的其他程序員對系統(tǒng)的視角更開闊，以更有策略和長遠(yuǎn)的方式來考慮問題。他們即使擁有比團(tuán)隊里所有其他程序員更高超的開發(fā)實現(xiàn)技能，對所有開發(fā)任務(wù)擁有最強大的實現(xiàn)自信，也需要轉(zhuǎn)變?yōu)榱硪环N「借助他人使之實現(xiàn)」的能力和自信，因為技術(shù)主管是一個承擔(dān)更廣泛責(zé)任的角色，必然導(dǎo)致能夠?qū)Ｗ⒂行Ь幋a的時間會相比以前減少很多，而這一點正是優(yōu)秀程序員轉(zhuǎn)變?yōu)榧夹g(shù)主管的所面臨的最大挑戰(zhàn)之一。

最后，我們總結(jié)下技術(shù)主管的職責(zé)要求：

· 技術(shù)職責(zé)

研發(fā)任務(wù)管理

工作量評估

任務(wù)分解、分配

代碼審核

風(fēng)險識別

技術(shù)能力提升

代碼規(guī)范制定和推廣

生產(chǎn)力工具研發(fā)和推廣

最佳實踐總結(jié)和推廣

關(guān)鍵代碼實現(xiàn)

· 組織職責(zé)

協(xié)調(diào)溝通

招聘面試

教練指導(dǎo)

復(fù)盤總結(jié)

架構(gòu)師

看完上面關(guān)于技術(shù)主管的職責(zé)能力要求，想必你會有些疑惑，感覺好像很多條目對架構(gòu)師也是這么要求的。對，你的感覺沒錯，技術(shù)主管的角色與架構(gòu)師這一角色會產(chǎn)生一些職責(zé)上的重疊，事實上我自己認(rèn)為在團(tuán)隊規(guī)模比較小的時候（10 多人的規(guī)模），架構(gòu)師和技術(shù)主管的職責(zé)幾乎完全重疊，甚至技術(shù)主管還會代理一些團(tuán)隊主管的角色。

和技術(shù)主管一樣，架構(gòu)師也是一個在業(yè)界擁有著名的稱謂，但在絕大部分公司卻不屬于一個職位序列。許多公司都很糾結(jié)于如何定義架構(gòu)師的角色，以及架構(gòu)師所做的工作。以前聽阿里同學(xué)說 P7 屬于架構(gòu)師職位，不過最近在看另一個阿里同學(xué)寫的文章說：“前幾年是有專職的「架構(gòu)師」職位的，現(xiàn)在已經(jīng)回歸到「工程師」、「技術(shù)專家」、「研究員」這樣的純技術(shù)職位?！?。可見在一線互聯(lián)網(wǎng)公司關(guān)于架構(gòu)師的定義也是很模糊的。

曾經(jīng)在一篇文章《在首席架構(gòu)師眼里，架構(gòu)的本質(zhì)是…》提到了一個架構(gòu)師能力模型，我曾經(jīng)寫過結(jié)合我自己的經(jīng)歷和經(jīng)驗，這個能力模型針對架構(gòu)師這個角色來說還是比較符合的。

但正因為業(yè)界和公司對架構(gòu)師這個角色的職責(zé)定義很模糊，所以很多經(jīng)驗積累到一定程度的優(yōu)秀程序員，并且在公司內(nèi)被提升到一定高度的技術(shù)級別后，都會冠以架構(gòu)師之名。但實際情況是大部分剛剛冠以架構(gòu)師之名的優(yōu)秀程序員，其能力模型大部分停留在上圖中的藍(lán)色區(qū)域，而對其他區(qū)域并未有過系統(tǒng)性的認(rèn)識和訓(xùn)練。

看過了架構(gòu)師的能力模型，我們再來試著分析下對應(yīng)的職責(zé)。隨著軟件系統(tǒng)復(fù)雜度和規(guī)模的提升，團(tuán)隊也相應(yīng)變大，那么一個架構(gòu)師此時所處的職責(zé)位置就開始和技術(shù)主管區(qū)別開來，如果把技術(shù)主管想成是站在樓頂看整個系統(tǒng)，那么架構(gòu)師此時就是需要掛個氣球（此處腦補下動畫《飛屋環(huán)游記》的場景），飛到天上去看整個系統(tǒng)了。

除了技術(shù)主管的技術(shù)職責(zé)之外，架構(gòu)師還需要站在更高的緯度去做關(guān)于軟件系統(tǒng)的抽象和封裝。如果技術(shù)主管的抽象和封裝層次更多考慮的是語言函數(shù)、設(shè)計模式、代碼結(jié)構(gòu)等這一類的事務(wù)，那么架構(gòu)師是站在整體軟件系統(tǒng)高度，考慮不同子系統(tǒng)之間的交互關(guān)系、技術(shù)的合理性、需求的完整性、未來的演進(jìn)可能性，技術(shù)體系發(fā)展與組織、產(chǎn)品商業(yè)訴求的匹配度。

這是相對技術(shù)主管更高緯度的全局視角，另一方面依然有很多技術(shù)主管可能感覺沒把握的技術(shù)決策和技術(shù)爭端需要架構(gòu)師的介入?yún)f(xié)調(diào)。之所以要找架構(gòu)師來對一些技術(shù)爭端和方案進(jìn)行決策判斷，很多情況在于程序員對架構(gòu)師在技術(shù)領(lǐng)域內(nèi)專業(yè)力和影響力的信任，而建立這種專業(yè)力和影響力是實際構(gòu)建架構(gòu)師非權(quán)威領(lǐng)導(dǎo)力的來源。

這里提到一個「非權(quán)威領(lǐng)導(dǎo)力」，這是什么？非權(quán)威是相對權(quán)威而言，管理者的權(quán)威領(lǐng)導(dǎo)力來自于公司正式任命的職位和職權(quán)，而架構(gòu)師在大部分公司基本連職位職責(zé)都沒定義清楚，更沒有職權(quán)一說，所以實際上就不會有任何權(quán)威領(lǐng)導(dǎo)力。所以，架構(gòu)師要發(fā)揮更大的作用和價值就需要去構(gòu)建自己的非權(quán)威領(lǐng)導(dǎo)力，而這需要長期的專業(yè)力和影響力積累，而關(guān)于如何去積累并很好的發(fā)揮作用，這一點我也還在摸索，還沒有形成很系統(tǒng)的認(rèn)知體系。

另一方面，架構(gòu)師的組織職責(zé)除了技術(shù)主管承擔(dān)的之外，架構(gòu)師還承擔(dān)著在技術(shù)團(tuán)隊和非技術(shù)團(tuán)隊（例如：產(chǎn)品設(shè)計等團(tuán)隊）之間的接口作用，明確產(chǎn)品的邊界，勾勒技術(shù)藍(lán)圖，協(xié)調(diào)不同技能的技術(shù)團(tuán)隊協(xié)作，完成最終的軟件系統(tǒng)交付。這時架構(gòu)師的角色就像服務(wù)化架構(gòu)中的 API，定義了協(xié)作規(guī)范、交互協(xié)議和方式，但并不會聚焦在具體的實現(xiàn)上。

在更大規(guī)模的系統(tǒng)上，架構(gòu)師似乎還要去涉獵更多的跨領(lǐng)域知識，否則很可能無法做出最適合的技術(shù)決策。但人終究是有局限的，你不可能學(xué)完所有領(lǐng)域，所以特定的領(lǐng)域又會涌現(xiàn)一些垂直領(lǐng)域的架構(gòu)師。比如：數(shù)據(jù)架構(gòu)師、網(wǎng)絡(luò)架構(gòu)師、業(yè)務(wù)架構(gòu)師、安全架構(gòu)師。因而某一個領(lǐng)域背景出身的架構(gòu)師，他對其他領(lǐng)域也只能做個初步了解，當(dāng)需要作出關(guān)于涉及其他領(lǐng)域的架構(gòu)決策時，他就需要和其他領(lǐng)域的垂直架構(gòu)師做深度的溝通交流，以輔助決策判斷。

最后，我們還是總結(jié)下架構(gòu)師的職責(zé)要求：

· 技術(shù)職責(zé)

繼承技術(shù)主管的職責(zé)

高緯度的系統(tǒng)設(shè)計、抽象和封裝

產(chǎn)品技術(shù)藍(lán)圖繪制與關(guān)鍵技術(shù)決策

· 組織職責(zé)

繼承技術(shù)主管的職責(zé)

跨技術(shù)和非技術(shù)團(tuán)隊的接口協(xié)作

發(fā)展取舍

從一開始，我就提到技術(shù)主管和架構(gòu)師是程序員自然成長路上的兩條支路，始終停留在上面「出色程序員」能力模型域的程序員是無法很好的勝任技術(shù)主管和架構(gòu)師這兩個角色的。所以程序員在成長到一定階段就需要去考慮是否真要往技術(shù)主管和架構(gòu)師的方向發(fā)展。而從技術(shù)主管走到架構(gòu)師相對而言更有延續(xù)性，但技術(shù)主管也會有另一條路，就是轉(zhuǎn)型走上純管理崗位，成為一名真正意義上的經(jīng)理。

一旦選擇走入架構(gòu)師這條路，基本你就從一名出色的程序員這個領(lǐng)域走出，需要盡快去補充上面能力模型中指出的其他能力。這一點會讓剛剛走上這條路的程序員很不適應(yīng)，因為承擔(dān)了更多其他職責(zé)，就必然要減少在編碼實現(xiàn)的時間，慢慢就會懷疑自己的編碼能力會退化，也跟不上一線最新的技術(shù)棧，各種酷酷的新工具。我曾有一段時間就產(chǎn)生過這樣的茫然與惶恐，如今算是釋然了。

舍得，舍得，沒有舍就沒有得。成為架構(gòu)師會擁有一個更立體的知識、技能矩陣，這是你的得。獲得了一個面，在某些點上必然面臨被超越的結(jié)局。如果成為一名架構(gòu)師好幾年后，你居然還是團(tuán)隊里面編碼最多，編程能力最強的人，其實這是一個失敗的架構(gòu)師，在教練和指導(dǎo)這個職責(zé)上已經(jīng)完全的失敗了。而有些談?wù)摷軜?gòu)師的文章說：

架構(gòu)師一定要負(fù)責(zé)整個系統(tǒng)中最核心和最難的地方的代碼編寫，如果一個團(tuán)隊里需要一個架構(gòu)師，那他一定必須是團(tuán)隊里寫代碼能力最好的，而且要負(fù)責(zé)至少 40% 以上的核心開發(fā)工作。

上面的說法就是扯淡，這樣的架構(gòu)師就是這個團(tuán)隊最大的瓶頸。一個稍具規(guī)模的軟件系統(tǒng)和團(tuán)隊中，承擔(dān) 40% 以上的核心開發(fā)工作，基本上這樣的架構(gòu)師就是一個資深程序員，而架構(gòu)師的其他職責(zé)我估計他都沒時間和能力去考慮了。他會意識到這種方式無法持久，同時也奪走了其他開發(fā)者的創(chuàng)新能力和解決問題的樂趣，一個有經(jīng)驗的架構(gòu)師能夠更好地表達(dá)某些指導(dǎo)原則，并且了解什么時候該插手，什么時候該放手。

而架構(gòu)師到底要不要編碼，承擔(dān)多少的編碼工作，不是由某種定義和說法決定的。而是由架構(gòu)師自己決定的，因為架構(gòu)師承擔(dān)了軟件系統(tǒng)的最終交付和過程風(fēng)險識別，如果架構(gòu)師認(rèn)為某些關(guān)鍵部分，團(tuán)隊里沒有其他人能在交付日期前寫出達(dá)到他認(rèn)可的足夠可靠的代碼，他把這識別為一種風(fēng)險，決定自己完成，那么他就去編碼實現(xiàn)，否則就委托給他認(rèn)為足夠可靠的團(tuán)隊成員，這就是前面提到的「借助他人使之實現(xiàn)」的能力和自信。

當(dāng)團(tuán)隊里的程序員都逐漸獲得成長，成了高級或資深程序員之后，架構(gòu)師實際還需要寫代碼的機會越來越少。這方面的能力必然面臨退化，所以這方面對一線技術(shù)棧的決策會越來越交給一線資深程序員來判斷。但我們擔(dān)心時代、環(huán)境變化，有一天又需要回到一線技術(shù)棧時，那時技術(shù)棧已經(jīng)發(fā)生了巨大變化，架構(gòu)師還能很好的適應(yīng)么。技術(shù)的理解和基礎(chǔ)如內(nèi)功，而重新學(xué)通一門技術(shù)棧如招數(shù)，我覺得也未必需要多少時間，數(shù)月、半年或一年也許又讓你恢復(fù)到在新技術(shù)棧上感覺良好的編程狀態(tài)。

…

有時候安安靜靜的做個程序員，也挺好的。

您可能也喜歡：