1. 承认冲突

产品经理和研发沟通的时间非常多，完全避免冲突是不现实的。在冲突发生的时候，我们最需要的就是控制自己的情绪。曾经听说过一个比喻：产品经理就像是化学中的催化剂，既能使得产品加速完成，也能阻碍产品的研发。

和研发保持愉快的合作关系，能够让研发产生更加积极的情绪，有利于产品目标的顺利完成。若是和研发产生矛盾，研发很有可能会产生懈怠情绪，从而导致产品延期，也有可能对后续的进一步合作产生影响。既然情绪本身不会给我们的产品带来任何好处，我们就需要在沟通的时候尽量避免负面的情绪，专注于如何解决问题上。

随后，我冷静地对研发说：

“当你说教室管理放在排课这里不合适的时候，我感觉有点为难，因为我们在需求评审的时候已经反复确认了这个问题，只有排课这里会用到教室，在这里维护的话，用户操作起来会更方便，界面也会更简洁。”

2. 寻找需求

这时，我也在同步思考为什么研发现在才提出这种想法，为什么之前评审的时候他说没问题了。于是，我问道：

“那你觉得怎么样做更合理呢？”

程序员回答：

“把这个功能放在门店管理里面，像分类管理那样做一个弹出框实现这个功能会更好。”

我这时候的想法是：你之所以这么说是因为你现在正在开发这个功能，你觉得这样实现起来需要耗费更多的时间来思考如何实现，用以前的方法来实现的话只需要直接复用以前的功能就行，减少了工作量。而且把这个功能放在门店管理部分，就不属于你的研发范围，你只需要调用就可以了，这就是你的需求。而我的需求是如何简单快速地实现这个功能，不管是谁实现的。

在研发产品的过程中，产品经理实现客户需求的主线是不变的，在此基础上，若能够平衡好内部的需求，我们就能成为了加速产品完成的催化剂。在这次冲突中，也有可能研发真的觉得这样实现会更好，只是我没法快速Get到他的思想。

3. 解决矛盾

这个产品的第一版需要在一个月内完成，时间非常紧迫。这个时候产品应该更多地考虑下一期产品的功能，而不是纠结于这个已经确定的功能。

这个时候我把技术经理和相关的人员叫在一起，问问大家对这个解决方案有没有意见，最终大家都同意了这样实现。

这个小功能不会对产品本身产生大的影响，不会造成他人的不满，不影响最终的产品目标，快速确定解决方案就是最重要的。

这对我以后管理需求有什么启发呢？

需求评审注重细节

需求评审的时候，为了减少研发人员的业务思考，避免产品研发过程中对需求的误解，一份高保真的原型和详细的需求描述很重要。前期沟通得越清楚，后期的沟通成本就越小。

迭代应对变化

遇到突发情况更改产品的需求也是正常的。对于需求变更频繁的产品，用迭代的方式进行研发能够减少不确定性。特别是C端使用的产品，根据用户的反馈，一周一迭代就是一个很好的控制需求变更的方法。

以不变应万变

若在迭代的过程中遇到需求变更，最好的方法就是先不开发此功能，充分考虑变化带来的后果，放到下一个迭代之后再实现这个需求对应的功能。

有需求就可能有冲突，面对变化的需求，要越来越处变不惊。

共勉。