上一篇我们写了《产品经理日记：悠哉产品经理的一天（1）》接续介绍需求评审会是什么。
午间的休息都是伴随着玩手机和趴在工位上睡觉度过，有的同事会买折叠床，但我嫌麻烦就从来没买过，一晃就到了两点的下午上班时间，会议举行的时间是两点半，太早两点也不好，刚睡醒同事们都还没准备好呢，太晚了，怕是被拖去忙别的事情又拖拖拉拉的来开会，所以我觉得两点半是刚刚好的时间，刚好给了研发和业务同事们准备的时间。
我一般会提前10分钟先到会议室准备，带着自己的手提电脑，到了会议室，把投影仪打开调节好，就再坐着等待其他人员登场了。顺便一提的是，会议室一般都是提前预定的，一般会在公司的oa系统预订，小型一些的公司因为人少可能就不需要。
前端两名和后台两名以及测试1名同事已经在2点中到达会议室并落座，业务人员1名来晚了几分钟，我们也已经习惯了。
在互联网中，我觉得挺有意思的一点就是，各职能并不是权力越大工资越高，得看职能的难易程度。其实在整个团队中，最能决定事情的是产品，而产品很多时候又要咨询业务部门的意见，也就是最终的拍板人还是业务部门的人，最没有话语权或者说决定权的是研发，研发只需要按照产品和业务定的规则去实现即可，这就好像是建筑行业，工人是研发，项目经理是产品，业务部门的人就是老板，然而工资等级一般确实倒过来，也就是业务部门一般薪资低于产品，产品低于研发。
在召开需求评审会的时候，ui设计师一般是不需要参与的，因为ui设计师，只需要负责画图就行，不必参与需求的讨论，测试是必须要参加的，而且测试在召开评审会的时候一般都是不说话的，他的角色就像是刻录机，把会上的所有信息都装到脑子里，然后在研发开发完成后，测试就要根据那天开的需求评审会的情况，结合需求文档和原型图测试一遍，哪些产品在会上说了要重点测试，哪些可以随意，一些没办法写在文档上的，通过口头说的，测试人员就得记住，这就是为什么测试人员需要参加各种需求评审会，而且一般他们都不说话，就默默的听。
好了，需求评审会马上开始。
首先我投影的是什么东西呢？我投影出来的东西是原型图，也就是我用axure画的低保证界面，这些图旁边都会附带一些文字说明。
我说：那么接下来我们就召开需求评审会，我先交代一下需求背景，即为什么要实现这个需求，以及实现了的意义和好处。
因为年底将至，我们想在我们的app上搞营销活动，这样能活跃新年的氛围，也对我们app和微信的用户活跃度有所帮助，所以我们决定本期做一个功能叫拼团群开红包，类似于拼多多的功能，通过微信分享，凑齐人就可以开红包，奖品是我们的优惠券，优惠券金额不等。实现的地方是在我们的微信小程序上。
好的，讲完了需求背景，那我们就开始讲详细的需求。
首先请大家看投影出来的流程图，这个流程是这样的，由一个人（比如a）通过点击小程序页面的某个按钮发起拼团，这个人就成为了该团的团长，然后他通过微信分享给其他人，其他人加入他的团，直到他凑够人数，则成功开团，获得优惠券奖励。
以上是正常流程，接下来讲解非正常流程，第一个是，到了这个点，我们有一个判断，判断这个人凑团是否过了时间，一个人要在规定时间内凑齐人，而如果过了规定时间，则要弹窗提示，这是第一点，第二点是如果用户拼团成功，但优惠券库存用完了，没法派发了怎么办？这个时候后台如何保障充足的库存？第三点第四点第五点……
此处省略了很多问题，一般在讨论流程的时候，研发会不停地提出问题，这些问题一般是为了让研发他们更好的了解这个流程，然后也会提出自己的一些不明白的地方，直到你把这个流程给研发讲明白讲透彻，当然我也不是神仙，研发问的有些问题我也回答不上来，当我没办法决定的时候，业务部门的人就会发话，他说的就是决定，当然我们也可以对他提出决定的合理性提出自己的观点来质疑，不过在模凌两可的情况下，还是听业务部门的即可。
研发有时候也会内部互相讨论，讨论这个该怎么实现，四个研发，两个前端两个后台，会在会上讨论这个需求他们该怎么配合能达到，他们互相讨论的东西，我和业务一般是听不太懂的，就等他们讨论，讨论完了，他们说ok,我就接着讲下一个逻辑，直到所有逻辑他们都点头说ok 为止。
好了，讲完了流程图，其实这个需求已经讲完了80%了，因为页面呈现的东西，其实工作量在前端工程师，而页面这个就好比人的一张脸，你想让他长得美长得丑鼻子高还是眼睛大这都是产品经理决定就行，但鼻子和眼睛必须要齐全，也就是说，页面的按钮要齐全，至于按钮你想怎么摆放，产品说的算就行。
比较复杂的其实是后端工程师（一般是java工程师）的工作量比较大，他的工作是写逻辑，相当于人脸背后的思维，比如一个人在接触到外部反应后的面部表情，喜怒哀乐，就是需要通过脑子思考并呈现在脸上，而后端工程师就是写这些逻辑问题。
而逻辑问题，就是我画的流程图，我的流程图走顺了走通了，后端工程师也就可以根据我的逻辑去做去开发了，前端工程师，其实更接近ui设计师，只是前端工程师是把ui设计师画的图转换为代码呈现到终端如电脑或手机上，然后通过一个叫“接口“的东西，来接收后台的信号，比如有人打你一巴掌，你觉得疼，这个流程是有人打你一巴掌，是外界发生的事情，人接收到了这个被打的信号，脸部（前端）通过神经（接口）传递给脑子（后台），后台接收到了信号后，进过逻辑处理后，发出疼痛想哭的指令，再次通过神经（接口）返回给脸和身体的其他各个部位（前端），表现出来了我很疼想哭。就是这么一个情况。
所以召开需求评审会，讲逻辑我得花去百分之八十的时间，期间研发不断问我这个流程的问题，哪些特殊情况该怎么办？我就一一回答，回答不了我就找业务部门确认，最终完全定下来。
最后我再过一下前端的页面，让大家可以更加直观的看见原来最终做出来的呈现在我们眼前的就是这个效果，最后会议结束。
所以召开两个小时其实是很短的，讨论东西会觉得时间过的很快，一眨眼就两个小时了，有时候还觉得时间不够。
会议结束后，大家都散会了，我回到自己的位置上，我要做两件事情。
第一件事情是把刚刚开会讨论的一些我没有想到但又在会议上决定的东西，体现在我的原型图中。
第二件事是在做完第一件事情之后，我要发送会议纪要，包括这次会议上临时决定的一些比较重要的内容以及附上我的原型图发给在会上的所有人，以及抄送给各部门的大佬让他们知悉情况。
做完这些已经快要下班了，有时候这些做不完我还要留到第二天去做。
然后我还要在一个叫teambition的任务管理系统中，把这个需求的进度从“未评审”改为“已评审”，这个任务管理系统整个团队都能登录在电脑中看到，就知道这个需求的进展了，然后涉及到这个需求，也就是今天开会的研发和测试就会在线上领取这个需求，每天在上面标注自己的完成进度，比如今天百分之十，明天百分之二十，遇到了什么情况等，我们就可以实时去观察进展了。
