当你在和开发进行需求评审时，你会发现原本规划半个小时的会议往往被各种各样的问题拖入无止境的小会中，结果会议时长一下子延伸了2~3个小时。这篇文章分享的内容就是如何规避类似这样的问题。

产品经理在和开发进行需求评审时，经常刚开个头，就被各种问题拖入无止境的解释、争辩、开小会中，结果通常就是会议几个小时无结论，强行推进开发，后期各种需求变更，搞得大家都很疲惫。今天思考的话题就是如何避免这样的情况。

就结论而言，就是四个字：做足准备！

首先，我们在写需求画原型时，要做足准备

第一，产品经理在做原型时，不要一开始就画交互界面，而是单独列一个区域，把这个版本需求的来龙去脉说清楚。包括为什么要做这个版本，要满足哪些人的哪些需求，做了这些后有什么价值，如何证明，以及大概要做的模块都有哪些，时间估算等等，让每个来开会的人一上来就有宏观意识。

第二，涉及业务流程的需求，也要单独列一个区域，专门绘制流程图，并把流程图中的“概念”解释清楚，然后才是针对概念的交互界面，这样也能方便开发迅速理解业务，再和交互稿对照查看，印象更深刻。

第三，在绘制交互界面时，也要尽量按目的、按逻辑分组归类。比如将“提升用户活跃”作为大分类，在这个分类下，“推送功能优化”作为小分类，在这个小分类下，我们要做哪些子模块，层层分解。

其次，我们在会议召开前期，也要做足准备

第一，在和全体开发开会前，尽量提前和开发各业务负责人召开一个小会，进行需求初评，目的是提前收集问题，沟通是否有技术难点，确认需求的开发成本，并从技术的角度看是否有考虑不全的逻辑漏洞等等。如果存在需求不足的地方尽快修改。当然还可让开发负责人向下简单传达要做哪些需求，让大家心里有数。

第二，在会议召开前，一定先通过邮件形式发布会议召开邀请，同时附上即将要讲解的原型文档，至少提前1天让所有参会人员了解需求。当然最好在发完邮件后到每个开发座位上再提醒一下，督促大家去阅读文档，有较大分歧的反馈尽早收集处理。

最后，在召开会议时，更要有备而来

第一，每一个需求点，产品经理自己要有充足的理由说服大家，无论是数据证明，还是市场调研，还是用户心理分析等等，尽量避免说出“我觉得应该XXX”这样的话，而是讲客观依据。

第二，每一种交互设计，都尽量有几套方案备选，如果大家对已画出的交互意见较大，就再摆出几种备选，让大家有目的地展开讨论。

第三，产品经理讲解交互稿时，可以先讲总体，再讲重要细节，再讲次重要细节，并层层确认。比如订单支付流程，先讲解支付顺利的主流程，再讲解支付失败的异常流程，最后再讲解支付成功、失败的交互效果。这样做的好处是限制讨论边界，避免理解偏差。

第四，对于会议上争议较大的问题点，有个“5分钟”原则，5分钟后还没有结论，就记录下来，会后再单独讨论。如果问题点太多，就说明产品经理还没考虑清楚，那就尽早结束会议，再重新修改原型，再召开一次会议，当然我们还是希望这样的情况不要发生，因为非常浪费时间和精力。

最后的最后，再介绍一个小经验

就是建议将PRD、需求FeatureList和原型都画在一起，统一讲解，这样能提高效率，减少理解成本。如下图所示：

当然这是我个人经验，不同公司可以根据情况调整~

以上是我的思考，你们公司是如何做需求评审的呢？期待你的留言~

#专栏作家#

申悦，人人都是产品经理专栏作家，36氪产品总监，微信公众号：互联网悦读笔记（ID：pmbox）

本文原创发布于人人都是产品经理。未经许可，禁止转载。