客製化需求為什麼更貴？用交集、聯集與差集估算研發成本

一句話結論：客製化需求越多，真正昂貴的通常不是機器，而是分析、溝通、開發、測試與維護的人力時間；能產品化共用，成本才有機會被多人分攤。

交集、聯集與差集能解決什麼？

我曾遇到客戶希望從既有資料條件中做更細的篩選，例如先找出對特定品牌有興趣的人，再排除賣家、新手或低評價帳號。這在數學上就是交集、聯集與差集：先定義每一個集合，再組合成真正需要的範圍。

這些例子只用來說明條件邏輯。實際處理個人或平台資料，必須先確認來源、授權、使用目的與保存方式符合法律及平台規範。

為什麼需求越精準，不一定越省錢？

結果筆數變少，不代表成本跟著變少。每增加一個排除或交叉條件，都要重新釐清定義、資料品質、例外、測試與更新方式。真正被消耗的是專業人員的時間。

客製開發成本包含哪些部分？

• 理解業務目標與資料欄位。
• 確認每個條件的定義與衝突。
• 撰寫程式、測試邊界與錯誤處理。
• 建立權限、紀錄、備份與回復方式。
• 資料或規則改變後的持續維護。

產品化如何降低單一客戶成本？

如果相同功能能讓多位客戶使用，研發費可以分攤；若只有一位客戶需要，這位客戶就必須承擔大部分開發與維護成本。這也是我評估需求時，會先問能不能標準化的原因。

正式討論前先寫需求單

1. 要做的決策是什麼，而不是先指定功能。
2. 資料從哪裡來，是否有權使用。
3. 必要條件與可放棄條件分開。
4. 錯誤結果會造成什麼損失。
5. 一次性分析或需要長期更新。
6. 預算、時程與驗收標準。

我會拒絕哪些客製需求？

資料權利不清、目的可能傷害他人、無法安全保存，或要求的精準度遠高於資料本身品質時，我不會因為技術上做得到就接。能做、值得做與應該做，是三個不同判斷。

案例與資料來源

更新紀錄

2021-08-28：首次發布，記錄當時的個人經驗、案例與判斷。

2026-09-04：補充集合條件、產品化、成本與資料使用邊界。