2022 年 10 月，軟體開發公司 37signals 共同創辦人與技術長 David Heinemeier Hansson（以下簡稱 DHH）在他的網站上發表一篇引起科技圈熱烈討論的文章〈我們為何搬離雲端〉（Why we’re leaving the cloud）。在文章中，他分享自己從 37signals 經營的經驗所得出，將服務部署在雲端的優缺點；以及在使用十多年的 AWS 和 GCP 等雲端服務之後，為何最終決定要把服務陸續搬離雲端，重新部署在公司自家伺服器的背後因素。不僅如此，37signals 還在網站上定期更新他們搬離雲端的進度，以及相關的成本計算，例如他就公布 37signals 在 2022 年的雲端費用高達 320 萬美元！（約新台幣 1.03 億元）
從上述案例中，可以看到工程師在公司貢獻商業價值的方式，不只有把程式寫好而已，像 DHH 這樣的技術大神除了擁有深厚的程式能力之外，也懂得綜合不同的因素來思考公司決策。想必許多工程師在職涯中也多少面臨過以下情形：明明依照同事的需求提供最理想的技術方案，卻因為技術以外的考量被否決。如果工程師能夠學習將程式以外的思維加入工作流程，對於未來的職涯成長會有很大的助益。
技術選擇中的商業價值
影響一間公司商業價值的層面非常多元，包含產品發想、軟體開發、定價策略、行銷方案等等。而身為在第一線開發軟硬體的工程師，除了顯而易見的開發新功能與維護服務穩定等工作之外，最直接與工程師有關的，就是像 DHH 這樣，針對公司服務所做出的各種「技術選擇」（technical decision）：前後端要使用哪一種語言？是團隊比較熟悉的？效能較好的？開發者社群較活躍的？還是有較多套件支援的；或者像 37signals 的問題一樣，服務要部署在雲端還是自建伺服器？如果選擇雲端的話，又要選哪一間？
面對無窮多的技術選擇問題，身為工程師可以怎麼做出決定？或許商業思維會是個很好的切入點。
根據工程師成長社群 LeadDev 的〈為什麼商業脈絡對技術選擇很重要〉所指出，許多人會認為世上存在「絕對最好的」技術選擇，但其實都得依照實際情況而定，而且往往受到商業模式和團隊組成等脈絡影響。
像是 DHH 就有提到，他認為適合在雲端部署的服務就剛好位於兩個極端的光譜：一個是流量穩定，功能單純的服務，或者是還沒有穩定顧客的新創，放到雲端就可以省去許多麻煩事；另一種則是負載暴起暴落，雲端運作空間的租借彈性在這種情況下就提供很大助益。
從商業思維出發，做出最好的技術選擇
即便是同一間公司，在不同的公司階段，都會有不同的最佳技術選擇結果。其中最著名的案例之一，就是社群媒體 X（以前的 Twitter）的搜尋團隊，1在 2010 年的春天，為了因應使用量的成長、降低延遲以及加快新搜尋功能的開發，他們決定換掉原先使用的 Ruby on Rails 與 MySQL。這樣的調整不只讓延遲減少了三倍，也讓前端伺服器 CPU 的使用量減少一半。這麼一來，同樣的伺服器就能處理多十倍的服務請求。
像這樣技術選擇會需要因時因地制宜的狀況，也可以在工程師的職涯看到。隨著工程師的資歷越來越深，對產品開發的涉入程度越多，就越常發現到技術選擇不是光評估工程端的條件優劣，而且是必須權衡各單位的需求之後，所做出的綜合選擇。
SaaS 服務管理平台 BetterCloud 在《2021 年 SaaS 營運報告現況》中表示，根據他們針對 523 位資訊部門或資安專業人士的調查發現，有高達 76% 的人認為，資訊部門在公司內部的角色，變得越來越具策略價值，不只是被動等待指令，而是主動參與商業決策的環節。
成本與效益：從技術選擇發展商業思維的兩個出發點
但要如何開始從技術選擇的環節納入商業思維呢？在〈為什麼商業脈絡對技術選擇很重要〉中，在 Mento 擔任技術總監的 Kevin Ball 建議你可以先關注兩個權衡點：成本與效益（costs & benefits）。
文中 Ball 就以自動化測試為例：公司是否需要有嚴格的自動化測試流程，以確保在產品推出前就找到所有潛在的 bug？純就技術的成本考量，要擁有自動化測試的流程，就需要有更多的人力來維護相關的程式碼與功能。此外，有沒有明確的紀錄機制，可以快速找出並修復 bug。
從商業的成本考量，則可以思考若上市產品裡面有 bug，對於營運的影響：如果是社交平台的服務，出現一點小 bug，顧客可能只會覺得略表不滿，導致客服的負荷增高；但若是醫療相關服務，一個小 bug 可能就是影響生死的問題。
另外，回到文章開頭的案例，2023 年 9 月，DHH 就發表文章更新，他們在開始搬離雲端之後，已經省下一年約 100 萬美元（約新台幣 3,200 萬元），而且這還是他們還沒完全搬離雲端的前提下。根據 DHH 推估，在完全搬離雲端之後，公司每年可以省下約 200 萬美元的雲端伺服器費用。就算扣掉約 60 萬美元購買器材的前置成本，仍是相當划算的公司營運策略。而且營運工程師的人數也沒有因此增加。
不只是減少成本而已
當然技術選擇不只有減少開發與營運成本而已，也需要同步考量技術選擇在產品開發流程所帶來的效益。譬如在技術面，自動化測試除了能夠減少 bug 之外，也能協助程式碼的後續重構或維護。另外，像是程式語言的選擇，也當然會影響到重構的容易程度：強型別的語言（如 Java）或有支援擴充的語言（如 C#）就會比弱型別的語言（如 JavaScript）來得容易。
但是從商業上的效益來看，則可以考量產品迭代的頻率有多快。若是在人手有限的新創公司，可能沒幾個禮拜就會推出新的功能，這個時候工程師的工作重心，就會是程式語言的靈活與否，以及能否在短時間內推出最小可行性產品（minimal viable product，MVP），而不是這段程式碼是否方便後續維護和重構。
或者像是 DHH 所提到，如果預期公司的產品有可能會面臨負載暴起暴落的話，那麼能夠快速、短期加開伺服器的雲端運算服務，與自家主機相比可能就會是更好的選擇。此外，選擇公司所使用的開發者工具、資安服務，以及各式各樣的 SaaS，除了服務費用的成本之外，也必須考量它們與目前工作流程的契合程度、上手使用的難易程度，或者是後續客服支援能力等細節。
除了從公司本身的條件進行成本與效益的考量之外，若想要知道像是 Facebook、Uber、Airbnb 等公司所使用的技術，也可以參考像是 Stackshare這樣的網站，上面有由社群所彙整出的各家公司技術清單。也可以使用 Builtwith這樣的搜尋工具，查看特定網頁使用的技術為何。
選擇技術的同時，也是在選人才
擁有十餘年程式開發經驗的 Snipcart 共同創辦人 Charles Ouellet 也建議，在進行技術選擇時，可以優先考量熟悉度、社群、可擴展性與招募人才。其中對工程師而言，如何面試人才，可能是很陌生的環節：要如何與公司內負責管理人力資產的同事攜手合作，從前來面試的候選人中找到適合團隊的生力軍？
Ouellet 認為，技術選擇對於人才招募可說是把雙面刃：選擇比較「傳統」的技術，你容易找到更多擁有豐富的工程師；但是如果選擇新潮的技術，就有機會吸引到很有才華的天才工程師。除此之外，更為「傳統」的技術，因為使用的人口眾多，自然也就更容易擴充團隊大小。
技術選擇：不只向內檢視，也要向外提問
最後，除了上面提到從「成本」和「效益」的角度來思考技術選擇之外，Ball 還會建議可以從「問問題」開始，讓你更清楚在進行技術選擇時，可以如何也把商業思維納入考量的一環。譬如當別的部門提出技術的需求，或者是針對你的技術提案提出調整建議時，透過提問就能釐清他們在提出這些需求與調整所在乎的點。或者試著向主管提問，在理解部門策略與公司目標之後，就能用更高的層級，來審視目前項目所面臨的技術選擇，如何能為公司貢獻更大的商業價值。
在工程師的成長之路上，需要顧及的面向也會越來越多元與複雜，而技術選擇只是其中最顯而易見的一環，也（可能）是身為工程師最能夠控制、貢獻的一環。而技術選擇也會是將商業思維納入工作流程的一個很好切入點。就像是 Ouellet 所說：「技術選擇不只與技術有關——而是大部分都與商業有關。」（Technical decision-making isn’t just about technologies—it’s mostly about the business.）
