跳至主要內容
AI 指令庫

專案管理 指令集

從專案範疇界定、會議紀錄到風險控管,確保專案如期達標的實戰工具。 將括號內的變數替換為您的實際業務場景,即可直接複製指令或在聊天視窗中開啟。

  • 50 個 專案管理 指令
  • 可複製或直接開啟對話

撰寫專案啟動定義書 (Project Charter)

在專案開始前對齊各方認知:包含範疇、排除事項、風險與里程碑。

請為 [公司名稱] 撰寫 [專案名稱] 的專案定義書。專案目標:[目標]。發起人:[發起人]。團隊成員:[成員組成]。預算:[預算金額]。預計結案日期:[日期]。專案背景:[背景說明]。

結構要求:
1. 背景與待解決問題(3 行內)。
2. 可衡量的具體目標。
3. 納入範疇(Scope In)。
4. 明確排除範疇(Scope Out):請詳細列出,以防止後期範疇蔓延。
5. 交付物與驗收標準。
6. 關鍵里程碑與日期。
7. 角色與職責分配(誰決策、誰執行、誰諮詢、誰知會)。
8. 已知風險與應對方案(針對 [預期風險])。
9. 前提假設與外部依賴項。

撰寫原則:每一節的表述應力求精確,確保若有異議能在審閱階段立即浮現,而非專案中途才爆發。最後請列出 3 個在啟動會議前必須由委員會裁決的關鍵問題。

將會議草稿轉化為行動導向紀錄

從雜亂的筆記中提煉出精簡的決策事項與指派任務。

請將我的會議草稿轉換為結構化的會議紀錄。會議主題:[主題],日期:[日期],與會者:[名單]。以下是原始筆記:[筆記內容]。

輸出格式:
1. 已達成決策:表述須清晰無歧義,並註明決策者。
2. 行動清單(表格形式):行動項目、負責人、截止日期。若筆記中缺少其中一項,請標註「待確認」而非自行捏造。
3. 討論重點(未達成決策):每項最多 2 行。
4. 追蹤事項:下次討論日期。

規則:總長度不超過一頁。嚴禁使用模糊的官腔(如「已達成共識將持續推進」),必須保留原始意圖。最後列出所有標註為「待確認」的項目,以便發送給與會者確認。

專案工作分解與時程規劃

將大目標拆解為工作包、任務、依賴關係與關鍵路徑。

請將以下專案拆解為工作包並建立時程表。專案:[專案描述與最終交付物]。截止日期:[日期]。可用人力:[成員與工時,例如:2 位成員各 50% 工時]。已知限制:[如:客戶驗收期、供應商交付期、國定假日]。

執行步驟:
1. 拆解為可驗證的「工作包」(Work Packages),避免「協調」等模糊項目。
2. 將工作包細分為 0.5 至 3 天的具體任務。
3. 識別任務間的依賴關係與關鍵路徑(Critical Path)。
4. 在高風險任務中加入顯性緩衝時間,而非隱藏在每項任務中。

交付內容:結構化的任務清單與預估工時、每週進度里程碑、關鍵路徑標註,以及 3 個必須立即啟動的關鍵任務。若根據人力配置發現 [日期] 無法達成,請以數據說明原因,嚴禁盲目壓縮工時。

撰寫專案週報 (Flash Report)

決策者真正會看的單頁週報:包含狀態燈號、事實與待決策事項。

請為 [專案名稱] 撰寫一份發送給 [收件人,如:指導委員會] 的週報。本週數據:進度 [實際 vs 預期]、困難 [遭遇問題]、風險變化 [風險動態]、預算執行 [已支用 vs 預算]、待決策事項 [卡關項目及延遲天數]。

嚴格格式要求(單頁):
1. 專案燈號(綠/黃/紅):用一句話說明燈號原因。
2. 本週 3 大重點事實。
3. 進度追蹤:每個執行中的工作包各佔一行。
4. 風險與痛點:僅列出與上週相比有變化的部分。
5. 待決策事項:註明決策者姓名與延遲後果。
6. 下週優先事項。

規則:未解決根本問題前,燈號不得轉綠;連續兩週黃燈必須轉為紅燈;待決策事項需標註初始請求日期。

主持專案結案回顧會議

準備一場有意義的結案回顧:流程、關鍵提問與可執行的教訓。

請為 [專案名稱] 準備結案回顧會議規劃。專案結果:[如:準時完成、延遲 X 天、終止]。參與者:[名單與角色]。時長:[如:90 分鐘]。專案亮點與痛點:[發生的好壞事、潛在衝突]。

交付內容:
1. 分鐘級流程(開場需強調「對事不對人」、個人意見收集、集體討論以避免從眾效應、決策)。
2. 具體提問清單:避免空泛問題,例如「我們何時發現進度開始失控?當時是什麼阻礙了我們及時通報?」
3. 針對 [敏感話題] 的引導技巧,確保討論不演變成批鬥大會。

輸出格式:將每個教訓轉化為下個專案的「可執行規則」(例如:從現在起我們必須...),並指派規則維護負責人。規則上限 5 條,以確保能被落實。

撰寫專案可行性研究與評估

結構化的 Go/No-Go 報告:目標、方案、成本、風險與決策準則。

你是一位資深專案總監。請協助我為 [公司名稱] 的 [專案名稱] 建立可行性研究。背景:[問題或機會]。預期效益:[效益]。最大預算上限:[金額]。已知替代方案:[如:維持現狀、外包等]。

報告結構:
1. 待解決問題與「不作為」的代價。
2. 可行方案對比(含現狀):列出優缺點。
3. 粗估成本與時程(以區間表示)。
4. 效益與可衡量指標的關聯。
5. 各方案的主要風險。
6. 最終建議與理由。

限制:每個效益必須對應一個可驗證的指標,否則歸類為「無法衡量的假設」。制定 5 個供委員會核取的 Go/No-Go 決策準則。最後列出目前缺失的資訊及其提供者。

撰寫精簡版專案章程

適用於小型專案的單頁章程,避免過於繁重的文書作業。

請為一個小型專案撰寫單頁章程。專案描述:[兩句話說明]。發起人:[姓名]。參與人員:[名單與投入工時]。期望截止日:[日期]。預算:[金額或無]。

格式要求(限一頁):
1. 一句話說明的衡量目標。
2. 最終交付物與驗收標準。
3. 排除範疇(至少 3 行,這是最重要的部分)。
4. 最終裁決者。
5. 里程碑(最多 3 個)。
6. 核心風險與對策。

規則:嚴禁使用專業術語,確保非專案管理人員也能一眼看懂。若輸入資訊不足,請標註「待與 [人員] 確認」而非虛構。最後列出 2 個啟動前必須詢問發起人的關鍵問題。

準備需求訪談大綱

針對不同角色的訪談指南,在界定範疇前挖掘真實需求。

我正在啟動 [專案名稱],需要收集需求。訪談對象:[角色名單,如:主管、第一線使用者、IT]。預計交付物:[初步想法]。每場訪談時間:[時長]。

請為每個角色設計訪談指南:包含 8-10 個由淺入深的開放式問題。區分「現狀評估」(痛點、繞道做法、業務量)與「未來需求」。為每個角色設計 2 個「陷阱題」以挖掘潛在需求,例如:「當現有工具無法滿足你時,你具體會怎麼做?」

限制:禁止引導式問題或是非題。提供一個彙整模板:包含已表達需求、隱含需求、角色間的矛盾點,以及關鍵原音紀錄(Verbatim)。

撰寫使用者故事與驗收標準

將原始需求轉化為可測試的使用者故事與明確的驗收準則。

請將以下原始需求轉化為執行團隊可用的 User Stories。專案:[簡述]。使用者角色:[角色]。原始需求:[需求清單]。

針對每項需求輸出:
1. User Story 格式:「身為 [角色],我想要 [執行動作],以便於 [獲得價值]」。
2. 3-5 個二元化(是/否)驗收標準,嚴禁使用「快速」、「美觀」等模糊詞彙。
3. 若需求太模糊,請列出需詢問發起人的問題。

限制:每條 Story 應能在數日內完成,否則請建議拆解方案。識別並修正「偽裝成需求的解決方案」。以表格呈現:Story、驗收標準、預估規模 (S/M/L)、開放性問題。最後列出 Story 間的依賴關係。

待辦清單 (Backlog) 優先順序評估

根據價值與投入成本進行排序,讓決策透明且具說服力。

請協助我為 [專案名稱] 的待辦清單排序。待辦項目:[清單與簡述]。團隊產能:[如:每月 15 人日]。本季首要目標:[目標]。壓力來源:[政治背景或特定主管要求]。

評估維度:
1. 價值(對目標的貢獻、受影響人數、不解決的成本)。
2. 相對投入成本。

分類建議:
- 立即執行(高價值、低成本)。
- 需規劃(高價值、高成本)。
- 填補空隙(低價值、低成本)。
- 明確拒絕或延後(低價值、高成本)。

規則:主管壓力不等於價值,但請單獨列出拒絕這些請求時所需的溝通話術。以表格呈現排序與理由,並針對 3 個最棘手的拒絕請求撰寫簡短、事實導向的說明信件。

建立季度產品路線圖 (Roadmap)

以成果為導向的季度規劃,並說明每個選擇背後的邏輯。

請為 [公司名稱] 的 [產品/專案] 建立未來兩季的 Roadmap。年度目標:[目標]。候選項目:[項目清單]。團隊產能:[規模與可用性]。已承諾事項:[不可更動的內外部承諾]。

規劃原則:
1. 以「預期結果」而非功能來描述(例如:寫「縮短申請處理時間」而非「開發 X 模組」)。
2. 每季最多 2-3 個大項目。
3. 註明衡量指標與依賴項。

限制:保留 20% 產能應對突發狀況並明確標註。列出刻意排除的項目及其原因,以應對「為什麼不做 X」的質疑。提供兩個版本:團隊詳細版與管理層 5 行精簡版。標註價值模糊、暫不排入的項目。

專案工時預估與風險校正

使用區間預估法,揭露假設條件並修正樂觀偏誤。

請協助我預估 [專案名稱] 的工時。內容:[工作包清單]。團隊:[角色與經驗]。歷史參考:[類似專案的實際耗時,若有]。

針對每個工作包提供:
1. 區間預估(樂觀、可能、悲觀)。
2. 前提假設(預估成立的條件)。
3. 導致悲觀情境發生的關鍵因素。

規則:若有歷史數據,請對比預估值與實際值的落差並解釋原因。必須加入常被遺忘的隱形成本:驗收後的修正、協調溝通、技術學習曲線、預期請假。以 3 種情境呈現總工時,並計算樂觀與悲觀間的百分比差距。若差距超過一倍,請指出哪些資訊能降低不確定性。

建立專案預算與每月追蹤機制

完整的預算分類、實支追蹤與預警機制。

請為 [公司名稱] 的 [專案名稱] 建立完整預算表。內部人力:[角色、人日、日薪]。外部採購:[清單]。時長:[時長]。核定總額:[金額]。

輸出內容:
1. 預算明細:內部人力價值、外部服務、授權工具、雜支,以及根據不確定性設定的預備金(Contingency Reserve)。
2. 預算追蹤模板:實支 vs 預算、重新預估的完工尚需成本(ETC)、完工預估總成本(EAC)。
3. 預警機制:設定兩個觸發發起人通報的門檻值。

最後列出此類專案最常見的 3 個超支陷阱及早期識別方法。確保在規劃階段就識別出任何超支風險,而非中途才發現。

建立專案風險登記簿 (Risk Register)

量化優先順序的風險清單,包含預防措施與負責人。

請為 [專案名稱] 建立風險登記簿。背景:[描述、截止日、重要性]。已知風險:[清單]。外部依賴:[供應商、跨部門協作]。

請補充我未提到的典型風險,涵蓋四大類:人員(離職、過載、技能缺失)、技術、組織(決策緩慢、範疇蔓延)、外部環境。針對每個風險提供:
1. 具體情境描述。
2. 機率與衝擊(低/中/高)。
3. 關鍵預警指標。
4. 預防措施與緊急應變計畫(Fallback Plan)。
5. 監控負責人。

規則:風險必須描述為具體事件(如「供應商延遲一個月交貨」),而非模糊主題。僅保留前 10 大核心風險。說明審閱頻率與關鍵檢視問題。

專案利害關係人地圖

分析影響力與支持度,並制定對應的溝通參與計畫。

請為 [公司名稱] 的 [專案名稱] 進行利害關係人分析。已識別對象:[名單與角色]。專案對其影響:[影響]。目前態度:[支持或阻力]。

分析維度:
1. 影響力(能否阻礙或加速專案)。
2. 支持度(支持、中立、反對)。

針對具影響力的對象:分析其利益得失、可能的反對理由,以及參與策略(如:參與決策、定期通報、私下溝通)。

限制:區分職稱與實質影響力,標註無職位但具話語權的人。以表格呈現參與計畫:對象、現狀、目標位置、行動、負責人、截止日。最後列出本週應優先拜訪的 2 位對象及其原因。

制定專案溝通計畫

明確誰需要資訊、內容為何、頻率與管道,避免資訊過載。

請為 [專案名稱] 制定溝通計畫。目標受眾:[如:發起人、團隊、受影響使用者、其他部門]。專案時長:[時長]。關鍵時刻:[里程碑、系統上線]。可用管道:[LINE、Email、會議、公告欄]。

針對每個受眾定義:核心資訊需求、頻率、管道、格式(短訊、單頁報告、會議)及訊息製作者。區分「例行溝通」(進度)與「事件溝通」(啟動、上線、事故、結案)。

規則:每項溝通必須回答受眾的「這對我有什麼影響?」,否則予以刪除。提供啟動與上線的訊息草稿。以表格呈現計畫,並列出 3 個常見溝通錯誤及此計畫如何規避。

建立專案 RACI 權責矩陣

明確劃分職責,消除灰色地帶並識別角色衝突。

請為 [專案名稱] 建立 RACI 矩陣。主要活動:[清單]。參與者:[人員或職能]。已知模糊地帶:[如:兩個人都認為自己有決定權]。

分配角色:R(執行)、A(負責/決策,每行僅限一人)、C(諮詢)、I(知會)。針對非顯而易見的分配提供一行說明。

品質檢查規則:嚴禁一行出現兩個 A、嚴禁無 R 的行。標註過度諮詢的對象(C 過多可能成為瓶頸)或無角色的對象。以表格呈現,並列出 3 個最可能產生衝突的項目及建議對策,以及在團隊會議中需對齊的問題。

準備專案啟動會議 (Kick-off)

設計一場能對齊團隊認知並激發參與感的啟動會議流程。

請準備 [專案名稱] 的啟動會議規劃。參與者:[名單]。時長:[如:1 小時]。目前狀態:[定義書已簽核或進行中]。敏感點:[如:過去失敗的陰影、團隊懷疑論]。

交付內容:
1. 分鐘級流程(目標意義、最終成果、範疇外事項、分工、里程碑、團隊運作規則、Q&A)。
2. 與會者離開會議時必須記住的 3 個核心訊息。
3. 處理 [敏感點] 的話術,確保不迴避也不影響士氣。

規則:啟動會議不應只是單向宣導,設計 2 個互動環節(如:現場風險識別、個人限制分享)。提供包含議程的邀請函草稿,以及啟動前必須確認的核取清單。

主持指導委員會 (COPIL) 會議議程

聚焦於決策而非單純報告進度的高效率會議規劃。

請準備 [專案名稱] 的指導委員會議程。參與者:[委員名單]。時長:[時長]。專案現況:[進度、困難、預算]。需要的決策:[待決策項與選項]。可能偏離主題的敏感話題:[話題]。

議程設計原則:以「決策」為核心。每個待決策項需分配時間、準備 2-3 個方案(含優缺點與建議),並說明若延遲決策的後果。進度報告限 10 分鐘內,並以會前資料為主。

提供:分鐘級議程、各項決策請求的精確措辭、禮貌中斷 [敏感話題] 離題討論的技巧,以及 24 小時內發送的決策紀錄模板。列出會前 48 小時需發送的資料清單。

指導委員會 (COPIL) 簡報結構設計

以 10 頁投影片為限,結構清晰且具決策導向的報告框架。

請為 [專案名稱] 設計指導委員會簡報大綱。本月數據:進度 [實際 vs 預期]、預算 [實支 vs 預算]、風險變化、待決策事項、本月大事記。

投影片結構(上限 10 頁):
1. 總結頁(燈號、核心訊息、待決策項)。
2. 各工作包進度與偏差分析。
3. 預算執行趨勢。
4. 風險評級變動。
5. 本月核心痛點深入分析(含方案建議)。
6. 決策請求(一頁一項)。
7. 後續步驟。

撰寫要求:標題必須是「訊息」而非標籤(如:「工作包 2 進度已追回」而非「工作包 2 進度」)。每頁最多 5 個重點。嚴禁重複已知的背景資訊。數據需四捨五入並與上月對比。最後進行測試:若委員只看第一頁,是否能掌握核心?

建立變更管理機制 (Change Request)

簡單有效的流程來處理範疇異動,防止專案無限擴張。

請為 [專案名稱] 建立變更管理機制。背景:[如:客戶隨意加需求、主管朝令夕改]。現有會議:[現有組織]。可用緩衝:[剩餘時間與預算]。

定義內容:
1. 最簡變更申請單(描述、申請人、理由、緊急度)。
2. 四大評估問題(時程影響、預算影響、對其他模組影響、不做的後果)。
3. 權限劃分(根據影響程度決定誰有權核准)。
4. 變更登記簿追蹤方式。

撰寫 3 種回覆模板:接受並說明影響、延至下期、拒絕並說明理由。規則:流程必須控制在半頁內,嚴禁口頭答應任何變更。最後說明如何向強勢的申請人介紹此機制而不引發反彈。

與發起人協商不合理的截止日期

當期限無法達成時,準備數據導向的論點與替代方案。

請協助我準備針對不合理期限的協商。專案:[名稱]。要求日期:[日期]。我的評估:需要 [真實時長],原因:[工時預估、依賴項、人力]。發起人關注點:[其在意的重點]。日期背後的意義:[若已知,請註明原因]。

內容要求:
1. 事實導向的落差證明(需求 vs 產能,使用簡單數據)。
2. 三種誠實的選項:縮減範疇以保日期(明確列出捨棄項)、維持範疇並延後日期、增加資源(需註明成本與新人的學習曲線限制)。

規則:嚴禁只說「不可能」而不給方案,嚴禁在會議中接受未經數據驗證的折衷方案。準備應對發起人 3 種常見質疑(如:「你自己想辦法」、「到時候再說」)的回答話術。格式:單頁論述加上三種選項的影響對照表。

制定專案趕工計畫 (Recovery Plan)

診斷延遲原因並建立現實的追趕計畫,而非盲目壓縮時程。

請為 [專案名稱] 制定趕工計畫。目前進度落後 [天數],目標日期為 [日期]。延遲原因:[原因]。剩餘工作:[清單與預估]。人力:[配置]。可調用資源:[額外預算、範疇彈性]。

執行步驟:
1. 診斷核心問題:預估過低、範疇蔓延、資源被挪用或外部卡關?
2. 使用真實槓桿制定計畫:縮減非核心範疇、調整任務順序以增加並行度、刪除冗餘任務、僅在關鍵路徑上增援。

規則:嚴禁在無理由的情況下直接壓縮剩餘工時,嚴禁刪除必要的驗收時間。交付內容:新的可靠時程表、為此犧牲的項目、計畫成立的 2 個前提條件,以及向發起人通報延遲且承擔責任的訊息草稿。

向發起人進行問題呈報 (Escalation)

事實導向的呈報訊息,包含選項與不作為的代價,即發即用。

請準備 [專案名稱] 的問題呈報訊息。卡關點:[如:決策遲遲未下、資源未到位、跨部門糾紛]。持續時間:[天數]。已嘗試努力:[追蹤紀錄]。呈報對象:[層級]。涉及人員:[相關人與潛在敏感度]。

撰寫要求:
1. 3 行內的事實性描述(含日期)。
2. 不作為的具體後果(損失天數、成本、威脅到的里程碑)。
3. 2-3 個建議方案與我的推薦選項。
4. 明確的決策請求與期限。

規則:不涉及人身攻擊,讓事實與日期說話。確保對象只需閱讀此訊息即可決策,無需額外開會。提供 60 秒口頭報告版本,以及給相關人員的知會訊息,避免其感到被「越級打小報告」。

建立會議間的行動追蹤機制

確保任務落實的追蹤系統,避免過度催促引發反感。

請為 [專案名稱] 設計會議間的行動追蹤系統。現狀:[如:決策後執行率低、催促被視為監視]。會議頻率:[頻率]。可用工具:[Excel、LINE、專案軟體]。

系統設計:
1. 行動登記簿格式(動詞開頭的任務、唯一負責人、期限、狀態)。
2. 更新機制(誰更新、何時更新、耗時多久)。
3. 階梯式提醒機制:期限前 2 天自動提醒、到期當天事實性私訊、第二次逾期才在會議中點名。

撰寫 3 個層級的提醒訊息模板,要求簡短且不帶指責。規則:拒絕無期限或無唯一負責人的任務;登記簿內容不得超過團隊產能。最後說明如何向團隊介紹此系統,強調其目的是協助而非監控。

設計專案儀表板指標

反映真實趨勢的關鍵指標,而非虛假的控制感。

請為 [專案名稱] 設計儀表板。專案性質:[類型與交付物]。時長:[時長]。監控重點:[如:時程緊迫、預算吃緊、品質要求]。可用數據:[來源]。

選擇 6-8 個核心指標,分為三大塊:
1. 進度(已完成交付物 vs 預期,嚴禁使用「任務完成 80%」等主觀百分比)。
2. 健康度(逾期行動數、待決策項天數、風險評級上升數)。
3. 資源(預算執行率、團隊負載)。

針對每個指標定義:計算公式、數據源、更新頻率、預警門檻。規則:指標必須對應可執行的動作(若變紅燈該做什麼),否則予以刪除。描述每週 15 分鐘的儀表板檢視流程:閱讀順序、關鍵問題、通報時機。

撰寫給管理層的月度進度報告

單頁完結的月報:包含趨勢、決策與預警。

請為 [專案名稱] 撰寫給 [管理層/委員會] 的月報。本月數據:達成事項、偏差(延遲或超支)、預算、風險動態、已決策項、預警點。

格式要求(限一頁):
1. 總體趨勢(2 句話說明專案是否能如期如質完成)。
2. 本月達成里程碑(3 個重點)。
3. 偏差說明與對策(嚴禁只有問題沒有方案)。
4. 預算執行與完工預測。
5. 需要管理層介入的預警(明確的決策請求)。

規則:管理層需閱讀多份報告,嚴禁自我表揚或廢話。壞消息與偏差應優先列出,不得隱藏在頁尾。每項預警必須導向具體請求(資源、裁決、決策)。

多專案資源協調與優先級仲裁

跨專案的資源分配方法,使每個決策的後果透明化。

請協助我在多個競爭專案間進行資源仲裁。專案清單:[名稱、截止日、重要性、進度]。共享資源:[人員名單與目前分配]。衝突點:[描述]。最終裁決者:[角色]。

執行步驟:
1. 建立真實的資源占用圖(百分比表示,標註負載超過 100% 的成員)。
2. 建立仲裁準則:企業策略關聯度、延遲成本、不可逆性(時機窗口)、外部承諾。
3. 針對當前衝突提出 2 種分配情境,並明確列出每種情境下各專案的得失及最終完工日期。

規則:嚴禁透過超時加班或承諾無法達成的兼職來解決衝突。選定的方案必須能向「落選」的專案經理合理解釋。輸出仲裁建議與溝通話術。

準備 Sprint 衝刺計畫會議

設定明確目標與真實產能,確保團隊能兌現承諾。

請準備 [團隊名稱] 在 [專案名稱] 的下一個 Sprint 計畫。時長:[週數]。產能:[人數、預期請假、常態性瑣事時間]。優先待辦項:[清單與估算]。上個 Sprint 遺留項:[清單]。

流程設計:
1. 計算真實產能(總時數扣除會議與瑣事,使用簡單公式)。
2. 制定 Sprint 目標(一句話描述本階段產出的成果,而非清單)。
3. 根據產能選取項目,優先處理遺留項。
4. 確認每項任務皆定義清晰且可立即執行。

規則:拒絕無驗收標準的項目。若需求方壓力超過產能,必須進行項目取捨,嚴禁默許超載。交付會議流程、目標措辭,以及 3 個顯示承諾可能跳票的早期訊號。

主持具行動力的 Sprint 回顧會議

精簡且持續的回顧格式,透過變換形式避免儀式感疲勞。

請準備 [團隊名稱] 的 Sprint 回顧會議。時長:[如:45 分鐘]。目前氛圍:[如:大家都不說話、近期有衝突、新團隊]。本期事件:[大事記]。前期行動執行狀況:[真實進度]。

交付內容:
1. 分鐘級流程(先檢視前期行動,若行動未落實,回顧會議將失去意義)。
2. 針對 [目前氛圍] 選擇合適的引導格式(如:Start/Stop/Continue)。
3. 當討論流於表面時的追問技巧。
4. 決策機制:最多選出 2 項改進行動,需有負責人與下個 Sprint 的期限。

規則:嚴禁「加強溝通」等模糊行動,必須是可觀察的改變。超出團隊權限的問題應記錄並呈報,而非反覆抱怨。提供 2 種備選格式以供未來輪替使用。

優化每日站立會議 (Daily Standup)

確保每日同步會議聚焦於排除障礙,而非流水帳報告。

請優化 [團隊名稱] 在 [專案名稱] 的每日站會。現狀:[如:開太久、變成向主管報告、有人放空]。團隊人數:[人數]。工作模式:[實體/遠端/混合]。

目標格式建議:
1. 嚴格限時與固定時間。
2. 內容聚焦協作:昨天完成什麼、遇到什麼阻礙、需要誰協助。
3. 非協作議題(技術細節、問題解決)記錄後會後討論。

提供:防止變成「報告大會」的引導規則(如:輪流主持)、禮貌中斷離題的話術、針對 [工作模式] 的調整建議,以及 3 個站會失效的訊號與修正對策。最後撰寫一份向團隊宣佈新格式的訊息,說明目的而非否定過去。

定義「完成」標準 (Definition of Done)

建立團隊共識的完成標準,避免「完成 90%」卻遲遲無法交付的情況。

請協助 [團隊名稱] 為 [專案名稱] 制定「完成定義」(DoD)。交付物類型:[如:軟體功能、培訓教材、研究報告]。現有問題:[如:宣布完工後又重啟、品質不一、驗收發現漏洞]。

內容要求:
1. 三個層級的標準:核心完成標準(可驗證項:如同儕審閱、測試通過、文件完備)、明確排除項(以保持現實)、例外處理規則。

限制:最多 8 項標準,必須全是「是/否」題。嚴禁設定團隊目前資源無法達成的標準。交付內容:引導團隊達成共識的工作坊方法、對既有工作的追溯規則,以及數週後的審閱機制。

規劃使用者驗收測試 (UAT) 與紀錄

包含優先級測試案例、異常分類規則與決策紀錄。

請規劃 [專案名稱] 的使用者驗收測試。交付物:[描述]。測試者:[角色與可用性]。預計時長:[時長]。現有驗收標準:[若有]。

內容要求:
1. 測試計畫:按真實使用者路徑(而非功能模組)設計案例,包含輸入、動作、預期結果。
2. 案例優先級(阻斷級、重要、優化)。
3. 異常分類規則(Bug 分級範例),避免無謂爭論。
4. 修正與複測流程。

交付驗收紀錄 (PV) 模板:測試範圍、各級異常統計、最終決策(接受、附帶條件接受、拒絕)及簽署位。規則:無真實數據的測試無效,說明如何準備測試資料。附帶條件接受必須有負責人與期限。

準備系統上線計畫與核取清單

小時級的上線流程、Go/No-Go 準則與回滾計畫。

請為 [專案名稱] 的 [交付物/系統] 準備上線計畫。目標日期:[日期]。受影響使用者:[人數]。作業窗口:[如:週末凌晨]。執行人員:[角色]。是否可回滾:[是/否/部分]。

內容要求:
1. 上線前核取清單(技術前提、簽核、備份驗證、人員就位)。
2. 小時級執行流程:註明負責人與可觀察的成功指標。
3. Go/No-Go 決策點:誰決定、依據為何。
4. 回滾計畫(Rollback):觸發訊號與具體步驟(需與上線流程同等詳細)。
5. 上線後首日監控計畫。

限制:每步必須有可驗證指標,嚴禁「應該沒問題」等描述。最後撰寫上線前後給使用者的通知訊息。

確保遷移期間的業務連續性

規劃新舊系統並行期間的過渡方案與風險控管。

請規劃 [公司名稱] 從 [舊系統/流程] 遷移至 [新系統/流程] 的業務連續性方案。預計過渡期:[時長]。不可中斷的關鍵業務:[項目]。受影響團隊:[團隊]。已知高風險時段:[如:月底結帳、旺季]。

核心問題處理:
1. 並行期間的資料權威性(Single Source of Truth):各情境下以哪套系統為準?
2. 如何避免或優化重複輸入?
3. 跨系統未結案單據的處理流程。
4. 最終切換時的資料凍結與同步機制。

交付內容:關鍵業務過渡矩陣、權威性規則表、首週強化支援機制,以及 3 個最可能的事故情境應對預案。

專案結案與經驗傳承

行政、合約與文件結案核取清單,確保專案完美收尾。

請為 [專案名稱] 準備結案清單。驗收日期:[日期]。專案元素:[廠商、預算、文件、團隊]。遺留問題:[待處理項]。

結案核取清單要求:
1. 合約維度(廠商結案、保固確認、外部權限回收)。
2. 財務維度(停止報帳、實支 vs 預算分析)。
3. 文件維度(歸檔路徑、兩年後仍需被找到的關鍵文件)。
4. 人員維度(團隊解編通報、正式致謝)。
5. 移交維度(維運負責人與支援流程)。

規則:區分「結案必要項」與「後續優化項」。設定強制的結案日期,避免「98% 完成」的專案拖延數月。提供單頁結案報告模板:關鍵數據、成功點、偏差分析、教訓歸檔處。

專案經理交接規劃

建立交接文件與重疊期計畫,確保專案管理不中斷。

請規劃 [專案名稱] 在 [離任 PM] 與 [接任 PM] 間的交接。背景:[原因與預告期]。專案狀態:[進度、痛點、近期里程碑]。重疊期:[時長或無]。

交接文件重點:聚焦於「文件中找不到的資訊」,包含決策背後的真實原因、與發起人的口頭承諾、利害關係人的敏感度與政治角力、PM 私下監控的潛在風險、各工作包的真實健康狀況(非官方報告版)。

規劃重疊期:關鍵會議引薦(發起人、客戶、團隊)、資訊傳遞優先順序、對外通報訊息(確保穩定感)。限制:交接必須可驗證,列出接任者在交接結束時應能獨立回答的問題清單。未竟事項需註明緊急聯繫人。

新進專案成員引導 (Onboarding)

讓新成員快速進入戰鬥狀態的引導流程,減少團隊負擔。

請為加入 [專案名稱] 的新成員 [角色] 準備兩週引導計畫。專案狀態:[進度]。預期職責:[任務]。團隊輔導時間:[限制]。

兩週規劃要求:
1. 首日必讀包(精簡版定義書、最新週報、風險登記簿、術語表)。
2. 4 場關鍵人員訪談及其目標。
3. 首週內可獨立完成的小型貢獻任務。
4. 指定導師(Buddy)與每日 10 分鐘同步。
5. 揭露非正式資訊:決策權力地圖、敏感話題。

規則:嚴禁只有被動參加會議,必須透過執行來學習。提供兩週時程表、閱讀清單,以及第 15 天用來驗證引導成效的自我檢核問題。

處理專案團隊成員衝突

三階段調解流程,處理影響專案進度的內部摩擦。

請協助我處理 [專案名稱] 團隊中的衝突。事實描述:[雙方衝突點,不帶主觀判斷]。專案影響:[如:資訊斷層、會議氣氛僵化、延遲]。我的角色:[有/無行政隸屬關係的 PM]。衝突歷史:[背景]。

三階段調解建議:
1. 個別面談:如何引導雙方說出版本而不偏袒、避免陷入是非評判的陷阱。
2. 共同面談:開場規則設定、如何將話題導回事實而非人身攻擊、達成 2-3 項具體協作規則。
3. 後續追蹤:如何在不給予壓力的情況下觀察改善狀況。

規則:嚴守 PM 角色,涉及 HR 或考績範疇應明確區分並呈報。確保雙方在團隊面前都不被貼上「犯錯者」標籤。列出必須立即呈報主管的嚴重衝突訊號。

外部供應商績效導正溝通

從事實通報到準備退場的階梯式溝通策略。

請協助我針對 [專案名稱] 中表現不佳的供應商進行溝通。供應商:[名稱與服務]。偏差事實:[含日期的具體事件:延遲、品質問題、承諾跳票]。合約背景:[交付物、罰則]。依賴度:[是否易於更換]。

階梯式策略:
1. 導正會議:準備事實清單(承諾 vs 實際),要求限期提交改善計畫。
2. 強化監控:縮短里程碑、明確的退場觸發條件、每次溝通後的書面紀錄。
3. 替代方案準備:若依賴度高,需啟動備選方案評估。

規則:所有口頭溝通後必須有書面紀錄以利法律保護。保持事實與合約導向,嚴禁無法執行的威脅。提供偏差清單表格、會議召集信、議程大綱及決策準則。

撰寫採購需求說明書 (RFP)

描述需求與限制而非指定方案,以獲得最佳供應商提案。

請為 [公司名稱] 的 [採購標的] 撰寫需求說明書。核心需求:[待解決問題]。技術與組織背景:[現狀與限制]。預算區間:[金額或不公開]。時程:[截止日]。

結構要求:
1. 公司與背景簡介(半頁)。
2. 目標與預期結果(描述「需求」而非「方案」)。
3. 範疇與排除項。
4. 不可協商的限制(技術規格、法規、日期)。
5. 交付物清單。
6. 評選準則與權重。
7. 招標流程與回覆格式。

規則:每項要求必須在驗收時可測試。區分「必須滿足」與「加分項」。最後列出 5 個在提案說明會中能測出供應商是否真正理解需求的關鍵提問。

供應商提案客觀評分表

加權分析表,避免被精美的簡報誤導,聚焦於實質內容。

請為 [採購標的] 建立供應商提案評分表。候選方案:[數量與簡述]。我們重視的指標:[如:時程穩定、售後支援、總持有成本]。觀察到的訊號:[如:報價異常低、回覆過於籠統]。

評分表設計:
1. 維度劃分:需求理解度、方案可行性、實際投入團隊資歷、總持有成本(含隱藏成本)、類似案例實績、合約條款。
2. 權重分配理由。
3. 評分量表定義(降低主觀性)。

分析建議:識別異常低價背後的範疇缺失、確認簡報人員是否為實際執行人員、列出各家需澄清的問題。交付對照表、澄清信件模板及 5 行內的推薦總結。

制定專案變革管理計畫

針對不同受眾的引導方案,從內部種子人員到上線後支援。

請為 [公司名稱] 的 [專案名稱] 制定變革管理計畫。受影響群體:[群體名單、人數及改變內容]。預期阻力:[擔憂點]。上線時程:[關鍵日期]。可用資源:[預算、種子人員]。

針對每個群體分析:具體改變(獲得與失去的利益,隱瞞損失會導致後期反彈)、所需支援程度(資訊、培訓、現場指導)、核心溝通訊息。

階段規劃:
- 前期:宣導、建立具公信力的種子人員網絡、培訓。
- 中期:強化支援、收集痛點、快速修正並通報。
- 後期:衡量真實使用率(而非培訓率)、處理殘餘阻力。

規則:嚴禁只有「加強溝通」的空洞計畫。每項行動需有負責人與日期。以表格呈現群體分析與整合時程表。

設計使用者培訓計畫

以真實場景為核心的分類培訓,並以實際使用狀況衡量成效。

請為 [公司名稱] 的 [新工具/流程] 設計培訓計畫。使用者:[角色、人數、資訊素養、地理分佈]。核心技能:[各角色需學會的操作]。限制:[產能、預算、上線日]。

計畫要求:
1. 分類培訓而非通用課程:針對各角色挑選 5-10 個核心操作場景(而非功能全覽)。
2. 合適格式建議(小組課、影音教材、現場輔導)。
3. 留存教材設計(單頁式任務卡而非厚手冊)。

規劃原則:培訓應緊鄰上線日,過早培訓會導致遺忘。建立缺席補課機制與種子人員支援網絡。限制:以「上線後真實使用狀況」衡量成功,而非「出席率」。交付培訓矩陣與優先教材清單。

專案危機溝通處理

針對不同對象的危機訊息,從首報到問題解決的完整序列。

專案 [專案名稱] 發生重大事故:[事故內容,如:上線失敗、資料遺失、服務中斷]。影響範圍:[對象與程度]。處理進度:[已知與未知]。受眾:[管理層、內部團隊、客戶、夥伴]。

撰寫溝通序列:
1. 首報訊息:快速發送,說明已知事實、處理中動作、下次通報時間(承諾通報時間而非修復時間)。
2. 進度更新:即使無新進展也需按時通報。
3. 結案訊息:說明解決方案與預防再發措施。

針對不同受眾調整重點:管理層關注影響與決策,使用者關注替代方案,客戶關注權益保護。規則:嚴禁推測原因、嚴禁指責、嚴禁無法兌現的期限承諾。交付訊息草稿與溝通權責規則。

撰寫團隊 OKR (目標與關鍵結果)

與公司目標對齊的季度目標,包含可衡量的關鍵結果。

請協助 [公司名稱] 的 [團隊名稱] 撰寫 [季度] OKR。公司本季優先事項:[事項]。團隊常態職責:[內容]。候選項目:[想法]。團隊人數:[人數]。

輸出要求:
1. 最多 2-3 個目標 (Objectives):具啟發性但具體,與公司目標掛鉤。
2. 每個目標對應 2-4 個關鍵結果 (Key Results):必須可衡量(從 X 提升至 Y)、衡量「結果」而非「活動」(如:寫「處理時效縮短至 X」而非「導入 Z 工具」)。

規則:常態營運 (Run) 不納入 OKR,應另行監控;無法衡量其數據來源的 KR 應予捨棄。標註團隊控制力不足的目標。交付 OKR 提案、團隊工作坊討論題,以及 15 分鐘的追蹤儀式建議。

主持季度 OKR 回顧會議

誠實評分、總結教訓並規劃下一季的季度回顧。

請準備 [團隊名稱] 的季度 OKR 回顧會議。本季 OKR:[目標與達成率]。重大事件:[如:突發狀況、優先級調整]。參與者:[名單]。時長:[時長]。

會議結構:
1. 誠實評分:基於真實數據(未衡量的視為未達成)。
2. 偏差分析:區分執行問題、目標設定過高或外部因素(原因不同,對策就不同)。
3. 下季決策:延續、放棄或重新校準。

規則:回顧會議不是辯解大會,嚴禁背景說明簡報,直接進入數據。100% 達成可能代表野心不足,20% 達成則需檢討執行力。交付會議流程、評分表、分析提問清單及會後總結訊息草稿。

主持事故檢討會議 (Post-mortem)

不尋找戰犯的事故分析,聚焦於系統性原因與預防措施。

請為 [專案名稱] 在 [日期] 發生的 [事故描述] 準備 Post-mortem。已知時序:[事件流程]。參與人員:[名單]。目前氣氛:[如:有人感到被針對、管理層在找戰犯]。

結構建議:
1. 集體重建事實時序(逐小時記錄,不帶詮釋)。
2. 原因分析:超越個人錯誤,探討系統漏洞(為何錯誤會發生?為何防護機制沒攔截?)。
3. 檢視應變過程中的亮點。
4. 預防行動計畫。

開場規則:明確聲明「對事不對人」,尋找系統漏洞而非戰犯。承認錯誤者應受鼓勵。限制:最多 5 項行動,優先選擇能「從機制上消除錯誤」的方案,而非要求「更加細心」。交付文件模板與會議流程。

將經驗教訓轉化為團隊標準規範

將累積的經驗轉化為可落實的運作規則,避免重複犯錯。

請協助我將 [團隊/公司] 累積的經驗教訓轉化為標準運作規範 (SOP)。現有素材:[回顧紀錄、結案報告、事故檢討]。現狀問題:[如:同樣的錯誤反覆發生、報告寫完就沒人看]。

執行步驟:
1. 按主題分類並找出重複出現的教訓(代表優先級最高)。
2. 轉化為「可執行規則」:一句話描述觸發條件與動作(如:「專案啟動時,我們必須執行 X」)。
3. 定義規則存放處:將其整合進現有的文件模板或核取清單中,而非放在獨立的知識庫。

規則:總數不超過 10 條,每條需有負責人。設定每半年審閱一次以刪除過時規則。交付建議規則清單、整合方式建議及團隊公告訊息。

準備專案稽核或品質審查

整理審查文件、識別弱點並準備面談應對。

請協助 [專案名稱] 準備由 [審查者:內稽、客戶、認證機構] 於 [日期] 進行的審查。審查範圍:[範圍]。專案實況:[已知優缺點、文件完備度]。重要性:[如:後續撥款、客戶信任、認證]。

準備工作:
1. 建立參考文件包(定義書、決策紀錄、風險追蹤、預算)。
2. 優先補正缺失或過時文件。
3. 預測審查者針對此類專案的常見提問。
4. 針對已知弱點準備誠實的立場:承認問題、展示已識別並受控、提出具日期的行動計畫。

規則:嚴禁造假或倒填日期。誠實面對弱點並輔以計畫,比虛假的外殼更能贏得信任。對參與面談者進行事實導向的簡報。交付文件核取清單、預測提問與回答建議及倒數準備時程。

針對您的業務數據測試這些 專案管理 指令

複製指令並在 GPTPro 中開啟,同步比較 Claude、GPT、Gemini 及 Mistral 對您案例的回答。