需求评审是在设计产品过程中的第一次审核，主要是帮助项目参与者快速理解产品意图，认可采用的方案。为了让需求评审更高效的完成，产品经理需要做哪些准备呢？
可以先回忆一下我们评审过程中遇到的一些问题：
“这个做了有什么用？”
“有没有认真想过？”
“唉，你这个做了，之前的XX是不是就没用了”
“这个做不了”
“有和业务方确认过吗？”
“你这个需求这么大，一下子评的完吗？”
“我靠，你是不是傻X，哪有这么设计的？”
“你是产品经理，你的数据呢？”
不管是新手上路，还是老司机开车，在需求评审过程中，相信都碰到过上面的情况。为了让效率更高，目标明确，我们可以在评审前、评审中和评审后做相应的准备：
1、评审前——做好产品基本功
1. 如果是一个商业产品需求，请和你的业务方认真推演产品要解决的问题。注意要抠出业务方要解决的问题，而不是问业务方“你要不要这个功能？” 作为产品经理，你要相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。
2. 如果一个是工具类的产品或者体验层面的优化，请认真分析各个方案背后的用户心理变化，同时准备好相关数据佐证你的假设。评审上可能用得到
3. 仔细推敲产品方案，是否有考虑过还有其他的方式可以解决问题，不同的方案优缺点各是什么。
4. 提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法，技术的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来。
5. 请去掉“我是产品经理，我比你懂市场，我比你懂交互，我比你懂人性”的帽子，很多技术小伙伴真的比你懂。
6. 准备好一份逻辑清晰的需求文档，形式不局限，核心是要表达清楚你的意图。
7. 如果之前评审经常出现表达混乱，说的意思别人不容易懂。你可以再辛苦点，准备好一份评审大纲
8. 仔细review你的需求文档，是否各个细节都考虑到了，尤其是异常的情况，和其他系统有依赖影响的情况。不然测试的同学会把你问的哑口无言
2、评审中——注意表达，注意情绪，控制好节奏
1）参与评审的技术，他们的关注点可能各不相同。有的擅长剖析你的需求动机业务目标（大部分的技术leader会关心）、有的擅长追求细节（比如测试同学）、有的喜欢带偏话题（在你评审的时候，可能他们会提一个其他的话题）、也有的喜欢用“教导你”的口吻“教你”做怎么产品，还有各种各样
2）需求开始，可以先讲清楚你的业务背景，确保大家理解的前提下再带入你的方案。然后记得要阐述为什么要用这套方案，而不是其他方案。这两件事情需要在开始就说的很清楚，讲完后可以停顿让大家提业务背景和方案的问题。这里要掐断那些喜欢问交互细节，逻辑细节的问题。
这一步骤的重点是要说清楚发生了什么问题，为什么这么干而不是那么干——这样不至于在后续的环节里，又有人提回来质疑你的需求背景
3）复杂的问题，考虑用一些流程图，再结合“总分总”的方式。可以先说明白整理步骤，先做什么，再做什么，最后做什么。然后再按步骤细评各个环节的细节，都评完后再阐述一下总的流程。
4）注意话题不要被带偏。在过程中，出现某个同学说“唉，之前有个XX也是类似的问题，还没解决”。这个时候作为产品经理，应及时掐住话题源头，可以说这个问题待会私下讨论。
5）新人控不住节奏的时候，可以求助会议上稍微资深的技术大大来控制节奏。 “这个问题好像和本次评审无关，李大大我们会后再聊这个，你看怎么样？”——李大大可能是个技术总监。
6）你也会遇到喜欢爆粗口的技术。“我操，这有个屁用啊！”“你是不是脑残啊！” 我们要控制好自己的情绪，因为这个粗口的背后，他们想表达的意是：“这样设计是不是不对”？只是加了一个感叹词嘛。听他们把背后的原因说出来，不建议用“为什么没用啊？”“这样挺好的啊”“我靠，你才脑残”来正面回应他们的感叹词，这会让气氛更尴尬，后面的评审更难进行。可以问“是有什么问题吗？”“方案哪里不合理？”
7）“这个不好做”、“实现不了的”。遇到技术们这样的回应时，绝大情况下是背后有一个巨大的开发量。不建议直接驳斥“这个还这么麻烦啊？”“很简单的啊，这样搞搞就行了啊”。我们需先权衡是否值得这样的投入？如果的确是一个很重要的业务卡口，可以表达清楚这件事的严重性，就算开发复杂，需要较多的时间也可以接受。
8）做好会议纪要！以便会后讨论和修改
3、评审后——保持持续跟进，反复review
1. 评审结束不代表就等着上线了，接下来要做的是持续的关注。需要不断的review，确保该表达的细节都有表达
2. 需求更新，请维护好更新的记录，在什么时间点更新的，请通知相关的开发测试设计同学，不要藏着掖着
3. 跟进开发计划和进度
4. 准备二期的内容
最后一句，你得让技术感受到你是要做好产品的，不是完成任务的（自行体会）。（本文出处）转载自http://www.swift51.com/post/6296.html
网友评论