一、需求原因

研发对需求不认可，觉得需求不合理，这是最关键问题。

1）需求本身有问题

任何产品经理的需求方案都不会一直完美的，被研发提出问题也算正常，不需要慌，再次思考下这个点就好，将最合理的需求方案再次过会评审，达成一致。

2）需求本身没问题

产品经理可以发挥你的口才了，业务场景、用户、价值等这一些全部跟研发讲下，研发不像产品，很多时候他们不了解业务，尤其是B端，理解没那么强，角度跟你不一致，多解释下就好。

毕竟需求评审不单单是评审这个功能点，也需要让大家理解需求背后的原因。

二、技术原因

1）现有技术实现不了

现有的需求没有技术是实现不了的。真的说了这个的就是研发本身能力不够，当然了，我们需要解决问题，如果研发说这个，可以考虑换个替代方案，两边沟通好就行，产品经理也需要灵活处理事情。

2）现有技术可以实现，比较难

这就是一个优先级和排期的问题了，比较难就是给足时间嘛，如果比较重要的需求，产品经理就可以协调下排期，这个不是问题。

3）需要更改系统现有技术框架

比如一个中台系统，用了 FastAdmin 的集成框架开发，你的需求想要在里面加个视频效果、动画效果啥的，这可能就需要换框架了，采用一个前后端分离的来处理，这个就不好搞了。

三、时间原因

时间原因有两个，一是研发本身有需求在身，新的需求期望上线时间可能有影响；二是新的需求要求时间本身研发就满足不了。

两者其实都好沟通，说出来就好。这里有个建议，需求评审前，可以跟研发负责人先简单过一下，需求的开发工时，有个大致的了解在后面评审就会好很多。

当然，如果产品经理懂技术，在研发的工时评估上就更占据主动性，也会更合理，我是很提倡产品经理学习技术的，不求你可以写代码，至少能懂个大概。

四、成本原因

1）价值不高

因为一些比较初级的产品经理，可能对研发的时间成本考虑不完全，一些对用户价值确实不算高的需求，研发需求花很多时间开发，这就是个问题。

当研发跟你说了，你理解了他们的工时，就要去做改变，不要觉得他们反驳你就失落，这都是成长。

2）价值很高

还是跟前面一样，研发没有理解透彻，看起来很容易的功能，对业务方可能会节省很大一笔人力资源，还是那句话，需求评审不单单是评审这个功能点，也需要让大家理解需求背后的原因。