Community生產力與協作github.com

Project Rescue(專案救援)

診斷陷入困境的專案,並根據專案自身的文件制定誠實的復原計畫——將症狀與根本原因分開,量化時間、成本與範圍的差距,列出真實的選項(復原、縮小範圍、增加時間或預算、暫停重新規劃、終止),並為贊助者撰寫一頁摘要,支援英文或阿拉伯文。

Project Rescue(專案救援) 是什麼?

此技能旨在幫助開發者或專案經理診斷陷入困境的專案,並制定誠實可行的復原計畫。它強調「證據先於意見」,要求所有發現都必須來自專案文件或當事人的陳述,若缺乏證據則標註為假設。該技能能將症狀(如「延遲六週」)與根本原因(如計畫估算不足)分開,並根據時間、成本與範圍的差距,提出包含縮小範圍、增加資源或暫停等選項在內的全面評估。最後,它會產出一份一頁的贊助者摘要,以清晰、誠實的語言說明現狀、原因、選項與建議。此技能適用於 Claude Code、Cursor 等代理工具,當專案出現延遲、超支、卡住或失去客戶信心時,可立即使用;但不適用於從零規劃健康專案或例行報告。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/CreativityHouse2025/pm-skills-for-claude/tree/HEAD/skills/project-rescue

Installed? Explore more 生產力與協作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

Project Rescue(專案救援) 是做什麼的?

協助某人釐清其專案為何陷入困境、有哪些真實選項,以及如何向必須做決定的人清楚說明。

陷入困境的專案通常會得到兩種錯誤回應:樂觀(「我們會趕上進度」)或一份通用的最佳實務清單。這兩者都沒用。此技能基於三項承諾:

  1. 證據先於意見。 每項發現都指向專案自身文件或當事人的陳述。若缺少證據,該發現會被標記為假設,並說明需要什麼來確認它。
  2. 原因,而非症狀。 「我們延遲了六週」是症狀。計畫必須針對「為什麼」採取行動。
  3. 誠實的選項,包括令人不自在的。 縮小範圍和終止都是真實的選項,並始終被考慮。

1. 掌握現況

要求提供任何存在的資料;根據可取得的資料進行分析,並說明缺少了什麼。

有幫助的文件: 原始計畫或章程、最新狀態報告、進度與預算對比實際情況、風險與問題日誌、自開始以來的變更清單。

在單一則訊息中最多問六個問題,只問那些尚未回答的問題:

  1. 該專案原本應在何時、以多少成本交付什麼?
  2. 它現在處於什麼狀態:完成了哪些工作、花了多少錢、今天現實的日期是什麼?
  3. 何時開始出問題,當時發生了什麼變化?
  4. 已經嘗試過哪些方法來修復它?
  5. 贊助者是誰,他們知道多少,他們最關心的是什麼:日期、成本,還是交付的內容?
  6. 哪些可以變動、哪些不能變動(固定日期、預算上限、合約承諾)?

如果當事人承受壓力且已提供足夠資訊開始,則先開始診斷並在最後列出缺少的資訊,而不是為了等待所有答案而擱置。

2. 診斷

閱讀 references/diagnostic.md 以了解原因領域及其徵兆。

  1. 列出症狀,以當事人和文件陳述的方式,並附上數字。
  2. 量化差距。 根據提供的數字計算時間、成本與範圍的差異,並顯示計算過程。不要估算未提供的數字;直接說明未知。
  3. 將每個症狀追溯至原因。 一直問「為什麼」,直到找到可以改變的東西。一個症狀通常有多個原因,一個原因也常解釋多個症狀。
  4. 標記每個原因為 Supported(有證據支持)(列出證據)或 Hypothesis(假設)(說明需要什麼來確認或排除它)。
  5. 挑選少數關鍵原因。 兩到三個原因通常解釋了大部分的問題。指出它們並說明為何是這些。
  6. 檢查計畫是否從一開始就可達成。 從一開始就被低估的專案需要新的基準,而不是在舊基準上更加努力。

用工作、決策和條件來描述原因。不要責怪特定個人:這很少是全部真相,而且會使計畫更難被採納。

3. 選項

始終列出可行的選項,而不僅是偏好的那一個:

選項適用時機
在目前計畫內復原差距小且原因可消除
縮小範圍日期或預算固定,且部分交付項目較不重要
增加時間或預算需要完整範圍,且贊助者能負擔
暫停並重新規劃原因不明,或計畫從不現實
終止剩餘成本超過剩餘效益,或需求已消失

針對每個適用的選項:它需要什麼、對日期、成本和範圍的影響(在數字允許的情況下計算)、主要風險,以及為了使選項成功必須成立的前提。已花費的資金不是繼續的理由;當它明顯主導思考時,請明確說明。

然後給出一個建議,標註為建議,並附上推理過程。決定權屬於贊助者。

4. 復原計畫

針對建議的選項:

  • 穩定(前兩週): 阻止損害擴大。典型行動:凍結新的變更、確認每個進行中任務的真實狀態、修復報告機制使數字可信、解決一兩個阻礙工作的決策。
  • 重新規劃: 經過修訂的範圍、進度和預算,且團隊相信它,並寫下所有假設。將其標記為需要贊助者批准的提議新基準。
  • 改變導致問題的原因: 針對每個主要原因提出一個具體改變(一項決策規則、一次審查、一個角色、一項供應商條款)。
  • 早期警示信號: 三到五個可衡量的信號,顯示復原正在偏離軌道,並標明觸發行動的門檻、每項信號由誰監控。
  • 檢核節奏: 在專案穩定之前,多頻繁地與贊助者審查進度。

每個行動都有一位負責人和一個截止日期。如果當事人未指定負責人,寫 Owner: to be assigned(負責人:待指派) 而非捏造一個名字。

5. 贊助者摘要

一頁,按此順序:我們在哪裡(以數字量化差距);為什麼(兩三個主要原因);選項及其對日期、成本和範圍的影響;建議;需要做什麼決定以及何時決定;接下來會發生什麼。

寫得直白。不要軟化數字、隱藏請求,或承諾一個依賴尚未達成事項的復原日期。如果當事人必須在會議中傳達,請提供口語版本(前兩分鐘要說什麼)。

6. 語言與語氣

使用當事人的語言。對於阿拉伯文,使用清晰的現代標準阿拉伯文從右到左書寫,並在首次使用時於括號內附上英文術語。配合當事人:對沒有專案訓練的人使用平實詞彙,對從業人員使用標準術語。正在管理失敗專案的人通常處於壓力之下;對專案要直接,對人要體面。

7. 界線

  • 基於文件及單一當事人陳述的診斷是初步觀點。說明你無法看到的部分。
  • 合約糾紛、罰款、終止供應商或員工、以及法律風險需交由組織的法律、商業或人力資源人員處理。標記它們;不要提供建議。
  • 不要協助以比證據顯示更好的方式呈現專案狀態。協助正確地表達真實情況。

相關技能