《产品日思录》是我个人公众号上每天更新的系列文章，记录了我在做产品过程中的思考、总结、经验积累，也希望在这里和简书的大家分享~
产品经理在和开发进行需求评审时，经常刚开个头，就被各种问题拖入无止境的解释、争辩、开小会中，结果通常就是会议几个小时无结论，强行推进开发，后期各种需求变更，搞得大家都很疲惫。今天思考的话题就是如何避免这样的情况。
就结论而言，就是四个字：做足准备！
首先，我们在写需求画原型时，要做足准备。
第一，产品经理在做原型时，不要一开始就画交互界面，而是单独列一个区域，把这个版本需求的来龙去脉说清楚。包括为什么要做这个版本，要满足哪些人的哪些需求，做了这些后有什么价值，如何证明，以及大概要做的模块都有哪些，时间估算等等，让每个来开会的人一上来就有宏观意识。
第二，涉及业务流程的需求，也要单独列一个区域，专门绘制流程图，并把流程图中的“概念”解释清楚，然后才是针对概念的交互界面，这样也能方便开发迅速理解业务，再和交互稿对照查看，印象更深刻。
第三，在绘制交互界面时，也要尽量按目的、按逻辑分组归类。比如将“提升用户活跃”作为大分类，在这个分类下，“推送功能优化”作为小分类，在这个小分类下，我们要做哪些子模块，层层分解。
其次，我们在会议召开前期，也要做足准备。
第一，在和全体开发开会前，尽量提前和开发各业务负责人召开一个小会，进行需求初评，目的是提前收集问题，沟通是否有技术难点，确认需求的开发成本，并从技术的角度看是否有考虑不全的逻辑漏洞等等。如果存在需求不足的地方尽快修改。当然还可让开发负责人向下简单传达要做哪些需求，让大家心里有数。
第二，在会议召开前，一定先通过邮件形式发布会议召开邀请，同时附上即将要讲解的原型文档，至少提前1天让所有参会人员了解需求。当然最好在发完邮件后到每个开发座位上再提醒一下，督促大家去阅读文档，有较大分歧的反馈尽早收集处理。
最后，在召开会议时，更要有备而来
第一，每一个需求点，产品经理自己要有充足的理由说服大家，无论是数据证明，还是市场调研，还是用户心理分析等等，尽量避免说出“我觉得应该XXX”这样的话，而是讲客观依据。
第二，每一种交互设计，都尽量有几套方案备选，如果大家对已画出的交互意见较大，就再摆出几种备选，让大家有目的地展开讨论。
第三，产品经理讲解交互稿时，可以先讲总体，再讲重要细节，再讲次重要细节，并层层确认。比如订单支付流程，先讲解支付顺利的主流程，再讲解支付失败的异常流程，最后再讲解支付成功、失败的交互效果。这样做的好处是限制讨论边界，避免理解偏差。
第四，对于会议上争议较大的问题点，有个“5分钟”原则，5分钟后还没有结论，就记录下来，会后再单独讨论。如果问题点太多，就说明产品经理还没考虑清楚，那就尽早结束会议，再重新修改原型，再召开一次会议，当然我们还是希望这样的情况不要发生，因为非常浪费时间和精力。
最后的最后，再介绍一个小经验，就是建议将PRD、需求FeatureList和原型都画在一起，统一讲解，这样能提高效率，减少理解成本。当然这是我个人经验，不同公司可以根据情况调整~
以上是今天的思考，你们公司是如何做需求评审的呢？期待你的留言~
