程式設計師、技術主管和架構師

技術主管

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

「技術主管」是開發團隊中的某位程式設計師需要對一起建立系統的整個開發團隊負責時所承擔的角色。通常他既要對最終交付的軟體系統負責，另外也會像一個程式設計師一樣去開發實現系統。一個技術主管的 60% ～ 70% 的時間可能花在了開發任務分解分配、開發實踐、程式碼稽核和風險識別上，而餘下的 30% ～ 40% 的時間則花在為了保障系統按時交付所需的各種計劃、協作、溝通、管理上。和團隊管理者不同的是，技術主管的大部分管理工作都是針對具體研發任務和技術事務的。

例如：在一個開發團隊中經常會碰到因為技術方案和實現細節方面的分歧，如果程式設計師無法自主友好的完成對不同技術意見的統一，這時候技術主管就需要介入去了解兩種不同意見所造成的衝突。對事不對人的去把問題搞清楚，分析各自方案的利弊，必要的時候甚至能夠提出第三種更好的技術方案，以幫助開發團隊達成共識。

另一方面，技術主管即使在日常的開發實現中，重點的內容一般也不是放在某個具體的功能實現上。在完成了具體的開發任務評估、分解並分配後，技術主管應該負責設計整體程式碼的結構和規範、必要時引入能提高整個團隊生產力的新工具，推廣程式碼模板，總結最佳實踐。他需要經常性的關注整個團隊完成一項研發任務的水平和實際要求的水平的差距問題，讓團隊不僅滿足及時的軟體系統交付，同時又得到成長。

現實中，一個開發團隊中最優秀的程式設計師容易被指定承擔技術主管的角色，但優秀的程式設計師又很容易陷入到實現功能的細節中，滿足於完美的實現，優雅簡潔的程式碼。實際上，這樣優秀的程式設計師轉入技術主管這個角色後，就很容易嘗試控制設計和程式碼的實現，他們很難接受程式碼不按照他們希望的方式去編寫，這個是他們作為優秀程式設計師一直以來的工作習慣，長此以往他們自身很容易變成整個開發團隊的瓶頸，而團隊裡的其他成員卻未能得到足夠的鍛鍊和成長。

所以技術主管實際相比團隊裡的其他程式設計師對系統的視角更開闊，以更有策略和長遠的方式來考慮問題。他們即使擁有比團隊裡所有其他程式設計師更高超的開發實現技能，對所有開發任務擁有最強大的實現自信，也需要轉變為另一種「藉助他人使之實現」的能力和自信，因為技術主管是一個承擔更廣泛責任的角色，必然導致能夠專注有效編碼的時間會相比以前減少很多，而這一點正是優秀程式設計師轉變為技術主管的所面臨的最大挑戰之一。

最後，我們總結下技術主管的職責要求：

技術職責

程式碼規範制定和推廣

生產力工具研發和推廣

最佳實踐總結和推廣

工作量評估

任務分解、分配

程式碼稽核

風險識別

研發任務管理

技術能力提升

關鍵程式碼實現

組織職責

協調溝通

招聘面試

教練指導

覆盤總結

架構師

看完上面關於技術主管的職責能力要求，想必你會有些疑惑，感覺好像很多條目對架構師也是這麼要求的。對，你的感覺沒錯，技術主管的角色與架構師這一角色會產生一些職責上的重疊，事實上我自己認為在團隊規模比較小的時候（10 多人的規模），架構師和技術主管的職責幾乎完全重疊，甚至技術主管還會代理一些團隊主管的角色。

和技術主管一樣，架構師也是一個在業界擁有著名的稱謂，但在絕大部分公司卻不屬於一個職位序列。許多公司都很糾結於如何定義架構師的角色，以及架構師所做的工作。以前聽阿里同學說 P7 屬於架構師職位，不過最近在看另一個阿里同學寫的文章說：“前幾年是有專職的「架構師」職位的，現在已經迴歸到「工程師」、「技術專家」、「研究員」這樣的純技術職位。”。可見在一線網際網路公司關於架構師的定義也是很模糊的。

曾經在一篇文章《在首席架構師眼裡，架構的本質是...》提到了一個架構師能力模型，我曾經寫過結合我自己的經歷和經驗，這個能力模型針對架構師這個角色來說還是比較符合的。

但正因為業界和公司對架構師這個角色的職責定義很模糊，所以很多經驗積累到一定程度的優秀程式設計師，並且在公司內被提升到一定高度的技術級別後，都會冠以架構師之名。但實際情況是大部分剛剛冠以架構師之名的優秀程式設計師，其能力模型大部分停留在上圖中的藍色區域，而對其他區域並未有過系統性的認識和訓練。

看過了架構師的能力模型，我們再來試著分析下對應的職責。隨著軟體系統複雜度和規模的提升，團隊也相應變大，那麼一個架構師此時所處的職責位置就開始和技術主管區別開來，如果把技術主管想成是站在樓頂看整個系統，那麼架構師此時就是需要掛個氣球（此處腦補下動畫《飛屋環遊記》的場景），飛到天上去看整個系統了。

除了技術主管的技術職責之外，架構師還需要站在更高的緯度去做關於軟體系統的抽象和封裝。如果技術主管的抽象和封裝層次更多考慮的是語言函式、設計模式、程式碼結構等這一類的事務，那麼架構師是站在整體軟體系統高度，考慮不同子系統之間的互動關係、技術的合理性、需求的完整性、未來的演進可能性，技術體系發展與組織、產品商業訴求的匹配度。

這是相對技術主管更高緯度的全域性視角，另一方面依然有很多技術主管可能感覺沒把握的技術決策和技術爭端需要架構師的介入協調。之所以要找架構師來對一些技術爭端和方案進行決策判斷，很多情況在於程式設計師對架構師在技術領域內專業力和影響力的信任，而建立這種專業力和影響力是實際構建架構師非權威領導力的來源。

這裡提到一個「非權威領導力」，這是什麼？非權威是相對權威而言，管理者的權威領導力來自於公司正式任命的職位和職權，而架構師在大部分公司基本連職位職責都沒定義清楚，更沒有職權一說，所以實際上就不會有任何權威領導力。所以，架構師要發揮更大的作用和價值就需要去構建自己的非權威領導力，而這需要長期的專業力和影響力積累，而關於如何去積累並很好的發揮作用，這一點我也還在摸索，還沒有形成很系統的認知體系。

另一方面，架構師的組織職責除了技術主管承擔的之外，架構師還承擔著在技術團隊和非技術團隊（例如：產品設計等團隊）之間的介面作用，明確產品的邊界，勾勒技術藍圖，協調不同技能的技術團隊協作，完成最終的軟體系統交付。這時架構師的角色就像服務化架構中的 API，定義了協作規範、互動協議和方式，但並不會聚焦在具體的實現上。

在更大規模的系統上，架構師似乎還要去涉獵更多的跨領域知識，否則很可能無法做出最適合的技術決策。但人終究是有侷限的，你不可能學完所有領域，所以特定的領域又會湧現一些垂直領域的架構師。比如：資料架構師、網路架構師、業務架構師、安全架構師。因而某一個領域背景出身的架構師，他對其他領域也只能做個初步瞭解，當需要作出關於涉及其他領域的架構決策時，他就需要和其他領域的垂直架構師做深度的溝通交流，以輔助決策判斷。

最後，我們還是總結下架構師的職責要求：

技術職責

繼承技術主管的職責

高緯度的系統設計、抽象和封裝

產品技術藍圖繪製與關鍵技術決策

組織職責

繼承技術主管的職責

跨技術和非技術團隊的介面協作

發展取捨

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

一旦選擇走入架構師這條路，基本你就從一名出色的程式設計師這個領域走出，需要儘快去補充上面能力模型中指出的其他能力。這一點會讓剛剛走上這條路的程式設計師很不適應，因為承擔了更多其他職責，就必然要減少在編碼實現的時間，慢慢就會懷疑自己的編碼能力會退化，也跟不上一線最新的技術棧，各種酷酷的新工具。我曾有一段時間就產生過這樣的茫然與惶恐，如今算是釋然了。

捨得，捨得，沒有舍就沒有得。成為架構師會擁有一個更立體的知識、技能矩陣，這是你的得。獲得了一個面，在某些點上必然面臨被超越的結局。如果成為一名架構師好幾年後，你居然還是團隊裡面編碼最多，程式設計能力最強的人，其實這是一個失敗的架構師，在教練和指導這個職責上已經完全的失敗了。而有些談論架構師的文章說：

架構師一定要負責整個系統中最核心和最難的地方的程式碼編寫，如果一個團隊裡需要一個架構師，那他一定必須是團隊裡寫程式碼能力最好的，而且要負責至少 40% 以上的核心開發工作。

上面的說法就是扯淡，這樣的架構師就是這個團隊最大的瓶頸。一個稍具規模的軟體系統和團隊中，承擔 40% 以上的核心開發工作，基本上這樣的架構師就是一個資深程式設計師，而架構師的其他職責我估計他都沒時間和能力去考慮了。他會意識到這種方式無法持久，同時也奪走了其他開發者的創新能力和解決問題的樂趣，一個有經驗的架構師能夠更好地表達某些指導原則，並且瞭解什麼時候該插手，什麼時候該放手。

而架構師到底要不要編碼，承擔多少的編碼工作，不是由某種定義和說法決定的。而是由架構師自己決定的，因為架構師承擔了軟體系統的最終交付和過程風險識別，如果架構師認為某些關鍵部分，團隊裡沒有其他人能在交付日期前寫出達到他認可的足夠可靠的程式碼，他把這識別為一種風險，決定自己完成，那麼他就去編碼實現，否則就委託給他認為足夠可靠的團隊成員，這就是前面提到的「藉助他人使之實現」的能力和自信。

當團隊裡的程式設計師都逐漸獲得成長，成了高階或資深程式設計師之後，架構師實際還需要寫程式碼的機會越來越少。這方面的能力必然面臨退化，所以這方面對一線技術棧的決策會越來越交給一線資深程式設計師來判斷。但我們擔心時代、環境變化，有一天又需要回到一線技術棧時，那時技術棧已經發生了巨大變化，架構師還能很好的適應麼。技術的理解和基礎如內功，而重新學通一門技術棧如招數，我覺得也未必需要多少時間，數月、半年或一年也許又讓你恢復到在新技術棧上感覺良好的程式設計狀態。

...

有時候安安靜靜的做個程式設計師，也挺好的。