产品新人如何开需求评审会？精选.pdfVIP

产品新人如何开需求评审会 ？ 很多产品经理谈到需求评审可能都闻风色变 ，因为总是 虐的不要不要的 ，就像荒野猎人里 熊虐的小李子 ；但是 ，依然有那么些产品经理对需求评审会情有独钟 ，难得有个机会和各 路大侠比试切磋 ，享受这舌战群雄的快感。前方高能预警 ，文章稍长 ，建议产品新人耐心认 真读完 ，高手求拍砖或自行闭目 ，阿门~ 什么是需求评审 ？ 需求评审是产品进入正式开发之前非常重要的一环 ，只有所有人都认为需求已经没有什么可挑剔了 评审才能通过 ，所以需求评审也是一个“鸡蛋里挑骨头”的过程。产品经理在这场 「辩论」过程中 ， 需要不断有效的展示自己的观点 ，以便获得更多的认可 ，最终号召大家 （乐意 ）一起往一个产品目 标努力奋斗。 为什么要需求评审 ？ 让与会者清晰的了解需求是什么 ，需求从哪里来 ，对现有业务有什么影响 ，预期收益是什么 ； 让技术及测试对产品方案有详细的了解 ，以便后续开发更高效 ，没有谁愿意在后续的编写测试用 例及开发阶段再去反复沟通确认 ，毕竟那是非常低效的做法 ，当然 ，特殊情况除外 ； 让与会者清晰的知道自己在整个方案落地过程中处于什么位置 ，职责是什么 ，需要做什么 ，准备 什么 ，提供什么帮助 ，对各自负责部分的实现难度及排期有一定的心理预期 ； 评估产品方案的技术难度及实现周期 ，一期实现 ，还是分期实现 ，投入产出比怎么样 ？毕竟互联 网产品讲究小步快跑 ，快速验证迭代 ，怎么样权衡产品设计 （用户体验 ），技术成本以及商业利益 是产品经理主要工作之一。 和谁进行需求评审 ？ 一面视需求大小来看 ，如果仅仅是一个迭代需求 ，比如增加一个广告投放类型 ，那么可能只要前端 技术、广告系统技术、测试 （前端测试+广告系统测试 ），三五人随便找个地儿快速就搞定了 ；如 果是一个中大型需求 ，比如收银台改版 ，那么涉及到的与会者可能就比较多 ，然而除了技术、架构 、测试以外 ，往往UE/UI经常 产品经理忽略 ，尽管UE/UI内部可能有自己的评审 （视公司不同情况 不一样 ，有些小公司是不存在设计评审 ），但技术评估环节往往会涉及到一些交互和设计的实现需 要沟通确认 ；然而 ，往往这样的大型项目一次需求评审基本是搞不定的。 一面视公司项目流程来看 ，大公司和小公司项目流程有时差异比较大 ，大公司分工细 ，并行项目多 ，尽管涉及的干系人较多 ，但是可能仅仅来那么几个主要干系人 ；而小公司因为项目比较聚焦 ，讲 究执行力 ，反而比较容易召集所有干系人参加。 不管哪种情况 ，产品经理务必保证核心负责人到场 ，个别干系人可私下再沟通 ；很多产品经理可能 会认为召集评审会议主要是项目经理的工作 ，产品经理只需要参会把产品方案逻辑说清楚就可以 ， 如果你也是那么认为 ，那后面的内容就不必继续往下看了 ，你倒不如省点时间多去解几个bug。 什么时间进行需求评审 ？ 根据项目迭代周期来灵活调整 ，一般是在确定下个版本迭代需求list之后 （当然 ，要保证需求已 排期 ），开发正式开工之前 ，建议选择开发开工前3-5天 ，主要因为 ： 就算一次评审通过 ，会后也有些细节需要完善补充 ，沟通确认 ； 中间间隔太久 ，很可能等到开发的时候 ，很多技术实现细节会遗忘 ，因为并行项目较多 ，这是难 免的事儿 ； 运气不好的话 ，有可能遇到开发及测试人员调整 ； 很可能需要进行二次甚至三次评审 对需求评审有了初步了解之后 ，把需求评审拆分为评审前、评审中、评审后三个阶段 ，这三个阶 段产品经理究竟要做些什么。 评审前 1. 保证物料齐全 产品需求文案 （PRD ） 怎么样写PRD ，请自行谷歌 ，如果需要显得专业一点 ，那么可以按照标准格式来 ，而阴阳建议是 ， 产品经理只要能把逻辑表达清楚 ，细节描述清晰 ，技术及测试人员都能看的懂 ，那就够了 ，无需局 限于到底是用wo rd格式 ，还是PDF或者axur 格式。 UE稿 按照普遍大公司的流程 ，产品经理在这个环节只需要把产品的逻辑描述清楚以及大致的想法和UE沟 通清楚即可 ，接下来就交给UE ；这样做也没有什么大问题 ，毕竟流程在那 ，但是这样做可能会有什 么状况发生呢 ？ UE并不是时刻为某个产品经理待命的 ，很可能并行其他项目 ，也就是说 ，很可能UE排期赶不上需 求评审 ； 产品经理有自己的想法 ，但仅仅停留在自己脑子里 ，与UE沟通清楚想法后 ，可能UE做出来的东西 不是产品经理想要的 ，然后开始二轮三轮的返工 ，撕B大战一触即发 ，严重影响效率 ； 难道产品经理真的只