: [实际应用面]
: <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