作为产品经理，您通常参与过需求审阅、您自己主持的需求审阅或其他人的需求审阅。 几乎所有的需求审查都陷入了两种极端的情况，一种是产品经理上面对产品需求文档照本宣科，下的参与者无动于衷，另一种是产品经理刚讲了一些需求，大家就已经开始了激烈的讨论，都是自己对会议无限延长，收效甚微。 因此，需求审查体现了产品经理的综合能力，如果顺利的话，后续的实施就会变得顺利，在团队内部的影响力也会提高，如果不顺利的话，后续的产品开发就会花费很大的沟通成本。
一、什么是需求评审？
需求审查通常是由产品经理主持，通过对产品需求文档的说明，使相关人员了解具体的需求，提出疑问，进行交流的过程。 统一大家对产品需求的理解，为后续“怎么办”奠定基础。 从整个产品的分析、设计和开发过程来看，需求评审是非常重要的一环，它连接着前期的需求收集、需求分析和后期的需求实施以及产品落地。
二、为什么要进行需求评审？
1、明确产品需求，达成统一认知。 为了明确产品的需求，主要面对需求提出者，即相关的业务人员或用户代表。 明确自己对用户需求的理解是什么，是否深入分析了用户需求背后的真正动机。 例如，用户想要钻头。 其背后的真正动机是想在墙上打孔，想画画，想要温暖的环境。 并与需求方沟通，阐述自己的分析过程，判断自己的理解是否正确，并与之达成一致。 因为对动机的理解不同，解决方法也不同。 动机一致后，介绍以下相关解决方案。 也就是说，他们会得到什么样的按钮，进行什么样的操作，看什么样的数据和分析等。 然后进行沟通，了解这些解决方案是否达到了其目标，是否带来了工作效率的提高。
2、沟通需求细节，优化实现方式。 关于需求细节的沟通主要面对需求的实现者，即相关的设计和开发人员。 在这个环节中，主要说明“为什么要制作”和“制作什么”。 首先，说明要求的背景和设计理由，并让实现方从源开始明确自己制作的功能为什么是这样的形式。 然后，我们将详细介绍如何实现要求，并让实现方知道自己下一步要做的是什么、特性是什么、流程如何以及如何操作。 最后对相关细节进行沟通和讨论，实现方站在他们的立场上，对实现方式提出自己的疑问和建议。 一般来说，他们提出的相关问题，弥补了产品经理前期没有想到的地方，使实现方式更加合理。
3、体现专业能力，获得团队支持。 需求评审体现了产品经理的综合能力。 这种综合能力不仅是主持和沟通需求审查会议，更重要的是在需求审查之前，收集、分析和实现需求，也就是将用户需求转化为产品需求的过程，需求审查就是这个过程因此，长期深入的思考和足够的专业能力是召开需求审查会议的前提。 作为产品经理，要认真对待需求审查，明确自己的中心工作在哪里，用什么方法能更好地进行演示，怎样沟通才能更准确地传达需求，并以此来考验自己如果自己不够专业，就不可能得到团队的支持。 有团队的支持，你会更有信心，在良性循环中不断迭代和完善产品。
三、如何进行需求评审？
1、提前准备。 事前立则立，事前不决定则废。 只要你觉得比较重要，想取得比较好的结果，前期的认真准备就必不可少。 需求审查会议的筹备工作主要包括三个方面。 第一，在资料方面，一定要详细、齐全。 至少包括产品需求文件和会议议题，形式越正式，大家对会议的重视程度也就越高。 第二，在人员方面，要考虑需要谁参与评审，相关内容是一次性全部评审，还是分批小范围评审，然后将资料发给相关人员。 第三，在沟通方面，分析相关人员的兴趣点在哪里，对方在哪些方面需要建议。 提前一个一个地进行沟通，以便在会议前了解相关内容，这样在审阅时就能有针对性、高效。
2、十分具体。 在说明具体产品需求时，不是囿于自己的逻辑而无法自拔，而是把参加会议的人当成粗鲁的橘子用户，站在对方的立场上，尽可能详细具体地说出来，主要有三个方面。 第一，形式多样。 产品的需求文档不仅是Word版本，而且Word一般用作利益相关方的后期审阅，在需求审阅时最好使用PPT、流程图或Axure格式。 另外，为了避免无聊，还可以交叉使用多种形式。 如果有一个可以实际操作和交互的原型，那就更好了。 面对具体的软件，很容易调动大家的动力。 第二，背景清晰。 要搞清楚产品设计的背景信息和需求分析的经过，让大家既“知道是”，又“知道是”。 对需求的理解越深，就越有利于需求的落地和实现。 第三，代入场景。 不直接谈论产品的功能，而是尽量将功能代入用户的实际使用场景，通过故事串联操作。 例如，苹果发布MacBook Air笔记本电脑时，直接从档案中取出电脑，震惊了会场。 这种方式比直接讲电脑的尺寸参数要形象得多。
3、长期跟踪。 不要期望通过一次审查和几次沟通就能全面了解产品的需求。 会议结束后，需要进行以下三项工作。 第一，创建文档。 会议结束后及时形成会议纪要，对会议中未确定的争议，产品经理应给出解决方案，并结合形成的决议和后续相关工作等，尽快形成详细文件，在后续过程中不断更新完善。 第二，沟通的确认。 通过电子邮件将文档发送给您，然后与相关人员联系，确保双方理解一致，并确定相关功能的设计开发时间点。 三是长期跟踪。 需求审查才刚刚开始，就开始了产品的具体实施和开放
发的另个一环节，在此过程中，产品经理要不断找相关人员确认需求细节，推进功能开发。总结
需求评审是产品设计开发的一个重要环节，贯穿了产品需求和产品实施的全过程，对于产品最终是否能按时落地起到关键的作用。所以，在需求评审前，要提前准备；需求评审中，要足够具体；需求评审后，要长期跟踪。虽然整个过程体现了产品经理的综合能力，但一定不要为了证明自己的能力而无法听取反对意见，带着情绪产生争执。争吵本身并不可怕，可怕的是为了捍卫自己，赢得辩论而争吵。需求评审是一次挑战，产品经理要把每次挑战都当成学习的机会，让自己不断成长，做出更好的产品。