※ 本文為 dinos 轉寄自 ptt.cc 更新時間: 2020-11-17 01:46:06
看板 P_Management
作者 標題 [分享] Conflict Resolution 解決衝突
時間 Mon Nov 16 09:56:50 2020
跟大家分享我對衝突管理 conflict resolution的一些想法跟心法
完整圖文版請見網誌:
https://smartpm760175948.wordpress.com/2020/11/16/解決衝突-conflict-resolution/
![[圖]](https://s0.wp.com/i/blank.jpg){kind=spacer}
以下內容擷取網誌文章：
[前言]
其實Project Manager or Product Manager在工作內容上，一直都扮演著協調者的角
色，沒有絕對公式可以參考，很多時候都是在不同的部門間、團隊成員間、老闆們﹝
色，沒有絕對公式可以參考，很多時候都是在不同的部門間、團隊成員間、老闆們﹝
stakeholders﹞間、與客戶的應對中找到一個權衡解決辦法，化解產品開發專案中、或是
業務推展中的重重關卡。Conflict Resolution絕對是PM必修的一堂課，且這個
interpersonal skill需要靠自己跌跌撞撞累積經驗，不存在一個一以貫之的葵花寶典可
以遵循，而且需要因時、因人、因地而制宜。這邊提出一些我的觀點跟親身經驗，給各位
參考
以遵循，而且需要因時、因人、因地而制宜。這邊提出一些我的觀點跟親身經驗，給各位
參考
[PMP怎麼說？]
PMBOK Edition 6提出有五種解決衝突的方式
1. Withdraw or avoid
2. Smooth or accommodate
3. Compromise or reconcile
4. Force or direct
5. Collaborate or problem solve
同樣的，PMP只是羅列可能的方法，但並沒有解釋適用於甚麼樣的情況、或怎樣個性的
人身上。我這邊特別分享 2. Smooth or accommodate 以及 5. Collaborate or
problem solve；因為1. Withdraw or avoid 如果目前被侵害到權益的人其實沒這麼重要
、或是問題非常小，根本不需要特別處理；而3. Compromise or reconcile剛好與之相反
，主要stakeholders或是大客戶就是要這樣幹﹝前提當然是該分析的、該反映的已經都討
論過了﹞，PM身為員工豈有不遵命的道理？而4. Force or direct 通常是如果你已經到
「喊水會結凍」，在公司極具影響力、且此問題沒甚麼最佳解的情況下，就強迫團隊照你
決定的方向去執行。這三個基本上我覺得現實專案層面上比較難遇到，就算遇到解決的方
法也蠻直白的；但如何判斷目前面臨的衝突型態適合用哪種方式，的確要看公司文化、也
視自己專案管理風格而定，沒甚麼統一標準。
、或是問題非常小，根本不需要特別處理；而3. Compromise or reconcile剛好與之相反
，主要stakeholders或是大客戶就是要這樣幹﹝前提當然是該分析的、該反映的已經都討
論過了﹞，PM身為員工豈有不遵命的道理？而4. Force or direct 通常是如果你已經到
「喊水會結凍」，在公司極具影響力、且此問題沒甚麼最佳解的情況下，就強迫團隊照你
決定的方向去執行。這三個基本上我覺得現實專案層面上比較難遇到，就算遇到解決的方
法也蠻直白的；但如何判斷目前面臨的衝突型態適合用哪種方式，的確要看公司文化、也
視自己專案管理風格而定，沒甚麼統一標準。
[實際應用面]
<Smooth or accommodate>
實際工作上我覺得這個手段是比較常被使用到的。比如說，遇到了客戶實際使用產
品後的技術問題；這時候絕對是先確認客戶目前的問題急迫性，而非先蒐集
debug/troubleshooting上的需要數據資料。先安撫客戶並解決最迫切的需求、也讓內部
客服、銷售團隊同仁理解產品研發部正全力化解這個危機是很重要的。比如，可以即時更
換新品給客戶，花點費用、但其實也相當於為自己買點時間去蒐集資料、分析討論、並找
出真正發生問題的根因﹝root cause﹞。
客服、銷售團隊同仁理解產品研發部正全力化解這個危機是很重要的。比如，可以即時更
換新品給客戶，花點費用、但其實也相當於為自己買點時間去蒐集資料、分析討論、並找
出真正發生問題的根因﹝root cause﹞。
<Collaborate or problem solve>
一般軟體研發、與驗證單位雖說是共同為產品最後的品質共同努力，但其實就KPI而言
，這兩個單位基本上是利益相對立的。有些公司甚至是把驗證單位測出的bug count作為
績效指標，bug count or severity越高，驗證單位績效越高；但研發部門就恰恰相反。
所以在專案執行的過程中，加上PM所在意的時程壓力，這三個單位簡直常常吵到不可開交
。我個人處理這種衝突的方法，是建立firmware pass criteria的基本準則﹝baseline﹞
，將資源放在有急迫性、重要的bug fixes；另權衡各單位的績效指標，驗證單位也應持
續追蹤產品售後客訴問題與test plan coverage，並持續強化驗證的test plan。
績效指標，bug count or severity越高，驗證單位績效越高；但研發部門就恰恰相反。
所以在專案執行的過程中，加上PM所在意的時程壓力，這三個單位簡直常常吵到不可開交
。我個人處理這種衝突的方法，是建立firmware pass criteria的基本準則﹝baseline﹞
，將資源放在有急迫性、重要的bug fixes；另權衡各單位的績效指標，驗證單位也應持
續追蹤產品售後客訴問題與test plan coverage，並持續強化驗證的test plan。
[小小心法分享]
解決衝突最重要的，除了辨識主要的stakeholders與其個別的重要性以外，還需要了
解main stakeholders真正的"interest"；這邊講的"interest"，比較像他"真正"在意的
、關注的重點是甚麼？每個人真正的意圖，其實並不一定就像表面上看到的這麼冠冕堂皇
。比如很多公司每年年度都會設定一些「高、大、上」的標的要完成，也許你也剛好負責
的是跨部門的所謂「指標型」專案；但有時候要尋求資源、甚至遇到協調窒礙難行的時候
，主事者卻不那麼關心的時候，就要注意了。先撇除幾種可能的其他原因，如老闆們顢頇
無能、聽不懂來龍去脈、或不明白他能做甚麼，或這些阻礙其實自己可以排除的等等，其
實非常有可能這所謂「指標型」專案並沒排在老闆們心中的前幾名；管理階層常需要喊得
很大聲，或總得有些"vision"鼓舞團隊能有士氣繼續前行，但實際上並沒這麼重要。若你
還是想要移開絆腳石以達成自己被交付的專案的話，就得找出他們真正在意的true
。比如很多公司每年年度都會設定一些「高、大、上」的標的要完成，也許你也剛好負責
的是跨部門的所謂「指標型」專案；但有時候要尋求資源、甚至遇到協調窒礙難行的時候
，主事者卻不那麼關心的時候，就要注意了。先撇除幾種可能的其他原因，如老闆們顢頇
無能、聽不懂來龍去脈、或不明白他能做甚麼，或這些阻礙其實自己可以排除的等等，其
實非常有可能這所謂「指標型」專案並沒排在老闆們心中的前幾名；管理階層常需要喊得
很大聲，或總得有些"vision"鼓舞團隊能有士氣繼續前行，但實際上並沒這麼重要。若你
還是想要移開絆腳石以達成自己被交付的專案的話，就得找出他們真正在意的true
interest，如營收成長率、新的business model等，並想辦法與你想達成的目標結合，借
力使力，完成目標。要不大部分結果可能會是事倍功半，無法圓滿達標。
[參考資料]
https://pmstudycircle.com/2012/01/best-conflict-resolution-technique/
Conflict Resolution Techniques | PM Study Circle
![[圖]]()
The PMBOK Guide sixth edition lists five conflict resolution techniques, such as: techniques: Withdraw/Avoid, Smooth/Accommodate, Compromise/Reconcile ...
![[圖]](https://pmsczone-na1401781608.netdna-ssl.com/wp-content/uploads/2019/08/conflict-resolution-techniques.jpg)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.168.180 (臺灣)
※ 文章代碼(AID): #1ViTndqY (P_Management)
※ 文章網址: https://www.ptt.cc/bbs/P_Management/M.1605491815.A.D22.html
※ 編輯: BlueSusan (223.137.168.180 臺灣), 11/16/2020 09:57:25
--
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 120
回列表(←)
分享