: [實際應用面] : <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 ----- Sent from JPTT on my Samsung SM-N960F. --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.230.211.111 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/P_Management/M.1605906886.A.260.html