當構想很多，但資源有限
在 CMoney 資料團隊裡，我們經常會主動發想一些「能幫用戶更快做決策」的加值數據。
這些想法的價值很明確：只要數據能夠產出，用戶就能立刻看見不同。
問題是，工程資源總是有限。當產品需求一個接著一個，工程團隊的排程再怎麼壓縮，也趕不上所有的數據構想。
這讓我們面臨一個現實問題：
是不是每一個數據產品，都一定要經過完整的工程流程，才能交付給用戶？
就在這樣的討論下，有夥伴拋出了一個提議——
「既然原始資料和商業邏輯我們都有了，能不能由數據分析師直接下 SQL（結構化查詢語言），把數據組出來提供給產品使用？」簡單來說，也就是分析師跳過工程團隊，直接用指令到資料庫抓取並組合出需要的數據，先提供給用戶使用。
先跑起來，還是等最穩的版本？
當時提議一丟出來，我的第一個反應是：這樣真的可行嗎？
數據分析師能直接把 SQL 寫出來，甚至能很快拉出產品要的數據，立即解決需求。這個想法聽起來合情合理，但背後隱藏的風險就是效能以及長期的維運成本。
數據分析師的優勢在於「理解問題」與「快速驗證」，他們能把需求轉化為 SQL 查詢語法，但這樣的查詢並不一定考慮到資料表的最佳化設計，因為他們的出發點是「商業邏輯對不對、能不能跑出我要的數字」，而不是去考慮「這樣的查詢會不會拖垮資料庫效能」，更不用說有一些商業邏輯過於複雜，其實不適合用 SQL 語法組成。
如果短期內只是一兩個需求，或許沒那麼嚴重；但當需求變多，這樣的堆積下去，可能讓整個系統變慢，甚至影響到其他人取用資料。
這就像蓋房子：臨時搭建的棚子可以遮風避雨，但若要住上十年，沒有穩固的地基遲早會出問題。
於是，我陷入一個兩難：
- 快：讓分析師直接下 SQL，立刻交出成果，滿足用戶需求。
- 穩：等工程師排期，確保效能最佳、架構乾淨。
這其實不只是工程與分析的差異，而是「短期價值」和「長期穩定」之間的抉擇。
我們最後選了「對用戶最好的那條路」
最後我們選擇了「快」，因為有價值的數據，能幫用戶在當下做出更好的判斷。對用戶來說，速度比完美更重要，特別是在數據產品裡，很多價值只有在「及時」的當下才存在，過了一週、過了一個月，那份數據可能就失去了原本的意義。
但我也清楚，這樣會留下技術債，所以工程團隊並沒有完全放手，而是定期檢視數據使用狀況
- 如果某份數據需求被大量使用，就代表它的價值已被驗證，工程師會接手，把它改寫成穩定的版本。
- 如果只影響少數場景，就繼續交給分析師用 SQL 處理，維持靈活性。
這樣的做法，既讓用戶馬上得到價值，也兼顧了長期的穩定。從外界看起來，這可能像是一種妥協，但對我而言，它更像是一種「動態平衡」：既不犧牲短期用戶體驗，也不放任技術債無限累積。
先試驗、再加碼：數據產品的漸進式投入方法
這樣的決策，和我們面對市場的方法是一樣的：
不是一開始就追求完美，而是用最小成本快速測試，確認真的有價值後，再投入更多資源優化。
就像投資組合一樣，我們先讓「快速 SQL 語法產出」成為一個小額嘗試，如果真的帶來高回報（用戶大量使用），就再加碼工程資源，讓它成為穩定的基石。
這種方式其實也避免了另一種風險：把太多資源投注在錯誤的方向上。假如一開始就用完整工程架構去支持一個數據需求，卻發現最後用戶很少用，那麼這段心血就成了沉沒成本，相比之下，先用「快速試驗」過濾出真正有價值的需求，才能讓後續的工程投入發揮最大效益。
70 分的現在，還是 100 分的半年後？
很多時候，工程團隊會陷入「一定要做對、一定要做完美」的糾結，但現實是，完美往往意味著錯過時機。
當你面對一個選擇，「立即給用戶 70 分的價值」和「延遲半年才給 100 分的價值」，你會怎麼選？
我的選擇是：先交 70 分，因為這 70 分的價值是真實被用戶感受到的，而剩下的 30 分，則是隨著時間、數據使用狀況，再逐步補上。這並不是鼓勵「粗糙上線」，而是一種務實的判斷：在不確定的世界裡，比起追求零缺陷，更重要的是快速檢驗真實需求，並用有限資源做對的事。
如果你習慣先嘗試、再不斷優化，那你可能會覺得這樣的文化很自在。
但如果你更重視一次到位、萬無一失，這裡可能不是你最舒服的地方。
