想知道行情的人分成兩邊。發案方希望先有個心理準備，免得談的時候被當外行；接案方則想確認自己開的價位是不是偏離市場。雙方共同的困擾是：問十個人會得到十種說法，而且差距大到讓人懷疑其中有人在亂喊。這其實不是市場混亂，而是「同一句需求」在不同前提下，工作量本來就差好幾倍。這篇不寫任何金額，而是把價格是怎麼被組成的說清楚，讓你在拿到報價時知道要追問什麼、又該怎麼把不同來源的報價放到同一個基準上比。
行情之所以問不出來的原因
軟體不像印刷或裝潢，沒有標準規格可以對照。同樣說要一套「訂單管理系統」，可能是一張表單加一份清單，也可能包含權限分層、多倉庫存、對外介接與報表。前者與後者之間，工作量的差距不是幾成，而是量級。
更關鍵的是，報價當下多數細節還沒被定義。開發方看到的是一段描述，要靠經驗去推測背後藏了多少東西。因此報價本質上是在替不確定性定價，而不同的人對同一份模糊需求，推測出來的範圍本來就不同。
真正影響價格的變數
- 需求明確度：有畫面稿與流程圖，跟只有一段口頭描述，估算的緩衝空間完全不同。
- 介接對象：要不要跟既有系統或外部服務往來、對方有沒有可用的說明文件與測試環境，這一項的變異最大。
- 資料狀況：既有資料是否乾淨、要不要轉檔、有沒有歷史包袱要一併處理。
- 使用規模與同時上線人數：影響架構選擇，也影響要投入多少效能與穩定性的工作。
- 合規要求：涉及個資、金流或稽核紀錄時，設計與測試的份量會明顯增加。
- 時程壓力：要求壓縮期限通常意味著加人或加班，兩者都會反映在價格上。
- 交付範圍：是否包含測試、教育訓練、文件、上線協助與保固期間的支援。
三種計價方式各自適合什麼情況
按專案總價：範圍清楚、變動不大的案子最適合。發案方預算可控，風險由開發方承擔，因此對方會把不確定性算進價格裡，並要求嚴格的變更程序。範圍越模糊，這種方式的緩衝就抓得越大。
按人天或按人月：適合需求會邊做邊調整、或長期投入的情況。透明度高，發案方看得到時間花在哪裡，但需要有能判斷進度合理性的人在內部把關，否則難以確認投入是否有效。
按階段：把專案切成需求規劃、雛型、開發、上線幾段，每一段各自報價與確認。前期投入較小，可以在資訊變多之後再決定要不要繼續，很適合第一次委外或需求還在成形的組織。缺點是總價要到後段才明朗。
同一份需求為何報價差距很大
先排除惡意低報之後，落差通常來自四個地方。第一是理解不同：有人以為只要做前台，有人把後台管理一起算進去。第二是品質標準不同：是否寫測試、是否做權限與稽核、是否處理異常流程，這些看不見的部分佔的比重不小。第三是交付內容不同：含不含文件、教育訓練、上線陪跑與保固。第四是承接形式不同：個人接案與有專案管理、測試分工的團隊，成本結構本來就不一樣。
比較的正確做法，是把幾份報價的功能項目攤開對齊，缺少的項目逐一回頭問。只比總價，等於是在比誰漏得多。
看得懂的報價單長什麼樣
一份可判讀的報價單，至少會把工作拆成可對照的項目，而不是只有一行總計。每個項目應該對應到具體的產出，例如某個畫面、某支介接、某份報表。另外要看得到不包含的事項、付款節點、變更需求的處理方式、保固範圍與期間。
如果報價單只有一句「系統開發一式」，那不是簡潔，是還沒被拆解過。後續一旦對範圍有爭議，雙方都沒有可以回頭比對的依據。
想降低費用，該調整哪裡
直接砍價通常換來的是隱形的減項。比較有效的做法是調整範圍與前提：把功能分成先上線與後續再做兩批，第一批只留下沒有它就無法運作的部分；自行準備好資料與素材，減少開發方的整理工作；把要介接的對象先問到文件與測試帳號；放寬時程，避免趕工帶來的額外成本。
另外一個常被忽略的是決策速度。確認慢、意見反覆，都會讓專案拉長，而拉長的時間終究會回到成本上。發案方能做到的最省錢的事，其實是把內部意見先整合好。
接案方怎麼替自己的報價找依據
對接案方而言，與其打聽別人開多少，不如建立自己的估算基礎。做法是把過去做過的工作拆成可重複的單位，記錄每一項實際花掉的時間，累積成自己的參考表。有了這份紀錄，面對新需求時就能用類比的方式估算，而不是憑感覺喊一個數。
同時要為不確定性保留空間，並在報價時說明清楚哪些前提成立才適用。前提被寫下來，日後條件改變時才有調整的正當理由，這比事後解釋為什麼會超支容易得多。
常見問題
為什麼有人不看規格就能報價？
通常是依據過去做過的類似案子直接套用，或是先給一個入門價位取得洽談機會，細節等進場後再談。前者在需求真的相似時有參考價值，後者則容易在中途出現追加。判斷方式是追問這個報價包含哪些項目、不包含哪些，以及需求與假設不同時如何處理。回答不出來的，代表這個數字沒有基礎。
報價明顯低很多，一定有問題嗎？
不一定，但要弄清楚低在哪裡。可能是對方已有高度相似的既有基礎可以沿用，這是合理的；也可能是把測試、文件、異常處理都省略，或誤解了需求規模。請對方說明交付清單與工作拆解，再與其他報價逐項對照，落差的來源通常會浮現出來。
按人天計價會不會被刻意拉長？
可以用制度降低風險：約定每個階段的預估投入上限、要求定期提供工作紀錄與可展示的進度、把驗收條件寫在每個階段結束時。另外可以先用小範圍的工作合作一次，觀察對方的產出效率與溝通品質，再決定是否用這種方式進行較長期的合作。
上線後的維護費用怎麼看才合理？
要先確認涵蓋範圍。維護通常包含系統可用性的照顧、環境與相依元件的更新、既有功能的瑕疵修正；新增功能一般不在其中。合理的維護約定會寫明回應時間、支援管道、服務時段，以及超出範圍時如何另行計價。只寫「提供維護」而沒有範圍描述的條款，日後爭議會很多。
只有一份簡單需求，怎麼取得可以比較的報價？
把同一份文件發給每一家，內容至少包含使用者角色、主要流程、必要功能清單、要介接的對象、預期上線時間，以及希望對方報價中一併列出的項目。統一提問的格式，回來的報價才會落在同一個基準上。若能附上畫面草圖，估算的準確度會明顯提高。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「程式外包行情」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
