軟件系統架構師成長之路（一）

時間 2020-01-23

標籤軟件系統架構師成長之路简体版

原文原文鏈接

幾個月前，公司由於戰略調整，將位於美國的系統工程（system engineering）部門的工做轉到了國內。也由於此次調整，我有幸以系統架構師（system architect）的身份主導產品一新功能（feature）的開發。在此我分享本身的一些體會。

從開發架構師變成系統架構師所面臨的第一個挑戰，是所面臨的技術範疇和問題複雜度變廣和變大了不少。作開發架構師（development architect）時，只要關心整個系統一個子產品的內容，而系統架構師卻得關心多個產品的內容。作開發架構師時，因爲系統架構師已將問題進行了分解，所以所看到的複雜度也只是整個解決方案的一部分。作開發架構師時，對於不明白的問題，咱們能夠想固然地向系統架構師諮詢，而作系統架構師時，很多情形下就要本身經過查閱規範去尋求問題的答案，並在必要時指導開發架構師的工做。

系統架構師引導產品開發工做的方式是提供系統架構文檔（system architecture document，其中以用例描述爲主），要寫好這一文檔也是不小的挑戰。一個組織得再好的文檔，新手要在2300多頁的文檔中找準開發新功能所需修改的各個點並不容易。找修改點的過程須要經過閱讀去把握文檔的編寫脈絡，修改點找到後又須要模仿前人的語氣、角度和風格進行編寫，不然寫出來的內容會讓人以爲突兀。在系統架構文檔中描述用例時，對於假設（assumption）、前置條件（pre-condition）和後置條件（post-condition）的把握有時是個難點，這須要本身有很清晰的思路和作深刻的思考。

作系統架構師須要與更多的人進行交互，這又會讓人面臨新的挑戰。好比，系統架構師須要瞭解各運營商的網絡部署狀況以尋求兼容性解決方案，這就須要與客戶團隊（account team）進行交互；要了解第三方的產品特性就得與賣方管理者（vendor manager）進行交互；等等。爲此，系統架構師須要對產品線的相關組織架構至關了解，並對各類角色（包括項目經理、產品經理、客戶團隊等）的職責有清晰的認識，不然會出現有問題不知向哪尋求幫助，或者作那些不在職責以內的事等問題。

除了以上提到的對於架構師的挑戰外，一個成熟、穩定的產品研發管理團隊對新系統架構師上手工做頗有幫助。它有助於系統架構師快速地明確本身的工做職責和幫助創建起所需的人際關係。反之，若是沒有這樣一個團隊，因爲系統架構師的經驗不足而容易出現一些扯皮現象而影響工做的開展。

系統架構師新手必定不能忽視團隊的做用，以及在合適的時機向上司或其它富有經驗的管理者尋求幫助，這是我最大的一個體會。團隊的做用在於能幫助分擔工做，併爲技術方案的定型出謀畫策。系統架構師新手因爲一直身處技術領域，因此與富有經驗的管理者相比，他們的技術大多不是瓶頸，但在管理方面就頗有可能不如他們。他們因爲閱歷豐富而能很快地幫助找到管理問題的根結點，幫助咱們從困境中走出。注意，系統架構師所需的不僅是技術能力，更有管理能力。

總而言之，作系統架構師的確是很大的一個挑戰。但不管如何，直面挑戰是咱們最好的選擇！沒有痛苦就沒有成長！