技術角色論系列：從一個架構師的角度看產品

架構由於複雜和規模增加而存在。複雜意味着功能和結構的變化和相互影響，是一個動態的過程概念。架構的邏輯開始於產品，着力於使用IT技術實現功能邏輯（業務邏輯）和非功能邏輯（安全、可靠、健壯、可維護、可移植、可重用、可擴充等）。

一個產品的IT技術實現能夠不須要架構師，無非是持續的人力投入，專一於更多的業務邏輯，維護龐雜而難延展的系統。如同任何一個專業的崗位出現，都是當收益和成本之間達不到預期、甚至不能平衡的時候，就產生了利用既有的專業知識的累積來下降成本的需求，這是經濟社會天然分工的規律。

很顯然重複使用是下降成本的方式（建造和維護）。重複使用代碼或功能（本身構建的、或第三方開源的項目）的前提是，代碼和功能必須是爲重複利用而設計的。就如同標準件纔是能夠拿來組裝和構成新產品的，而非標準件只能存在於它被製造和使用的惟一場景中。在實際需求指導下，部分構成總體後引入的複雜性問題解決，也是架構師要面對的挑戰。

優化軟件性能是提升硬件投資的利用率、突破硬件擴展邊際遞減的方式。也是優化軟件系統結構、優化算法、資源分配到高價值的部分以及突破系統瓶頸，這都須要一個更高的層次去檢視技術實現。

從軟件工程的角度，實施及時反饋調整開發資源的有效使用。測試驅動、敏捷短週期迭代開發、自動化測試、持續發佈/部署等，都是經常使用的工程質量及效率的流程管理（開發過程管理在團隊主管和項目經理這兩個角色中介紹）。

架構師的能力和工具箱豐富多彩，架構體系、模塊和組件、算法和邏輯、編程語言及運行環境、工程構建和維護，系統配置和健康監測，數據分析和調優等都須要各類能力和工具的使用。好比，對SOA, Microservices, Service Mesh ,Serverless 等架構的發展與理解，對開源項目的優缺點的理解及使用，對設計模式的理解及靈活應用，對編程語言的發展及瞭解，對雲服務大數據平臺的應用及瞭解，對CI / CD/ Docker 應用等就不一一列舉了。

邏輯和溝通能力是全部IT從業人員的基礎能力，也是團隊協做的基石。

架構師和產品經理的交叉點

產品經理是一個產品上下游關係的關鍵崗位，優秀的產品經理市面上也是稀缺的。產品經理的能力需求有，用戶調查研究、競品分析借鑑、需求管理（需求的系統化構建，將來產品的形式可能性，非功能需求的技術理解力，公司產品戰略意志的選擇），版本規劃（產品的階段劃分，每個階段交給用戶的模樣，具有必定的完整性、可用性），數據分析，產品工具（原型、交互、業務邏輯、需求文檔等）使用。邏輯和溝通能力在這個崗位上顯得特別重要。關鍵崗位，關鍵職責，也承擔產品成敗的關鍵責任。是否存在低價值需求消耗高成本技術資源，產品版本功是否錯過恰當市場時機的決策在這個崗位上都有必定的決定權。

固然也有極端作法，那就是什麼功能都要（沒有需求分析，沒有功能優先級，沒有版本規劃）做爲需求，把產品責任都交給技術團隊。一個產品的存在，必定是知足必定數量用戶的特定場景下的需求，用戶數量不足和場景需求不能知足，或不具有競爭力，都是賠本買賣。這裏說的是產品價值，能給用戶帶來什麼價值（產品有用）？爲何用戶要選擇使用該產品（產品好用）？產品解決了市面上已有產品的什麼缺陷（也就是產品的競爭力）？這都是開始作一個產品，要回答的基本問題。

競爭無處不在，產品要和它出生之前的產品競爭，也要和它將來的潛在對手競爭，還有非同行業產品對本行業的影響(Side Effects)。好比手機的使用減小了零售行業收銀臺擺放小物品的銷售（付款排隊時，吸引用戶關注力的競爭）。初創企業（應用型，非原創技術型）在資源、人力、專業技能上都沒有優點，在產品創意、激勵制度創新、團隊精神上卻是有船小好掉頭的靈活性優點，但在試錯上沒有資源能消耗的起。熟讀戰爭的藝術（《孫子兵法》英譯名）仍是頗有幫助。

架構師和產品經理的交叉點，是對產品需求的系統構建（將來產品的模樣）的共享以及版本規劃的現狀和將來，以便架構師能爲將來產品的模樣預留足夠的發展空間和技術架構平衡點的選擇。產品經理要理解架構師的技術架構設計的平衡點，以及非功能需求的技術約束【知足產品需求仍是技術的首要任務，技術路線選擇要先知足業務需求，而後體現優點】。以便理解從需求到技術實現的一些約束和優點。以便在後續中產生有本身產品競爭優點的功能實現。因此要求產品經理有必定深度的技術理解能力（對產品可開發、可設計及公司資源可承受的可行性瞭解）。

架構師在本身的領域，參考產品規劃，產品功能和非功能需求，根據本身的經驗和行業一般作法，作架構設計和具體設計，本着「抽象約束，封裝變化」的原則，提供系統應對複雜和規模增加的能力。

架構師在技術團隊的做用

架構是結構和願景的綜合，結構體現了複雜的分解，同時展示了系統將來的模樣。充分展現和詳細講解，讓開發人員理解實現細節中的約束如何反映總體架構的意圖。鬆耦合的簡單約束更多體如今系統級別，模塊化內的結構性約束可能會更具體一些。因此溝通和邏輯能力在架構師崗位上很重要。

應對複雜，下降開發和硬件成本是架構師最重要的做用，重複利用和適應新變化是美好追求，相應的提升標準化和性能優化的能力要求，技術流程、正向激勵等都須要管理者提供支持。架構師天然的分工出現，體現一個團隊和產品的階段性發展階段，是團隊和產品內在需求的推進。

測試從進入開發階段開始，單元測試、功能測試、集成測試、系統測試、壓力測試、性能測試、驗收測試，部署時smoking測試等，測試是保證質量，檢查系統瓶頸，驗證系統設計指標是否達成的手段，也是架構師要重點關注的部分，測試涉及的測試用例設計，測試邊界，測試環境，自動化測試，測試Bugs/報告等知識，會在測試經理和團隊主管這兩個角色中介紹。

架構師在有些團隊裏只體現了高級程序員或項目經理的角色職能，或者說團隊和產品尚未到須要架構師的天然分工階段。這並不利於技術團隊產生內驅的能力來提升要求，也達不到增長架構師崗位就能產生的預期效果。引入架構師崗位，意味着技術管理和開發人員提升能力的總體意願升級（創業技術團隊主管兼職架構師的角色，在能作好兩個角色的前提下，產生的強推進力是值得鼓勵的）。

架構師如何應對業務變化

在成熟行業或場景中，約束條件和發展方向已經固定，過往經驗已足夠應對業務的變化，這裏就不涉及了。對於創新性業務的變化，意味着約束和發展方向都在探索中，或者直接就是產品經理角色缺失，只寄但願於市場對產品的反向重塑，這是個巨大的挑戰，成本也相對比同時具備正向戰略、規劃、塑造的產品來的大。在競爭中失敗風險也大，畢竟亂拳打死老師傅的前提是你們都失去理智。

個人經驗作法是，先不設約束，也不作架構設計，力求快速實現，跟蹤用戶使用數據，提煉核心功能。核心功能穩定後儘快模塊化服務，並獨立出去發展。成熟一個獨立一個，及時地少許適度粒度的標準化接口，實現各功能組合的靈活性。合理安排模塊抽象封裝、代碼複用、關鍵優化，適度控制標準化程度和我的習慣的協調（強制和靈活的平衡，人的能動性和制度的強約束性平衡），把握開發節奏和系統維護效率，維持團隊的高效激勵機制，並在過程當中祈禱用戶有足夠的耐心、市場給你留下足夠的改進時間。

---

原創文章，轉載請註明出處