为什么说需求评审被怼成狗是一件好事？

　　被怼需求的合理度、需求的效果、需求的逻辑、产品没有认真阐述需求的背景目的和效果预估、没有实操的可能性这些正当的“怼”，都能帮助产品人梳理清楚思路和逻辑，从而将产品完善做好。
　　先摆明自己观点：需求评审上产品经理被怼不是坏事，甚至是好事！
　　当然，被怼分三种：
　　一、怼需求的合理度，怼需求的效果，怼需求的逻辑
　　这个层面的被怼，绝对是好事。
　　笔者经历过怼需求的合理度需求效果需求逻辑的开发，有时候对这种开发简直不要太爱。（虽然经常怀疑自己的产品sense怎么还比不过开发，曾怀疑到质疑自己能力以至于不断push自己更努力）
　　很多时候尤其是新手产品，在没有想那么清楚的时候，一怼二怼三怼的来回批斗和不断完善中，你的产品方案才能逐步完美，你的产出才能保证效果。
　　试想：做之前的几个挑战你都没能很好的回答，想都没有想清楚，更不用说做了，做出来的效果又能怎么样呢？
　　一个产品在想清楚的情况下，实现中还会因为这样那样的问题而无法达到预期状态，一个没有想清楚，怼一下就蔫儿回去的产品方案，又如何能保证线上的成功呢？
　　所以说：怼需求的合理度、需求效果、需求逻辑的怼，是真的好事。
　　只有有产品sense的开发、UED才能怼出高水平的问题；也只有有责任心的开发和UED才能如此以owner精神怼产品。而遇到这样的怼，是打是亲骂是爱的怼，遇到这样的虐，是虐恋的虐是打铁成钢的虐，你应该开心有人帮你发现这些问题，评审完马上针对这些漏洞找各种方法完善自己的产品方案和产品逻辑。
　　这样的过程才能真正做出好的产品，也才能真正建立自己在其它团队的影响力，而回过头来，当产品上线并有效果时，你只能感谢这样虐的过程。
　　二、被怼是因为产品没有认真阐述需求的背景目的和效果预估
　　自己做需求方产品时，通常在写文档前通常会花一章节专门认真的阐述需求的背景、目的和预期效果（不限于已有数据分析、竞品情况、预估上线后效果和数据、未来长期规划等等）。
　　我相信只有把需求背景描述清楚，需求方才会与你站在同样的角度和立场上。
　　沃顿商学院的教授亚当格兰特研究发现：
　　员工没能把最大的潜力发挥出来，往往是因为少了一个基本的因素：他们忘了这份工作的意义和重要性。
　　格兰特认为：如果有人能提醒员工，他们的工作时多么重要，他们可能就会更有干劲儿。
　　史蒂夫马丁《细节》
　　一方面，认真阐述需求的背景、目的和预期效果，是产品经理把需求想清楚的必要条件；另一方面，产品经理要学会正确的“画饼”能力。
　　从自己的经历出发，在做产品助理的实习时，经常要完成一些枯燥而机械的评估工作，过了一段时间，产品老大在开会中花时间从产品经理的定位和成长角度出发，为我阐述了做评估工作的意义，从此，干劲十足由此说明，产品经理的画饼能力还是挺重要的哈哈哈。
　　三、、怼需求纯粹是因为不想增加工作量
　　那么这种情况又要分三种请看来看：
　　1。需求没有价值，或ROI产出低
　　这种情况比较简单，和第一种情况类似，是自己的产品方案有问题。一般这种问题不应该出现在评审会上，而是在评审会前就应该就产品方案像技术了解基本的实现逻辑和开发成本，提前沟通便能轻松解决这一问题。
　　2。需求没有问题，人力无法实现
　　这种情况非常普遍，需要分情况考虑：
　　首先，评审前自己项目需求的节奏需要提前梳理清楚，什么是重要非重要紧急非紧急的，在评审前即考虑清楚。
　　往小里说，判断产品模块里需求的优先级，是基层产品即应掌握的方法；往大里说，一个产品整体的优先级便是整个产品的战略核心。产品经理就是在不断的判断做与不做，什么先做什么后做的过程中，不断提高自己的产品能力。
　　如果优先级已经梳理清楚，仍然面临必须要做的内容没有人力，那么这时候考验的是产品经理跨团队协调能力。是否可以借调其它兄弟团队或团队中其它同事帮忙实现需求？是否可以利用已有的资源绕开卡中的某个环节来进行实现等等。
　　这里情况需要按情况具体分析，灵活处理。
　　3。需求没有问题，但实现团队与需求方不shareKPI，只是为了省事
　　这种情况是最棘手的情况，如果不幸遇到这种情况，可以找机会试着跟自己团队的leader或对方团队的leader沟通，通常领导会帮忙给予一些支持，甚至从管理的角度是否有优化空间，比如需要成立单独项目组大家为同一个目标共同做事等等。
　　
　　总结