符合台灣
專案風險盤點清單產生指令|上線前把地雷提前找出來
一句話結論輸入專案類型、開發階段與核心功能,AI 產出分類風險盤點清單,含技術、業務、法規、人力與外部依賴五大維度,幫 PM 在問題發生前就看到風險。
指令介紹
台灣科技業的 PM 做風險管理最常見的問題是「事後才想到」——功能上線後才發現沒有備援計畫、法規問題沒事先問過法務、第三方 API 沒有降級機制。這組指令幫你在專案開始前就系統性地把可能的地雷找出來,而不是等踩到才處理。
適用情境
風險管理專案風險上線前檢查PM清單
懶人貼上・複製就能用
已填好範例複製就能直接用
▸ 想換成你自己的內容?點開填一填選填
AI 指令庫編輯的話
編輯實測五維度分類確保技術面和非技術面風險都被系統性覆蓋,而非只盤點工程師容易看到的技術風險;把最高優先風險直接轉成 Definition of Done 檢查項目,讓緩解措施有明確的執行機制。 這組「專案風險盤點清單產生指令|上線前把地雷提前找出來」是 Prompts 編輯團隊實測整理的職場 AI 指令(Prompt),適合用 ChatGPT、Claude 執行,特別適合「0」等台灣在地場景。複製上方指令範本即可使用,免費、免註冊。
模型實測對照
## 風險盤點清單
### 技術風險
| 風險 | 機率 | 影響 | 優先級 | 緩解措施 | 負責人 |
|---|---|---|---|---|---|
| LINE Pay 沙箱與正式環境行為不一致 | 中 | 高 | P1 | 沙箱測試完成後,在正式環境用小額交易做完整 E2E 測試 | 後端工程 |
| 付款狀態 Webhook 遺失(網路中斷或 LINE 端重發) | 中 | 高 | P1 | 實作 idempotency key,對帳機制每小時自動比對 | 後端工程 |
| 高峰流量下付款 API 逾時 | 低 | 高 | P2 | 設定 timeout 與 retry 機制,付款失敗提示明確 | 後端工程 |
### 業務風險
| 風險 | 機率 | 影響 | 優先級 | 緩解措施 | 負責人 |
|---|---|---|---|---|---|
| 用戶對 LINE Pay 授權畫面感到疑慮而放棄結帳 | 中 | 中 | P2 | 在結帳頁前加安全說明,A/B 測試「LINE Pay 安全付款」標章 | PM+設計 |
| 轉換率提升不如預期(KPI 無法達成) | 中 | 中 | P2 | 上線前設定基準轉換率,上線後兩週評估是否需調整導流策略 | PM |
### 法規風險
| 風險 | 機率 | 影響 | 優先級 | 緩解措施 | 負責人 |
|---|---|---|---|---|---|
| 隱私政策未涵蓋 LINE Pay 資料傳輸聲明 | 高 | 高 | P0 | 上線前請法務更新隱私政策,加入第三方金流資料處理條款 | 法務+PM |
| LINE Pay 商業帳號審核延誤 | 中 | 高 | P1 | 申請後持續追蹤,備妥備援方案(信用卡直接結帳仍可用) | PM |
### 人力風險
| 風險 | 機率 | 影響 | 優先級 | 緩解措施 |
|---|---|---|---|---|
| 負責串接的後端工程師請假或離職 | 低 | 高 | P2 | 確保有另一位工程師交叉了解串接文件,不要只有一人知道 |
### 外部依賴風險
| 風險 | 機率 | 影響 | 優先級 | 緩解措施 |
|---|---|---|---|---|
| LINE Pay API 服務中斷 | 低 | 高 | P2 | 實作降級機制:LINE Pay 不可用時,自動顯示信用卡結帳選項 |
## 前三大優先風險
1. P0:隱私政策更新(上線前必須完成,法規風險)
2. P1:Webhook 遺失的對帳機制(金流問題影響最大)
3. P1:LINE Pay 商業帳號審核進度
## Definition of Done 建議加入
☐ 隱私政策已法務審核完畢
☐ Webhook 對帳機制有 unit test
☐ 正式環境小額交易 E2E 測試通過
☐ LINE Pay 不可用的降級畫面有 QA 測試
實測(ChatGPT):五維度分類確保不同類型風險都被覆蓋,P0/P1/P2 優先級讓 PM 知道哪個要先處理,DoD 清單直接可加入 Sprint Review 驗收條件。
產出技術/業務/法規/人力/外部依賴五維度風險清單,每項含機率、影響、優先級與緩解措施,加前三大優先風險摘要與 Definition of Done 風險檢查項目。
實測(Claude):把 Definition of Done 風險檢查項目直接列出是最實用的設計——讓風險緩解措施不只是文件,而是進入 Sprint 驗收流程,確保真的被執行。
為這個指令評分
常見問題
風險清單要多詳細才夠?
依專案規模調整。小功能改動列 5-8 個風險就夠,跨系統整合或新產品上線要列 15-20 個。重點不是列越多越好,而是每個風險都要有具體的緩解措施,沒有措施的風險列了也沒用。
風險清單要多久更新一次?
每個 Sprint 回顧時確認一次風險狀態,已解決的標注完成,新出現的補入清單。關鍵里程碑(如 Code Freeze、上線前一週)要做一次全面重審,確認沒有遺漏的風險。
相關指令
猜你喜歡
每週 5 組最新台灣 AI 指令,寄到你信箱
免費訂閱電子報,第一時間收到新指令與實測心得;現在訂閱立即領取「50 組必備 AI 指令懶人包」。
訂閱成功!懶人包連結已寄到你的信箱,請收信。
不寄垃圾信,隨時可取消訂閱。