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