最近正在做一款APP，研发前期进行了3轮需求评审和1轮测试用例评审，确定了第一版的需求，研发周期为一个月。
在产品研发进行到半个月的时候，一名程序员对我说：“我觉得教室管理放在这里不合理啊，这里的功能这么复杂，要做成即可选择又可新增的多复杂啊！”
在此之前的一周，该名程序员跟我说了几次后台的收银下单功能完全可以不做，直接手机APP买单就可以了。
整个连锁店的背景我是跟所有项目组成员描述过的，对于一个现在全部靠线下来运营的连锁店铺来说，既需要基本的店务管理功能又需要线上的下单和分享功能。
这两个在最终需求评审的时候已经反复确认过的问题现在再拿出来说，在我看来是在浪费时间，我觉得现在应该把全部的精力都放在完成这个产品上。
转念一想，作为产品经理的我不就是来解决冲突的吗？研发与产品的冲突、运营与产品的冲突、客户与产品的冲突，现在我要做的是先反思一下遇到冲突的时候该怎么办，而不是一味地觉得研发不对。
一、承认冲突
产品经理和研发沟通的时间非常多，完全避免冲突是不现实的。在冲突发生的时候，我们最需要的就是控制自己的情绪。曾经听说过一个比喻：产品经理就像是化学中的催化剂，既能使得产品加速完成，也能阻碍产品的研发。
和研发保持愉快的合作关系，能够让研发产生更加积极的情绪，有利于产品目标的顺利完成。若是和研发产生矛盾，研发很有可能会产生懈怠情绪，从而导致产品延期，也有可能对后续的进一步合作产生影响。既然情绪本身不会给我们的产品带来任何好处，我们就需要在沟通的时候尽量避免负面的情绪，专注于如何解决问题上。
随后，我冷静地对研发说：“当你说教室管理放在排课这里不合适的时候，我感觉有点为难，因为我们在需求评审的时候已经反复确认了这个问题，只有排课这里会用到教室，在这里维护的话，用户操作起来会更方便，界面也会更简洁。”
二、寻找需求
这时，我也在同步思考为什么研发现在才提出这种想法，为什么之前评审的时候他说没问题了。于是，我问道：“那你觉得怎么样做更合理呢？”
程序员回答：“把这个功能放在门店管理里面，像分类管理那样做一个弹出框实现这个功能会更好。”
我这时候的想法是：你之所以这么说是因为你现在正在开发这个功能，你觉得这样实现起来需要耗费更多的时间来思考如何实现，用以前的方法来实现的话只需要直接复用以前的功能就行，减少了工作量。而且把这个功能放在门店管理部分，就不属于你的研发范围，你只需要调用就可以了，这就是你的需求。而我的需求是如何简单快速地实现这个功能，不管是谁实现的。
在研发产品的过程中，产品经理实现客户需求的主线是不变的，在此基础上，若能够平衡好内部的需求，我们就能成为了加速产品完成的催化剂。在这次冲突中，也有可能研发真的觉得这样实现会更好，只是我没法快速Get到他的思想。
三、解决矛盾
这个产品的第一版需要在一个月内完成，时间非常紧迫。这个时候产品应该更多地考虑下一期产品的功能，而不是纠结于这个已经确定的功能。
这个时候我把技术经理和相关的人员叫在一起，问问大家对这个解决方案有没有意见，最终大家都同意了这样实现。
这个小功能不会对产品本身产生大的影响，不会造成他人的不满，不影响最终的产品目标，快速确定解决方案就是最重要的。
这对我以后管理需求有什么启发呢？
1 需求评审注重细节
需求评审的时候，为了减少研发人员的业务思考，避免产品研发过程中对需求的误解，一份高保真的原型和详细的需求描述很重要。前期沟通得越清楚，后期的沟通成本就越小。
2 迭代应对变化
遇到突发情况更改产品的需求也是正常的。对于需求变更频繁的产品，用迭代的方式进行研发能够减少不确定性。特别是C端使用的产品，根据用户的反馈，一周一迭代就是一个很好的控制需求变更的方法。
3 以不变应万变
若在迭代的过程中遇到需求变更，最好的方法就是先不开发此功能，充分考虑变化带来的后果，放到下一个迭代之后再实现这个需求对应的功能。
有需求就可能有冲突，面对变化的需求，要越来越处变不惊。共勉。
