对产品来说，最担心的莫过于需求评审会了，如果没准备好，一般都会被喷得体无完肤。这篇文章，组综合总结了自己在需求评审方面的心得，肚子里东西多了，自己也会信心倍增。

众所周知，产品经理最需要面对的、且不能逃开的，就是需求评审了，说是产品经理的噩梦也不为过，你既要保证你的需求可以让开发、测试、设计等人员痛快的接受，还要面对他们的不断质疑，在一次次谩骂中脱颖而出，做好了你就是舌战群儒的孔明。

总而言之，产品经理需要用自己的三寸不烂之舌，来说服所有的执行人员，接下来就让我们来一起看看需求评审要注意的事项吧，主要是分三个部分来分享。

一、需求评审意义

1. 明确产品与研发对需求的一致性，以免双方理解不一致，出现需求偏差，也加深了产品与研发的矛盾，不利于后续工作的开展
2. 需求不评审，容易浪费开发资源，对公司以及业务方的影响很大，公司浪费了资源与时间，业务方降低了对我们的信任度

二、需求评审流程

1. 外部需求评审

准备详细的需求文档，特别是需求中需要确认的部分，比如角色权限操作规则等，详细的与业务方（需求提出方）进行一对一或者一对多的沟通，保证与需求方的一些框架以及细节理解达到一致无误，才能进入内部评审；不然过不了业务方这一步，后面做的都是一些无用功（本人深有感触，有些需求抱着就这样的心态去跟业务方对，结果到后面只能产品自己担着）。

2. 内部需求评审

评审前：文档、通知、提前沟通

准备好详细的需求文档，并提前做好通知和文件发送（重点！！！），如果有条件可以以官方的形式发送，比如邮件钉钉闪推等，或者是提前跟相应的开发负责人员进行简单的沟通，这样也可以加大评审时的效率。

一定要提前发送相关资料，功能清单、流程图、需求文档等，每个人吃完饭还要消化呢，文档都还没看完，就直接开始讲了，那等于评审了个寂寞。

评审中：节奏、内容、细节、反馈、完善

• 节奏：就是我们在评审中一定要把握会议的节奏，需求评审是要在正常的节奏中让所有人都知道需求的概要，而不能一开始就在一个细节上进行死抠，本人的心得就是，分模块进行消化提问（例如：我这个模块讲完了，有人有不理解的吗，有的话现在就提，待会下个模块讲解中就不要提这个模块的问题了），诶，这样一讲，开发每个阶段接受的信息量是差不多的，每个模块的问题整理下来，我们再来一个总结，那就是对我们的会议有个初步的整理了
• 内容：也就是我们的一个框架吧，会议是我们主持，我们要让他们知道这个会是干嘛，正常功能优化还行，要是整体改版，开发根本都不知道你说的什么东西，比如说我们这个版本需求的一个背景，为什么要做这个需求，这个需求能带来什么价值，我们准备怎么来做这个需求，先把我们的框架给过一遍，然后才进行下一步
• 细节：等把前面的东西都过完了，这个时候我们才要去过一下每个模块的细节部分，比如一些操作规则，显示规则等，也是分模块去记录一下开发提出的问题或者是建议
• 反馈：在会议上每个人提出的问题或者是建议，我们都要进行记录和完善，在把握会议节奏的同时，回答一些必须的问题，其他问题以会议纪要的形式输出
• 完善：根据会上提出的一些问题，进行二次分析，在不改变产品定位的情况下，可以进行适当完善，必要的时候可以进行二次评审会议，以达到与开发理解一致

评审后：纪要、排期、跟进

不要以为评审后就没事干了，除了上述必要的会议纪要和二次评审，结束后，要及时与技术团队进行技术方案的确认，确认版本的具体排期，实时的跟进开发的进度和质量。

我这里针对app采取的是分模块更新测试包，产品进行分模块验证大方向是否有误，如果大佬们有其他更有效的方法，可以一起讨论一下。

三、总结

我个人认为，需求评审是最锻炼产品经理沟通能力、协调能力、逻辑思维能力的体现，其实不止是需求评审要准备这么多资料，这么多时间，在做其他的工作时，也同样需要做足准备。

比如：

• 在需求调研时，要提前明确调研的目的、输出调研结果；
• 原型阶段时，要把握业务流程闭环、用户体验升级、功能展示突出；
• 验收时，要进行功能性验收、保证上线无误；
• 迭代时，要做足数据分析、运营分析、用户反馈。

产品从来不打无准备的仗，只要任何时候，我们心中有框架、有数据支撑、有理论支持、有场景衬托，那么在一定程度上都可以解决问题的。

肚子里东西多了，自己也会信心倍增，把所有可怕的变成可爱的；把所有不可实现的变成可能；把自己从未了解的变成信手拈来，这就是我从近期的多次评审中找到的一点点心得。

需求评审不仅是产品经理技能的体现，也是团队协作和项目管理的重要组成部分。

以下是一些额外的建议：

1. 用户参与：如果可能，让最终用户参与到需求评审中，他们的反馈可以提供宝贵的视角。
2. 迭代思维：需求评审不应该是一次性的，而应该是一个持续的过程，随着项目的进展不断调整和完善。
3. 工具利用：使用项目管理工具（如JIRA、Trello等）来跟踪需求的状态和评审的进度。
4. 培训和分享：定期组织培训，分享最佳实践，提升整个团队的需求评审能力。

通过这些方法，可以进一步提升需求评审的效率和效果，确保产品开发过程的顺利进行。

上面是我对整个文章做的一个总结框架。同时，也欢迎其他产品大佬分享你们的经验和技巧，共同提升整个行业的专业水平。