我曾經做過一個「加購功能」，最後成為公司的資源黑洞。

不是技術有多難，而是我們從一開始就沒搞清楚這個坑有多大。

▌ 故事的起點：我們想切路跑市場

那時我還在當 PM，公司想要切入路跑活動市場。

路跑在台灣是大生意，每場動輒幾千人報名，報名費加上周邊商品，金流規模很可觀。

我們覺得這塊餅很大！當時很天真的覺得只要讓報名人在報名時能「加購商品」，應該就能滿足主辦的需求了吧。

這聽起來真的很單純——使用者買票的時候，順便加購一件路跑紀念衫、限量紀念品，商品和票還輯很像，應該沒毛病才對！

當時剛好業務有接洽到一個路跑公司，我們內部評估後，覺得這個功能應該不難，市場又有需求，不做做看，也沒機會切進去，二話不說就接了。

▌ 然後，潘朵拉的盒子就被打開了

說來慚愧，我們把「加購」想得太簡單了。

一開始確實只是「讓使用者在買票時多選一件商品」，技術上不複雜。

但需求這東西，就像俄羅斯娃娃，你以為打開一個就結束了，結果裡面還有一個，再打開，還有一個，層層疊疊環環相扣。

第一層：路跑活動有基本報名就能拿的衣服，那件衣服要選尺寸。好，加個尺寸欄位。>> 這邊還算合情合理，沒問題。

第二層：每個尺寸有數量上限。S 號只有 200 件、M 號 300 件、L 號 150 件。這表示我們要做即時庫存管理，搶購時還要鎖庫存，防止超賣。>> 這邊開始有點辛苦了。

第三層：要開實體紙本發票，不是電子發票，事前要寄送，現場也要拿給報名人。（當年大多平台沒串電子發票，而且報名大多蒐集手機號號碼不是 mail ，又有團報的隊伍，發票開立方式蠻複雜的。）>>不是吧？這根本要走到活動現場跟活動公司一起了

第四層：參加人要能隨時回到系統查詢和修改訂單。改尺寸、改數量、改收件資訊。這代表整個訂單管理系統要重新設計，不能只是單向一次性的結帳流程。>> 來唷，資料庫結構改起來。

第五層：也是最要命的一層：退票的時候，票券和商品的退款規則不一樣。票可能活動前 7 天退全額，但 IP 周邊只要下訂就不能退，同一張訂單裡，兩種東西的取消邏輯完全不同。>> 購物和退票的流程要整個大改寫。

每打開一層，開發團隊的臉就更綠一點。

▌ 不怪客戶，只能怪自己

說坦白的，我不覺得這是客戶的問題。

路跑活動的營運流程本來就是長成這樣，尺寸、庫存、發票、退款，每一個需求都是標配。

對這些路跑主辦單位來說，這些根本不是什麼特殊需求，他們會認為這些都是「基本常識」，在需求會議時，並不會特別提出來，因為既有的路跑平台，每個都做得到，他們怎麼也無法想像，我們居然每個都辦不到。

「真正的問題是我們自己功課沒做夠。」

我們在決定切入這個市場之前，根本沒有做好市場調查。沒有找路跑主辦單位深度訪談，沒有拆解他們完整的營運流程，沒有盤點每一個環節對系統的要求。

我們只看到「路跑報名 = 大量票券銷售 = 賺錢」，有人剛好提了桶水上門，我們也沒想太多，就把頭洗下去了。

老實說，就是對方說什麼我們都照單全收，因為太怕錯過這次，再也接不到下一單，整個心態 FOMO 起來，理智線就先收起來了。

▌路跑功能成績單

功能做完後，最後的結果？

功能上線後，因為功能不夠完整，無法支援各種情境 印象中應該是只接了不到 10 場路跑活動。

投入的開發資源——工程師的工時、PM 的協調成本、QA 的測試時間、客服處理——這些投入都完全無法回收。

更慘的是，這個功能做完之後，幾乎沒有其他類型的活動用得上。路跑活動的營運邏輯太複雜了，在其他的活動場景中根本不適用。 .

等於我們花了大把資源，做了一個只有不到 10 個客戶用過的功能，更不用說因為被壓縮工時，所以也留了不少的技術債下來，但最後卻任由它就躺在那裡生灰塵而已。

註：都是七八年前的事了，現在系統狀況如何我不確定，或許更完整了也說不定

✄———✄———✄———✄———✄

▌ 覆盤：客製化不該只是客製化

這件事過了好幾年，我偶爾還是會想起來。

不是因為虧錢——在公司營運的尺度上，那筆開發成本不會造成致命的危機，讓我一直放不下的是，我們犯的是低級錯誤。

當時我們認為「客製化」就是「客戶要什麼我們就做什麼」。

但客製化不該是這樣的，如果今天有一個客戶帶著很特殊的需求來找你，你該問的第一個問題不是「這個功能做不做得出來」，而是：「這個需求，有沒有機會變成我們的第二曲線？」

第二曲線的意思是——這個需求除了眼前這個客戶，還有更大的市場在後面等著。這個功能能從「幫一個客戶解決問題」變成「幫一整個產業解決問題」？

如果答案是有，那它才值得投資。正確的流程是要做詳細的市調和訪談，先驗證需求是真實的、市場是存在的，再決定要不要投入完整的開發資源。

如果答案是沒有——這個需求就是非常特定、非常局限、只有少數客戶會用到——那不管客戶出多少錢，你都該認真考慮拒絕。

因為開發資源是有限的，每一行程式碼都有機會成本。你把工程師的時間投入到這朵花上，就等於放棄了外面的整片森林。

▌ 怎麼判斷一個需求值不值得客製化？

其實很多成長期的公司都會遇到類似的誘惑——有個大客戶揮著鈔票跟業務說「你幫我做這個功能，我就跟你簽約」。

那個瞬間，大多數業務，只會想到這個案子可以是下個月的業績獎金，很少業務會冷靜下來思考：「這個功能做完之後，會帶我們走向哪裡？」

大部分的人，包括當年的我，都是先想「太好了，有錢進來」。但錢進來之後，如果那個功能沒有帶公司走向更大的市場，它就不是一門好生意，只是一時腦充血的錯誤投資。

不知道各位 PM 或 BD，過去有沒有接過什麼不該接的需求？ 或是你會怎麼判斷一個客製化需求值不值得做？

如果你也有類似不願回想起的經驗，很想聽聽你的故事。

喜歡我的文章，歡迎追蹤我的 LinkedIn 或訂閱我的 Substack