需求评审，是产品经理的一场自我较量

大家好，本期我们分享的是产品经理每天都会做的工作，很熟悉，但是很多产品经理也很恐惧，那就是：需求评审。需求评审是产品经理的一场考试，其实我觉得更是产品经理的一场自我较量，是产品经理自己是否准备充分，是否能将自己的方案经受住其他人的灵魂拷问，归根结底，还是产品经理自己的事。

一、故事引入

小李新入职了一家公司，领导安排小李先熟悉业务，给他开通了一个测试账号，小李就在测试环境上走流程、看功能，流程都走通了，对业务也有了一定的了解。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. 评审结束，要和相关角色讨论排期，如果不要排期，后面很可能会进度失控，不能如期上线，产品经理可能就要背锅了，其实产品经理某种程度上也在做项目经理的一部分事情。

六、结尾

需求评审是每个产品经理必经的过程，从被开发怼，到自己应付好多人的拷问都是需要一个过程的，除了对业务本身精通外，还需要多总结经验，多和开发、测试沟通，多听取优秀的产品经理的评审，需求评审会越来越顺利。

本文作者 @糖炒栗子 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！