: [實際應用面]
: <Smooth or accommodate>
: 實際工作上我覺得這個手段是比較常被使用到的。比如說，遇到了客戶實際使用產
: 品後的技術問題；這時候絕對是先確認客戶目前的問題急迫性，而非先蒐集
: debug/troubleshooting上的需要數據資料。先安撫客戶並解決最迫切的需求、也讓內部
: 客服、銷售團隊同仁理解產品研發部正全力化解這個危機是很重要的。比如，可以即時更
: 換新品給客戶，花點費用、但其實也相當於為自己買點時間去蒐集資料、分析討論、並找
: 出真正發生問題的根因﹝root cause﹞。
兩個方向
如果是以短時間內的客戶滿意度
以換機器是最快，但日本人要的是5c,8d,fishbone
你要怎樣用最快的時間去抓問題才是重點
這個時候有經驗與否就非常重要
怎樣去isolate叫rd去抓問題方向，這很吃經驗。
: <Collaborate or problem solve>
: 一般軟體研發、與驗證單位雖說是共同為產品最後的品質共同努力，但其實就KPI而言
: ，這兩個單位基本上是利益相對立的。有些公司甚至是把驗證單位測出的bug count作為
: 績效指標，bug count or severity越高，驗證單位績效越高；但研發部門就恰恰相反。
: 所以在專案執行的過程中，加上PM所在意的時程壓力，這三個單位簡直常常吵到不可開交
: 。我個人處理這種衝突的方法，是建立firmware pass criteria的基本準則﹝baseline﹞
: ，將資源放在有急迫性、重要的bug fixes；另權衡各單位的績效指標，驗證單位也應持
: 續追蹤產品售後客訴問題與test plan coverage，並持續強化驗證的test plan。
如果是這樣就代表該公司的EDD沒有做好。
QA team並沒有在一開始PRD review 的時候根據SPEC發現到的問題去做揪錯，甚至後面的NUDD,FEMA甚至test strategy, case coveragr review也沒有好好去執行。
RD部分的UNIT TEST跟Pair programming也應該要思考怎樣去推展 如何 designed in quality
比較合理的做法是每隔一段時間review做權重，在sev1限定時程，sev2壓時間，sev3推遲或是怎樣的方式規範好做法
我覺得台灣除了少數軟體公司有在認真教，其他根本放著爛。
: [小小心法分享]
: 解決衝突最重要的，除了辨識主要的stakeholders與其個別的重要性以外，還需要了
: 解main stakeholders真正的"interest"；這邊講的"interest"，比較像他"真正"在意的
: 、關注的重點是甚麼？每個人真正的意圖，其實並不一定就像表面上看到的這麼冠冕堂皇
: 。比如很多公司每年年度都會設定一些「高、大、上」的標的要完成，也許你也剛好負責
: 的是跨部門的所謂「指標型」專案；但有時候要尋求資源、甚至遇到協調窒礙難行的時候
: ，主事者卻不那麼關心的時候，就要注意了。先撇除幾種可能的其他原因，如老闆們顢頇
: 無能、聽不懂來龍去脈、或不明白他能做甚麼，或這些阻礙其實自己可以排除的等等，其
: 實非常有可能這所謂「指標型」專案並沒排在老闆們心中的前幾名；管理階層常需要喊得
: 很大聲，或總得有些"vision"鼓舞團隊能有士氣繼續前行，但實際上並沒這麼重要。若你
: 還是想要移開絆腳石以達成自己被交付的專案的話，就得找出他們真正在意的true
: interest，如營收成長率、新的business model等，並想辦法與你想達成的目標結合，借
: 力使力，完成目標。要不大部分結果可能會是事倍功半，無法圓滿達標。
通常這種我就會放著讓客人出來咬
畢竟我是拆炸彈習慣的人，你現場沒有讓我說了算，根本沒辦法做事。 如果老闆過分干預，通常就是把他要的東西搞定，搞定老闆面子之後，剩下才會去拆炸彈。
不過拆彈人通常老闆的立場是眼不见為淨。
拆彈的原則是保留最大資源，去拆最眼前的炸彈。
當然如果要給老闆看，就是用最大資源去讓最小的問題看起來炸很大。
以上各人自己參悟。
: [參考資料]
: https://pmstudycircle.com/2012/01/best-conflict-resolution-technique/
: PM Study Circle: Conflict Resolution Techniques