产品经理,如何进行有效需求评审.pdf

产品经理 ，如何进行有效的需求评审 好久没有写文章了 ，因为最近换工作了 ，正 拼命学习新东西中… 上周连续针对同一个版本进行了三次需求评审 ，第一次进行了全范围的评审 ，涉及到各方相关人员 ，包含 ：产品、设计、开发 （客户端和服务端 ）、测试 ；第二次产品团队内部小范围的评审 ，主要 是为了确定第一次评审中部分不太确定的/没考虑到实际可能遇到的问题的需求 ，涉及人员 ：产 品 （iO S端和A ndro id端 ）和运营 ；第三次针对那些不太确定的/没考虑到实际可能遇到的问题的需求 进行确认 ，涉及人员 ：开发和测试。等三场评审下来 ，就累成了狗。 一场需求评审会议变成了三场 ，这肯定是有问题的 ，是该好好检讨下了。 之前一直 创业公司 ，需求评审会基本很随意 ，叫上开发、设计和老板就可以直接开始了 ，评审会 上也会遇到一些问题 ，但涉及的人比较少 ，且一个人从头到尾都只负责一个项目 ，事后基本上只要 口头确认下评审时的问题就行了。但流程较复杂的公司情况就有些不一样了 ，需求评审会参会人数 比较多 ，并且一个人可能会负责多个项目 ，需要重新调配资源 ，一旦评审中需求不确定/没考虑周全 的问题 ，就会出现多次需求评审的情况 ，这就极大的降低了工作效率。 需求评审时常发生的情况 ： 1. 与会人员对需求的目标不明确 ，易发散思维 ，最终偏离方向。 2. 对某个需求点相持不下 ，认为该需求不合理/开发周期长不划算 ，从而导致场面混乱 ，长时间僵持 下去。 3. 对技术方案探讨不定 ，对问题点无限引申。 4 . 遗漏评审时的待改动的需求点 ，会后找相关人员再次确认。 基本上遇到上面情况中的任意一种 ，都会将需求评审时间拉长 ，导致效率低下 ，轻则需求产生变更 ，重则需求功能无法实现 ，产品人员 评审过程中也容易产生浑身燥热、体乏无力和头昏脑涨的感 觉_ |￣|○… 那如何进行有效的需求评审呢 ？ 我结合我自己上周做的需求评审作了一些总结 ，天热了给自己拔拔罐 ，希望能做到更规范 ，减少评 审时会出现的问题 ，少踩点坑。 将需求评审分为三阶段 ： 评审前 相关资料准备 （确保人 安全 ） 1 ）产品需求文档 我的需求文档里一般包含四块 ：项目背景、项目目标、需求概述和需求详细描述 ，必要的时候可以 带上项目风险 （说明此次版本可能带来的问题或考虑不够完善的地方 ）和业务流程图 （对某些复杂 功能/逻辑的分解 ）。 （需求文档结构 ） 产品需求文档主要是要把需求的逻辑表达清楚没歧义 ，对各个细节描述清晰 ，各输入输出项 （涉及 到表单/数据的输入输出 ）、业务流程 （功能的交互步骤和数据的流转 ）、计算规则 （某些特定须计 算的规则 ）、判断逻辑 （业务流程中出现的一些判断逻辑及各种判断下的反馈情况 ，账号的权限范 围也属于这种 ）和一些特殊情况 （如是否支持横屏啊之类的 ）都要写清楚 ，如果实 记不住太多 ， 每次写需求文档时都会这里漏个流程那里漏个判断的 ，可以整理一份适合自己的需求文档自查清单 ，每次写完后从头到尾对照一遍。当然不能事无巨细都通通一股脑写进去 ，不然开发和测试的朋友 会看的很辛苦 ，小心被打… 举一个活生生的反例 ：上周写文档时有一个计算规则比较想当然了 ，要算“累计阅读时长” ，阅读时长 嘛就是阅读时长嘛 ，一句话就带过了 ，然后 需求评审时就比较惨了 ，该如何统计这个阅读时长 ？ 直接用定时器吗 ？还是使用本地时间 ？用定时器比用本地时间相比既复杂又低效 ，但如果用本地 时间 ，那用户直接修改手机上的时间给不给累计阅读时长 ？还有用户如果一直停留 当前阅读页还 给不给算阅读时长 ？…后面对这个功能的计算规则讨论了好久 ，最终评审会上也没确定下来。所 以说 ，做好细节是多么的重要 ！/(ㄒo ㄒ)/~~ 产品需求文档的准确和详细可以有效减少需求评审时的花费的时间 ，也能让参会人员更清楚地了解 需求。 2 ）线框图 带上线框图而不是比如这样或那样 ，配合线框图有利于对需求点的梳理。需求文档里可以简要配些 线框图方便文字的理解 ，不过需求评审时还是另外打包一份线框图单独带着吧 ，可以详细点 ，把交 互稿也带上。 第一次评审的时候 ，我忘了带 ，而需求文档里也刚好没放那个页面的线框图…于是我只能让大家跟 着我一起 脑海中绘制一副图 ，能不能绘出来我就不清楚了O rz …反正不要学我 ！ 3 ）相关数据 带上数据而不是我认为 ，一些需要数据支撑的需求点要带上相关的数据 ，用数据说话。 小范围的沟通 （确认方案 ） 产品需求文