如何开好这个最体现产品经理能力的会议？

作为产品经理，一般都经历过需求评审，或者是自己主持的需求评审，或者是参加别人的需求评审。大部分需求评审会陷入两种极端情况，一种是产品经理在上面对着产品需求文档照本宣科，下面与会人员无动于衷；另一种是产品经理刚讲几个需求，大家已开始了激烈的讨论，都在证明自己是对的，会议被无限延长，效果甚微。所以说需求评审体现了产品经理的综合能力，如果完成的好，后续实施会比较顺利，也会提高自己在团队中的影响力，如果完成的不好，会对后面的产品开发增加巨大的沟通成本。 

一、什么是需求评审？ 
需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看，需求评审是一个非常重要的环节，它串起了前期的需求收集、需求分析和后期的需求实施和产品落地。

二、为什么要进行需求评审？

1、明确产品需求，达成统一认知。对于明确产品需求，主要面对的是需求提出方，即相关的业务人员或者用户代表。讲清楚自己对于用户需求的理解是什么，是否深入分析了用户需求背后的真正动机。例如用户想要一个钻孔机，背后真正的动机是想要墙上的一个钻孔，还是想挂一副画，或者是想要一个温馨的环境。然后与需求方沟通，阐述自己的分析过程，确定自己的理解是否正确，并与其达成一致。因为对动机的理解不同，解决方案也会不同。当动机达成一致后，接下来介绍相关的解决方案，也就是他们将得到什么样的按钮，进行如何的操作，会看到什么样的数据或分析等。然后进行沟通，这些解决方案是否实现了其目的，是否带来了工作效率的提升。

2、沟通需求细节，优化实现方式。对于需求细节的沟通，主要面对的是需求实现方，即相关的设计或开发人员。在这个环节主要是讲清楚“为什么做”和“做什么”，首先交代需求的相关背景和设计原因，让实现方从源头就清楚自己要做的功能为什么是这种形式，其次详细描述需求的实现方式的相关细节，让实现方知道自己接下来做的东西是什么，特性是什么，具有什么样的流程，如何操作等。最后针对相关细节进行沟通和讨论，实现方会站在他们的角度，对实现方式提出自己的疑问或建议，一般情况下，他们提出的相关问题，会弥补产品经理前期没有想到的地方，从而让实现方式更加合理。

3、体现专业能力，获得团队支持。需求评审，体现了产品经理的综合能力。而这种综合能力，不仅体现在需求评审会议的主持和沟通上，更重要的是在需求评审前，对需求的收集、分析和实现，也就是把用户需求转化为产品需求的过程，需求评审只是对这个过程完成度的体现和考验。所以，长期深入的思考和足够专业的能力是开好需求评审会议的前提。作为产品经理，要认真对待需求评审，清楚自己的核心工作在什么地方，通过什么方式能进行更好的呈现，如何沟通能让需求更准确的传达，把它当成一次考验和锻炼自己的机会。只有自己足够专业，才能得到团队的支持，有了团队的支持，才会更加自信，在良性循环中，使产品不断的迭代和完善。

三、如何进行需求评审？

1、提前准备。凡是预则立，不预则废。只要你认为比较重要的事情，想获得比较好的结果，前期的认真准备都必不可少。对于需求评审会议的准备工作，主要有三个方面。第一，资料方面，一定要详细，齐全，至少包括产品需求文档和会议议程，形式越正式，大家对会议的重视度也越高。第二，人员方面，要考虑清楚都需要谁来参加评审，是一次性把相关内容都评审完，还是分批次小范围评审，然后提前把资料发送给相关人员。第三，沟通方面，分析相关人员的关注点在什么地方，需要对方在哪些方面给出建议，最好提前逐个进行沟通，让对方在会议之前就对相关内容有所了解，这样在评审的时候会更有针对性，效率也更高。

2、足够具体。在讲解具体产品需求时，不要陷入自己的逻辑不能自拔，而是要把参与会议的人员当成小白用户，站在对方的角度，尽量讲的详细具体，主要有三个方面。第一，形式多样。产品需求文档，不要只有Word版本，Word一般作为相关人员的后期查看使用，在需求评审时，最好使用PPT、流程图或Axure形式，也可以多种形式交叉使用，避免枯燥。如果有可以实际操作和带交互的原型更好，面对具体的软件，更容易调动大家的积极性。第二，背景清晰。一定要把产品设计的背景信息以及需求分析的来龙去脉讲清楚，让大家“知其然”的同时也“知其所以然”，对需求的理解越深入和全面，越有利于需求的落地和实现。第三，代入场景。不要直接讲产品的功能，尽量把功能代入用户的实际使用场景，通过故事来串联操作。例如苹果在发布MacBook Air笔记本电脑时，直接从档案袋中把电脑拿了出来，惊艳全场。这种方式就比直接讲电脑的尺寸参数要形象的多。

3、长期跟踪。不要指望一次评审和几次沟通就能让大家全面理解产品需求，会议结束后，还需要进行以下三方面的工作。第一，形成文档。会议结束后要及时形成会议纪要，对于会议中没有确定的争议点，产品经理要给出解决方案，并结合已形成的决议和后续相关工作等，尽快编写出详细的文档，并在后续过程中不断更新和完善。第二，沟通确认。把文档以邮件的形式发送给大家后，找相关人员进行沟通，确认双方理解一致，并敲定相关功能的设计开发时间点。第三，长期跟踪。需求评审只是开始，开启了产品具体实施和开发的另个一环节，在此过程中，产品经理要不断找相关人员确认需求细节，推进功能开发。

总结

需求评审是产品设计开发的一个重要环节，贯穿了产品需求和产品实施的全过程，对于产品最终是否能按时落地起到关键的作用。所以，在需求评审前，要提前准备；需求评审中，要足够具体；需求评审后，要长期跟踪。虽然整个过程体现了产品经理的综合能力，但一定不要为了证明自己的能力而无法听取反对意见，带着情绪产生争执。争吵本身并不可怕，可怕的是为了捍卫自己，赢得辩论而争吵。需求评审是一次挑战，产品经理要把每次挑战都当成学习的机会，让自己不断成长，做出更好的产品。