: [实际应用面] : <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/cn.aspx?n=bbs/P_Management/M.1605906886.A.260.html