【專案衝突管理】5層級判斷法＋6步驟解決流程｜含工具比較

專案衝突是團隊成員或利害關係人因目標、資源、角色等差異，在專案執行過程中產生的意見分歧或對立。 本文完整解析 5 大衝突類型、Speed B. Leas 5 層級判斷框架、Thomas-Kilmann 5 種處理風格，以及 6 步驟解決流程，附工具比較表與 4 項預防策略。

專案衝突是什麼？建設性 vs. 破壞性的關鍵差異

想像一個場景：週三下午的跨部門會議上，行銷主管堅持產品要在月底上線配合檔期，研發主管卻說測試還沒跑完、強行上線會出大問題。兩邊各有道理，會議室的氣氛越來越僵——這就是典型的專案衝突。

專案衝突是指在專案執行過程中，團隊成員或利害關係人之間因目標、資源、角色、溝通等差異，產生意見分歧、爭論甚至對立的現象。幾乎每位有經驗的專案經理都會同意：衝突是專案中不可避免的一部分，而處理衝突的能力直接影響專案成敗。

但衝突不一定是壞事。關鍵在於區分「建設性衝突」與「破壞性衝突」。

判斷維度	建設性衝突	破壞性衝突
焦點	聚焦問題本身（「這個方案的風險是什麼？」）	聚焦個人（「你每次都這樣拖延」）
解決意願	雙方願意尋找共同方案	一方或雙方只想贏，不想解決
人際關係	討論後關係不受損，甚至更信任	討論後關係惡化，出現迴避或敵意
資訊流動	促進資訊透明，挖掘隱藏問題	資訊封鎖，各自為政
對專案的影響	提升決策品質，激發創意	延誤進度，降低士氣

在專案管理流程中，專案經理的核心任務不是消滅所有衝突，而是讓建設性衝突發生，同時阻止破壞性衝突升級。

衝突的早期警示信號

等到衝突在會議上爆發，通常已經是中後期了。有經驗的團隊管理者會注意這些早期信號：

1. 會議中特定成員持續沉默：原本活躍發言的人突然不說話，可能代表他覺得「說了也沒用」或已經放棄溝通。
2. 任務延誤頻率上升：不是能力問題，而是動力問題——當成員對任務分配不滿，最常見的被動反應就是拖延。
3. 私下抱怨增加：茶水間、Line 群組裡的抱怨比會議上的討論更多，代表正式溝通管道已經失效。
4. 跨部門溝通頻率驟降：原本每天互傳訊息的兩個團隊，突然只剩下正式信件往來。
5. 會議出席率下降：成員開始找理由缺席特定會議，尤其是需要跨部門協作的會議。
6. 決策反覆推翻：已經達成的共識被不斷翻案，代表當初的「共識」其實只是表面妥協。
7. 非正式小團體形成：午餐時固定的小圈圈、特定幾個人總是一起行動，可能代表團隊正在分裂。

實務上，你可以在 monday.com 的看板上設定自動化規則：當任務延遲超過 2 天時自動通知 PM。這個簡單的設定能幫你在衝突還沒浮上檯面時，就察覺到異常模式。

專案衝突的 5 大類型與典型情境

專案衝突可依發生原因與影響層面分為五種主要類型。辨識衝突屬於哪種類型，是選擇正確處理策略的第一步。

衝突類型	說明	台灣職場典型情境	早期警示信號
任務衝突	對專案目標、工作內容或執行方式有不同看法	PM 與客戶對「完成」的定義不同——PM 認為功能上線即完成，客戶認為需通過 UAT 才算完成	需求文件被反覆修改、驗收標準爭議
人際衝突	個人價值觀、性格或溝通風格差異引發的摩擦	資深工程師習慣直接指出問題，新進設計師覺得被當眾羞辱，開始迴避互動	特定成員之間不再直接溝通，改由第三人傳話
資源衝突	資源分配（人力、預算、設備）不足或競爭所引發的爭執	兩個專案同時需要同一位資深後端工程師，兩邊 PM 都認為自己的專案優先	資源申請頻繁被駁回、跨專案協調會議增加
流程衝突	對工作流程、決策機制或權責分工有不同認知	行銷部門認為設計稿應由行銷主管審核，設計部門認為應由設計總監決定	審核流程卡關、同一份文件被不同人退回修改
目標衝突	各方對專案終極目標或優先順序有不同期待	業務部門要求快速上線搶市場，品保部門堅持必須完成全部測試才能發布	優先順序不斷被調整、專案範圍持續膨脹

這些衝突經常交互影響。例如，表面上看起來是「資源衝突」（兩個部門搶人），背後可能是「目標衝突」（兩個部門對公司策略方向的理解不同）。專案經理需要挖掘衝突的真正本質，而不只是處理表面症狀。

專案衝突的 6 大成因與預防動作

了解衝突為什麼發生，才能從根本上減少衝突的頻率和強度。以下是六大常見成因，以及對應的預防措施。

1. 溝通不良

在台灣職場中，溝通不良最常見的表現是「以為對方知道」。PM 在會議上口頭交代任務，沒有書面紀錄，兩週後發現雙方理解完全不同。另一個常見情境是跨時區團隊的訊息延遲——台北辦公室下班前丟出問題，美國團隊回覆時台北已經睡了，一來一回就是兩天。

預防動作：所有重要決策必須有書面紀錄。在 monday.com 的更新功能中記錄會議結論，並 @相關人員確認，確保資訊不會在口頭傳遞中失真。

2. 資源有限

台灣科技業最常見的資源衝突是「人力不足但專案不減」。一個工程師同時被分配到三個專案，每個 PM 都覺得自己的專案最重要。當資源分配不透明時，成員會覺得不公平，衝突自然產生。

預防動作：建立透明的資源分配看板，讓所有 PM 都能看到每個成員的工作負載。

3. 目標不一致

不同部門或利害關係人對專案目標有不同期待。這在專案管理中極為常見——老闆要營收、行銷要曝光、研發要技術品質，三方目標看似一致，實際執行時卻互相矛盾。

預防動作：在專案啟動階段就明確定義成功標準，並取得所有利害關係人的書面同意。

4. 角色與責任不明

「這件事不是你負責的嗎？」「我以為是他要做。」——這種對話在台灣職場每天上演。當分工不清時，要嘛工作重疊（兩個人做同一件事），要嘛責任真空（沒人做）。

預防動作：專案啟動時建立 RACI 矩陣，明確定義每個任務的負責人（Responsible）、當責者（Accountable）、諮詢對象（Consulted）和知會對象（Informed）。

5. 個人價值觀或工作風格差異

有人習慣快速決策、邊做邊修；有人偏好深思熟慮、一次到位。這兩種風格沒有對錯，但放在同一個團隊裡很容易產生摩擦。在台灣的多元文化團隊中（例如與日本、美國團隊合作），文化差異更會放大這種衝突。

預防動作：在團隊組建初期進行工作風格討論，建立團隊合作公約（team agreement），明確溝通頻率、回覆時間、決策方式等基本規則。

6. 外部壓力

時程緊迫、需求變動、預算縮減——這些外部壓力會讓團隊的容錯空間變小，平時可以包容的小摩擦在壓力下會被放大成嚴重衝突。

預防動作：在專案風險管理計畫中，將「團隊壓力過大」列為風險項目，設定觸發條件（例如連續加班超過兩週）和應對措施。

Speed B. Leas 衝突層級框架：判斷嚴重程度的標準工具

Speed B. Leas 的衝突層級框架（Levels of Conflict）是專案管理中最實用的衝突評估工具之一。它將衝突分為五個層級，從輕微分歧到嚴重對抗，幫助你判斷「現在該怎麼做」和「誰應該介入」。

這個框架的核心價值在於：不同層級的衝突需要完全不同的處理方式。用處理層級 1 的方法去處理層級 4 的衝突，不但無效，還會讓情況惡化。

層級 1-2（分歧與爭論）：PM 可自行處理

層級 1：分歧（Problem to Solve）

在這個階段，衝突的本質是「我們對問題有不同看法」。雙方都還聚焦在問題本身，語氣平和，願意傾聽對方觀點。

台灣職場情境：Sprint 規劃會議上，前端工程師認為登入頁面應該用 React 重寫，後端工程師認為現有架構加上 API 優化就夠了。兩人各自提出技術論點，討論雖然激烈但對事不對人。

若未處理：當一方覺得自己的意見被忽視，會開始「收集證據」證明自己是對的，衝突升級到層級 2。

建議介入者：PM 自行引導討論即可。
處理方式：鼓勵雙方完整表達觀點，用數據或原型驗證，做出決策並記錄原因。

層級 2：爭論（Disagreement）

雙方開始有明確的立場，語氣變得更強硬。討論從「哪個方案比較好」變成「我的方案才是對的」。成員開始在意「誰贏誰輸」，但還沒有人身攻擊。

台灣職場情境：行銷部門和產品部門對新功能的上線時間爭論了三次會議。行銷堅持配合雙十一檔期，產品堅持功能未完善不能上線。雙方開始引用過去的案例來支持自己的立場（「上次就是因為趕著上線才出包」vs.「上次就是因為拖太久錯過市場時機」）。

若未處理：當爭論持續無果，成員開始覺得「對方不是不懂，是故意跟我作對」，情緒介入，升級到層級 3。

建議介入者：PM 主導協商。
處理方式：將討論拉回共同目標（「我們都希望產品成功」），尋找折衷方案（例如先上線核心功能，其餘功能在檔期後補上）。

層級 3-4（情緒化與組織分裂）：需要主管介入

層級 3：情緒化（Contest）

這是衝突管理的關鍵轉折點。從層級 3 開始，衝突的焦點從「問題」轉移到「人」。成員不再只是反對對方的觀點，而是開始質疑對方的動機和能力。

台灣職場情境：研發主管在會議上說：「行銷部門根本不懂技術，每次都亂開需求。」行銷主管回擊：「研發部門只會說做不到，從來不想辦法解決問題。」會議後，兩個部門的成員開始在各自的 Line 群組裡抱怨對方。有人開始選邊站。

具體行為特徵：

• 會議中出現人身攻擊或諷刺語氣
• 成員開始「選邊站」，形成小團體
• 私下抱怨取代正式溝通
• 開始翻舊帳（「你上次也是這樣」）
• 對方的任何提議都先反對再說

若未處理：信任完全崩解，團隊分裂成對立陣營，升級到層級 4。

建議介入者：PM 的直屬主管或部門主管需要介入。
處理方式：先分別與雙方一對一談話，了解情緒背後的真正需求；再安排有主管在場的協調會議，重新建立溝通規則。

層級 4：組織分裂（Fight/Flight）

衝突已經不只是兩個人的問題，而是兩個「陣營」的對抗。成員的目標從「解決問題」變成「保護自己的陣營」或「打敗對方」。有人開始考慮離職或要求調部門。

台灣職場情境：一個數位轉型專案中，IT 部門和業務部門已經完全不信任彼此。IT 認為業務不配合系統測試，業務認為 IT 開發的系統根本不符合實際需求。兩邊開始各自向高層打報告，試圖讓對方「被檢討」。專案進度完全停滯。

若未處理：衝突變成「你死我活」的零和遊戲，升級到層級 5。

建議介入者：HR 部門與高層主管共同介入。
處理方式：可能需要重新定義專案治理結構、調整團隊組成，甚至暫停專案進行組織層面的調解。

層級 5（嚴重對抗）：高層介入與結構調整

層級 5：嚴重對抗（Intractable）

這是最極端的情況。雙方的目標已經不是「贏」，而是「讓對方輸」。即使傷害自己也在所不惜。在組織中，這通常表現為公開的敵對行為、惡意破壞、或集體離職威脅。

台灣職場情境：某公司的兩個事業部因為資源分配問題長期對立，最終演變成兩位副總在董事會上互相指控對方的部門績效造假。事件曝光後，公司股價下跌，多位核心人才離職。

建議介入者：最高層管理者，必要時引入外部顧問或調解人。
處理方式：結構性調整——可能包括組織重組、人事異動、甚至拆分專案。這個階段的目標不是「解決衝突」，而是「止血」。

5 種衝突處理風格：選對策略比努力更重要

Thomas-Kilmann 衝突模式量表（TKI）是全球最廣泛使用的衝突處理風格評估工具。它根據兩個維度——自我主張性（追求自己目標的程度）和合作性（滿足對方需求的程度）——將處理風格分為五種。

處理風格	自我主張	合作性	何時適用	何時不適用
競爭	高	低	緊急決策、安全議題、必須快速行動時	需要長期合作的關係、對方有同等權力時
合作	高	高	雙方利益都很重要、有足夠時間討論、需要創新解決方案時	時間緊迫、議題不重要時
妥協	中	中	雙方權力對等、需要暫時解決方案、合作和競爭都行不通時	可以找到雙贏方案時（妥協意味著雙方都沒有完全滿足）
迴避	低	低	議題不重要、需要冷靜時間、收集更多資訊再決定時	問題會自行惡化、對方期待回應時
遷就	低	高	維護關係比贏得爭論更重要、你發現自己是錯的、議題對對方比對你更重要時	你的核心利益受損、對方會得寸進尺時

在專案管理中，「合作」是首選風格，因為專案成功需要所有成員的投入。但這不代表其他風格沒有價值：

• 當伺服器當機、需要立即決定修復方案時，競爭（由技術主管直接拍板）是正確選擇。
• 當兩個成員因為座位安排起爭執時，迴避可能是最有效率的——不值得花時間處理。
• 當資深成員對新流程有強烈抵觸，但新流程確實更好時，先遷就他的部分意見，再逐步推動改變，比硬碰硬更有效。

真正厲害的 PM 不是只會用一種風格，而是能根據情境靈活切換。

專案衝突解決的 6 步驟流程

以下用一個貫穿案例來示範完整的衝突解決流程。

案例背景：某科技公司正在開發新產品，行銷部門要求在 Q3 結束前上線配合年度行銷計畫，研發部門認為至少需要到 Q4 中才能完成所有功能測試。雙方已經在三次會議上爭論無果，開始出現情緒化語言（Leas 層級 2-3 之間）。

步驟 1：辨識衝突

用 5W1H 框架清楚描述衝突：

• Who：行銷部門（主管 + 3 位行銷專員）vs. 研發部門（主管 + 5 位工程師）
• What：對產品上線時間有嚴重分歧
• When：過去三週，從第二次 Sprint Review 開始
• Where：主要在跨部門週會上爆發
• Why：行銷有年度 KPI 壓力，研發有品質標準堅持
• How：已從理性討論升級到情緒化指責

常見錯誤：只描述表面現象（「他們在吵上線時間」），沒有挖掘衝突的完整脈絡。
適用 Leas 層級：所有層級——無論衝突多嚴重，第一步都是先搞清楚狀況。

步驟 2：分析成因

表面上是「時間衝突」，但深入分析後發現三個根本原因：

• 目標不一致：行銷的 KPI 是「產品上線數量」，研發的 KPI 是「上線後 bug 數量」。兩個 KPI 互相矛盾。
• 資訊不對稱：行銷不知道研發還有多少測試沒完成，研發不知道行銷的檔期有多重要。
• 決策機制不明：沒有人有最終決定權——PM 說要配合行銷，技術主管說要聽研發的。

常見錯誤：只看表面爭議（上線時間），沒有挖掘背後的利益需求（KPI 壓力、品質標準）。
適用 Leas 層級：層級 1-3。層級 4 以上通常需要先處理情緒，才能理性分析成因。

步驟 3：促進溝通

PM 分別與行銷主管和研發主管進行一對一談話，了解各自的核心需求和底線：

• 行銷的核心需求：Q3 結束前必須有產品可以推廣（不一定要全部功能）
• 研發的核心需求：上線的功能必須通過完整測試（不一定要全部功能都上線）

常見錯誤：直接把雙方拉到同一個會議室「談」，結果變成又一次爭吵。
適用 Leas 層級：層級 2-3 建議先一對一，層級 1 可以直接團體討論。

步驟 4：尋求共識

發現雙方的核心需求其實不矛盾後，PM 提出方案：分階段上線——Q3 結束前上線核心功能（已通過測試），其餘功能在 Q4 中補上。行銷有東西可以推廣，研發不用犧牲品質。

PM 在 monday.com 上建立了一個「上線計畫」看板，將功能分為「Phase 1（Q3 上線）」和「Phase 2（Q4 上線）」，讓雙方都能清楚看到哪些功能在哪個階段完成。

常見錯誤：急著找「折衷方案」（例如把時間切一半），而不是找「雙贏方案」。
適用 Leas 層級：層級 1-3。層級 4 以上可能需要主管直接裁決。

步驟 5：執行決策

明確分工並記錄：

• 研發：在兩週內完成 Phase 1 功能的最終測試，每日在看板更新進度
• 行銷：根據 Phase 1 功能調整行銷素材，不再要求全功能上線
• PM：每天檢查看板進度，每週召開 15 分鐘的同步會議

常見錯誤：達成共識後就覺得「搞定了」，沒有明確的執行計畫和責任歸屬。
適用 Leas 層級：所有層級。

步驟 6：追蹤與回饋

Phase 1 成功上線後，PM 召開回顧會議（retrospective），討論：

• 這次衝突的根本原因是什麼？（KPI 設計互相矛盾）
• 我們做對了什麼？（分階段上線的策略有效）
• 下次如何預防？（建議高層重新設計跨部門 KPI，避免互相矛盾）

常見錯誤：問題解決後就忘了，同樣的衝突在下一個專案又重演。
適用 Leas 層級：所有層級。即使是層級 5 的衝突，事後回顧也是必要的。

（推薦試試 monday.com 的免費方案，光是「任務進度透明化」這一點，就能大幅減少因資訊不對稱產生的衝突。）

預防專案衝突的 4 個主動策略

處理衝突很重要，但預防衝突更有價值。以下四個策略可以在衝突發生前就降低風險。

策略 1：專案啟動時建立 RACI 矩陣

RACI 矩陣明確定義每個任務的四種角色：負責執行（R）、最終當責（A）、需要諮詢（C）、需要知會（I）。大多數「誰該做這件事」的爭議，都可以透過一張 RACI 表在專案啟動時就預防。

簡單範例：

任務	PM	研發主管	行銷主管	設計師
需求定義	A	C	R	I
技術架構	I	A/R	I	C
UI 設計	C	C	A	R
上線決策	A	C	C	I

你可以用 ClickUp 的 RACI 模板快速建立這張表，省去從零開始的時間。

策略 2：定期回顧會議的衝突預防功能

回顧會議（retrospective）不只是 Scrum 團隊的專利。每兩週花 30 分鐘，讓團隊討論「什麼做得好、什麼可以改善、有什麼困擾」，能在小問題變成大衝突之前就處理掉。

關鍵做法：

• 使用匿名投票讓成員提出議題（降低發言壓力）
• 聚焦在「流程改善」而非「追究責任」
• 每次會議產出 1-2 個具體行動項目，並在下次會議追蹤

策略 3：建立心理安全感

心理安全感是指成員覺得可以安全地表達不同意見、承認錯誤、提出問題，而不會被懲罰或嘲笑。缺乏心理安全感的團隊，衝突不會消失——只會從檯面上轉入地下，等到爆發時已經是 Leas 層級 3 以上。

具體做法：

• PM 以身作則，公開承認自己的錯誤（「上週我的估算太樂觀了，我們來調整」）
• 在會議中明確邀請不同意見（「有沒有人看到這個方案的風險？」）
• 當有人提出反對意見時，先感謝再討論（「謝謝你提出來，我們來看看這個風險」）
• 絕對不在公開場合批評個人

策略 4：明確的決策機制

很多衝突的根源不是「意見不同」，而是「不知道誰有最終決定權」。在專案啟動時就定義清楚：

• 技術決策由誰拍板？
• 預算調整需要誰核准？
• 時程變更的決策流程是什麼？
• 當 PM 和技術主管意見不同時，誰是最終裁決者？

這些規則寫在專案章程裡，所有人簽名確認。當衝突發生時，不需要爭論「聽誰的」，直接按照事先約定的機制處理。

專案衝突管理工具比較

當團隊規模超過 5 人，光靠口頭溝通和 Excel 已經不夠。專案管理工具能透過透明化資訊、自動化提醒、結構化溝通，從根本上減少衝突發生的機率。

比較項目	monday.com	ClickUp	Notion
最適衝突類型	資源衝突、流程衝突、任務衝突	任務衝突、流程衝突	目標衝突、溝通不良
核心功能	視覺化看板、自動化規則、工作負載檢視、Dashboard	自訂工作流程、多視圖切換、內建文件、目標追蹤	知識庫、會議紀錄、決策文件、資料庫
台幣月費（每人）	免費方案可用；付費約 NT$270 起	免費方案可用；付費約 NT$225 起	免費方案可用；付費約 NT$240 起
最適團隊規模	5-50 人跨部門協作	5-30 人技術導向團隊	3-15 人知識型團隊
衝突預防亮點	工作負載檢視一眼看出誰過載；自動化規則在任務延遲時即時通知	多層級權限設定減少流程爭議；目標功能對齊團隊方向	共享知識庫減少資訊不對稱；會議紀錄模板確保決策有據可查
	免費試用 →	免費試用 →	免費試用 →

monday.com 的衝突管理具體操作場景

如果你想用 monday.com 來預防衝突升級，可以這樣設定：建立一個「議題追蹤」看板，專門記錄團隊中浮現的分歧和待解決問題。每個議題卡片包含：衝突描述、相關人員、嚴重程度（用 Leas 層級標記）、處理狀態、解決方案。

關鍵的自動化規則：當議題卡片停留在「待處理」狀態超過 3 天，自動通知 PM 和相關主管。這條規則的價值在於，它強制團隊在問題還小的時候就面對——很多衝突之所以升級到層級 3 以上，就是因為在層級 1-2 時沒有人正式處理，拖到月會才被提出來，屆時情緒已經累積到難以理性討論。

ClickUp 的衝突管理具體操作場景

如果你的團隊是技術導向、跑 Scrum 的團隊，ClickUp 的多視圖功能特別適合處理任務衝突。你可以在同一個空間中切換看板視圖（看任務狀態）、甘特圖視圖（看時間衝突）、工作負載視圖（看資源分配），快速找出衝突的根源。

你是哪種團隊？

• 5 人以下、剛開始接觸專案管理：先用 Notion 免費版建立共享知識庫和會議紀錄，解決最基本的資訊不對稱問題。
• 5-15 人跨部門協作：monday.com 是我們的首選——視覺化看板和自動化規則能大幅減少因溝通不良產生的衝突。免費方案不需要信用卡。
• 技術團隊跑 Scrum：ClickUp 的自訂工作流程和 Sprint 管理功能更貼合你的需求。
• 15 人以上的大型專案：monday.com 企業方案的 Dashboard 和跨看板報表，能讓高層一眼掌握所有專案的衝突風險。

結論：根據你的現況，決定下一步

讀完這篇文章後，與其重新複習所有框架，不如直接根據你現在的狀況採取行動：

如果你的團隊現在正有衝突：
1. 先用 Leas 框架判斷層級——衝突還聚焦在問題上嗎？有沒有人身攻擊？有沒有形成對立陣營？
2. 層級 1-2：用本文的 6 步驟流程自行處理，從「辨識衝突」開始，重點放在步驟 3（一對一溝通）找出雙方的真正需求。
3. 層級 3 以上：停止嘗試自己解決，立即通知直屬主管或 HR，並參考層級 3-4 的處理建議安排介入方式。

如果你的團隊目前沒有明顯衝突，想做預防：
1. 最高投報率的第一步是建立 RACI 矩陣——大多數衝突源自「不知道誰負責」，一張表就能預防。
2. 第二步是在專案管理工具中設定自動化提醒（任務延遲超過 2 天通知 PM），讓早期警示信號不會被忽略。
3. 第三步是在下一次回顧會議中，向團隊介紹 Leas 的 5 層級框架，建立共同語言——當所有人都知道「層級 3」代表什麼，溝通效率會大幅提升。

如果你是新手 PM，不確定從哪裡開始：
先把 Thomas-Kilmann 的 5 種處理風格記住，下次遇到衝突時有意識地問自己：「這個情境適合哪種風格？」光是這個思考習慣，就能讓你的衝突處理能力超越大多數只會「直覺反應」的 PM。

想把這些方法論付諸實踐？在 monday.com 建立一個「議題追蹤」看板，設定自動化提醒規則，讓團隊中的分歧在升級前就被看見。免費方案不需要信用卡，10 分鐘就能建好。

專案衝突管理常見問題

專案衝突一定要解決嗎？什麼時候可以讓它自然發展？

不是所有衝突都需要 PM 介入。當衝突屬於 Leas 層級 1（輕微分歧），且雙方都有能力和意願自行解決時，PM 刻意不介入反而能培養團隊的自主解決能力。但如果你觀察到衝突持續超過一週沒有進展、或開始出現情緒化語言，就該主動介入了。判斷標準：衝突是否仍聚焦在問題本身？雙方是否還在溝通？如果兩個答案都是「是」，可以再觀察。

專案經理沒有正式權力，如何調解衝突？

這是台灣職場中 PM 最常面臨的困境——你要負責專案成功，但團隊成員不是你的直屬下屬。有效的做法是運用「影響力」而非「權力」：(1) 用數據說話，呈現衝突對專案時程和成本的具體影響；(2) 借力使力，在適當時機請有決策權的主管背書；(3) 建立信任，平時就與各部門保持良好關係，衝突發生時才有調解的立場。

衝突已經升級到人身攻擊，該怎麼辦？

當衝突到達 Leas 層級 3 以上（出現人身攻擊、選邊站、私下抱怨），PM 應該：(1) 立即中止當前的對抗場景（例如結束會議）；(2) 分別與雙方一對一談話，先處理情緒再處理問題；(3) 通知直屬主管或 HR，因為這個層級的衝突已經超出 PM 的職權範圍；(4) 在有主管在場的情況下重新安排協調會議，並事先設定溝通規則（例如：不翻舊帳、不使用攻擊性語言）。

遠端團隊的衝突為什麼更難處理？

遠端團隊的衝突更難處理有三個原因：(1) 缺乏非語言線索——你看不到對方的表情和肢體語言，容易誤讀文字訊息的語氣；(2) 溝通延遲——非同步溝通讓誤解有更多時間發酵；(3) 社交連結薄弱——沒有茶水間閒聊、沒有午餐聚會，成員之間缺乏信任基礎。解決方式：增加視訊會議頻率（至少每週一次開鏡頭）、建立非工作的社交管道（例如 Slack 的 #random 頻道）、文字溝通時多用表情符號降低誤讀風險。

Speed B. Leas 衝突層級框架如何應用在日常管理中？

不需要等到衝突發生才拿出這個框架。建議在團隊啟動會議時就介紹這五個層級，讓所有成員都有共同語言。當有人說「我覺得這個議題已經到層級 2 了」，團隊就能快速對齊嚴重程度並決定處理方式。你也可以在每週站會中加入一個「衝突溫度計」環節——用 1-5 分讓成員匿名評估當前團隊的衝突狀態，及早發現升溫趨勢。