交代一下背景：某泛IT领域在线教育公司的产品经理一枚。之前一直从事软件测试工作，公司人事变动转了产品。目前主要负责TO B业务线以及在线教育平台PC、H5部分的产品工作。

项目成员及版本迭代情况：一个产品对2组研发人员，大版本为1月一版，小版本视需求紧急程度及工作量1~2周不等。新功能初期大版本居多，后续迭代大部分以2周一个的小版本为主。2组的上线、评审时间错开，所以相当于每周都会有评审和上线。

之前看过一个关于演讲方面的文章，说的是演讲分为3个层次：

第一层次：传递 ,别人能够听懂你说的话
第二层次：影响，别人不仅能听懂你说的话，还能受到你的影响
第三层次：说服，别人不仅受到你的影响，还会把你的话作为信仰

一直以来我都把每次的需求评审做为一次演讲来对待，争取达到说服别人的程度。但是需求评审并不是单方面的信息push，还需要所有与会人员的积极参与才能达到较为理想的效果，这里我仅从产品经理的角度来说一下如果能够做好一次需求评审。
先来说一下需求评审普遍会存在的一些问题：

• 逻辑复杂的功能评审的时候讨论时间过长
• 经常被带偏，节奏把握不好
• 评审内容没有层次，与会人听的很累

我主持的评审很少或者说基本没有出现过上述情况，个人认为出现上述情况的主要原因是产品经理对于需求想的不够透彻，没有做足充分的准备。做产品时间久了对于功能的复杂度和可能遇到的问题是有一定预判的、可以预见哪块内容会在评审的时候会引起大家的讨论。至于评审内容没有层次的问题个人感觉是缺少一些表达的技巧。

针对需求准备阶段，我把需求概括的分为3大类：

1.逻辑较为复杂的功能
2.功能但是逻辑相对简单
3.样式调整或者相对来说较为单一的功能

针对第1类的需求：
在准备需求文档的时候一定要准备多次推演的流程图、原型、每个逻辑分支在推演的时候都要想彻底。我的习惯是先在纸上推演，然后在processed on上绘制流程图，根据流程图进一步设计原型，原型设计完成后根绝原型细化需求，细化需求的同时还会对原型进行一些调整。如果遇到技术上的问题可以提前找开发沟通一下，开发人员可以给予一些新的思路。而且在需求设计阶段找过开发的话他们也会提前想一下需求会影响的地方。提前参与进来。
针对第2类的需求：
可以不用准备流程图，但是原型一定要有。图形能够传达的信息较言语更具象，可以减少语言的歧义。一些自己把握不准的地方或者需要提醒自己需求评审时着重要说的内容可以在需求文档中特殊标记；如果涉及原有数据的一定要记得写明历史数据如何处理。。。
针对第3类的需求：
原型图可以不用准备，但是需求评审的时候一定要在对应的页面针对效果图，或者原有功能页面进行针对性的讲解。
以上是需求准备过程中个人认为需要注意的地方。

接下来说一下需求评审时注意的地方

额。。。就像如果你的大学是地质大学，即使学的是法律专业大一也要学习地质概论一样，因为我们是在线教育机构，即使是研发人员基本的授课思路培训也是有的。走过最长的路就是套路~~，授课也是有套路在的，譬如3W1H，譬如总分总的结构、譬如结构化思维。经过不断的刻意练习这些思维方式都已经内化了。

• 评审的时候都会按照总分总的形式给大家先概括一下评审的主要内容。让大家对所有内容有心里预期。每一个功能讲解的时候也会按照总分总的结构来说，都说重要的事情说3遍，如果想提高评审的效果，让大家在评审的过程中get尽可能多的内容，可以有技巧的重复
• 先评简单的优化类需求，再评功能性需求。如果功能性需求比较复杂的话说之前会给大家说一下，引起大家的注意
• 具体的讲某个功能时我都会按照3W1H的思路讲解，为什么要做这个功能/要具体解决什么问题，实际的使用场景是什么样的。脱离业务、脱离场景的功能说服不了别人更说服不了自己
• 避免对着大段文字进行评审，不论是上面提到的3类需求中的那一类我都会先对着图形化的东西：流程图、原型或者效果图亦或原有可参考的功能页面 先把功能点和交互都说一遍，让大家对于功能有心里预期后再针对文档中的文字把需要特别说明的地方再重复一遍
• 如果评审中出现与本次评审无关的讨论，或者本次评审的功能点存在分歧讨论，可控的范围内可以适当允许，讨论过程也是风暴的过程，会有些额外的收获，但是如果影响了正常版本的评审，一定要记得产品经理是主持人，需要控制局面，把大家拉回来
• 我们的版本周期一般是5天开发/5天测试。人员配比情况为3PHP、1前端、0.5UI、1.5测试，评审的内容一般会控制在半个小时到1个小时之间。否则大家的注意力可能会不集中，达不到预期的评审效果
• 切忌单方面push，讲解的过程中要和与会人员有眼神的交流，关注大家的表情，进而了解大家对于所要传达的内容的理解程度
• 鼓励并引导大家发言，需求评审的过程尤其是逻辑复杂的功能评审的过程也是研发团队头脑风暴的过程