09/04/2026
【一個案子，多花了 30 萬】
他多花了 30 萬
不是因為工程師不會做
而是從一開始，溝通就失控了
這是一個我輾轉聽來的案子
一個電商老闆
找了一間接案公司做系統
他只講了一句話：
「我要一個會員點數系統，可以讓用戶累積點數，然後可以折抵消費。」
對方說可以
工程師也說沒問題
報價合理
直接開工
兩個月後
開始測試
問題一個一個出來
為什麼沒有會員等級？
為什麼沒有推薦分潤？
商品不能有不同點數倍率？
工程師回一句：
「這些一開始沒有講清楚」
他回去翻紀錄
真的只講了一句話：
「會員點數可以折抵消費」
但他腦中想的是：
點數累積規則
會員等級
推薦分潤
商品倍率
他沒有講
但他以為這些是理所當然
最後
多花了 30 萬
溝通，是整個專案最貴的成本
而且是最不可控的成本
它有一個特性
一開始幾乎看不到
後面會被放大
大部分人會以為
多講一點就會更清楚
但實際上
很多時候只是讓偏差被放大
為什麼一定會失真
流程通常是這樣：
客戶 → 業務 → PM → 工程師
每一層都在做兩件事：
1.把資訊壓縮
2.用自己的理解再講一次
最後工程師拿到的
不是原始需求
而是被改寫過的版本
所以你會看到一個很常見的結果
看起來合理
但用起來不對
那是不是直接找工程師就好
很多人會這樣想
少一層，就少一層失真
但實際上，常常更糟
因為工程師擅長的是
把「規則」做對
但你給他的
通常是「模糊的目標」
例如
點數系統
但問題通常不是出在「功能不完整」
而是出在「邏輯沒有對齊商業」
例如一個實際會發生的情境
一個電商老闆想做點數
他的想法很單純：
「讓客戶多買一點」
工程師照這個需求設計系統：
每消費 100 元 = 1 點
1 點可以折 1 元
點數可以累積
不足的部分可以先扣（變負數）
從系統設計來看
完全合理
甚至還很「彈性」
客戶可以先用點數
再慢慢補回來
但實際上線後發生什麼事？
第一個問題
有些用戶看到「負點數」
會產生一種感覺：
👉「我欠這個平台錢」
結果是
👉 使用壓力上升
👉 部分用戶直接不再使用
第二個問題
👉 點數可以折抵
但折抵機制沒有設計門檻
結果變成
👉 用戶習慣等有點數再買
👉 或只在有優惠時下單
👉 原本想提升回購
反而變成
👉 降低原價轉換
第三個問題
👉 點數累積規則太簡單
結果是
👉 高價商品給太多點
👉 利潤被吃掉
👉 但低價商品誘因又不夠
整個系統變成
👉 邏輯正確
👉 但策略錯誤
這時候你會發現一件事
👉 工程師沒有做錯
但中間缺了一件事
👉 沒有人問
👉「這個機制，會怎麼影響用戶行為？」
👉「會不會影響毛利？」
👉「你的目標到底是回購，還是利潤？」
所以最後會變成
👉 系統可以用
👉 功能是完整的
👉 但整體結果是錯的
這種錯最麻煩的地方在於
👉 不是 bug
👉 不是壞掉
👉 而是「看起來正常，但實際在傷你生意」
工程師沒有做錯
但那不一定是你要的版本
問題真正卡住的地方
不是寫程式
是問題被怎麼理解
比如我要會員點數
這句話，理想上應該要被兩種人處理
第一種人
會把會員點數定義到很細
他會問
點數怎麼來
有沒有等級
商品倍率
推薦機制
邊界條件
你會覺得很麻煩
但他在做的
是把未來會出錯的地方拆掉
第二種人
不會從會員點數開始
他會問
你為什麼需要這個
是要提升回購
還是提升客單
還是增加黏著
甚至會直接告訴你
這個做法不一定是對的
他在做的
是修正方向
這兩種人
都不便宜
因為他們在做的
不是執行
一個在降低錯誤
一個在避免做錯
而大部分專案缺的
就是這一層
最後一句話
代工，可以做出你說的功能
工程師，可以做出他理解的版本
但
系統可以做對
但那是工程師的對
不一定是你的對
甚至更常見的是
看起來是你的對
但沒有達成你要的效果
功能是對的
邏輯是對的
但結果是錯的
因為
中間沒有人把問題定義對
所以你做的每一件事
都只是把偏差放大
很多系統最後都能用
但沒有用
30 分鐘把問題講清楚
30 萬在後面修正
差別不在技術
在一開始
有沒有人真的在解問題
