如何准备一场高效的需求评审会议

　　需求评审会议对整个项目想影响至关重要，作为产品经理，我们应该本着对项目和研发团队负责的态度，认真准备，以提高需求评审会议的效率。
　　准备不充分的需求评审会议，是一个事故现场
　　主持会议是产品经理的日常工作，尤其是需求评审会议。如果没有为需求评审会议做充足的准备，会议现场往往会变成＂事故现场＂。
　　曾经参加过一个同事的需求评审会议。需求是根据用户最近4个月的月交易额，分析用户的经营情况。产品的方案是：将最近4个月的交易额的值线性回归为一条直线，再根据这条直线分析用户的交易额趋势是在增长还是在减少。
　　研发人员非常不认同这个产品方案，有的甚至表示听不懂。会议现场争执不断，最后需求被拒绝。
　　为什么一个需求评审会议，会变成事故现场？
　　一个最重要的原因是：产品经理没有为会议做充足的准备。
　　为什么要充分准备需求评审会议？
　　高效传递需求
　　一场高效的需求评审会议，可以在有限的会议时间内，向研发人员清楚地说明我们要做什么、为什么要做，以及如何做。这不仅要求我们对产品方案有清晰、深度的理解，还要提前预测参会人员的关注点，并找到对应的解决方案。
　　根据信息传递漏斗效应：信息的传递过程中，会逐步出现衰减。我们想表达的内容是100%，表达出来的可能只有80%，听众听到的只有60%，但由于各种原因，听众真正理解了的信息可能只剩下30%。
　　要想提高听众最后理解到的信息比例，我们就必须要深度理解我们要表达的信息，并找到合适的方式把它们表达出来。
　　对产品方案有清晰、深度的理解，仅仅靠编写需求文档是远远不够的。还需要我们仔细去思考每一个流程、逻辑、细节，提炼其中的关键信息，找到最佳的需求表达方式。这就需要我们充分准备。
　　提高产品方案的合理性
　　需求评审时，被研发质疑产品方案不合理，是我们大部分产品经理都会遇到的问题。一个产品方案，在没有与研发沟通前，是否存在的问题，我们可能是无法预知的。
　　我们在需求评审前，应该与核心研发就产品方案以下4个方面展开详细的讨论：
　　核心的业务流程：业务最基本的底层流程；
　　涉及到的功能模块：需求包含的、以及相关联的功能模块；
　　关键逻辑：对整体业务影响很大的重要逻辑；
　　不确定的细节：产品经理无法确认是否合理的需求细节。
　　充分吸取核心研发的建议和意见，形成的产品方案，一定会更具有可行性，实现的成本也可能会更低。
　　当然，提前沟通也没办法完全消除研发对产品方案的质疑。但如果我们提前沟通，带着更合理的产品方案做需求评审，研发的质疑一定会更少。
　　如何充分准备需求评审会议？
　　让核心研发参与方案设计，并达成一致
　　同一个需求，我们往往能想到多个产品方案。有时候我们自己也不能确定哪一个方案会更好。
　　此时，我们可以把这几个方案都跟核心研发讲一遍，征求下他们的意见。他们就能从研发成本、复杂性、可扩展性等多个维度对几个方案进行优缺点分析，最后帮助我们选择一个最合适的方案。
　　有些方案很简单，研发成本很低，但往往只能解决用户最核心的需求；
　　有些方案很复杂，能覆盖的用户场景更多，但研发成本很高；
　　有些方案不利于后期扩展，但能快速上线；
　　有些方案扩展性很强，但做起来很麻烦。
　　如果我们有自己强烈的选择倾向，但核心研发并不认同。我们就要非常有耐心地去解释：选择这个方案最重要的原因是什么？为什么其他的方案不够好？从长远来看这个方案有多大的优势？
　　如果能取得核心研发的理解和认同，我们在需求评审时，遇到的阻力就会小很多。即便其他的研发人员不同意，核心研发也会帮助我们说服他们。
　　核心研发的专业能力，能帮助我们权衡多方面的因素，找到并选择最合适的一个方案。而他们同时还是研发团队的权威，能对其他的研发产生很大的影响力。
　　提高需求文档的可读性
　　如果我们把需求文档当做一个产品来设计，目标用户就是研发人员。那么需求文档的高可读性，就是用户体验的核心指标。
　　要提高需求文档的可读性，我们需要将阅读效率低下的需求描述方式替换为更清晰易懂的描述方式。
　　a. 将长段落换成结构化的多个段落
　　长段落就是一种阅读效率低下的描述方式。如果我们改用结构化的多个段落，阅读效率和体验就会高很多。
　　一大段长句：由于用户需要通过结算时间来查询订单信息，所以要在列表的最后一列后增加结算时间列并做为查询条件，结算时间显示精确到秒。
　　换成结构化的文字：需求背景：用户需要通过结算时间来查询订单信息；
　　解决方案：
　　在列表的最后一列增加＂结算时间＂列；
　　结算时间显示精确到秒；
　　查询条件新增＂结算时间＂，查日期区间。
　　b. 将复杂流程拆分成主流程和多个子流程
　　复杂业务往往伴随着复杂的流程。如果我们在一个流程图中，将所有的细节都囊括进去，研发理解起来肯定会非常困难。
　　这时候，我们应该从复杂的详细流程中，先抽象出多个核心节点，绘制成一个相对简单的主流程图。再将每个核心节点的细节展开，分别绘制成多个子流程图。
　　在需求讲解时，先讲主流程。确认大家都理解后，再将核心节点展开，分别讲详细的子流程。
　　通过这种方式，研发就能形成＂总-分＂的逻辑结构，理解起来会更轻松、更高效。
　　c. 补充功能结构图、信息结构图、状态流转图
　　这3种图并不是需求文档所必须的。但如果我们的需求文档中有，需求表达的效率会更高。
　　前面几篇文章有详细介绍，此处就不再赘述他们的优点及绘制方法了。
　　对需求做优先级排序
　　对于一个复杂的项目，我们应该列一个需求清单，并用kano模型对每一个需求分析，确认优先级。
　　在需求评审前，对优先级高的需求做更细致的准备：
　　按上文的方法，让需求的可读性更高；
　　确认该需求对其他模块是否有影响，并给出对应的解决方案；
　　穷举异常情况，并给出对应解决方案。
　　提前确认好需求优先级，会让我们在面临研发＂砍需求＂时，更从容、更有底气。
　　预测研发可能会提出的问题
　　需求评审时，研发人员会提出各种各样的问题。如果我们能在会前就预测研发可能会提出的问题，并有针对性得想好回复方式。在需求评审时，就能游刃有余地应对，快速消除研发人员的疑虑。
　　研发提出的问题，大多围绕以下几个点：
　　异常逻辑：用户输入无效信息要怎么提示？必填项不填要怎么处理？上传过程重突然断网怎么办？
　　交互设计：这个交互设计似乎不符合iOS交互规范？不用弹窗行不行？一个操作要经过5个页面，能不能设计的更简便些？
　　技术实现复杂度：数据每天凌晨更新一次行不行？一定要做到实时更新吗？能不能换种更简单的方案？
　　目标达成度：你这个方案没解决XX问题吧？这个方案为什么能提高用户的付款率？
　　如果我们完全不为可能的提问做准备，在需求评审会议中，我们很难在短时间内想到一个合适、准确的答案。这不仅不能高效传递需求，还会损害研发对产品经理的信任度。
　　其他准备
　　还有一些看起来很简单，但很容易被我们忽略的准备工作：
　　请研发人员提前浏览需求文档：在需求评审前，就让开发提前浏览，大致了解需求；
　　提前准备好会议用具：在会议正式开始前，就要进入会议室，调试好投影仪、打开需求文档，确保参会人员到齐立即就可以开始，而不是浪费大家的时间看我们准备。
　　总之，时间对每个人来说，都是很宝贵的。我们应该使用各种方法，提升需求评审会议效率。
　　总结
　　需求评审会议对整个项目想影响至关重要，作为产品经理，我们应该本着对项目和研发团队负责的态度，认真准备，以提高需求评审会议的效率。