軟體外包廠商的評估表與簽約前查核項目

這份評估表的來源

開發團隊是廠商，這篇站在廠商這一側寫。

開發團隊開報價單有自己的標準：範圍窮盡列舉，每一項交付能當場判定，兩者衝突時先綁住範圍。把這套標準反過來，就是買家用來檢驗廠商的查核項目。

評估表：逐列向廠商確認

簽約前可以直接複製使用的句子

• 請確認報價單上的頁面、功能與資料表就是完整的交付範圍，沒列的一律算新需求。
• 請說明交付表的每一項要怎麼當場判定做完。
• 請廠商確認：合約內的功能不能運作時免費修，超出範圍的新要求先透明報價再動工。
• 請載明交付後超過多久沒提異議，就視為通過。
• 若為公部門專案，驗收時可能被要求補軟體合法取得證明，請說明這份證明由誰準備。
• 專案若含 AI 問答，請說明資料由誰整理。（基本概念見 RAG 企業知識問答）
• 若要過第三方查核，例如弱掃和滲透測試，請說明廠商配合產出哪些文件；通過與否由查核方判定，廠商只能配合產出，不能擔保。

開發團隊的做法與自評檢查的例子

預想功能表與合理範圍的落差

開發團隊讀客戶資料有固定順序：先看客戶對第三方的義務文件與查核條文，再看既有系統，最後才看預想的功能表。依開發團隊的經驗，客戶預想的功能表通常比合理範圍大 1.5–3 倍，所以每一項都要對照第三方文件有沒有要求、報價有沒有涵蓋，都沒有的就移出範圍。客戶列了一長串，廠商卻一項都沒砍，就該請廠商說明怎麼判斷。

總金額除以月數

把總金額除以合約總月數，換算成每個月養得起多少人力，再決定 MVP 砍多狠。重點不是一個專案多少錢，而是要養幾個月。委託方收到的報價也能這樣算，範圍和價格對不上，就請廠商說明哪一邊會縮水。

交件前用腳本核對數字

交件前，開發團隊用腳本核對表格的列數，和文字寫的「共 N 個」是否一致。例如文字寫 6 個頁面路徑，表格實際卻列了 7 列。這種不一致進了合約，就是日後吵架的材料。

把難做的部分在簽約前寫進報價單

某個零件展示專案，有一類零件很難逐件建成 3D 模型。開發團隊沒有等簽約後再談，而是寫進報價單：這類零件用位置與角度的參數呈現，不逐件建模；哪些零件能互相搭配的規則由客戶提供；零件編號與掃描排程用試算表管理。客戶簽字前，就知道這一塊會做成什麼樣子。

反過來，也可以請廠商說明最難做的那部分在報價單上怎麼寫。答不出來，就是還沒講清楚。

資安與維運要看實際紀錄

資安與維運能力，看做過的紀錄最準。請廠商說明做過哪些政府或大型專案、擔任什麼角色，再看弱點掃描與源碼檢測的發現怎麼修補、複測結果如何，最後確認上線後的 SLA 怎麼寫進合約。

開發團隊配合教育部專案多年，工作內容包含配合主管機關要求的掃描、修補中高風險與誤判申覆。這類配合與上線後的維運，見Polish+ 資安與後台。

連續承接只是一個訊號

教育部戶外教育資源平臺專案，開發團隊從設計標承接到工程標，詳見教育部戶外教育平臺案例。

連續承接是一個訊號：做過前後分階段的專案，也就做過階段之間的銜接。標案各自招標，這個訊號要和評估表上的其餘項目合併判斷。

不適合的情況

如果需求是現成的 SaaS 產品，或一次性的小改，這套評估表就不適合。這類需求沒有範圍可以窮盡列舉，也沒有上線後的服務期，看產品方案或單次報價就夠。要分階段、要養好幾個月，或有第三方查核的專案，才需要這張表。

拿去用

把評估表和上列句子寄給每一家候選廠商，請對方書面回答。也可以把開發團隊的報價單放進同一張表比，聯絡開發團隊。