该帖子同步发自：(flymy23的博客  访问该博客)

PM把计划做好后，细节的讨论是不是就不用参加了？很多人觉得只要他们讨论完，告诉我结果就ok了，因为我也不能做什么，应该请产品负责人/技术负责人来搞定。但其实价值非常大，举今早的例子说说。

产品和开发就近期要开发的通知机制细节在讨论，其实已经做过需求评审了，但是还是有很多细节问题，我看到了，就自己跑过去听听，其间我做了三件事：

1.       把测试拉过来。我发现这里的场景非常多，有很多异常情况，于是赶紧把测试喊过来。你会发现测试常常被忽略在早期的讨论中，这一点恐怕只有PM才会常常想起。

2.       梳理思路。对于离线消息应该如何实现，大家有很多分歧。但是产品、开发分别站在自己的角度在思考，一个觉得很容易实现，一个则相反，而且越讨论越坚信自己是对的，这个时候特别需要PM

a)         做一个“好的聆听者”，听懂双方的观点，帮助双方理解彼此的观点。

b)         进而简化信息，除去掉大量干扰信息，把焦点归结为一个简单的问题，再继续讨论。

这样可以大大减少误解，加快讨论速度，更重要的为PM提供很好的风险判断依据。

3.       化解冲突。因彼此不能理解，中间一度险些吵起来，并想放弃讨论。这对团队未来的配合非常不利，同时问题也并没有解决。这时PM又可以及时干扰大家的情绪，比如采用打断、调侃、解释等方式，让彼此平静，由紧张变的轻松，继续讨论。当问题无法解决的时候，PM又能通过计划调整、时间拉长、目标重提等方式平衡产品需求和技术困难，取得一个双方都能接受的最终结论。