本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

周委員拿著兩份維護方案來管理室，問林總幹事，地下二樓的照明既然已經查過，為什麼兩個處理方式的費用不一樣。

總幹事說明各自包含的工作和後續支援，還有幾項需要再向廠商確認。師父只補充夜班觀察到的現象和位置，沒有加入零件選型的討論。

等周委員帶走資料，我問師父：「你們美國的軟體也會這樣比嗎？有些東西明明自己寫得出來，為什麼還要每個月付錢買服務？」

會寫第一版，和能長期提供是兩件事

師父用通知功能舉例。假設客服草稿工具需要寄出工作通知，工程師可能很快就能寫出呼叫寄信介面的程式。但產品開始使用後，還要處理寄送失敗、重複通知、退信、設定錯誤和客服詢問。

我說：「這些也能自己做啊。」

師父回答，可以，接著就要估算誰做、花多久，以及做完後誰持續處理。比較自建和採購時，應該把初期開發、維護、故障處理和未來修改放在一起，才知道花出去的是哪一種成本。

他提醒，有時候所謂自建，也只是自己組合幾個外部服務，並沒有真的去掉依賴。團隊應該畫出實際使用哪些元件，知道哪些事情仍然由供應商負責。

我問：「那訂閱費是不是就能換到不用管？」

師父說，買服務仍然需要整合、設定、觀察狀態和處理客戶影響。供應商可以承擔部分工作，但我們對自己的客戶做了什麼承諾，還是要知道。

哪些能力值得自己掌握？

師父把問題拉回產品用途。如果客戶買的是協助客服理解政策、準備可用回覆，團隊要投入的核心能力就和資料理解、工作流程以及結果品質有關。對某個普通通知功能，現成服務如果足以滿足條件，可能讓有限人力先放在更重要的部分。

我追問：「所以不是核心的都買？」

師父說，還要看條件。現成方案如果無法滿足資料處理、可靠性或部署要求，就需要評估其他做法。也可能當使用量大到某個程度，自建的投入開始有合理回收機會。不能只用「核心」兩個字替代全部比較。

他也提醒，自己喜歡寫某一段，不一定表示公司應該投資那一段。反過來，難寫也不能成為永遠不掌握的理由。要問的是，這項能力會不會影響產品的差異、成本、交付或長期選擇。

我問，如果兩個創辦人意見不同，一個想省時間買，一個想省錢自己寫呢？師父說，就把各自假設列出來：預計用量、需要的人力、可接受的等待、未來最可能的變動。假設不同，算出來的選擇本來就會不同。

客戶的工程團隊其實是想要外包風險

我問師父：「那客戶的工程團隊，為什麼有時候寧願買服務，也不自己寫？」

師父說，有工程團隊寧願買服務，往往是因為這樣可以把風險轉給供應商。

自己寫雖然可能省錢，但要承擔維護、故障處理和長期演進的責任。買服務則把這些不確定性外包出去，團隊可以專注在核心能力上。

所以我們要不要接這種服務，也要看我們願意承擔多少風險，以及哪些工作是我們希望自己掌握的。

Vendor Lock-in

我又問：「買了以後，供應商漲價怎麼辦？資料搬不走，不就被綁住？」

師父回答，這也是採購成本的一部分。可以先確認資料能不能匯出、格式是否可使用、替代服務需要改哪些介面，以及切換時是否有並行或回復的辦法。

不過也不必一開始就把每家供應商都抽象成一套巨大的通用框架。如果目前只用很小的功能，把對接位置集中、保留必要資料和測試，可能就足以降低改換服務的成本。為了假想中的移轉寫太多額外系統，也會占掉產品時間。

我問師父：「那怎麼比較才不會一直討論，最後什麼都沒做？」

師父說，可以先把決策範圍縮小。挑一個代表性的工作流程，確認現成服務做不做得到、估算一段合理期間的使用成本，再和自建所需人力比較。若有關鍵未知，就安排有限的驗證，拿到資料後再決定。

如果最後選擇採購，留下當時理由和需要重看的條件。例如用量大幅增加、供應商改變服務條件，或產品開始需要原本沒有的能力。這樣未來回頭評估時，知道哪個假設變了。

維護的責任，總要有人接住

林總幹事補完一項廠商回覆，拿回來和師父確認後續來訪要怎麼登記。師父把需要日班接續的部分寫下，問清楚這次由誰帶到現場。

我說，剛才看報價，只看總額真的少了不少東西。師父回答，自建和採購也是如此。要比較核心價值、整體投入與長期依賴，會寫只是其中一個條件。

他沒有替所有團隊選同一個答案。能合理負擔、又需要自己掌握的能力，可以自建；現成服務符合條件、能讓團隊把時間用在別處，也可以採購。重要的是把維護和出問題時的工作一起算進去。