需求的折磨：需求评审的前、中、后,产品都要做些什么.pdfVIP

需求的折磨 ：需求评审的前、中、后 ，产品都要做些什么 半年经验的产品助理为什么会犯这 错误呢 ？这是我最近一直在反思的问题。最后 ，我发现 这和我之前的工作方式有关。 每一 需求的从无到有 ，从有到确认 ；每一次的需求评审 ，从失败到成功。对产品经理来说都是一 次折磨。每一 版本迭代 ，我们都需要反复地被折磨 ，换了新工作后到现在已经4 月了 ，工作方 法的转换 ，2 版本 ，4次需求评审的折磨。我也慢慢发现错误 ，改变工作方法。 第一 问题 ，出在需求评审 ，为什么需求评审就是没办法一次通过呢 ？为什么需求总会被大家指责 ？ 首先 ，我们应该知道需求评审存在的意义 ，到底需求评审的作用是什么 ？ 在之前几次失败的需求评审中 ，我把需求评审用来与大家敲定需求 ，许多人是第一次了解到这 需求 ，但是每 人都会有不同的想法 ，显然 ，这里错了。 1、2 小时跟您根本完不成统一意见、达成共识、确定需需求细节这所有的工作。因此需求评审的 真正作用应该是在前期沟通充分的基础上作为最后一次的需求确认 ，得到各方认可 ，令相关方配合 接下去的工作 （不要觉得前期沟通太充分 ，需求评审再核对一遍大家都已经清楚的内容 ，就像在浪 费时间 ）。 但是还是能够帮助所有项目成员更加清楚了解项目的所有内容 ，有利于后期的配合 ，因为单独沟通 的时候都是片面的 ，不可能单独和运营人员沟通过多的技术问题 ，一起开 会会让大家更好的互相 了解。 需求准备 ： 收集需求 ： 日常工作中我们需要建立自己的需求池 ，与用户的沟通 ，跟踪主要竞品迭代情况 ，留意市场变化 ， 反复体验现有产品找出待优化的点等工作 ，应当成为产品经理的日常工作 ，需要不间断的去做 ，而 不是在产品迭代项目启动后踩开始进行。用户直接反馈的需求是比较有价值的 ，通常可以从用户的 来电／用户在app内的反馈 ／相关的讨论社区／各种社交群 ／甚至是成熟竞品开设的讨论群组等 （ 不仅可以了解用户反馈的需求 ，也可以探查竞品的部分问题与后续迭代方向等 ）。 验证需求必要性 ： 适当的用户调研 ／竞品分析验证需求合理性 ，为说服相关方做准备。 迭代排期 ： 总有无数的需求要做 ，要按照产品的生命周期去做合理的排期。 讨论会 ： 初步方案完成后 ，尽可能的去组织产品内部的讨论会 ，发散思维 ，吸收更多的意见与建议 （其中可 能有你没有想到的哦 ，团队作战总好过一 人瞎想 ）。 与需求方沟通需求 ： 需求是否做 ？何时做 （排期情况 ）需要及时喝需求放反馈 ；需求如何做 ？在有了策划方案后要和需 求放沟通 ，看是否符合他的期望 ，同时协调需要配合的相关事宜。 需求大致确定后 ，不确定开发成本的需求 ，需要额外和技术人员做沟通 ，即使调整方案。有些技术 方面的需求 ，要尽早与开发达成共识 ，尽早筹划。比如现有数据库、服务器性能是否能承受后续业 务的快速成长等 ？ 需求评审前 ： 完整的需求说明 ： demo 图并注释文字的做法会比较好 ，此外将所有相关的内容 （包括流程图、表格、版本管理等 ） 全部整理在一 Axure文件中 ，并写明需求场景与前置后置需求 ），会更方便与设计、技术、测试 的沟通 ，避免不必要的反复沟通。 尽可能想清楚所有的细节、准备尽可能完善的文档 ，（当然了 ，完美几乎是不可能的 ，尽力而为吧 ！不要出大的纰漏 ）并提前与相关人员沟通 （研发、需求放等相关人员 ），达成一致。减少二次 评审、扯皮的概率 ，避免不必要的背锅。 需求说明文档说到底是给设计、开发 ／测试人员看的 ，不管使用什么样的工具、格式 ，最重要的是 看文档的人能够看明白能够接受 ，方便他们工作 ，不妨在交付物交付后询问一下他们的意见与建 议 （对于需求文档而言 ，这些相关工作人员才是用户啊 ，以用户为中心 ，产品经理时刻牢记 ！） 前发出文档 ： 可能有些时候文档来不及提前完成 ，但是没关系。合理安排时间 ，尽量提前完成文档 ，完不成就先 把初稿 （需要完成大部分内容 ，少数细节未完成影响不大 ）完成发给大家看 ，目的并不是过细节 ， 而是希望在需求评审前大家对接下来的项目要做什么内容 ，为什么做达成一致 （目的认知上的不 一致 ，根本就不可能聊到一起去。 ） 需求评审中 ： st ep1 ：说明此次迭代 ／产品的主要目的是什么 让大家对项目有一定的了解。 st ep2 ：需求简要说明 （告诉大家项目范围在哪里 ） 常用xmind ，mindmanager等工具 （前面有说整合到阿axure中 ，凭审批还是可以用