軟體外包還是自建團隊：兩種模式的真實成本與決策檢查表
「是不是該自己請工程師？」這個問題通常在兩種時刻出現：一是外包專案結束後，發現每次小改動都要等廠商排程；二是公司開始有第二個、第三個數位需求，覺得長期算下來自己養比較划算。
這個決定不該只比「月薪 vs 專案報價」，因為兩邊帳面上看到的數字，都不是真實成本。
兩種模式的真實成本構成
自建團隊：薪資只是其中一項
把一位工程師的月薪乘以十二，那只是起點。實際上還要加上：
- 招募成本：職缺曝光、面試所耗費的主管時間、獵才服務費用；以及最容易被忽略的——職缺空著的期間，需求全部卡住。
- 管理成本：誰來決定做什麼、誰來審查程式碼品質、誰來處理技術決策的爭議。如果團隊裡沒有資深的人，這些工作會落到你身上，而你未必有能力判斷。
- 設備與工具：開發機、雲端環境、程式碼託管、設計工具、監控服務，多半是按人頭計的訂閱制。
- 知識集中在少數人身上的風險：一人團隊的離職，等於整個系統的知識歸零。
- 技能覆蓋的缺口：一個完整的產品需要前端、後端、設計、測試、部署等不同技能。小型團隊很難每一項都有人，缺的部分最後還是要外求。
外包：報價之外的隱藏成本
- 溝通成本：需求要寫清楚、要開會確認、要驗收。這些時間會落在你或你的同事身上，是真實的人力投入。
- 需求釐清能力的落差：如果你方無法把需求說清楚，來回修改的成本會反映在追加報價或時程延誤上。
- 交接與知識移轉：專案結束時，知識是否真的留在你公司，取決於文件品質與交付完整度。
- 回應速度不由你決定：緊急狀況時，你排在廠商的隊伍裡，除非合約另有約定服務時間。
- 更換廠商的成本：如果沒有拿到完整原始碼與文件，換人接手的代價會很高。
各自適合什麼階段
| 情境 | 比較適合 | 原因 |
|---|---|---|
| 還在驗證想法、第一版產品 | 外包 | 需求還會變，不該先背固定人事成本 |
| 專案型、有明確起訖點 | 外包 | 做完就結束，不需要常態人力 |
| 需要特定專業（設計、資安、雲端架構） | 外包 | 全職養這類人才的成本高、用量低 |
| 產品已被市場驗證、要持續迭代 | 自建 | 迭代速度與累積的產品知識變成核心競爭力 |
| 系統是公司的核心競爭力 | 自建 | 不宜把最關鍵的知識放在外部 |
| 資料高度敏感、法遵要求嚴格 | 自建或嚴格約束的外包 | 存取控制與責任歸屬 |
| 需求零碎但持續（每週都有小調整） | 自建或長期維護約 | 專案制不適合處理零碎需求 |
一個簡單的判準：這件事是不是「一次做完」？ 是，傾向外包；不是，而且會持續長出新需求，就要認真考慮自建或長期合作關係。
另一個判準：這套系統壞掉的時候，公司會不會停擺？ 會，那麼「能立刻找到人處理」的能力就必須在內部或明確的服務合約裡。
常被忽略的第三個選項：混合模式
實務上最適合多數中小企業與早期新創的，往往不是純粹的外包或自建，而是兩者的組合。
外部技術顧問 ＋ 小型內部團隊
由外部顧問承擔「技術決策與品質把關」的角色——技術選型、架構審查、廠商評估、驗收標準、招募時的技術面試；內部則保留一到兩位負責日常維運與小幅迭代的人力。
這個組合解決的是一個常見困境：公司需要高階技術判斷力，但用不到一個全職技術長；而只招募資淺工程師又沒有人能帶。NETVANA 的軟體顧問服務包含技術架構審查、技術選型與供應商評估、CTO-as-a-Service（兼任技術長，也就是不用全職聘僱的外部技術主管），以及工程團隊組建建議，內容見軟體服務介紹。
專案外包 ＋ 內部產品負責人
開發交給外部團隊，但公司內部一定要有一個人真正負責「決定做什麼」。這個人不需要會寫程式，但必須熟悉業務、有決策權、願意投入時間。缺了這個角色的外包專案，失敗率明顯偏高——因為沒有人能拍板，需求會一直飄。
先外包、再內化
第一版由外部團隊做出來並驗證市場，同時在合約中要求完整的文件與知識移轉；產品站穩後再逐步把維護與迭代接回內部。這條路徑的關鍵在於第一天就把「未來要接手」寫進合約，而不是等到要接手時才發現接不了。
決策檢查表
在做決定前，逐題回答下面這些問題。答案偏向哪一邊很清楚：
關於需求本身
- 這個需求有明確的結束點嗎？還是會持續長出新功能？
- 未來一年可預期的工作量，夠不夠餵飽一位全職工程師？
- 需求規格現在寫得出來嗎？還是要邊做邊想？
關於公司現況
- 公司裡有沒有人能判斷技術方案是否合理？
- 有沒有人能負責「決定做什麼」並且說了算？
- 現金流狀況比較適合一次性支出，還是固定的月度人事成本？
關於風險
- 這套系統停擺一天，業務損失有多大？
- 資料敏感度如何？有沒有法規要求？
- 如果負責的人明天離職，還有誰知道怎麼運作？
關於長期
- 這套系統是公司的核心競爭力，還是支援性的工具？
- 三年後，我希望這個能力在公司內部，還是留在供應商那裡？
如果多數答案指向「持續、核心、高風險」，往自建或長期深度合作靠；如果多數答案指向「一次性、支援性、需求明確」，外包通常更有效率。
不管選哪一邊，都要做好的幾件事
把需求寫下來。 不論交給誰，模糊的需求都會變成昂貴的返工。
確保知識不集中在單一個人或單一廠商。 文件、原始碼、帳號權限要在公司手上。
建立驗收標準。 「看起來可以用」不是驗收標準。功能清單、測試情境、效能與相容性要求，應該事先講好。
保留切換的可能。 不論是員工離職還是更換廠商，都應該有一條成本可接受的路。這一點主要靠合約條款與交付完整度來保障，細節見如何挑選軟體開發公司。
用可預測的節奏推進。 固定的進度節點與可實際操作的階段性成果，比「做完再看」更能及早發現偏差。NETVANA 採用的階段性交付與固定 Demo 節點，可以參考軟體開發流程。
常見的誤判
「自己養比較便宜」：只比薪資與報價時成立，把招募、管理、工具、空窗風險算進去後往往不成立，尤其在需求量不穩定的階段。
「外包比較不用管」：外包不會減少「決定做什麼」的工作，只會減少「怎麼做」的工作。前者仍然是你的責任。
「先請一個工程師，之後再擴編」：一人團隊沒有人可以互相審查，也沒有人可以在他請假時接手。如果一定要從一個人開始，搭配外部的技術審查會安全得多。
「等有錢再補文件」：文件與交接機制是在開發過程中順手產出的，事後補寫的成本高、品質差，而且通常永遠不會補。
「外包的人不懂我們的產業」：這確實是外包的先天限制，但可以用流程補。作法是把產業知識寫下來——你的客戶是誰、一筆生意怎麼跑、有哪些例外狀況與行規，並在專案初期安排讓開發團隊實際看一次真實作業流程。願意花時間理解你的業務的廠商，通常也是比較值得長期合作的廠商；反過來，如果對方從頭到尾只問「要做哪些功能」而不問「你們平常怎麼做事」，那才是真的風險。
「先做大一點比較省」：需求尚未驗證時把範圍做大，是最貴的選擇。第一版該怎麼縮，見MVP 最小可行產品開發指南；不同專案類型的成本結構，見App 開發費用完整指南。
外包與自建不是對立的兩條路，而是一個光譜。多數公司真正需要的，是在對的階段用對的組合——早期借助外部速度與經驗，把驗證過的核心逐步內化。
如果你正在評估該外包、自建，還是採用顧問搭配小團隊的混合模式，與 NETVANA 討論你的狀況。技術顧問的立場是中立的，我們會先看你的實際需求量與風險結構，再給建議。
延伸閱讀：外包前先看如何挑選軟體開發公司；估預算可參考網站製作費用怎麼算與App 開發費用完整指南；還不需要全職技術長時，兼任是折衷的解法，可以看兼任技術長服務指南；接手舊系統的難度，常是這個決策的變數，可以看舊系統現代化指南；外包交付的程式碼裡混了什麼授權，你得知道，可以看開源授權白話指南；決定自建團隊之前，先看買現成方案是否更划算，可以看買現成 SaaS 還是客製開發；ERP 導入該外包還是自建，先看這篇的成本比較，可以看中小企業 ERP 導入指南；選外包還是自建前，先想清楚原始碼會歸誰，可以看原始碼歸屬與專案交接指南。
