如何挑選軟體開發公司：該問的問題、合約條款與紅旗訊號
挑軟體開發公司最常見的失敗，不是挑到技術不好的廠商，而是雙方對「要做什麼」的理解從一開始就不一樣，直到驗收時才發現。
價格只是其中一個變數，而且往往是最不重要的那個。以下把評估流程拆成四件事：怎麼問、怎麼看、合約怎麼讀、以及哪些訊號該直接走人。
開始找廠商之前，先準備好三份東西
你能給出的資訊越明確，收到的回覆就越有比較價值。至少準備：
一、需求清單。 不必寫成規格書，但要能回答：使用者是誰、他要完成什麼事、哪些功能沒有就不能上線、哪些可以之後再說。
二、現況與限制。 現有的網站或系統、要串接的服務、資料量、預期使用規模、有沒有硬性的上線時間。
三、預算區間與決策方式。 不必透露上限，但要說明大致量級與誰有決策權。刻意隱瞞預算的結果，通常是收到一堆無法比較的提案。
如果你連需求清單都寫不出來，那第一步該找的其實不是開發廠商，而是能幫你把需求整理清楚的人——這也是技術顧問服務的常見用途，相關取捨見軟體外包 vs 自建團隊。
評估廠商時該問的問題
1. 這個專案會由誰做？
很多時候提案的人和實際執行的人不是同一批。該問清楚：專案經理是誰、開發人員有幾位、是否有外包再外包的情況、主要聯絡窗口是誰。
2. 你們的流程長什麼樣子？
好的回答會包含明確的階段、每階段的產出物、以及你需要參與的節點。含糊地說「我們很有彈性」通常代表沒有流程。可以對照 NETVANA 公開的軟體開發流程，看看對方能不能把自己的流程講得同樣具體。
3. 我什麼時候能看到可以操作的東西？
「開發完再給你看」是高風險的安排。合理的作法是分階段交付，過程中就能看到可實際點擊操作的版本。愈早看到，愈早能修正方向。
4. 需求變更怎麼處理？
專案中途需求會變，這是常態。重點是有沒有明確的處理機制：變更如何提出、如何評估影響、如何計價、誰批准。沒有機制的專案，最後多半以爭執收場。
5. 上線後呢？
保固期多長、涵蓋哪些狀況、緊急問題的回應時間、之後的維護方案怎麼計費。這部分常常在簽約時被跳過，卻是長期關係的關鍵。
6. 如果我們日後要自己接手或換人，會拿到什麼？
問這題時觀察對方的反應。坦然列出交付清單的廠商，和顧左右而言他的廠商，差別很明顯。
看作品：該看的不是畫面漂不漂亮
作品集當然要看，但多數人看錯地方。
畫面之外，問這幾件事：這個專案當初要解決什麼問題？做了多久？中途遇到什麼困難？上線後有沒有持續合作？能回答得具體的，通常是真的參與過。
留意展示方式的誠實度。 有些作品是完整承接，有些只是參與其中一部分，有些是「這類專案的做法示範」。這幾種都合理，但應該講清楚是哪一種。NETVANA 的軟體作品集呈現的是各類專案的做法說明，而非特定客戶的實績展示，這種標示方式本身就是一種資訊揭露。
技術面的合理提問：這個網站在手機上打開順不順？點進去後載入要多久？如果你打算重視搜尋流量，可以直接檢查網頁標題與描述是否完整——這些是基本品質，不是加值服務。
問流程的痕跡。 有沒有設計稿？有沒有測試紀錄？有沒有交付文件的範例（可去識別化）？這些比精美的作品圖更能反映實際的工作方式。
合約裡一定要看清楚的條款
以下僅為一般性原則的整理，實際簽約前建議請律師針對條文逐項確認。
一、原始碼與智慧財產權歸屬。 要寫清楚款項結清後，原始碼、設計檔、文件的權利歸屬，以及廠商是否保留重複使用的權利。特別留意「授權使用」與「權利移轉」在法律效果上並不相同。
二、交付物清單。 具體列出會交付什麼：原始碼、設計檔、部署與環境設定文件、帳號與權限、教育訓練。沒有列出來的，日後就沒有依據可以要求。
三、驗收標準與流程。 什麼情況算完成、驗收期多長、逾期未回覆視同驗收與否、驗收發現問題的處理方式。模糊的驗收條款對雙方都危險。
四、變更需求的計價方式。 是按人天、按功能點，還是有一定額度的免費調整？變更是否會連動時程？這部分講清楚，才不會在專案後期為了小需求爭執。
五、時程與延遲責任。 雙方各自的義務（廠商的交付、你方的回覆與素材提供），以及延遲時的處理。多數延遲其實來自客戶端回覆太慢，條款應該對稱。
六、保固與維護。 保固期間、涵蓋範圍（Bug 修復通常涵蓋，新功能通常不涵蓋）、回應與修復的時間承諾、保固期後的維護計費方式。
七、保密條款（NDA）。 雙向保密，涵蓋你的商業資訊與使用者資料。如果專案會接觸到個人資料，還要確認資料處理與保存的約定是否符合法規要求。
八、付款節奏。 常見是依里程碑分期。要注意尾款比例不宜過低，否則對交付品質缺乏約束力。
九、終止條款。 合作不順時如何終止、已完成部分如何計價、資料與程式碼如何移交。這條沒人想用到，但沒有它的時候最痛苦。
紅旗訊號
出現以下情況，建議提高警覺：
- 第一次談就報出精確價格，卻沒問過你的使用情境與規模。
- 不願意提供書面規格或報價明細，只給一個總價。
- 保證排名、保證流量、保證成效，且不說明依據。
- 對原始碼歸屬含糊其詞，或表示「結案後可以再談」。
- 把驗收與測試當作額外收費項目。
- 用「我們用的是最新技術」取代解釋為什麼適合你。
- 急著要簽約、給出限時折扣。
- 報價明顯低於其他所有家，卻沒說明省在哪裡。低價的合理來源（例如可重複使用既有模組）應該說得出來。
- 溝通階段就已經回覆緩慢、答非所問。合作後只會更明顯。
- 無法提供任何具體的過往工作說明，或作品無法查證。
怎麼比較不同的報價
把報價攤平成同一個基準，才有意義：
| 比較項目 | 要確認的事 |
|---|---|
| 範圍 | 頁面／功能清單是否一致 |
| 不含項目 | 是否明確列出（內容、素材、主機、金流申請） |
| 設計 | 全客製、版型調整，還是套版 |
| 測試 | 是否含跨裝置測試與修正輪次 |
| 上線 | 是否含部署、DNS 設定、教育訓練 |
| 保固 | 期間與範圍 |
| 維護 | 月費金額與涵蓋內容 |
| 交付物 | 原始碼、設計檔、文件是否齊備 |
| 時程 | 各里程碑與你方需配合的節點 |
不要單看總價，要看「總價 ÷ 範圍」。 兩份報價的數字差距，很多時候只是因為其中一份把測試、上線與保固拆出去了。成本結構的完整拆解見網站製作費用怎麼算與App 開發費用完整指南。
合作開始之後，你也有責任
即使找到好廠商，專案仍可能失敗，常見原因多半在客戶端：
- 沒有指定一位有決策權的窗口，需求由多人各說各話
- 回覆與確認的速度太慢，導致廠商空轉
- 素材與內容遲遲沒有提供
- 驗收時才第一次認真看，然後要求大幅修改
- 需求不斷追加，卻期待價格與時程不變
把自己該做的事做好，專案成功率會明顯提高——這是最便宜的品質保證。
具體來說，開工前可以先做三件事：指定一位單一窗口，所有需求與回饋都經過他彙整後再傳達，避免不同主管各自向開發團隊下指令；約定回覆時限，例如設計稿與功能確認在幾個工作天內回覆，並把它寫進時程表；建立一份需求變更紀錄，每一次追加或調整都記下日期、內容與雙方對時程與費用影響的確認。這三件事不需要任何技術能力，卻能擋掉大部分的爭議。
挑廠商的本質是在挑「接下來幾個月要一起工作的人」。技術能力是門檻，溝通方式與資訊透明度才是決定體驗的關鍵。
如果你正在比較幾份提案、或想在簽約前確認需求規格有沒有漏項，與 NETVANA 聊聊。我們的軟體服務採先諮詢再報價，第一步是釐清你真正需要的範圍。
延伸閱讀：估算預算見網站製作費用怎麼算與App 開發費用完整指南；決定該外包或自建，見軟體外包 vs 自建團隊；接電商案的廠商，要另外看這幾項能力，可以看電商網站開發指南；改版發包前，先確認搬遷步驟誰負責，可以看網站改版 SEO 檢查清單；合約簽下去之後，驗收條款才是真正的保險，可以看軟體驗收與 UAT 測試指南；挑好廠商之後，合約模式同樣會決定專案體感，可以看固定報價還是敏捷開發怎麼選；廠商交付的程式碼用了哪些開源元件也要問清楚，可以看開源授權白話指南；挑好廠商之後，還要學會怎麼看懂他們的報價單，可以看軟體報價單怎麼看；導入 ERP 得先選對開發夥伴，這篇教你怎麼挑，可以看中小企業 ERP 導入指南；挑廠商時該問的問題，也包括原始碼歸屬，可以看原始碼歸屬與專案交接指南；公司內沒有懂技術的人幫忙把關廠商時，可以看兼任技術長是什麼。
