今天團隊在聊技術人員的商業思維。
傳統的分工中，junior engineer 是手腳，將常被賦予的責任就是按著規格把功能實作出來，而當你接受這樣的定位時，你確實不需要什麼商業思維，因為事情都是別人決定好的，你甚至連老闆跟業務團隊的需求是甚麼都不用懂，你只要能看懂規格，然後把程式實作出來就好了。
但如果你不滿足於擔任手腳角色，希望自己能更有價值，更知道自己到底為何而戰，那你得漸漸往動腦袋的角色走，最少要能理解需求，要能開始擔任設計的角色。這也是跨入 senior engineer 的方法之一，另一個方法則是你在技術上邁向卓越，程式寫得比別人快，效能更好，bug 更少，程式架構更易於維護。
而 senior engineer 很多時候會擔任制定技術規範、帶領新人、跨部門溝通，有時還會擔任 PM 或者是窗口的角色，除了技術能力外，你會有更多需要與他人協作或領導的時候。
過往，我看過許多 senior engineer 就掛在這邊。繼續扎深技術本來就是必要的，但就算是工程師，你單靠自己一個人，產出還是很有限的。你得學習領導他人，你得學會帶 team，你得更好的與他人合作，而要做到這些，你得聽懂別人的語言，你也得學習技術之外的其他能力。
而隨著角色更往上走，有些人會開始擔任 architect 角色，開始負責架構規劃與設計。好的架構設計，要素很多，而這些要素的背後，其實都有滿滿的商業道理在。
以前曾有工程師問我：「為什麼不一步到位把架構做好，而要用重構的方式來進行，這不是多此一舉嗎？」
因為公司沒有那樣的資源停下來等新的架構做好後才繼續推進商業策略，我們必須要一邊在商業上推進，一邊完善我們的架構，這不是二擇一的問題，而是如何兼顧的問題。
我曾看過一位 architect 提案了一個完全忽略現實的架構，軟硬體規格是最高階的，團隊也要最好的，時程一拉就拉兩年。而當我們問他原因以及規劃背後的思路時，他的說法很微妙，他說這樣比較不會有問題。
我們請他解釋他對商業計畫的理解，他腦袋裡思考的是技術規格，沒有商業面的 insight，也沒有考量任何財務、成本上的議題。但他覺得老闆應該信任他的專業，讓這個提案過關，因為從技術層面思考，這些都是必要的。
確實，從技術層面思考，很多問題都會有最佳解。但商業問題一直都不是單純的技術問題，而是涉及較複雜的資源分配問題。而技術是用來解決商業問題的，所有的技術決策，都應該考量商業目標才行。
我花了一些時間跟他討論提案的問題。我問他：「我們的技術規格需要一開始就用最高規的嗎？前期市場驗證階段，用戶數量不多，服務 500 位，5,000 位 user 的規格大概長怎樣？必要的錢可以花，但你得清楚交代『必要性』才行。」
「一樣的邏輯，你要把全公司最強的工程師都找來，那其他產品線怎麼辦？你把現在產品線最有生產力的人都拉走，那你這專案創造的價值一定得比他在原先的位置上更高，不然誰會同意？你說得出對你這個專案有利的提議，但卻說不出這個提案對公司的有利之處，基本上沒人會同意啊。」
架構設計之所以困難，就是因為它除了考驗 architect 的技術能力外，還考驗他的商業思維。
你有圍繞著商業目標與計劃去展開你的架構與計畫嗎？
你的架構具有隨需求而敏捷更迭的擴充性與彈性嗎？
你評估過的解決方案裡面，目前的設計是 CP 值較好的方案嗎？
你做規畫時，有考量產業特性、客戶對象與商業模式嗎？
你掌握了多少非功能性(non-functional)需求？
目標、價值、效益，這些是所有職務往高階邁進時無法迴避的，因為若你想要跟其他人溝通，那你得理解他們在意些什麼，而為了創造更高的價值，你一樣得明白，什麼才是對組織最有價值的事情。
而這些，就是商業思維。
技術人員必須理解商業，而愈高階的技術工作者，則要把商業思維當成一項核心能力。
商業，其實是一堂所有人的必修課。
