需求评审，产品经理们再也熟悉不过的工作，但对于许多产品新人来说，不是一件简单的事。这是一场和自己的较量，毕竟是否准备充分，是否能将自己的方案经受住其他人的灵魂拷问，归根结底，还是产品经理自己的事。具体要怎么做，希望本篇文章能给各位带来帮助。
大家好，本期我们分享的是产品经理每天都会做的工作，很熟悉，但是很多产品经理也很恐惧，那就是：需求评审。需求评审是产品经理的一场考试，其实我觉得更是产品经理的一场自我较量，是产品经理自己是否准备充分，是否能将自己的方案经受住其他人的灵魂拷问，归根结底，还是产品经理自己的事。
小李新入职了一家公司，领导安排小李先熟悉业务，给他开通了一个测试账号，小李就在测试环境上走流程、看功能，流程都走通了，对业务也有了一定的了解。3天后小李找到领导；
小李：领导，我熟悉的差不多了，有什么工作吗，分给我一个？
领导：正好业务方提了一个需求，你来跟进下吧。这个需求就是住院的医嘱计费节点配置功能（医嘱是指医师在医疗活动中下达的医学指令，比如开药，做一次CT检查）
小李拿着需求，第二天就画完了原型，写完了PRD，约了开发准备评审。
评审会上小李慷慨激昂的讲完了需求，心里想：等着开发排期吧。
突然，气氛有些不对。
开发老张说：第三方检查系统要触发计费的怎么处理，据我所知，有的PACS系统是在登记成功的时候要调用HIS进行计费。
小李有些懵，以为所有的计费只需要护士分解提交就可以计费了呢。
这个故事告诉我们，新人去了公司一定不用急着干活，虽然我们做不到很全面地了解业务和功能，但是在接到需求时，一定要了解清楚这几点：
1.这个需求的背景是什么
也就是说为什么要做这个需求，谁提出的，比如HIS系统里，是护士提出的，还是医生提出的，是在什么场景下提出的？是遇到什么困难了需要系统帮忙解决？
2.这个需求对现有系统有哪些影响
如果做这个需求，对现有系统哪些地方会影响，列出影响当前系统的点，这个一定要自己亲手去体验产品，根据现有的逻辑和交互去考虑，如果不了解现在的功能，那么很容易会遗漏或者方案有冲突。
3.这个需求的分类
需求是否是属于标准型产品还是个性化产品，思考能否做成通用的产品，如果不能，怎么来平衡对其他客户对影响，尤其是在to B的业务里，是经常遇见的，产品经理要深入了解业务场景，才能判断好。
4.做最优的方案
这个是最难的，也是值得我们最应该思考和努力的。
如果有多个解决方案，我们肯定会采取成本最小的方案，但是笔者最近一直在思考一个问题：系统做的功能就是最优的方案吗，我的答案是非也，其实很多时候我们通过管理要求、相关制度可以解决问题，举个例子：医院放射科的主任说需要限制每天临床的加急患者，否则加急的插队多了患者会投诉，但是控制加急的患者靠系统合适吗，是否需要加急医生最有决定权，系统是完成不了这个事情的，所以不是所有的需求都应该通过系统满足，有时会适得其反。
5.这个需要的范围有多大
这个需求仅仅是我们看到的样子吗？未必，一个需求有时候会连接好几个系统都要配合，这个也要考虑到，拿HIS系统举例，HIS和医技系统有很多业务接口交互，新增需求很可能会影响到第三方改动。
我们做产品的，对需求评审的一个共识就是需求评审就是给开发讲我们要做的功能，让开发帮我们干，这样理解没有问题，但是最重要的是让我们做的事情，大家达成一个共识。只有大家达成了共识，认为我们是做一件正确的事，你的需求评审就赢了一半，大家也才会努力的去做，剩下一半就是要把功能怎么讲解给项目人员，让大家对自己要做的部分很清晰。
需求评审时参与的角色：项目经理、产品经理、前后端开发，UI，测试等项目人员。
俗话说，知己知彼，百战百胜，很多人之所以评审时被开发怼或者质疑，就是因为不清楚评审的对象他们心里想要的评审是什么样子。
前后端开发关注的点如下：
业务逻辑：我们拿线下购物举例，我们去超市购买东西需要先加入到购物车，然后收银台付款后，商品我们才能带走，映射到程序里，就是提供搜索、浏览商品、加入购物车、提交订单、支付的功能，在程序里也是有逻辑的，不可能未付款就给发货，只有有了逻辑，开发才可以按照逻辑去写代码。
数据字典：数据字典产品可以理解为我们设计产品的字段，开发设计数据库时，需要表，表里面就是字段，我们提供一份完整的数据字典，开发在设计表的时候就能填充进去字段，数据字典一般包括字段名称、字段的类型、字段的来源、字段的长度等。
实体关系：实体关系说经过现抽象出来的概念，比如我们去医院看病，患者就是一个实体，医生是一个实体，医生所在的科室也是一个实体，实体和实体之间是有关系的，一个科室可以有多个医生，一个医生属于一个科室，我们在设计产品的时候也要把业务类的概念抽象出实体，然后梳理实体店关系
业务流程：凡事都有流程，先做什么后做什么，产品设计也是如此。在评审的时候我们一定要把流程描述清楚，拿购物举例：用户浏览商品-加入购物车-提交订单-付款-商家发货-商品配送-用户收货，可以通过画流程图的形式将业务的流程表达出来。
页面：前端关注的是页面的元素是什么，页面上是否需要表单、下拉框、弹窗等等
交互：交互有页面之间的跳转关系，也有特殊要求的动态效果
总结：前端一般不参与处理业务逻辑和处理数据，所以关注的是交互和页面上的元素，相反，后端开发需要处理逻辑处理数据，所以前后端关注的点是不一样的。
建立场景化的表达
场景表达是具体到用户或者系统的操作场景，这样参加评审的人员听起来就不会很懵，建立起来场景，大家的接受情况就会很高，评审效率也会很高
举例：PACS系统医院的登记员给患者在登记时调用HIS的计费接口，需求评审时候可以说在点击【登记】按钮时，调用计费接口。
这个说法看上去没有问题，但是如果通过场景化来表达，就会特别清晰。
2.描述要准确
在需求评审时描述尽量用可以量化的词进行，尽量少用名词，或者描述不准备的词汇
举例：比如订单金额必须大于0才能提交，有的产品经理可能会描述成订单金额不为空、必须有订单金额才能提交。很明显，第一种的描述开发是特别清晰怎么去做的。
3.规则要定义好
现在技术发展迅速，基本没有实现不了的功能，我们在评审的时候一定要想好我们的业务规则，业务规则清晰，开发就能按照规则去开发。
举例：医生开立医嘱后，护士要执行，有的医院药房周六日休息，护士会提前领取（周五）将周日的药品，领取药品后就意味着给患者计费了，但是医生在周六突然停止医嘱了，周日的药不再给患者吃了，那么周日的药就要退掉，系统要做自动给护士创建一个退药的申请，那么，这个是评审的时候就需要设计到退药申请的规则问题。
那么，我们在设计产品时，这个规则一定要考虑清楚，就执行单计划时间（护士给患者服药的时间）晚于医嘱停止时间的才允许自动创建退药申请，不然没有这个规则，都退药的话，就把不该退的药也给退了。
1. 评审时切忌说模棱两可的话，会让大家对你失去信任。我们知道，程序员的世界很简单，要么对，要么错，如果我们说一些可能、也行、大概的话，会遭致评审人的反感，逐渐对产品经理失去信任，产品经理是要给参加评审的人一个主心骨的，如果自己都做不到，那么别人可想而知了。
2. 产品经理在需求评审前和过程中，一定要自信，只有心里充满自信，才能在评审过程中有条理的回答别人的疑问，不要怕被质疑，产品经理注定是在不断的质疑中成长起来的。
3. 评审过程中，遇到逻辑错误、遗漏的时候，也不要慌，毕竟人无完人，可以先回答说我下去确认下或者我再思考下，尽量不要直接给出方案，因为当场给出的方案，基本都是我们没有仔细思考的，容易掉坑里。
4. 如果有需要调整方案或者补充的内容，产品经理会后要及时的完成，否则容易遗忘，丢掉关键信息。
5. 评审前，产品经理可以找好的开发同事帮忙看看大的逻辑是否存在问题，技术实现是否可行？同时在评审前，将要评审的内容提前发出来，评审时候大家就会比较有针对性的提问，提高评审效率。
6. 评审结束，要和相关角色讨论排期，如果不要排期，后面很可能会进度失控，不能如期上线，产品经理可能就要背锅了，其实产品经理某种程度上也在做项目经理的一部分事情。
需求评审是每个产品经理必经的过程，从被开发怼，到自己应付好多人的拷问都是需要一个过程的，除了对业务本身精通外，还需要多总结经验，多和开发、测试沟通，多听取优秀的产品经理的评审，需求评审会越来越顺利。
本文由 @糖炒栗子 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。