判據一：人月估算的理由
費率這一側其實是公開的。根據中華民國資訊軟體服務商業同業公會的 115 年資訊服務委外經費估算原則，各職類人月報價逐項列出，例如「軟體開發及程式設計師」是 181,502 元、207,486 元、235,232 元三級。所以總額真正的變數是人月數。
而人月數是唯一沒有公開對照表、完全靠專業判斷的一項。問法很具體：這 6 個人月是怎麼估的、哪幾個功能最吃工時、砍掉某個功能會少幾個人月。答得出來表示真的拆過；答不出來，總額再低你也沒有比較基礎。
- 費率可對照，人月不可——所以人月才是該追問的
- 「砍掉這個功能少幾個人月」是最有效的驗證題
- 答得含糊不必然是壞公司，但你確實缺少判斷依據
判據二：實際執行的人是誰
簽約主體與實際執行團隊不同，在這個行業很常見，本身不是問題。問題是不講清楚：你以為買到的是提案時見到的那位資深工程師，實際進來的是另一組人。
可查證的做法是寫進合約：主要執行人員的角色與資歷、更換時要不要通知、更換後的交接責任。這幾條寫下來之後，對方換人仍然可以，但你不會是最後一個知道的。
判據三：交付物包不包含文件與交接
功能做完了不等於你拿到了完整的東西。如果沒有文件與交接，知識全部留在對方身上，將來換廠商或自己接手時要重新摸索一遍——那筆成本會在最壞的時間點一次付清。
這一條最好在報價階段就提，因為它會影響報價（寫文件是工時）。報價後才追加，通常變成變更議價。把它當成一筆會計入總額的工時，而不是附贈品——報價單該怎麼拆見網頁設計費用為什麼問不出答案。
- 文件與交接要列進交付物清單，不是口頭承諾
- 報價階段就提，因為它是工時、會影響報價
- 駐點模式下這一條最容易被忘記，也最貴
判據四：驗收標準能不能判定
「功能正常」不是驗收標準，因為它無法判定——雙方都可以有各自的解釋。可判定的標準長這樣：在什麼條件下、做什麼操作、應該得到什麼結果。這種寫法不需要懂技術，只需要把業務流程講清楚。
驗收標準要和規格一起定。規格模糊的專案不適合固定總價，因為對方只能把不確定性算成報價裡的保險費；這一段的取捨見軟體外包的三種計價模式，報價怎麼拆見資訊委外經費估算原則怎麼用。