事前驗屍法提示詞（Pre-mortem：假設項目已經失敗，倒推失敗原因並提前設防，附 45 分鐘會議流程）
項目計劃基本定稿、正式開工前用：讓模型站在客戶、一線人員、財務、技術、外部合作方五個立場各寫一段「項目是怎麼失敗的」，歸併出最可能的失敗原因，逐條配上預防動作和預警信號，並給出帶團隊現場做一次事前驗屍的流程。
通用大模型 對話模型通用
我們要給一個即將啟動的項目做一次「事前驗屍」。請先不要評價計劃好不好，直接接受這個設定：現在是 [設想的失敗時點]，這個項目已經徹底失敗了。 項目計劃概要：[項目計劃概要] 當初定義的成功標準：[成功標準] 團隊與主要干係人：[團隊與干係人] 有人私下擔心、但沒在會上說的事：[私下的擔憂] 請分四段完成。 第一段，失敗故事。分別站在 5 個立場——客戶或最終用戶、一線執行人員、財務或出資方、技術或交付負責人、外部合作方——各寫一段 80 字以內的「事後回憶」，用過去時，講清在他看來項目是怎麼垮掉的。五段的原因不許重複；至少有一段涉及人和協作（沒人敢說、互相等、關鍵人離開），不能全是技術和進度問題。 第二段，歸併原因。把故事裏的失敗原因合併成 6–8 條，每條寫成「因為某事，所以某結果」。逐條給兩個判斷：發生的可能性（高 / 中 / 低），以及發現時是否已來不及補救（是 / 否），並說明依據來自計劃裏的哪句話；計劃裏沒有相關資訊的，標【計劃未提及】——這本身就是一個發現。 第三段，設防。只挑「可能性高」或「發現時來不及」的原因，每條寫：現在就能做的預防動作（本週誰去做什麼）、最早的預警信號（能觀察到的現象，不是「進度落後」這種結果）、信號出現後的應對。預防動作要落到對計劃的修改上：加一個檢查點、提前一項驗證、增加一個備選，而不是「加強管理」。 第四段，帶團隊現場做的 45 分鐘流程：主持人宣佈設定 → 每人獨立寫 5 分鐘，不討論 → 輪流每人念一條，直到唸完 → 歸類投票 → 定預防動作與負責人。寫出主持人的開場白，以及有人說「別這麼悲觀」時怎麼回應。 約束：失敗原因必須和我給的計劃內容掛鉤，不寫放之四海皆準的套話；不編造計劃裏沒有的數字和人名。
高亮處換成你自己的內容：[設想的失敗時點]、[項目計劃概要]、[成功標準]、[團隊與干係人]、[私下的擔憂]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[設想的失敗時點] 選一個結果已經見分曉的時間，比如「上線後第 3 個月」「交付後半年」。[項目計劃概要] 貼里程碑、分工、關鍵假設，越具體，模型找到的漏洞越貼近實際。[私下的擔憂] 把茶水間裏聽到的話寫進來，這些通常最接近真相。
常見失敗與調整：
- 做成了常規的風險討論，大家禮貌地說「可能會有點延期」。事前驗屍的關鍵是設定「已經失敗」，讓人從辯護計劃轉為解釋失敗，說話的顧忌會少很多。
- 現場直接開始討論，職位高的人先開口，後面的人就跟着說。一定要先獨立寫，再輪流念。
示例輸出
示例，僅供參考（虛構：某連鎖健身房的會員系統更換項目，設想時點為上線後第 3 個月）
失敗故事（節選）
- 會員：「換系統那週，我的次卡少了 6 次，前台查不到記錄，讓我等通知。等了兩週沒消息，我就沒再續費。」
- 前台店員：「培訓只有一個小時，還排在晚高峰之前。上線第一天排隊排到門外，我們只好先用紙登記。」
- 技術負責人：「舊系統的數據格式比想像的亂，可我在啟動會上沒敢說需要再多兩週。」
歸併原因
| 原因 | 可能性 | 發現時來不及 | 依據 |
|---|---|---|---|
| 因為會員餘額遷移後沒有逐店核對，所以上線後出現餘額錯誤 | 高 | 是 | 計劃中數據遷移只安排 1 次，沒有核對環節 |
| 因為培訓壓在上線前一天，所以店員不會操作 | 中 | 否 | 計劃只寫「上線前完成培訓」，未寫時長 |
| 因為技術負責人不敢提延期，所以帶着隱患上線 | 中 | 是 | 【計劃未提及】任何提出延期的渠道 |
設防（第 1 條）：本週由項目經理在計劃中增加「遷移演練 2 次，每店抽 30 名會員核對餘額」。預警信號：第一次演練的核對差異超過 1%。應對：暫停上線排期，逐條查清差異來源。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～