科技猎从0到1构建电商平台之需求评审会的流程与坑
编辑导语：作为一名产品经理，一定会经历需求评审。要想开一场完美的需求评审会，必须明白需求评审的目的，只有明确目的后，做好相关的准备工作才能够事半功倍！本文作者总结了从0到1构建电商平台之需求评审会的流程与坑。
对一些新人产品经理来说，主持产品评审大会是一件头疼的事，整场会议下来感觉主持得不怎么样，但又说不出哪些地方需要完善；或者没意识到主持会议中的一些坑，不知觉地踩了进去，导致会议的效率较低。
我是非常享受产品评审大会的，我觉得这算是产品经理的高光时刻之一，作为整场核心角色，整场会议由你把控。但会议的质量也完全取决于你。
这篇文章就是以我之前主持过的一个项目为例，介绍需求评审会中应有的“流程”，再结合我自身经验和参加别人主持会议时发现的一些“坑”，来和大家做一次分享交流。
一、先介绍项目的目的、范围、主要的功能流程等
我们主持评审会是为了让参与小伙伴明白这个项目是用来干嘛的，有哪些主要功能，流程。所以当别人对你的项目还不足够了解时，先要对这个项目做一个大概的介绍，不然就会听得云里雾里的。
例子：
- 作为一个全品类电商平台，我们的平台的模式是邀请商家入驻发布商品，并吸引用户产生订单，并给商家结款等等，这次评审的主要是公司内部用的管理后台；
- 管理后台作为数据的输入来源方，首先需要商家管理功能，用来添加和管理商家的数据；
- 添加了商家之后，商家就可以通过自己的商家后台来上传商品，而我们用的管理后台也可以上传商品，且管理审核商家上传的商品，所以就需要商品管理功能；
- 有了商品数据之后，前台或app就可以看到这些商品并且下单了，所以管理后台需要有订单管理功能来对订单进行发货等操作；
- 有了订单，用户也可能会退货换货等操作，所以需要售后管理功能；
- 由于用户支付的订单金额先由公司代为保管，所以需要财务管理功能来结算商家的货款；
- 花个几分钟把项目先这样按数据的流转介绍一遍，提高参与小伙伴的接收效率。
1. 坑一：直接讲功能
我以前参加评审会遇到过，新项目一上来就讲其中一个模块，而且这个模块还是流程中比较靠后的，理由是这个模块内容较少，就好像是为了完成任务而讲。
但是参与小伙伴作为小白连这个项目是用来干嘛的、有哪些功能、使用流程都不知道，接收的效率可能会很低，因为他们可能需要一边听，一边先猜测这个项目是做啥的，再一边验证之前的想法。
就像你看一本书，一上来可能只知道名字，但是连目录都不知道，还得看你一边看一边去脑补目录。
2. 坑二：会议时间过长，忘了之前讲过的内容
小项目还好，如果大项目的评审时间长达几个小时，甚至分几天评审，就要注意这个问题了。我一般的做法是先提前在黑板上把各级菜单写出来，这样方便参与小伙伴回忆之前的内容，一边讲一边指着黑板，就不用来回切换原型（原型页面太多时会很不方便）。
比如我两小时前讲到了标签管理功能，再讲到商品管理的添加商品时，可以为商品选择标签，但这些标签是在标签管理中添加的，我在黑板上指着数据流转对应的功能，这样就回顾了一次。
二. 再介绍页面上的详细功能
秉承“数据怎么来，数据怎么去”的原则，按商家-商品-订单-售后-财务-营销等顺序，这样的顺序来讲是最容易让参与小伙伴理解的。再按归类的原则，来介绍页面上的字段。
例子：
如图这是售后单详情，由5个部分组成：
- 售后单本身的属性：售后单编号、申请时间等；
- 售后单的成分：用户选择填写的图片、理由等；
- 售后单关联信息：申请的商品信息、对应的订单信息等；
- 售后单各个状态与对应的操作；
- 操作日志。
先将该页面中的字段做一个分类的介绍，让小伙伴对页面的组成部分有一个大概的了解，不至于一点开页面字段太多看得眼花缭乱，然后再挑一些重点字段、涉及到数据流转的字段来着重介绍：
申请退款的金额是按该商品的实付金额来算，比如买了单价100，买了2件应付200，用了20的优惠券，实付就是90，申请退款的商品金额就是90。
3. 坑三：介绍时功能之间没有联动，接受效率较低
A功能讲完了讲B功能，又讲C功能…每个模块当成独立的个体来讲，但是他们之间哪些地方存在联系呢并没有讲。所以在黑板上提前写出各级菜单的另一个好处就是，可以直接指着黑板上的内容方便联动。
4. 坑四：页面内容太多时抓不住重点，机械地介绍每一个功能
先要明白一点，评审会的目的只是为了引导小伙伴，让他们大概了解到这个项目是做什么的，有哪些主要流程，有哪些主要功能等。不可能让大家在几个小时内就将这么多流程和字段都理解清楚，应该是引导完后再将原型给到他们逐一字段去看，再给到回复。
如果想什么都在会上讲清楚，会议时间将大大拉长，别人听着也累，容易注意力不集中，效率下降。所以我们需要提前把主次功能，页面上的主次字段标出来，挑重点讲就行了。
三、回答小伙伴的问题
讲完后或者讲的过程中一般参与者就会提出各自的问题。需求方、开发、测试、UI站的角度不同，提的问题不同。
5. 坑五：回答问题时被牵着鼻子走
产品经理作为会议的主持者最忌讳自信不够，别人说什么就是什么，在会议中就会失去主动权，损害了你在团队中的公信力。
所以回答的时候需要先分析别人为什么会提出这个问题，是因为功能不好用？开发难度较大不想做？开发时间过长？还是数据的流转设计就存在缺陷？如果对方说得有道理，他提的方案就是最佳选择吗？有没有更好的解决方案？
当然也要充分听取别人的意见，找到一个更好的解决方案。这一点很重要，产品经理需要考虑与团队间微妙的关系，强势一点会让人觉得你太独断；弱一点又会让人觉得不够自信，从而怀疑你的专业性。
6. 坑六：讨（si）论（bi）时间过长，没有控制会议的节奏
一些新人产品经理容易在会上与对方纠结某一个小点，比如为某一个按钮摆放的位置产生分歧，标题是左对齐还是右对齐好等等。这一点说着简单，但是在这么多人的大会上遇到质疑你的人，可能会不服气，被情绪带动时就想争个输赢，所以记得管理好情绪。
如果遇到确实没办法马上得出结论，一些模棱两可的功能，此时该做的就是记下来，会后再讨论。
比如我遇到过有小伙伴跟我争添加商品信息应该分段保存还是添加完逐一保存，这不光涉及到技术成本，还涉及到使用体验与使用过程中的风险，还要分析风险可能发生的频率与是否可控，没办法马上给出答案，这时要做的就是先记下来，会后找到现关的负责人再沟通。
7. 坑七：声音没有起伏，不懂控制气氛
这一点算是产品经理的外功，主持评审大会和演讲是一样的，目的是让别人听得进去你说的话，且听着很轻松，所以说话时的断句节奏和起伏程度是有影响的。
比如上图中的售后单编号、申请时间等不重要的内容我讲的时候会以较快的语速不停顿地说过去。而遇到金额等需要计算，且有特定的计算方法的字段时，我会提高音量让大家明白这里是重点。
我观察过，会议进程过半时，有一些小伙伴就开始走神玩手机，我突然提高了音量，那些走神的小伙伴就马上看向了投影屏幕。
8. 坑八：会议过程没有互动
会上讨论时间过长不好，但一点没有互动也不好，如果遇到参与小伙伴都比较沉闷，你又自顾自的讲，会让人感觉你像来念字的，比较生硬。
我一般讲完重要的页面或者重要的字段时，会问一句有问题吗；如果没人回答我会再问相关前端或后端的负责人，问到具体的人时就会有人回答了。但是不要每次都这样很生硬的问，可以适当的开一些小玩笑活跃一下气氛，这些都是提高会议传达效率的小技巧。
9. 坑九：非语言行为
这一条就见仁见智了，你的眼神、动作、坐/站姿可能都影响整场会议的氛围。我见过性格内向的产品经理因为紧张整场会议都是规规矩矩地坐好，声音都不高不低，给我的感觉就是不自信，会议氛围也比较沉闷。
我主持的时候一般都喜欢站着，因为我是整场会议的控制人，站着有俯视的感觉，也有助于我提高音量时大家的目光能快速转移到我身上，讲到重点字段我有时也会走到投影屏幕前指着，这样有助于增强大家对该字段的印象。
四. 确认每个开发人员的时间
如果评审会是为了给开发人员评审原型需求，就需要在讲完之后确认团队各自的时间。
但是需要注意，一般在会议上制定的都是确定大概的时间节点或者大概的项目计划，是为了让大家心里有个数，大概应该在哪个时间段上完成哪些事；而真正具体的进度计划需要会后制定，因为详细的项目管理计划是需要精确到每个人员的每一天的。
这时有两种情况：
1. 已经确定了上线时间
首先要把具体的模块分给具体的开发人员（比如甲开发商品管理，乙开发订单管理，丙编写财务管理的测试用例），确定各自大概需要的工时（不光写接口还有对接口的时间），汇总起来评估能否在上线时间前开发测试验收完。
- 如果能：就先制定一个大概的里程碑计划，什么时间节点完成哪些事，大家心里有个准备；
- 如果不能：先找原因，工时不够？是否需要加班，是否需要重新排优先级先砍掉一些功能，是否有替代方案替代一些开发时间较长的功能等，甚至考虑加人；当前技术不足以实现部分功能？是否可以暂时搁置或找替代方案。
2. 暂未确定
也是需要分工、分别确定工时、汇总，然后大概完成时间是否符合预期，或者符合上级预期。如果不符合也需要像上述一样，先找到冲突点再来协调。
五. 会后的复盘
会后的复盘相当重要，我一般下来后会回忆整场会议中做得好与不好的地方：
- 讲到哪些地方参与度较高？
- 为什么会议后半程大家开始走神了？
- 是不是因为讨论时间过长而拖会了？
- 有没有因为讲得过快而导致大家还没听懂就过了？
- 有没有在和别人讨论时过度否定和打断别人的想法？
- 有没有因为准备不足而紧张把一些字段重要的地方讲漏了？
- ……
一般通过小伙伴们的表情和气氛能反映出来，就像老师讲课时都会观察学生的面目表情。主持需求评审会不像做数学题，知道公式就能求解出答案，我觉得像书法，你知道该怎么写好看，没练过就是写不出，所以还是多练多总结，准备充足，足够自信就好。
本文由 @橘钻 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。