在固定價格合約與按工時計費之間做取捨，通常會被說成是一次關於風險的選擇。這個說法本身沒錯，可是緊接著就被處理歪了，因為雙方都預設風險會消失，而不是只在兩邊之間換手。

風險並不會消失。在固定價格的安排裡，估算失準的風險由廠商承擔，而廠商會把這份風險先算進報出的金額裡。在按工時計費的安排裡，承擔的人換成業主。真正的問題從來不是哪一種做法能消除不確定性，而是哪一方比較有條件去管理它，以及把風險轉移出去的代價值不值得付。

能事先看出哪一種做法會成功的檢驗： 你能不能把「完成」寫下來，寫到兩個人對於是否已經達到這個狀態能夠得出一致判斷的程度？如果可以，固定價格就是你能用的選項，而且多半是合理的。如果寫不出來，固定價格合約並不會把模糊消掉，它只是把未來每一次歧見從技術討論換成商務協商。

固定價格合約究竟買到了什麼

買到的是帳單金額上的確定性，除此之外什麼也沒有。具體來說，它並沒有買到成果、時程或品質上的確定性，而業主往往以為這三樣是包在一起送的。

它同樣有代價。以固定價格報價的廠商一定會加上風險準備金，因為超支要由自己吸收，而這筆準備金的幅度會隨著規格書愈模糊而愈大。範圍界定清楚的案子，這筆錢可以很有限。描述鬆散的案子，它可能逼近工作本身的成本，而且不論風險最後有沒有發生，你都得付。

第二種代價出現在行為上。金額一旦鎖住，所有含糊的地方都會朝著少做一點的方向被解讀，因為廠商的利益現在落在那一邊。這不是惡意，而是合約本身造出來的誘因。做到一半才看出更好做法的廠商，沒有動機把它提出來；發現某條需求寫錯了的業主，面對的是一張變更需求單，而不是一次對話。

固定價格在真正畫得出邊界的工作上表現很好：來源與目標都清楚的轉移、串接一個有文件的 API、依照已確認的設計做出一組固定的畫面。只要工作帶有摸索性質，它就表現得很差。

按工時計費何時比較便宜

和直覺相反，這種情況其實常見，因為你不必付風險準備金，也不必付處理變更需求的成本。

它適合範圍會因為正當理由而變動的工作：方向取決於使用者實際行為的第一版、與一套沒有人寫過文件的系統串接、對一個打開之前根本不知道狀況的程式庫進行搶救。在這些情況下，固定價格說穿了就是替一個猜測標上死價。

它對業主的要求是投入注意力。缺乏參與的按工時計費會變成一張沒有盡頭的帳單，典型的失敗形態是一個專案跑了好幾個月，卻沒有人問上週究竟交付了什麼。控制力不在合約條款裡，而在運作方式裡：一份看得見的待辦清單、固定節奏的展示，以及業主這邊一位有權調整優先順序的負責人。

如果你這邊找不出人來投入這份注意力，就把話講清楚，因為按工時計費不會運作得好，而且沒有任何條款修得好這件事。

多數專案真正該採用的第三種做法

一種設有上限、或是切成階段的安排。它不屬於前面兩種中的任何一種，實際適用的軟體工作卻比兩者都廣。

有上限的按工時計費。 工作依時間計費，同時設一個雙方談定的上限金額。業主保留轉向的彈性，廠商承擔超過上限之後的尾端風險。兩邊都還留著把事情做有效率的誘因，這是兩種純粹模式都做不到的。

分階段的固定價格。 先用一段簡短而付費的需求釐清產出規格書，之後才針對真實存在的東西替開發階段報固定價格。這才是固定價格誠實的版本，因為估算是在未知被壓縮之後才做，而不是之前。那份規格書該寫些什麼，我們的軟體招標文件指南有完整說明。

依增量報固定價格。 每個階段分開報價、分開確認。你以分段的方式取得預算的可預測性，同時保留隨時喊停的權利。這是業主手上最有價值的權利，也正是長期固定價格合約會拿走的那一項。

共同的線索只有一條：只要已經做完一部分工作，估算的準確度就會提升一大截。把商務結構設計成能吃到這個好處，比任何一條條款都值錢。

固定價格專案真正失敗的地方

不在價格上。在範圍與變更的交界處。

每一個固定價格專案都會產生變更需求，因為規格書是在任何人真正用過這個東西之前就寫好的。這份安排健不健康，完全取決於這些需求怎麼處理，而這又取決於一開始把範圍界定得多精確，而不是取決於誰的善意。

有兩件事能降低摩擦。用書面約定一項變更會怎麼走：由誰評估、依什麼基礎報價、多久給出結果。同時在業主這一側也留一筆準備金，因為業主沒有變更預算的固定價格，會讓每一次新發現都變成一場爭執。

另一種常見的失敗是驗收。如果合約沒有定義該怎麼證明已經完成，尾款就會變成一場關於看法的協商。把驗收標準寫在範圍旁邊，並且優先採用有人測得出來的標準，而不是有人得去判斷的標準。

實務上怎麼選

先問真正未知的是什麼。如果答案是所剩無幾，固定價格是合理的，而你應該預期為這份確定性付出一筆準備金。如果未知的部分很多，固定價格只是把技術上的不確定換成商務上的摩擦。

再問你盯得住什麼。按工時計費會回報注意力，也會懲罰注意力的缺席。固定價格每週向你要的比較少，卻在最前面的規格階段向你要得更多，那裡的錯誤比較便宜，卻也更難被察覺。

最後問這份確定性值多少錢。有時候董事會就是需要一個數字，這時準備金就是一個公道的價碼。這是選擇固定價格的正當理由，也比相信固定價格能消除風險要好得多。

Mecanik 在軟體開發服務中三種安排都承接，最常建議的是分階段的那一種。經過兩週需求釐清之後才給出的估算，對雙方來說都比在那之前給出的更有價值。

常見問題

固定價格合約比按工時計費更安全嗎？ 它比較好預測，這和安全不是同一件事。固定價格把估算風險轉給廠商，廠商會把這份風險當成準備金算進價格裡，所以不論風險有沒有發生，你都得付這筆錢。它買到的是帳單金額上的確定性，而不是成果、時程或品質上的確定性。

按工時計費什麼時候比較便宜？ 當範圍會因為正當理由而變動時：方向取決於使用者行為的第一版、與一套沒有文件的系統串接，或是在一個打開之前不知道狀況的程式庫上動工。這些情況下你同時省掉風險準備金和變更需求的處理成本，因為這裡的固定價格只是替一個猜測標上死價。

什麼是有上限的按工時計費？ 依時間計費，但設一個雙方談定的上限金額。業主保留轉向的彈性，廠商承擔超過上限的風險。它讓兩邊都還留著把事情做有效率的誘因，而純粹的固定價格與純粹的按工時計費都做不到這一點。

固定價格的軟體專案為什麼會出狀況？ 幾乎都出在範圍與變更的交界處，而不是價格上。規格書是在任何人用過這套軟體之前寫的，所以變更需求無可避免。專案健不健康，取決於事先談好由誰評估變更、怎麼報價，也取決於業主自己有沒有留一筆準備金。

驗收標準應該寫進合約嗎？ 應該，就寫在範圍旁邊。如果沒有約定該怎麼證明已經完成，尾款就會變成一場關於看法的協商。優先採用有人測得出來的標準，而不是有人得去判斷的標準，因為測得出來的標準能了結歧見，靠判斷的標準只會把歧見拖長。