固定報價還是敏捷開發：軟體專案合約模式怎麼選
固定報價的合約看起來最安全：金額寫死、範圍寫死、時程寫死，出事找廠商。但實際做過專案的人都知道，最後爭執的通常不是價格，而是「這件事到底算不算在原本的範圍裡」。
另一邊，敏捷開發聽起來很彈性，卻讓不少業主不安：沒有一份鎖死的總清單，要怎麼控管？
這兩種模式沒有誰比較進步，差別在於需求估錯的風險由誰吸收，以及你的專案本身適不適合被一次寫死。
兩種合約模式的本質差異
固定範圍固定價：雙方先把功能清單、交付物與時程談定，總價隨之確定，之後的變動要走變更程序。
迭代式計價（時間與材料）：依實際投入的人力與時間計費，範圍可以隨每個週期的結果調整。這裡說的「時間與材料」是業界對這種計價方式的通稱，指的是照投入結算，而不是照清單結算。
關鍵差別只有一句話：估算失準的成本落在誰身上。
固定價把估算風險轉嫁給廠商。廠商為了承擔這個風險，會在估算時留緩衝，也會對超出範圍的要求嚴格把關——這不是刁難，而是這種合約結構必然的結果。
迭代式則把風險留在業主這側。好處是隨時可以調整方向，不必為了改一個小地方重新談約；代價是總投入不會在第一天就鎖死，需要你自己控管節奏與優先順序。
| 面向 | 固定範圍固定價 | 迭代式計價 |
|---|---|---|
| 估算風險 | 廠商承擔 | 業主承擔 |
| 需求變更 | 走變更程序、另行議定 | 下一個週期直接排入 |
| 前期投入 | 需求必須先寫清楚 | 方向清楚即可啟動 |
| 業主投入 | 前期重、中期輕 | 全程持續投入 |
| 適合情境 | 範圍明確、變動少 | 探索性、需求會演化 |
| 典型風險 | 範圍爭議、廠商保守 | 失焦、看不到終點 |
固定範圍固定價適合哪些專案
當以下條件成立，固定範圍是比較省事的選擇：
- 要做的東西有成熟的參照：形象官網、產品型錄、規格明確的功能模組，這類專案的工作內容可以被完整描述。
- 流程已經跑順，只是要搬上線：既有作業方式穩定，開發只是把它數位化，不涉及邊做邊想。
- 有預算核銷或採購程序：內部需要一個確定的總額去申請，彈性計價在行政上不可行。
- 決策鏈長、無法即時回饋：如果窗口沒辦法頻繁參與，固定範圍反而比較安全。
前提是需求真的寫得出來。範圍能不能寫清楚，可以先對照軟體需求怎麼寫裡的結構自我檢查——如果連主要流程與欄位都列不出來，那份固定報價其實是建立在雙方各自想像上的。
迭代式適合哪些專案
反過來說，下列情況硬要固定範圍，通常會兩敗俱傷：
- 產品還在驗證假設：第一版的目的是確認市場反應，功能清單本來就該隨著學到的東西改，這正是MVP 最小可行產品的精神。
- 要整合的外部系統行為不明：對方的介面、資料格式與限制要實際串了才知道，事前估算幾乎一定失準。
- 內部流程還在調整中：後台系統最常見的狀況，做到一半發現原本的流程本來就該改。
- 成敗取決於使用者體驗的細部打磨：這類工作沒辦法用清單窮舉，只能反覆試。
變更到底怎麼算
這是兩種模式最容易踩到的地雷，簽約前就該講清楚。
固定範圍的合約裡，變更通常分三類：釐清（原本就隱含在範圍內，不另計）、調整（同等工作量的替換，以換工方式處理）、新增（超出範圍，另行估算並更新時程）。三者的界線一定要寫進合約，否則每次討論都會變成立場對立。
迭代式則沒有「變更」這個概念，只有「優先順序」。想加東西不需要談判，但必須有人決定什麼往後排——如果所有事情都是第一優先，時程一樣會失控，這也是軟體專案延誤最常見的根因之一。
混合模式：先固定範圍做第一期
實務上最常用、也最容易被接受的，其實是混合做法：第一期採固定範圍，後續轉為迭代。
典型的切法是這樣：
- 釐清階段獨立成案：需求訪談、流程盤點、畫面原型單獨計價交付，產出一份雙方都認可的規格。
- 第一期固定範圍：用上一階段的成果界定核心功能，範圍明確、可以固定，業主也能先看到能實際運作的東西。
- 第二期之後轉迭代：上線後依真實使用狀況決定要優化什麼、擴充什麼，用週期計價持續推進。
這個做法同時解決兩邊的痛點：業主在最不確定的起點有一個明確的終點與總額；廠商不必為了一份想像中的清單報一個防禦性的價格。前提是第一期的架構要留得住後面的擴充，這件事在需求訪談時就要講明。
業主在敏捷專案裡的角色
敏捷不是把責任交出去，而是把責任分擔回來。選擇迭代模式時，業主端至少要提供三件事：
一位能拍板的窗口。這是最關鍵的一項。窗口不需要懂技術，但必須有權決定優先順序，並且能在合理時間內回覆問題。決策卡住的時間，在迭代模式裡會直接變成成本。
固定的回饋節奏。每個週期結束要有人真的去操作 Demo，而不是看完簡報說「看起來不錯」。沒有被使用過的功能，等於還沒被驗收。
對優先順序負責。廠商可以建議，但決定先做什麼是業務判斷，不是技術判斷。這一點無法外包。
如果組織內部無法提供上述條件，那麼老實選固定範圍會比勉強做敏捷更好。這也是評估合作對象時該一起談的事，相關提問可參考如何挑選軟體開發公司。
兩週一個 Sprint 實際上會發生什麼
NETVANA 的開發階段以兩週為一個 Sprint，每個週期結束提供可操作的 Demo。具體到業主的體感，一個週期大致是這樣運作的：
- 週期開始：確認這兩週要完成哪些項目，以及各自的完成定義。
- 週期進行中：開發過程冒出的細節問題（某個欄位是否必填、例外狀況怎麼處理）需要業主回覆。
- 週期結束：拿到可以實際點選操作的版本，在真實環境中試用並提出回饋。
- 下個週期開始前：依回饋與當下的業務優先序，決定下一期要做什麼。
這種節奏的價值在於問題會早一點浮現。範圍寫得再細，很多問題也只有在能點下去之後才看得見；能早兩週發現，修改成本就完全不同。完整的階段說明可以看軟體開發流程。
簽約前該確認的事
不論選哪一種，這幾項都該在文字上講清楚：
- 完成的定義：功能寫完算完成，還是測試通過、部署到正式環境才算？這會直接影響軟體驗收與 UAT的進行方式。
- 變更或優先序的決策機制：誰提、誰審、多久回覆、怎麼記錄。
- 交付物清單：原始碼、設計檔、部署與維護文件在什麼時間點交付。NETVANA 在專案費用結清後會完整移交原始碼、設計檔案與相關文件。
- 停止與退出條件：迭代模式尤其重要，雙方在什麼情況下可以收尾。
- 上線後的支援安排：保固範圍與後續維護是分開的兩件事，簽約時一併談。
固定價買的是確定性，迭代買的是調整空間，兩者都要付出對應的代價。真正該避免的，是用固定價的合約去做一件範圍講不清楚的事——那等於把爭議留到最後才爆。
如果你手上的需求還在成形，不確定該一次談清楚還是分期推進，和 NETVANA 聊聊你的專案。軟體服務採詢問報價制，沒有固定套餐，我們會先釐清範圍與合作方式，再談後面的事；各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：想避免時程失控，先看軟體專案為什麼總是延誤；需求文件不知道從哪裡下筆，可以照軟體需求怎麼寫的結構整理；第一版該做什麼不該做什麼，看MVP 最小可行產品開發指南；在猶豫外包還是自建團隊，可以看軟體外包還是自建團隊；驗收怎麼綁付款節點，看軟體驗收怎麼做；選好合約模式後，啟動前還要準備這些事，可以看軟體專案啟動前業主要準備什麼。
