Randy Loomis, PMP — Andover, Connecticut, USA

從一個軟體升級案說起#

我們公司使用的培訓軟體已落後五個版本，廠商宣告不再支援。於是我們啟動了一個升級專案：與廠商合作，將舊系統升級至最新版本，並訓練使用者操作新介面。

我們簽訂了兩份工作說明書（Statement of Work）：一份針對使用者培訓，另一份則設定了升級腳本（Scripts）開發的不超過上限費用（Not-to-Exceed Cost）。廠商取得我們的資料後，開始遠端開發並測試所需的轉換腳本，再逐步遷移至我們的開發環境進行驗收測試，五個版本依序如此循環。

問題的核心：誰的錯誤誰買單#

測試過程中，我們不只發現腳本問題，還發現了應用程式本身的 Bug——這些問題與客製腳本無關，而是廠商產品的既有缺陷。我們詳細記錄每一個問題：截圖、重現步驟、影響範圍一一留存，並提出廠商當初承諾的功能規格作為佐證。

廠商起初堅稱這是「按設計運作（as designed）」，但隨著問題愈揭愈深，他們最終承認確實存在 Bug。由於合約設有費用上限，廠商不得不自行吸收超出上限的修復工時。

核心教訓： 我們當時太專注於趕上線，忽略了針對每個問題單獨追蹤廠商工時。若能做到這點，就能精確區分「專案工作費用」與「廠商產品修復費用」，從而節省更多成本。

合約談判的關鍵條款#

談判建議： 與廠商簽約時，務必明訂雙方工時須按個別問題分開追蹤。如此一來，專案經理才能在出現廠商產品缺陷時，有憑有據地要求減免費用，清楚區分「你的產品問題」與「我們的實施工作」。

具體做法包括：

• 要求廠商以問題單（Issue Ticket）為單位記錄工時
• 每個 Bug 對應獨立的工時帳目，而非匯入整體費用池
• 在合約中明確定義「應用程式 Bug」與「客製腳本問題」的責任歸屬

補充： Scripts（腳本）在此指由程式而非處理器直接執行的指令序列，可用於控制應用程式行為而不修改核心程式碼。本案中的腳本負責將舊版資料轉換為新版格式。