今天来讲一下产品经理都经历过且最怕的一件事；你是否经历过苦思冥想设计的产品方案到需求评审阶段被领导质疑、同事炮轰；半路接手一个产品，根据需求设计的产品方案，被领导、同事问两句就招架不住；抱怨你的产品方案不合理、缺少对相关联功能的考虑、设计的功能难实现…
最后别人会觉得你思考问题不全面，经验少、做事不细心…你反驳多了，会被认为你内心不够强大，接受不了别人的批评；默不作声又会被人觉得你是没有底气辩论，得出的结果就是你对产品的认识程度浅薄；
而你被所有人炮轰肯定也会一肚子委屈，明明很努力，却一直摆脱不了这种局面，从而变得对需求评审产生恐惧；
事实上不论是工作经验长短，在每个阶段的产品经理都会经历过这样的需求评审，今天我们就来分析一下为什么需求评审时，产品经理总被怼；
01、产品经理没有考虑好需求定位、背景
产品定位主要包含制定目标用户及解决这部分用户的哪些问题，是产品经理设计产品所围绕的核心，如果产品经理在会议一开始就强调了产品定位，在你讲解产品的过程中，参会者就会根据这个定位来看待你的产品，如果你的产品设计方案跑题了，参会者发现后，就会对你抛出一连串的问题；
一个产品从无到有并不是只靠产品经理就能完成的，在这个过程中我们还需要有各个岗位人的密切配合，当很多人一起合作共同完成一件事情的时候就需要有共同的目标——那就是我们要共同创造出一款好的产品，一款对用户有价值的产品；
对于研发来说，如果在一开始发现了产品的定位不清晰，那么一定会毫不犹豫的指出来，对自己无法理解且不认同的东西一定会弄清楚
如果产品经理没有给出很好的回答，没有得到研发的认可后，会产生如下几种情况：
第一，对于开发来说 也需要了解我们做这个产品是为谁做、在什么环境下会用到这个产品；你都没有搞清楚这一点，开发当然不乐意，在开发眼里，开发一款产品，就算在后续要优化也是在原有基础上优化，而不是因为产品经理定位没考虑好而造成大幅度的删掉重来；
第二，他一定不会认同这个产品的发展，认为继续做这个产品是无意义无发展的，我们对于自己不认同的东西会有抵触，在后续的开发过程中研发的积极性也会降低；
第三：研发会对产品经理的能力有质疑，你说什么东西研发都不配合，同时会因为觉得产品经理能力低从而让产品经理跟着研发的思路走，不断指出你的问题并给你建议；
在产品上线后面临的后果就是发现结果和预期偏离，用户量上不去，要么就是推翻重来，要么就是团队担责任，对于每个人来说，未来的成长和发展都会受到影响，辛辛苦苦做出来的产品浪费了时间又得不到很好的成果。
产品最终呈现是每个人辛苦产出的结晶，谁也不希望辛辛苦苦做出来的产品没有任何价值，不论每个参与项目的人都会想要在产品成功后自豪的跟别人说，这个项目是我参与的；
所以在关乎产品成败的方面，及关乎各位评审人切身利益的情况下，各位评审人才会不断提出自己的意见或建议，希望可以把产品做到最好。
02、缺乏对业务逻辑关系的思考
业务逻辑主要是考验产品经理对业务的了解程度及考验产品经理的逻辑思维能力。具体的表现形式体现在一个产品功能的完整性。
例如我们在阅读平台中购买了一本期刊，购买后可以在我的购买中查看并阅读；
那么在产品业务逻辑中就需要考虑：
- 每本期刊每个用户是否只能购买一次？
- 是否按照用户ID判定为同一用户？
- 如果用户在平台内再次查找此期刊，是否需要判定不再重复收费？
一个业务逻辑会涉及到多个功能点，或多个解决方案，如果缺乏对业务逻辑关系的思考就会导致遗漏功能点，产品经理在需求评审时讲解方案时，也会容易讲不清楚前因后果，导致参会者产生出很多疑问；
研发在准备开发一个产品时，需要了解产品的业务逻辑，如果说研发没有了解清楚产品的业务逻辑，那么在开发过程中遇到稍微复杂的功能、涉及多种数据类型、不了解多个模块之前的关联关系就一定会出现问题
在业务逻辑错误或者缺失的情况下对研发来说会有以下几种影响：
1、研发是基于了解业务逻辑后才会着手准备开发，只有先了解了要做什么，才能更好的知道下一步怎么做。
举个例子：
如图：这是一个阅读平台购买期刊的页面，用户可以自定义购买期刊本数，1本为100元，第二个套餐是已经设定好优惠的价格；
在开发过程容易产生的疑问：
a：点击加号增加1套，点击减号减少1套，那么展示为1套时，点击减号是否还减少呢？
b：在第一个套餐自定义了20套期刊，价格是否按照后面设立好的优惠价格走？还是单独计算为（20套*100元=2000元）？
C：这个定价后期是否需要更改？套餐价格做成可维护的还是程序先写死？
如果在前期没有对业务逻辑了解的很清楚，那么研发在开发过程中会很困难，遇见一些业务方面的问题，产品和研发会陷入不断确认需求的过程，增加了沟通成本，会直接影响到开发进度；
2、因为前期没了解清楚业务逻辑，导致在开发过程中需求变更次数太多，有时候一个很小的需求变更，对开发来说却会影响到整个开发的框架性调整，从而总是看不见工作成果，陷入因为业务逻辑问题而对代码进行的修改和调试过程中，久而久之开发的积极性也会因此大大降低；
那么具体什么是需求变更呢，我曾在知乎上看到这样一个简单易懂例子：
你去饭店，坐下来。
“服务员，给我来份宫保鸡丁！”
“好嘞！”
——————这叫原始需求大厨做到一半。
“服务员，菜里不要放肉。”
“不放肉怎么做啊？”
“不放肉就行了，其它正常做，不就行了？”
“好的您稍等”
——————中途需求变更厨房：
大厨：“你大爷，我肉都回锅了”
服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗”
大厨：“行你大爷”
然而还是一点点挑出来了
——————改动太大，部分重构餐厅：
“服务员，菜里能给我加点腐竹吗？”
“行，这个应该简单。”
——————低估改动成本厨房：
大厨：“你TMD，不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就等半天”
服务员：“啊你怎么不早说？”
大厨：“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
——————新需求引入了新研发成本餐厅：
“服务员，还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“…好的您稍等”
——————某一功能点摇摆不定
事实上我们在做项目的过程中都会遇见这种反复确认更改需求的情况，甚至有些需求的更改，导致了开发不断的在拆东墙补西墙，时间久了，开发的积极性降低了，对产品经理的怨恨也增加了…
3、还有一种情况，如果一开始业务逻辑错误或缺失，那么研发在开发过程中就会一直朝着错误的方向走，本来能解决用户的需求就会被忽略，客户问题最终没能得到解决，产品上线后对用户体验造成影响，研发最终也需要承担不该有的责任和风险；
举个例子：
用户需求是想要减肥；
产品方案围绕着用户减肥，在产品设计中为用户提供了非常有效的减肥操，但是这个减肥操跳起来特别难看。我们意识不到，一般想要减肥的用户都是注重自己形象的人。那么最终产品上线，一定会造成用户的流失；
通过以上我们了解了，如果因为产品经理定位没有考虑好，那么对于研发来说从一开始一定不会认同这个产品的发展，导致在后续开发过程积极性降低，也会因为产品开发方向错误导致最后大幅度删掉重来。
对于业务逻辑不了解也是一样的，在后续开发过程中会因为业务逻辑不清晰导致产品和研发陷入反复确认需求的过程，从而增加沟通成本，影响开发进度，久而久之造成开发的不满，积极性降低。
如果按照一开始确认的需求开发，最后产品上线了，出了问题，也会对用户体验造成特别大的影响。
所以为了避免这样的事情发生，我们在一开始的时候就会尽量减少这样的失误，团队中的每一个人在发现问题，对某个业务逻辑、某个功能点、某些交互逻辑产生疑问时都会向产品经理抛出来，以上细节遗漏的越多，参会者向你抛出的疑问点就越多，如果产品经理被一个问题就难住了，那么所有人的疑问像你抛来的时候，你就会觉得压力山大，所有人都在怼你了。
总结
其实在工作中没有永远的敌人，团队每个人的出发点都是为了打造出好的产品，减少在项目开发过程中各个岗位人不必要的工作交接。而对于产品经理来说有时候被怼也不一定是坏事；
