需求评审：如何让开发明白产品的需求
需求评审会，虽然是产品经理的演讲会、高光时刻，但是更重要的是怎么让“与会人员”明白我的需求是什么，达成一致意见或知道会后如何修改。
发现问题，刻意练习
我发现近几个月的需求评审中自己出现的3个比较具体的问题，通过一天观察导师是怎么高效做需求评审，记录总结了可以“刻意练习”的要点。
需要提醒自己的是，“刻意练习”是书《优秀到不能被忽视》中明确刻可以成为更好的自己的一种方法，共有5个步骤。其中我认为首要是先找到自己的“对标对象”，即 找到自己需要提高的不同能力的学习对象。
因此我找到了需求评审可以学习的对象，下一步则是“摧毁和拉伸”， 就是承认自己的失败;突破自己的舒适范围。“摧毁”自认为优秀的部分，“拉伸”自己离开舒适圈，刻意练习自己不会的但是适用的东西。
“刻意练习”的5个步骤(摘录自书《优秀到不能被忽视》)
3个问题分别是：
在写文档的时候思考的逻辑点，该怎么告诉开发需要这样做?
会议过程中，先说什么?后说什么?
展示需求文档时，什么场景下对着文字说?什么场景下对着原型说?
针对这3个问题，我进行了下述要点的刻意练习。
如何告诉开发WHY、WHAT、HOW
1. 评审前
开发同事虽然是帮助产品完成需求，但是也需要通过为什么做和做什么，来判断该开发工作是否是新增的，开发量是否很大，排期等。这就涉及到产品在开需求评审前，需要提前查看本期backlog中和这个需求相关的，明确本需求是新增的，还是优化的。
如果是新增的需求，直接进入评审中的3个开题环节。
如果是优化的需求，需要先打开backlog说明“本需求是针对上一期需求做的二期、三期优化，其中在这个需求版本中只做二期优化。二期优化的内容有以下这些，分别是xxxxxx”。因此也涉及到填写backlog的时候，需要清楚详细写明需求的名称，让开发一眼明确这个需求是做哪块儿内容。
2. 评审中
打开需求文档时需要先说明需求类型、背景或现状、需求的目的。需求背景或现状也就是在设计这个需求时，自己思考的点。比如最近在设计抽奖活动，需要新增需求目的是在微信环境下完成活动闭环。
为什么要在微信环境下闭环，因为(背景)：“班主任或销售的宣发渠道普遍是通过微信，家长在看到宣传海报后，想直接点击二维码参加活动”，说清楚什么人在什么时候做什么事情，得到什么结果或遇到什么问题。
因此这个需求，主要是解决xxx问题，这就是需求目的。说完背景和目的后，再接着说需求重点解决的是什么问题、整个流程是怎么样的，再一个部分一个部分去描述。
如果评审的需求是比较大、内容比较多和复杂的新项目时，在开始讲下一个大模块前，需要对上一个模块总结。
比如观察导师做商城需求评审，是总结刚才模块的整体流程：“刚才说的基本是从商品列表进来，用户看到详情页，点击后兑换商品，看到兑换明细。那么接下来到了xxx部分。”
需求描述中，先说什么?后说什么?
需求评审会先说需求背景和目的、功能设计，进入到需求描述。本着高效原则，每个需求点只描述重点和难点。
在一个需求点的描述中：
1. 从上到下，从左到右描述
我认为，针对B端工具，从上到下描述，从左到右描述是比较完整的，既可以当做是使用者查看顺序来描述，也可以当做是自己在思考时逻辑过程再走一遍，查漏补缺。
比如，最近在设计微信模板消息推送的后台工具，属于B端后台工具。在需求评审时，可以直接打开流程的原型图，对着原型页面从上到下，从左到右描述。
上述图中，可先从上到下，第一部分是信息筛选：可支持筛选xxx数据，点击查询的结果展示在下方的表格数据;
第二部分是表格数据，展示的数据项按原型图顺序排列。再从左到右：表格数据中，前两项是xxxx，中间这几项是反馈微信推送的结果，最后操作中可支持以下几种状态的不同操作，分别是xxxx。
这样说下来，自己会感觉很清晰，开发也能明白这个页面需要做什么，不同状态下可以做什么操作，剩下的内容可请开发自行查阅需求文档。
2. 从用户操作路径描述
针对C端产品，根据用户操作路径来描述，会让整个流程的听众也能把自己当做这个产品的用户一样去完整体验一遍这个需求的闭环。因此根据用户操作路径来说会比较完整，需要讲清楚每个部分之间的联系，这个联系通俗来理解，就是下一个页面是通过上一个页面的什么操作的来的。例如用户在商品详情页点击“去购买”，就跳转到了订单确认页。
考虑到C端产品通常会有后台系统进行配置，所以在需求评审中通常也涉及到前端页面和后台页面的描述。所以我认为在评审中将前端页面和后台页面对应起来描述会更流畅，还是例如用户进入商品详情页，可看到页面顶部是5张商品图轮播，商品图是在后台的新增列表中可配置，是怎么样的上传规则xxxx。
3. 暂无结论的尽量不占用会议时间
虽然需求评审是产品经理的“演讲会”，但是也难免会存在开发与产品、开发与开发之间会因技术实现的问题占用较长的时间。除了在前期设计需求时需要主动和开发讨论技术实现最优方案，在评审会中也需要把握技术讨论的时间。如果不能一下子讲清楚或者暂无统一结论的，先不占用会议时间，会后再和开发讨论。
和开发讨论技术方案实现，我认为千万不能被开发用产品“听不懂”的技术带跑。透过现象看本质，深究影响这个技术实现的业务问题到底是什么，因为产品不一定懂很多技术知识，但是一定是了解业务的。
什么场景下对着文本说?什么场景下对着原型说?
首先需要明确，文本和原型的区别/效果分别是什么?
在我看来，文本是针对逻辑、格式、规则等一些规范性需求要求的详细阐述。原型是针对操作界面、流程、展示大概的样式的图像化呈现，因此需要根据当下讲的内容来匹配对应的展示内容(文本or原型)。
例如，近期设计的抽奖活动，在需求评审时，需要阐述用户可以通过完成什么任务获得抽奖卡。
一个任务包括：任务名称、任务时间、任务触发入口、任务展示、任务状态等。可以将上述的先分类，任务名称、时间、入口、展示都是可以通过图像化形式呈现，任务状态需要有规则告知什么时候展示什么任务、当用户完成该任务时任务排序是怎么样的等等。因此可以在描述用户可以完成什么任务的时候，对着原型说是合适的;在描述详细的任务排序规则的时候，对着文本说是合适的。
上述3个问题是我从入职以来到现在，在需求评审会中最常见的，因此通过观察导师的需求评审总结了一些提高效率的方法，虽然并不是完全我都能立刻掌握，但仍在“刻意练习”的过程中。如何在需求评审中让开发能更快、更清晰、更准确明白产品的需求，也是锻炼产品经理“同理心”(换位思考)的技能。