“需求评审会”跟“产品文档”讲的内容是一样的。
不同之处是：需求评审会才是真正的让大家接收信息，产品文档只是一个备份。
千万别指望发了个产品文档邮件就能解决沟通的问题，重要的事必须当面沟通。
简单版（日常使用，简单直接有效）：
喊一嗓子：XX同学、XXX同学、XXX同学、XX同学过来看个需求。。。XXX，有时间没，过来听一下呗。。。XX，走，一起到我电脑那里看新版的交互吧。。。
这次我们要做。。。。
XXXXX，之所以这么做是因为XXXXXXXX（一般我会把最重要的一件事，放在第一个说。因为这时大家的头脑最清醒，对信息接受度最高。）
XXXXXXXXXXX
XXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX
在这个过程中：
对于大家不明白的地方，会详细讲解，直到大家认可为止。
对于有意见的地方，会进行探讨；对交互有不认同的地方会记下原因，会后修改；有好的方案时，也会记录下来，会后修改。
根据每一个界面的改动，请程序同学评估成本，有没有更好的方案，预计什么时间能完成
需要后端那些同学的支持
对旧版数据的迁移有没有什么问题
标准版（较少使用，只在较大版本更迭时使用）：
首先，预约会议室，
然后，发邮件跟大家预约时间，一般会至少提前3天。
会议开始前，会先到会议室提前布置好投影仪等。
会议开始时，会按照产品文档的规范讲：
背景
具体做什么
优先级
关系人
协调大家一起做好这个需求。
会议结束后，会把产品文档和会议记录群发邮件。
如果你在评审讲方案时紧张，我有以下建议：
开会前，在产品文档中，写出你所有要讲的东西。这样你会印象深刻，知道自己该讲些什么。同时会帮助你讲方案时，更加有条理性（原因是什么，我们如何解决。。。）
在心里模拟讲方案时的情形，在心里默默的模拟几次
如果开会时，有人提出你暂时没有考虑到的问题，同时，你也暂时无法解决。这时你就说：“这个问题很好，我先记下，开完会之后我来解决。”
