写了半天，发现偏题了，见谅见谅，可以看成我对需求评审的一些做法...

我和女朋友都是产品～

虽然是生活在一个屋檐下的两口子，但是在需求评审的时候，我们的风格完全不同，她～婆婆嘴，一个需求评审四个小时很常见，而我尽量会压缩在一个小时，最多一个半小时之内～

当然，在这里我不是diss她，毕竟我还要活着，不过我可以阐述下我的一家之言～

人是懒惰的，我不否认会有评审前通读文档、认真思考、输出问题的开发，但这样的人少之又少，大多数开发对于评审都抱着反正后面有产品讲，我临场发挥能力贼强的想法（不要试图用什么评审问题表之类的管理手段，解决不了内驱力的问题，评审表上都是又浅又蠢的问题，恰恰会证明他没有好好看）～

人的注意力是涣散的，90分钟的电影，就是人类注意力能够保持相对集中的极限时间，铁打的汉子也讲不了四个小时而不逻辑混乱，打铁的汉子也听不了四个小时而不魂游天外～

所以，你想通过一次需求评审（4个小时，没错就说你呢～），就一战而功成，把一个周期的开发任务安排的明明白白，我只能说，啥菜啊，喝成这样～

我的需求评审，绝不是从我发出文档，让研发仔细阅读，三天后评审时开始的～

我的迭代思路，要实现的主要流程，想要的交互效果，预判断的实现难点，我会在刚开始编写需求的时候就向研发leader开始渗透，这可能在他找我确认某一问题的时候、可能在我们一起排队等厕所的时候、可能在我们一起抽烟的时候。在他看到我的详细文档之前，我要给他建立起基础的框架并完成彼此初步的妥协，普通开发可能不会仔细阅读文档，但leader基于责任or金钱大多数会仔细阅读，并基于他们丰富的经验在需求评审时提出相对靠谱的问题～

大概总结下我的需求评审理念，评审前搞定leader，评审中彻底搞定leader，然后挑出评审里中最最重要的部分，敲黑板划重点的讲半个小时给其他开发，中间穿插几个段子，活跃下气氛，集中下注意力。之后开发阶段，leader帮我挡住7成问题，自己搞定剩下3成；

美滋滋～～～

评审时顺利，研发时出问题，主要是评审的时候，开发并不会想得非常细，他们可能只是来了解这期的需求list和评估需求实现期限等，只有等真正开发时才会去梳理里面的各种逻辑。

产品评审肯定是有意义的，包括确认本期需求、理解需求和推动项目进行，有问题可以在评审提出来及时讨论解决，但是可能在开发过程中也会遇到其他问题，遇到解决就行。

需求评审是经验主导。

后续各种岔子很正常，任何项目都是先考虑是否能做，再去考虑细节。

能力稍强的技术首先用的是设计师思维，他们会考虑跟业务挂钩的各个大方向上有没有冲突，产品做出来了对业务的发展加了多少分，别看他们不说，其实他们心里都有一杆秤的。需求会能顺利通过，说明产品经理的能力基本已经到位。

具体实现过程中，他们就会转换到工程师思维，会有各种限制、管理、掣肘。这个时候就是要妥协的时候，不是开发人员要妥协，而是考验产品经理的planB能力，当需求不能完全实现的时候，得评估能实现多少？70%？80%？达到预期，请大胆妥协。

然后就是等！等到有更成熟的技术，或者跟牛的技术来把产品更新到100%。

所以说，提的这个问题不是技术的问题，而是整个系统的问题。开发人员有困难，只要不是消极怠工，整条系统链条都是要妥协和想办法解决问题的！请不要甩锅，不要抱怨，想做成项目，妥协，就是门艺术！

看一般遗留的是什么问题吧。大家在评审会上一般不会看的特别细的，所以一些小问题在开发过程中才发现是很正常的现象。

评审会对我来说是有帮助的，下面我说下我对评审会的理解。

（前提，这是一个面向开发同事的，评审开发方案的评审会。）

由我组织的评审会，目的就几个：

①确认需求，这次我们做的内容是什么，是A不是B，别到时候给我做错了。

②理解需求，让开发能够了解到这个需求的背景和整体。这种情况下我们的客户这么痛苦，你还好意思跟我说不好实现？

③提前了解技术问题，有什么大问题早点提出来，以后再提不接受。小问题就随便了。

这种问题产品跟开发都有锅。

如：

产品的锅：

产品给到需求思考时间是否充裕让开发了解和思考需求？产品描述是否准确精简，让开发仅看文档、原型、和流程图就大致理解需求？是否需求会议描述时逻辑不清晰导致开发可能根本没听懂？

开发的锅：

公司是否明确这类事项责任方，导致开发觉得bug数量事不关己高高挂起？

评审会的时候开发忙别的事情去了吧，没认真听，经常会碰到这样的事情。PRD评审会很顺利结束了，然后实现的时候问题一大堆。

当然一个巴掌拍不响，久而久之，就会关注这些疑问的点，是不是自己在评审会的时候没有讲清楚，自己讲清楚每个逻辑每个点以后，就问心无愧了。

再碰到开发过来问就反怼回去，“这个在评审会的时候着重强调了哦，可以看下当时的会议纪要~”

主要原因就是研发人员高估了自己的实力。

在评审的时候，听上去所有的功能也就那样，给自己造成了：可以啊，很简单，就这样么之类的假象，然而，在敲代码的时候发现：不行啊，不对啊，实现不了之类的问题。

不是他们羞于表达，就是对自己能力的错误认知！！!

其实这个情况还是挺常见的，在过评审的时候，一般是大概看一下业务逻辑和需求在大面上是否是可行的，开发在过的时候也不会说具体看得那么细...细枝末节的地方可能评审会上很可能是看不出来的，真正是要做起来才会发现这里那里的问题，在建表、堆代码的时候才会发现开发成本、用户体验、异常情况等等问题，还有一部分是需要双方具体共识的内容，以防开发和产品理解不一致导致做错的情况。

需求评审的目的和意义不单单是过需求可行性，更重要的明确业务背景，让协作的几个人员都了解、参与到项目当中。

需求评审会的时候，最好产品把能想到的功能点都讲解清楚；

并时刻观察开发的表现，看他们是否有问题，如果有问题可以在评审过程中及时沟通；

如果有不确定的先记下，线下确定后再告知；

按照自己的理解认为是比较负责的功能点要提前和开发说清楚，询问他们是否有问题和困难；

评审的时候没有，但是真正在开发过程中却总有因为功能难点的问题找你，你可以记住他们的难点在哪里，下次再有类似的功能时也好着重提醒下。

这种问题其实很常见，造成这种现象的原因主要有2方面

第一、需求的不确定性，在需求评审会结束后有些需求会发生变更，在PM看来仅仅是变更一个需求，但是对于研发人员就是牵一发而动全身，可能因为一个功能的变化导致原先写的东西都会变成废物。

第二，需求评审会的时候没有将需求明确，这也会导致开发人员在开发过程中一脸懵B，我们只会告诉开发人员我们要什么，而没有站在全局的角度去考虑问题，甚至连一个需求的异常状态也不愿意考虑，那么在开发的过程中怎么会前进呢?

第三，毫无意义的需求评审会，需求评审会很多情况下就是个伪需求，仅仅是为了开而开，并不能产生任何有价值的东西需求评审会后，PM要根据需求做产品设计（也就是画原型），技术人员要针对不好实现的需求做技术解决方案和底层架构的搭建。

第四，我估计楼主把需求评审和原型评审放一起了，在原型评审的时候就是着重解决每个需求转化成的功能的细节部分，要是 细节狗沟通清楚了，还怎么会出现问题呢

这里我写过一篇完整的文章，总结了自己遇到的各种坑（包括参与方的坑），可以参考下：http://www.woshipm.com/zhichang/5358947.html

需求评审，研发只是对产品的需求是否有价值和排期进行讨论，具体的细节逻辑肯定是开发的时候思考是最为全面。并且在研发的时候沟通细节是效率最高的，工作本就是不断交流，不能期待一次讲完就完事或者给个prd就可以让研发无脑开发，不然开发完，产品又要吐槽了研发不给力了

这太正常了，很多事情都是要做的时候才发现一堆问题，以为只要1天，实际要3天。以为一个人能搞定，后来要加人才能做。

其实嘛，只要不是大问题，比如活动临近开始，预热都已经放出去了，技术两手一摊说这没法整。

其他小问题，大家还是可以一起想办法解决的。

作为一个研发，我认为这个现象很正常，也有办法解决。

首先说为什么正常：

1. 评审需求时产品已经想了几天了，但研发是第一次接触，双方信息就不对等，然后在一次评审1-2小时之内get到所有信息很难，需要时间消化；

2. 产品的需求文档很难做到面面俱到，难免有考虑不全；

3. 研发在需求评审中疏忽，问题没有及时暴露，之后稀稀拉拉的一直有问题；

4. 个别研发事逼，什么都让产品决定，原因就是不思考不主动不担责。

用流程解决：

1. 在需求评审前产品先和架构师、经理沟通，获取反馈，同时潜移默化的给对方灌输，同样一个需求讲第1遍和讲第10遍研发的反馈截然不同，有的吹耳边风的意思；

2. 在需求评审通过后，留1-2天给研发消化并提问题，把问题收集起来产品一次性答疑；

3. 研发完成设计后需要给产品反讲，产品check和自己的理解是否一致，防止出现击鼓传花的理解偏差。
   

总结来说，研发在评审后持续有问题是无法避免的，既然如此干脆在流程上给研发设定提问环节，集中解决，提升效率。

能想到两个原因：

1 、开发团队对这个项目不熟悉，听不出来里面有什么需要注意的，上手做才能了解；

2 、需求评审没有讲需求背景和现有产品的关联，只在功能层面讨论讲逻辑，枯燥且无味。

需求评审之前最好就搞定对应的技术负责人，沟通技术可行性，需求评审本质上是信息同步，把需求的详细信息同步给整个团队，以及阶段推进，把需求从策划设计推到研发阶段。

不用期望光靠评审解决所有问题，开发阶段也要经常跟进，鼓励团队进行沟通。

2个场景:

(1)你与研发经理关系很好：你所担心的问题都不是问题，就算在设计上有逻辑考虑不全的地方，他也不会怼，整个评审会在很轻松的过程中度过；

（2）你两关系一般：提前想清楚为什么提这个需求（切记误言“领导要求的”，‘客户要求的’），为什么这样设计，把逻辑考虑完善；这样就能立于不败之地；

综合2点：做人、做事；没有捷径；