工作經驗談：SA
在之前的公司中，有幸擔任了 SA 的角色，而且還不是某個單位的 System Architect，而是跨單位的 Solutions Architect
稍微解釋一下，單位內的 SA（System）主要面向的是個別部門內的系統設計/架構，像是後端 Server，前端 App / 網頁、網站的系統架構。
跨單位的 SA（Solution）主要是面向多個不同單位，像是組織整個產品在前後端的合作架構，甚至是幫整個公司規劃跨產品的基礎服務，安全架構等。 所以雖然不是單位內的 System architect，但是工作時是需要跟個別單位的 SA 合作，溝通出最適合公司以及各部門的整體架構
雖然之前在做 Senior / Principle developer 的時候，或多或少也需要接觸到架構的設計（通常在公司沒有專職 SA 的情況），但是第一次擔任專職的 SA，能夠不被特定專案綁住的前提下，專注在架構面的規劃與設計，也還是蠻特別的經驗。
首先可能先聲明一下，我可能不屬於那種「學術型」或是「理論型」的 SA，可能很多 design pattern、或是其他架構方面的基礎理論並不是這麼扎實。 但是我還是希望透過過去的工作經驗，試著從實務面來協助團隊與產品，如何更有效率的溝通，如何讓團隊更有效率的開發/維護產品，如何解決跨部門的技術問題，或是幫忙產品開發團隊花時間研究一些平時沒時間研究的解決方案。
身為一個 SA，我覺得首先要對公司團隊本身有一定的認識，各個團隊的技術水平如何？ 強項/弱項個別是在哪？ 手中有哪些資源可以利用？
這樣你在設計時，才能清楚的規劃未來會有什麼樣的資源，能夠來完成你的設計。
在這段時間的 SA 經歷中，除了有時候會遇到一些奇怪/麻煩的問題之外，我覺得對我來說最大的挑戰就是：讓我真正理解到 SA 的困難之處，其實並不是「提出設計方案」，而是如何在現有的團隊以及工作排程下，「漸進的導入」新的設計方案。
因為在實務中，除非是全新開啟的專案，或是真的三生有幸老闆願意讓某個專案砍掉重練，不然大部分的時間，是沒辦法重頭規劃一個產品的。
而且在現今的軟體生態，在求變求快的市場下，是很難有一個架構/產品能夠只要單純維護就能夠長期存活的。 不斷的新增/移除功能，大改版都是時常會遇到的。
所以時常會遇到一種情況，大家明知道現有的架構不健康，裡面都是技術債的情況下。 大家都想改寫，可能資深一點的工程師也大概知道如何改，但是就是被新功能/Bug 時程的壓力下放棄了。
所以，SA 如何在了解產品的狀況下，除了能夠提出一個好的「解決方案」，如何設計一套流程「階段性的」從現有的架構過渡到新架構，是我這一年最大的挑戰與學習。
這方面，我覺得有兩大技巧是很重要的
溝通
良好的溝通與理解能力是核心之一，因為通常 SA 需要接觸不同的團隊，而且許多產品團隊或許又常常會被專案時程壓榨的喘不過氣。
所以第一步是要透過有效的溝通技巧，快速的理解產品團隊目前的架構，遇到的問題，並且與團隊成員建立足夠的信任，讓他們信任你是來幫他們解決問題的，而不是增加工作的（這一點很重要！！！）
接著在你的解決方案出來後，也是要透過溝通（甚至是談判技巧），跟團隊成員，PM爭取時間與空間，階段性的導入解決方案，並且要能夠讓團隊以及產品負責人相信，雖然重構或是改寫架構是有風險的，但是新架構帶來的好處（不管是出錯率更低，維護更輕鬆，更省成本，效能更好）還是值得這樣的投入
用證據說話
這部分就需要更多的專業能力與技巧，當 SA 設計出一個全新的架構時，如何讓團隊成員/管理者買單？ 如何讓他們心甘情願花時間花人力來做？
嘴遁是沒有用的，或許有些公司的 SA 話語權很大，但是這樣其實很難真正讓人信服。
最好的方法其實還是除了設計架構外，同時也透過其他手段來提除客觀的證據/數據來佐證。
可能是透過測試報告？ A/B 測試對比？ 或甚至親手改寫了一部分（不是 prototype，而是真正產品的一部分）
因為有時候 developer 對 code ， Manager 對數據是最敏感的。
所以身為一個 SA，捲起袖子下來動手還是很有必要的。
因為有時候把自己親身投入到產品中的時候，有時候常常也會發現一些當初在設計時遺漏掉的一些問題，並且也能夠增進與開發團隊的關係。 並且在實際導入的時候隨時的參與在整個過程中，適時的解釋甚至調整，而不是把一份設計丟出來，然後就叫產品團隊吃下去。
好的 SA 不應該只是象牙塔上面的學者，設計一堆高端但是不切實際，而且產品團隊也無法使用的天書。
而是時而站在更高的角度，在不被產品時程壓得昏頭轉向的前提下，更理性的分析，解決問題
時而站在開發者身旁，一步步的帶著團隊改善，優化產品。
