軟體外包專案「風險登錄簿」完整指南：8 個風險類別、5 條合約止損條款、3 個老闆每週 30 分鐘檢核模板，中小企業老闆專案治理工具包

「我以為這個專案會準時上線，結果上線前 3 週才知道核心模組根本還沒寫。」，這是我們過去 5 年聽過至少 15 個中小企業老闆說過的同一句話。問題未必是廠商工程師不認真，更可能是沒有任何人在專案中段把風險清單攤開來、定期檢視。

這篇給找外包做軟體專案的中小企業老闆，介紹一個被職業 PM 用了 20 年、但中小企業幾乎沒人用的治理工具：風險登錄簿（Risk Register）。8 個常見風險類別、5 條應該寫進合約的止損條款、3 個老闆每週 30 分鐘就能跑完的檢核模板。目的是讓你在簽合約前就把風險治理框架擺好，而非讓你變成 PM。

根據 PMI 2026 軟體專案治理研究，有正式風險登錄簿的軟體專案，上線準時率比沒有的高 2.4 倍。但這份研究調查的對象是中大型企業，中小企業幾乎沒人跑這套，主要原因是「太複雜、看起來很 PM、老闆覺得『我又不是工程主管』」。本篇要打破這個迷思精簡版的風險登錄簿，老闆每週花 30 分鐘就能跑。

為什麼大部分中小企業老闆都不跑風險登錄簿？

我們訪談過 50+ 找我們做客製化系統的老闆，問他們專案中段怎麼追風險，答案大致 4 種：(1) 「我用 LINE 群組看 PM 每週回報」；(2) 「我看 Notion / Trello 的 task 進度條」；(3) 「我等廠商有問題會主動 raise」；(4) 「我們不追，反正驗收時看結果」。這 4 種全都會在上線前 3 週發現核心模組沒寫。

LINE 群組會被吃掉訊息、task 進度條只顯示「做完幾個 task」不顯示「風險發生機率」、等廠商主動 raise 等於不追、不追的反正驗收時看結果，這 4 種方法都把「機率 × 衝擊」這個風險核心給漏了。風險登錄簿的關鍵是定期攤開「現在最大的 3 個風險是什麼、發生機率多少、發生後損失多少、誰負責盯」，而非格式漂亮。

市面上專案管理顧問會教你用 PMBOK 那套，每週寫 30 頁 RAID log。我們的判斷是中小企業老闆不需要這個，**簡化到一張 A4、每週 30 分鐘、3 個動作就夠**：(1) 加新風險；(2) 重新評估舊風險機率；(3) 標記要採取行動的風險。其他都是裝飾。**簡單到老闆會持續做、才是有效的工具**。**繁複到只有 PM 會做、就沒有治理價值**。

軟體外包專案的 8 個常見風險類別

我們從 30+ 案累積出最常見的 8 類，這 8 類涵蓋約 85% 的中小企業客製化系統翻車原因。

1. 需求漂移風險：使用者上線前需求改了 30% 以上，工時爆表（發生率 50-65%）
2. 廠商人力流失風險：主力工程師中途離職、新接手熟悉 codebase 要 4-8 週（發生率 20-30%）
3. 第三方依賴風險：用了會出問題的第三方 API / SDK，廠商沒 fallback（發生率 25-40%）
4. 整合風險：跟既有 ERP / CRM / 會計軟體整合不順、規格沒早期確認（發生率 30-50%）
5. 資料遷移風險：舊系統資料髒、欄位對不上、上線前 3 週才發現要重洗（發生率 40-60%）
6. 驗收標準模糊風險：合約沒寫驗收 KPI，廠商說「我做完了」客戶說「我覺得沒做完」（發生率 35-55%）
7. 雲端 + API 成本失控風險：上線後雲端帳單比預期高 2-3 倍（發生率 30-45%）
8. 資安與隱私風險：個資外洩、權限設計漏洞、API key 外露（發生率 15-25%）

中小企業老闆不需要記每一類細節，只要在簽合約前看一遍這 8 類、針對每類問廠商「你怎麼預防、發生了怎麼處理」就好。問不出答案的類別 = 高風險區。

5 條應該寫進合約的止損條款

光有風險登錄簿不夠，合約沒寫止損條款 = 風險發生時老闆沒籌碼。我們建議的 5 條最低限度條款：

1. 「主力工程師更換預警條款」：主力工程師離職 / 換人，廠商須提前 14 天告知 + 提供 knowledge transfer 計畫
2. 「需求變更工時上限條款」：超過合約原始規格 X% 的需求變更，需走 change request 流程 + 額外計費
3. 「整合測試 milestone 條款」：跟既有系統整合須在合約期 50% 時做第一輪整合測試，未通過廠商分擔延期成本
4. 「驗收 KPI 量化條款」：每個 deliverable 都要寫量化驗收標準（如「響應時間 < 2 秒」「報表生成 < 30 秒」），不寫「使用者滿意」這種模糊詞
5. 「資料 + IP 歸屬條款」：原始碼、資料庫、API key、雲端帳號、第三方授權，100% 歸客戶所有，廠商不得保留 backdoor

老闆每週 30 分鐘檢核模板

我們給中小企業老闆的精簡版風險登錄簿，只需要一張 A4、5 個欄位：

• 風險描述（一句話）
• 發生機率（高 / 中 / 低）
• 衝擊（嚴重 / 中等 / 輕微）
• 負責盯的人（廠商 PM 或我方代表）
• 下次檢視日期（每週 / 每兩週 / 每月）

每週固定 30 分鐘跟 PM 過一次這張表，3 個動作就好：(1) 有沒有新風險要加；(2) 舊風險的機率有沒有變化；(3) 有沒有風險要立刻採取行動（升級到「風險發生」狀態，啟動止損條款）。

如果廠商不願意跑風險登錄簿怎麼辦？

這是中小企業老闆最常見的問題，「我的廠商會不會覺得我在找麻煩？」我們的判斷是：會願意跑風險登錄簿的廠商，才是值得簽長約的廠商。願意把風險攤開來討論的廠商，代表他有自信、有 PM 紀律、不怕被檢核。反過來說，會推託「我們是 agile 不用這套」「我們有自己的方法」的廠商，多半是不想被追蹤、不想透明。

如果你正在評估外包廠商、想知道「這家廠商願不願意跟我跑風險登錄簿」，可以在第一次 RFP 提案會議就直接問：「你們的專案會有風險登錄簿嗎、能不能給我看一份過去案的範例」。願意給的廠商，後面合作問題會少 60% 以上。

風險治理放到 RFP 階段，怎麼選廠商？

我們的建議：在 RFP 階段就把「風險治理」當成一個篩選維度，3 個問題篩掉一半廠商。

1. 「請給我看一份過去 3 個專案的風險登錄簿範例」（不能提供 = 排除）
2. 「主力工程師中途離職時，貴公司怎麼處理 knowledge transfer」（沒 SOP = 紅旗）
3. 「貴公司過去 2 年有沒有專案延期超過 30%、原因是什麼」（不願揭露 = 排除）

如果你看完想開始導入風險治理框架，但不確定怎麼跑，可以參考我們的 /services/customize-web 服務頁的「專案治理」段，也歡迎預約 30 分鐘對談、我們會直接給你「這個專案該怎麼設風險治理」的具體建議，不收費。

常見問題（FAQ）

我不是工程出身，看得懂風險登錄簿嗎？

看得懂。風險登錄簿的 5 個欄位（描述、機率、衝擊、負責人、檢視日期）都是商業語言，不需要技術背景。廠商如果跟你解釋風險時用一堆技術術語，那是他的問題，不是你的可以直接要求廠商「用我能懂的話描述這個風險」。

每週 30 分鐘真的夠嗎？

對 100-300 萬規模的客製化系統夠。專案規模超過 500 萬建議升級到每週 60 分鐘 + 每月一次 deep dive。少於 100 萬可以縮短到每兩週 30 分鐘。重點是固定頻率，而非時間長短。

如果廠商寫的風險登錄簿都是「無顯著風險」怎麼辦？

這就是最大的風險。我們的經驗：寫滿「無顯著風險」的廠商，要麼是怕被追責不敢寫、要麼是 PM 沒受過訓練不會識別。可以直接要求「請列出至少 5 條中等以上機率的風險，否則我會找另一位獨立 PM 來盤點」。多半廠商會立刻認真寫。

風險登錄簿要不要給客戶看？

老闆要看，但業務團隊不一定要看。風險登錄簿是治理工具，給決策層用。給業務團隊看會增加焦慮、降低使用系統意願。中小企業老闆 + 廠商 PM 共同看、決定要不要把風險揭露給內部其他人。

用 Jira / Notion / Asana 內建的 risk feature 行不行？

行但中小企業老闆通常會用不下去，這些工具的 risk module 太重，學習成本高、UI 不夠直觀。我們的建議是先用 Excel 跑 3-6 個月、習慣節奏後再考慮搬到正式工具。簡單的工具持續用 > 複雜的工具放棄用。