半年经验的产品助理为什么会犯这个错误呢？这是我最近一直在反思的问题。最后，我发现这和我之前的工作方式有关。

每一个需求的从无到有，从有到确认；每一次的需求评审，从失败到成功。对产品经理来说都是一次折磨。每一个版本迭代，我们都需要反复地被折磨，换了新工作后到现在已经4个月了，工作方法的转换，2个版本，4次需求评审的折磨。我也慢慢发现错误，改变工作方法。

第一个问题，出在需求评审，为什么需求评审就是没办法一次通过呢？为什么需求总会被大家指责？

首先，我们应该知道需求评审存在的意义，到底需求评审的作用是什么？

在之前几次失败的需求评审中，我把需求评审用来与大家敲定需求，许多人是第一次了解到这个需求，但是每个人都会有不同的想法，显然，这里错了。

1、2个小时跟您根本完不成统一意见、达成共识、确定需需求细节这所有的工作。因此需求评审的真正作用应该是在前期沟通充分的基础上作为最后一次的需求确认，得到各方认可，令相关方配合接下去的工作（不要觉得前期沟通太充分，需求评审再核对一遍大家都已经清楚的内容，就像在浪费时间）。

但是还是能够帮助所有项目成员更加清楚了解项目的所有内容，有利于后期的配合，因为单独沟通的时候都是片面的，不可能单独和运营人员沟通过多的技术问题，一起开个会会让大家更好的互相了解。

需求准备：

收集需求：

日常工作中我们需要建立自己的需求池，与用户的沟通，跟踪主要竞品迭代情况，留意市场变化，反复体验现有产品找出待优化的点等工作，应当成为产品经理的日常工作，需要不间断的去做，而不是在产品迭代项目启动后踩开始进行。用户直接反馈的需求是比较有价值的，通常可以从用户的来电／用户在app内的反馈／相关的讨论社区／各种社交群／甚至是成熟竞品开设的讨论群组等（不仅可以了解用户反馈的需求，也可以探查竞品的部分问题与后续迭代方向等）。

验证需求必要性：

适当的用户调研／竞品分析验证需求合理性，为说服相关方做准备。

迭代排期：

总有无数的需求要做，要按照产品的生命周期去做合理的排期。

讨论会：

初步方案完成后，尽可能的去组织产品内部的讨论会，发散思维，吸收更多的意见与建议（其中可能有你没有想到的哦，团队作战总好过一个人瞎想）。

与需求方沟通需求：

需求是否做？何时做（排期情况）需要及时喝需求放反馈；需求如何做？在有了策划方案后要和需求放沟通，看是否符合他的期望，同时协调需要配合的相关事宜。

需求大致确定后，不确定开发成本的需求，需要额外和技术人员做沟通，即使调整方案。有些技术方面的需求，要尽早与开发达成共识，尽早筹划。比如现有数据库、服务器性能是否能承受后续业务的快速成长等？

需求评审前：

完整的需求说明：

demo图并注释文字的做法会比较好，此外将所有相关的内容（包括流程图、表格、版本管理等）全部整理在一个Axure文件中，并写明需求场景与前置后置需求），会更方便与设计、技术、测试的沟通，避免不必要的反复沟通。

尽可能想清楚所有的细节、准备尽可能完善的文档，（当然了，完美几乎是不可能的，尽力而为吧！不要出大的纰漏）并提前与相关人员沟通（研发、需求放等相关人员），达成一致。减少二次评审、扯皮的概率，避免不必要的背锅。

需求说明文档说到底是给设计、开发／测试人员看的，不管使用什么样的工具、格式，最重要的是看文档的人能够看明白能够接受，方便他们工作，不妨在交付物交付后询问一下他们的意见与建议（对于需求文档而言，这些相关工作人员才是用户啊，以用户为中心，产品经理时刻牢记！）

提前发出文档：

可能有些时候文档来不及提前完成，但是没关系。合理安排时间，尽量提前完成文档，完不成就先把初稿（需要完成大部分内容，少数细节未完成影响不大）完成发给大家看，目的并不是过细节，而是希望在需求评审前大家对接下来的项目要做什么内容，为什么做达成一致（目的认知上的不一致，根本就不可能聊到一起去。）

需求评审中：

step1：说明此次迭代／产品的主要目的是什么

让大家对项目有一定的了解。

step2：需求简要说明（告诉大家项目范围在哪里）

常用xmind，mindmanager等工具（前面有说整合到阿axure中，凭审批还是可以用原文件，方便修改）。

step3：需求详细说明（配合demo图进行讲解）

step4：最好用自己的笔记本电脑做展示 ，有问题的地方做标注，帮助会后的修改调整工作。

这部分最好能自己做，虽然会影响会议进程，但是只有自己最了解所有内容，别人帮忙记录可能会抓不住重点。

需求评审后：

评审完成后，修改相关问题后，连同修改内容清单邮件给参会人员，取得最后的沟通协调。如果修改功能过多，且比较重要的，就只能开二次评审会了。

敲定设计时间、测试时间、上线时间。

配合设计是完成产品设计的工作，当中可能会遇到需求的调整问题。

后续工作

到此为止，围绕需求评审的相关事宜就告一段落了，当然在后续的工作中，根据项目的具体情况，可能还需要召开设计评审、测试用例评审、功能评审（一般由开发召开），虽然这些评审会，产品并不是第一负责人，但是按照目前的通行情况，产品经理通常会兼任项目管理方面的工作，因此我们需要帮助设计、测试、开发完成后面的评审工作，特别是在设计与用例评审中，有时会遇到对需求提出异议的情况，此时已定要做好协调工作，保证项目的顺利进展。

总结：

之前大多数的时间，在师傅的提醒下去做一些事，或者说在师傅确定大致迭代目标与方向后做后续的策划沟通工作。同时大部分的需求来源于运营方，所以只要沟通到位就没有大问题了。但是目前的一些需求，来源于产品内部，来源于各位老板，没有比较具体的目标，在产品方向上各有各的想法争论不休（这也是目前公司最大的问题，战略不清，方向不明）并且产品总监，技术总监，上级产品经理都有各自的想法，干涉影响需求确定的工作。此外也有沟通上的一些问题，存在有人固执己见的现象，而我一时之间又找不到说服他们的方法。或许这就是产品助理与产品经理的区别吧！

本文由 @Emma 原创发布于人人都是产品经理。未经许可，禁止转载。