随着羊群人数的不断增加，使得大部分同事改成居家办公和线上会议。线上会议的特点不用提前抢会议，不用担心会议时长，顶着40℃的高烧，听者需求评审会，也不知道烧了多久，睡了多久，会议开了多久....

需求评审会经常被大家吐槽时间久，最终问题得不到解决似乎是无法破解的问题。我记录了最近几次PM组织的评审会过程，发现一些问题，并想到一些可以改变的方法。

  问题1  

开场一句话背景和模糊的收益

介绍背景和收益必不可少，这是团队成员在初期达成目标一致的必要过程，并且通过说明相关成员能够认同该项目的价值和意义，通常一句话轻描淡写是不够的。

建议：充分做好会前功课和线下沟通，保证会上快速达成一致

①老项目要介绍上一个版本历史数据分析结论或者用户反馈问题分析结论。

②新项要使用SWOT等分析方法，明确自身的竞争优势，市场规模等核心问题。

③竞品分析讲结论。不要挨个讲竞品，也不要讲字号和颜色等细枝末节问题(可以在需求文档中给予参考建议)，注重战略层面和功能层面的差异介绍，以及那些适合自身与竞品之间的差异。

④本次要解决的问题，也就是具体我们要做什么。不需要复杂的论述，简单列出本次需求点，一目了然。

⑤清晰表述项目价值。讲明白本次优化能给项目带来多大的价值，以及是如何推导出来的，让团队成员信服。价值一定是可以衡量的，我们常听到项目的价值是提升用户体验，但实际既没有用户满意度等用户指标，也没有具体收益等业务指标，那这就是不可衡量，全靠感觉，项目后期对于方案的讨论分歧点会很多。

⑥不要一开始就甩锅给老板。很多PM在开会时功课做得不够，被问到一些无法回到的问题时直接说这是老板让做的，如果觉得需求有问题可以去找老板，这样的结果大家以后对于项目态度都会变成应付了事，PM自己的工作后续也很难推进。

  问题2  

上来就讲原型，陷入细节纷争

PM喜欢画原型喜欢讲原型应该是不争的事实，还有一些PM对原型的精美度要求还很高，于是需求确认前就找交互设计师按照自己设想完成交互设计，很多不完善、不合理的地方也很强硬的要按照自己的来。需求评审会上来讲原型很容易让团队成员陷入界面的细节争论不休，开发又会追问每个有台逻辑，评审会你一句我一句就乱套了，同这时通常设计也会与开发一边，表示出不满。

建议：清晰且详细文字的描述产品逻辑及字段

①清晰表述产品中所有的字段、数据格式以及相应的逻辑。让开发能看懂所有功能逻辑、操作逻辑、展示逻辑，设计能看懂产品需要用户如何操作以及限制条件，通过文字能明白整体需求逻辑关系。

②尽量使用文字描述。我们发现当图和文字同时出现在文档中时，设计师和前端更偏向于看图，后端会细看文字描述的逻辑，这样到了打法阶段容易形成gap，导致新的问题产生。

③产品画的原型会影响设计师的思考，造成设计师被带跑偏，甚至一些强硬的PM要求设计师按照记得来，这样一来设计师不想给自己找不痛快，就按照美工的标准应付完工，并没有发挥真正的价值。

  问题3  

需求评审开成技术评审

很多时候在评审会上开发人员会就从能不能实现聊到怎么实现，然后聊到各服务端如何来配合，一聊起来就没完没了，线上会还可能随时就拉个新成员进入参与讨论，需求背景又要被重复。此时的需求还没有定论，占用大量会议时间讨论技术实现明显是不合适的，浪费大家宝贵的时间。

建议：做好会议把控，控制问题讨论边界

①PM在会议中要起到把控的作用，会上不讨论技术实现方案，只讨论需求是否合理，技术可否实现，如果当时不能确定能否实现的，需要记录todo在规定的时间内反馈。

②对于一些不确定的技术问题，或可能存在争议的难点，最好在开会前就能和技术负责人了解清楚技术背景，做好功课，防止在评审会上被牵着鼻子走。

  问题4  

跑题

跑题通常是不知不觉的，甚至全体参会人都享受其中，越聊越嗨，忘记了开会真正的目的。印象比较深的是一个方案要主管确认，主管从这个方案聊到了另一个项目，开发顺着另个项目聊到了项目进度，遇到的问题。整个评审会成为了另一个项目的汇报会，到最后也没确认当前方案。

建议：明确会议目标，时刻关注会议方向

①PM会前要和主观确认好方案，以保证内部一致性，会上主观只要回复确认没问题即可。

②放下面子敢于说话。很多时候PM不太好意思打断大家的对话，这样就不能把跑题扼杀在摇篮里。

总结一下，就是立足本职做好自己职责范围内的工作，承担好项目角色。

               啥都别说了，点它就对了