PMI PMP: 團隊領導與資源管理 — 學習指南

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

屬於 PMP — 學習指南. 使用經過驗證的解答練習： PMI 考試中心, 或參加限時模擬考試： ExamRoll.io.

團隊建立、章程與角色釐清

每個高績效團隊的起點都是一個精心設計的建立儀式，而不是第一次的狀態會議。團隊章程是創始的產物——一份由團隊共同撰寫的文件，記錄了團隊的共同價值觀、決策規則、跨時區的工作時間、溝通節奏以及上報路徑。與專案章程（授權專案並指明贊助者）不同，團隊章程是由團隊為團隊自己所撰寫。它的力量在於共同撰寫的過程：當日後有開發人員打斷同事或錯過站立會議時，專案經理不是動用個人權威，而是指出團隊自己建立的規範。

除了章程之外，運作規則將日常紀律具體化：設計審查時開啟攝影機、回顧會議期間禁止多工、口頭更新遵守兩分鐘規則、決策在 24 小時內文件化。運作規則應該要顯而易見（張貼在團隊室或釘選在協作頻道中），並在每次迭代或階段關卡開始時重新檢視。一份放在 SharePoint 資料夾裡沒人打開的章程只是裝飾品；一份每週都被參考的章程才具有約束力。

角色釐清是團隊建立鐵三角的最後一環。一份 RACI（或其變體 RASCI）矩陣，將交付成果對應到負責 (Responsible)、當責 (Accountable)、諮詢 (Consulted) 和告知 (Informed) 的各方，可以消除「我以為那是你負責」的失敗模式。當專案經理接手一個已經在無領導狀態下漂流數週的新團隊時，正確的第一步既不是積極地重新規劃，也不是立即與贊助者重新協商時程。而是召集團隊，傾聽他們認為受阻的地方，並重新建立團隊章程和角色地圖。團隊之所以感到迷失，正是因為缺少了這些定錨的基礎。

根據成熟度調整領導風格

情境領導將領導風格視為一個變數，而非個人特質。經典的 Hersey-Blanchard 模型將領導風格對應到追隨者的準備度：

僕人式領導的姿態——移除障礙、為團隊隔絕噪音、優先考慮他們的成長——是疊加在這個模型之上的，但不能取代情境判斷。僕人式領導不等於放縱式領導。當團隊偏離方向時，僕人式領導者仍然會進行指導；他們這樣做是為了團隊的成功，而不是為了自己的能見度。

在一個沒有方向的團隊中採用放任式領導是一個常見的失敗陷阱。當團隊對工作沒有共同的認知模型時，袖手旁觀「讓團隊自我組織」只會造成混亂、遺漏相依性並打擊士氣。自我組織是成熟度的結果，而不是起始條件。相反地，對已經交付過五次類似工作的資深工程師進行微觀管理，則會傳達不信任、壓抑主動性並導致人員流失。一個警訊是，當專案經理審查領域專家的 commit 層級細節，卻忽略了在 portfolio 層級的風險對話。

加入一個資深程度不一的團隊時，起手式是進行一輪一對一會議，並結合一個工作協議工作坊。這能讓每個人在準備度光譜上的位置浮現出來，從而可以針對個人調整領導風格，而不是統一應用。

教練指導、一對一會議與績效管理

定期的一對一會議（通常是每兩週 30 分鐘）是進行教練指導、早期問題偵測和職涯發展的主要管道。它們不是狀態更新會議。議程應由團隊成員主導，專案經理則有 70% 的時間在傾聽。主題輪流涵蓋當前的阻礙、技能成長、雙向回饋以及團隊士氣。

績效問題必須在第一次觀察到時就提出，而不是累積到正式的績效評估週期。拖延困難的對話是專案領導中最具破壞性的模式之一：表現不佳者直到為時已晚才學到教訓，高績效者看在眼裡而逐漸疏離，團隊士氣則會默默地被侵蝕。回饋應該引用可量化的指標——例如瑕疵逃逸率、story 週期時間、程式碼審查周轉時間、會議出席率、承諾可靠度——而不是主觀印象（「你似乎不太投入」）。可量化的指標將對話錨定在可觀察的行為上，並給予團隊成員一個具體的目標。

只有在教練指導、明確設定期望，以及有文件記錄的績效改善討論都失敗後，才有理由上報給職能經理，或最終要求更換人員。跳過這些步驟會損害信任，且通常違反人資政策。

衝突解決與團隊建立

人際衝突若不處理，將會擴散惡化。當一個團隊成員在短期專案中被同儕孤立時，專案經理的回應既不是等待它自然結束（專案在問題解決前就結束了），也不是公開與團隊對質（這會羞辱對方並使立場更加僵化）。正確的模式結合了三個步驟：與受影響的個人私下對談以了解其經歷、分別與表現出排擠行為的同儕溝通以指出觀察到的模式及其影響，並透過團隊章程和引導式的團隊建立活動來強化包容性的規範。記錄此干預措施至關重要，以防有必要將情況上報給人資部門。

Thomas-Kilmann 的五種衝突模式——協作、妥協、圓融、強迫、迴避——可用於指導應對方式的選擇。對於長期團隊中的人際和技術爭議，通常偏好協作（解決問題以找到雙贏方案），而強迫則可能僅在涉及安全、道德或硬性死線的決策時才合理。

資源分配、撫平與產能規劃

資源管理既是算術，也是協商。Resource leveling (資源撫平) 透過延長時程來解決過度分配的問題；resource smoothing (資源平滑) 則保持結束日期不變，並在浮動時間內進行調整。當關鍵專家承諾過多且品質可能受損時，選擇 leveling；當結束日期有合約規定時，選擇 smoothing。

當功能經理在 sprint 中期重新指派一位共享的架構師時，專案經理應使用數據進行協商：目前的承諾、對要徑的影響，以及下游的延遲成本。只有在嘗試直接協商並留下紀錄後，才適合將問題上報給發起人或指導委員會。未先嘗試解決就直接向上級抱怨，會消耗政治資本。

知識轉移與交叉訓練

單點依賴是專案中最可預測的風險之一，卻也最常被忽視。當某人是某個子系統的唯一負責人，並住院兩個月時，失敗的不是這次意外——而是先前缺乏緩解措施。預防性做法包括配對編程或配對指導、輪流 on-call 責任、強制將部落知識（tribal knowledge）文件化為 runbook、錄製知識轉移會議，以及進行交叉訓練輪調，讓第二負責人先見習，然後實際執行專家的任務。新進人員的到職計畫應明確指派一位夥伴（buddy）並提供一份 30-60-90 天的能力地圖。

團隊層級的繼任計畫旨在識別誰可以接替每個關鍵角色，以及他們需要彌補哪些能力差距。這些資訊會記錄在每季審查一次的技能矩陣中。

會議引導與表揚

會議消耗了團隊產能中最顯眼的一部分。紀律要求會議要有明確的目的、事先分發有時間限制的議程、邀請正確（而非最多）的與會者、明確記錄決策和行動項目（包含負責人與日期），以及一個有效的議題暫停區（parking lot）來處理離題的討論。沒有決策產出的例行會議應該取消。

最後，表揚——對團隊的勝利要及時、具體且公開；對個人的指導則應私下進行——這並非無關緊要的客套話。與團隊章程價值觀一致的獎勵，會強化產生這些成果的行為。在審查會議中一次簡短的公開表揚、與功能經理協調後發放的即時獎金，或寫給某人直屬主管的書面便條，成本雖低，卻能在士氣和留任率上產生顯著的複利效應。

實務問題：使用案例情境

情境： Priya Kapoor 剛被指派領導一間中型區域性銀行的「Meridian」支付現代化專案，預算為 420 萬美元，時程為 14 個月。這個 11 人的團隊橫跨三個時區：五位開發人員在邦加羅爾，三位業務分析師在倫敦，以及一位品保主管、一位架構師和 Priya 本人在多倫多。專案開始兩週後，邦加羅爾的開發人員建立了一個原型，但倫敦的業務分析師們卻以不符合他們「假設大家都讀過了」的合規要求為由而拒絕了該原型。同時，多倫多的架構師聲稱，從沒有人就技術堆疊的決策諮詢過他。

挑戰： Priya 必須在專案進度進一步落後之前，重設團隊的運作規範與角色清晰度，同時避免讓人覺得她在為這次的溝通不良歸咎於任何單一群體。

建議方法：

1. 暫停進行中的開發工作，舉行為期兩天的線上團隊建立工作坊。安排重疊的工作時間 (多倫多上午 7:00–10:00／倫敦中午 12:00–下午 3:00／邦加羅爾下午 4:30–7:30)，讓所有 11 位成員都能即時共同編寫產出文件。
2. 引導團隊共同創建一份團隊章程，內容涵蓋共享的重疊工作時間、決策權、「諮詢 (consulted)」與「告知 (informed)」的定義、非同步決策的 24 小時回覆規則，以及最終上報至專案發起人的升級途徑。
3. 針對 WBS 中的 18 項主要交付成果建立一份 RASCI 矩陣，並與團隊逐一檢視每一列，確保「當責者 (Accountable)」永遠是單一指定人員，且任何技術堆疊決策的「諮詢者 (Consulted)」都明確指定為架構師。
4. 建立基本原則——例如設計審查時開啟攝影機、決策須在一個工作日內記錄於 Confluence、每週在重疊時間進行 30 分鐘的跨時區同步會議——並將這些原則釘選在團隊的 Slack 頻道中。
5. 與業務分析師和開發人員一起重新規劃原型範疇，並利用新釐清的 RASCI 來確定在撰寫程式碼前應由誰簽核。
6. 在每次迭代的首次回顧會議中，增加一個固定的 10 分鐘「章程檢視」環節，以便隨著團隊的成熟度來修訂規範。

為何此方法有效： 共同編寫的方式將團隊章程從一份強制命令轉變為同儕間的承諾，這使得專案經理在不需動用職位權力的情況下，也能有立場去執行這些規範。RASCI 矩陣消除了導致合規疏失的「我以為你處理了」這種認知落差，而每次迭代重新檢視規範，則能防止章程淪為裝飾品，確保它是一份與時俱進的有效協議。

← 利害關係人參與與溝通 · 所有領域 · Agile、Scrum 與混合式交付 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →