工作經驗談：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 不應該只是象牙塔上面的學者，設計一堆高端但是不切實際，而且產品團隊也無法使用的天書。
而是時而站在更高的角度，在不被產品時程壓得昏頭轉向的前提下，更理性的分析，解決問題
時而站在開發者身旁，一步步的帶著團隊改善，優化產品。
Scrum 的那些事 Part 3：Water-Scrum-fall
在前一篇說明了，其實有許多的企業跟團隊，其實並不適合單純的導入 Scrum，或者其實根本就不需要單純的 Scrum。
可能是企業/產品屬性，團隊特質或是組成特性造成的。
由於台灣我待過的許多開發團隊中，公司本身可能就是屬於代工/外包性質，開發團隊本身對於產品本身可能基本上就沒有自主權，而是被動地被交付需求與時程。
或是分工較細的公司部門中，設計就得由設計團隊負責，測試就得由測試團隊負責。 其他部門可能沒有餘力，或是沒有足夠的能力（或是公司不允許）跨越部門間的那道牆。
但是在專案管理上，又需要一種能夠快速迭代管理，快速反應市場，快速應對需求改變的方式。
或是某些團隊在導入單純的 Scrum 後，有意無意的發展出了這樣傳統與現代的混合模式。
Read moreScrum 的那些事 Part 2：今天，我們來聊聊 scrum
既然上一篇已經介紹過了 Scrum / Agile 的起源，以及對照 Waterfall 的一些差異。
這篇就直接來聊聊 Scrum，以及 Scrum 到底提供了怎樣具體的方法來做到敏捷式開發的核心價值
SCRUM Process
這張圖很清楚了表達整個 scrum 的核心流程：
- 把產品的核心 Vision 切分成多個可描述的 User Story，然後放到 Product backlog 中
- 每一次迭代，從中提取出最重要（市場價值）的部分放入 Sprint backlog
- 團隊經過討論，根據需求內容與團隊的可用資源，適時的調整（增/減）Sprint backlog 的內容
- 在 2~4週的 Sprint 中，每天透過 Daily Standup 來確保開發進度
- 在每次 Sprint 後，都有一個可上線的產品（疊加於之前的迭代版本）
並且依照這個流程不段迭代，因應市場變化不斷的調整 Product backlog 中的內容與優先級。
並確保在每次 Sprint 前都能夠提取當前最重要的項目優先開發。
Read more
一個人的職場價值
今天不聊技術，來聊聊「職場價值」這件事
常常有人說要多提升自己的價值，才能在職場上有著穩固的位置，或是能夠繼續往上爬。
但是具體要怎麼實現？ 或是如何檢視自己的價值？ 有時候會讓人覺得很困惑。
這裡就提出幾個意見，跟我這幾年工作下來的一些想法。
首先，我覺得在工作職場上，一個人的價值有區分成幾個層級
不同的面向上，用不同高度的標準來評斷，也會有著不同程度的價值。
個人層面
首先在個人層面 能否在主管交付的工作上，能夠自主完成，並且還能夠完成超乎預期的成果。 是否能超越你收到的需求，真正理解這份工作背後的需求，進而完成比主管交付的還要好的成果。
團隊層面
再來是在團隊層面上 現在的很多工作或是產品，都會需要團隊合作來完成，所以如何在團隊中發揮影響力，讓這個團隊能夠發揮出最大戰力。
團隊合作，不是加法，而是乘法
很多人應該聽過這一個比喻，一個團隊的強弱，不是覺得在最強的那個人；而是最弱的那個人。
如何在團隊中，讓每個人都能夠真正發揮實力。先不用說要超乎自己的實力，但是其實很多時候如果能改善流程：不管是工作流程，或是溝通管道 省下來的時間精力，其實都能夠有效的提升單位時間內的整體團隊產出。
有時候不一定要是團隊主管，在很多時候的會議中，討論中。 如何有效的簡化一些不必要的流程/會議，或是讓每次討論完的結論都更有建設性，不要討論的半天，整體進度還是在原地踏步。
公司/商業層面
最後是在公司或是商業的層面 這部分也是最難的，但是也是最直得挑戰的。
在之前的 你在做產品還是在做專案？ 中也有提到，商業上的產品，最終還是以賺錢會核心目的。
所以如何能夠在現有的人力資源與時間的前提下，能夠達到更大的商業利益。
有時候可能會是增加更多附加價值，或是透過前一步的簡化團隊合作/溝通成本，省下來的時間，都是整體對產品有商業價值的。
所以，工作時不仿不時的反思
- 我今天自己成長了嗎？
- 我今天讓團隊成長了嗎？
- 我今天讓產品進步了嗎？
為公司創造價值，為團隊改善合作品質
不只是為了別人，最後也在提升自己的價值，建立起良好的人脈 畢竟台灣的職場，尤其是軟體開發圈子真的不大。 在同業人群中建立起良好的口碑與人脈，在未來的職涯發展上絕對是有利無害的
