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

From 理想城计划

需求评审,产品经理们再也熟悉不过的工作,但对于许多产品新人来说,不是一件简单的事。这是一场和自己的较量,毕竟是否准备充分,是否能将自己的方案经受住其他人的灵魂拷问,归根结底,还是产品经理自己的事。具体要怎么做,希望本篇文章能给各位带来帮助。

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

故事引入

小李新入职了一家公司,领导安排小李先熟悉业务,给他开通了一个测试账号,小李就在测试环境上走流程、看功能,流程都走通了,对业务也有了一定的了解。3天后小李找到领导;

小李:领导,我熟悉的差不多了,有什么工作吗,分给我一个?

领导:正好业务方提了一个需求,你来跟进下吧。这个需求就是住院的医嘱计费节点配置功能(医嘱是指医师在医疗活动中下达的医学指令,比如开药,做一次CT检查)

小李拿着需求,第二天就画完了原型,写完了PRD,约了开发准备评审。

评审会上小李慷慨激昂的讲完了需求,心里想:等着开发排期吧。

突然,气氛有些不对。

开发老张说:第三方检查系统要触发计费的怎么处理,据我所知,有的PACS系统是在登记成功的时候要调用HIS进行计费。

小李有些懵,以为所有的计费只需要护士分解提交就可以计费了呢。

这个故事告诉我们,新人去了公司一定不用急着干活,虽然我们做不到很全面地了解业务和功能,但是在接到需求时,一定要了解清楚这几点:

202303171059839.png

这个需求的背景是什么

也就是说为什么要做这个需求,谁提出的,比如HIS系统里,是护士提出的,还是医生提出的,是在什么场景下提出的?是遇到什么困难了需要系统帮忙解决?

这个需求对现有系统有哪些影响

如果做这个需求,对现有系统哪些地方会影响,列出影响当前系统的点,这个一定要自己亲手去体验产品,根据现有的逻辑和交互去考虑,如果不了解现在的功能,那么很容易会遗漏或者方案有冲突。

这个需求的分类

需求是否是属于标准型产品还是个性化产品,思考能否做成通用的产品,如果不能,怎么来平衡对其他客户对影响,尤其是在to B的业务里,是经常遇见的,产品经理要深入了解业务场景,才能判断好。

做最优的方案

这个是最难的,也是值得我们最应该思考和努力的。

如果有多个解决方案,我们肯定会采取成本最小的方案,但是笔者最近一直在思考一个问题:系统做的功能就是最优的方案吗,我的答案是非也,其实很多时候我们通过管理要求、相关制度可以解决问题,举个例子:医院放射科的主任说需要限制每天临床的加急患者,否则加急的插队多了患者会投诉,但是控制加急的患者靠系统合适吗,是否需要加急医生最有决定权,系统是完成不了这个事情的,所以不是所有的需求都应该通过系统满足,有时会适得其反。

这个需要的范围有多大

这个需求仅仅是我们看到的样子吗?未必,一个需求有时候会连接好几个系统都要配合,这个也要考虑到,拿HIS系统举例,HIS和医技系统有很多业务接口交互,新增需求很可能会影响到第三方改动。

需求评审是为了什么,都有哪些角色参与

我们做产品的,对需求评审的一个共识就是需求评审就是给开发讲我们要做的功能,让开发帮我们干,这样理解没有问题,但是最重要的是让我们做的事情,大家达成一个共识。只有大家达成了共识,认为我们是做一件正确的事,你的需求评审就赢了一半,大家也才会努力的去做,剩下一半就是要把功能怎么讲解给项目人员,让大家对自己要做的部分很清晰。

需求评审时参与的角色:项目经理、产品经理、前后端开发,UI,测试等项目人员。

需求评审,开发关注什么

俗话说,知己知彼,百战百胜,很多人之所以评审时被开发怼或者质疑,就是因为不清楚评审的对象他们心里想要的评审是什么样子。

前后端开发关注的点如下:

202303171101865.png

后端

业务逻辑:我们拿线下购物举例,我们去超市购买东西需要先加入到购物车,然后收银台付款后,商品我们才能带走,映射到程序里,就是提供搜索、浏览商品、加入购物车、提交订单、支付的功能,在程序里也是有逻辑的,不可能未付款就给发货,只有有了逻辑,开发才可以按照逻辑去写代码。

数据字典:数据字典产品可以理解为我们设计产品的字段,开发设计数据库时,需要表,表里面就是字段,我们提供一份完整的数据字典,开发在设计表的时候就能填充进去字段,数据字典一般包括字段名称、字段的类型、字段的来源、字段的长度等。

实体关系:实体关系说经过现抽象出来的概念,比如我们去医院看病,患者就是一个实体,医生是一个实体,医生所在的科室也是一个实体,实体和实体之间是有关系的,一个科室可以有多个医生,一个医生属于一个科室,我们在设计产品的时候也要把业务类的概念抽象出实体,然后梳理实体店关系

业务流程:凡事都有流程,先做什么后做什么,产品设计也是如此。在评审的时候我们一定要把流程描述清楚,拿购物举例:用户浏览商品-加入购物车-提交订单-付款-商家发货-商品配送-用户收货,可以通过画流程图的形式将业务的流程表达出来。

前端

页面:前端关注的是页面的元素是什么,页面上是否需要表单、下拉框、弹窗等等

交互:交互有页面之间的跳转关系,也有特殊要求的动态效果

总结:前端一般不参与处理业务逻辑和处理数据,所以关注的是交互和页面上的元素,相反,后端开发需要处理逻辑处理数据,所以前后端关注的点是不一样的。

需求评审时描述功能要怎么描述

建立场景化的表达

场景表达是具体到用户或者系统的操作场景,这样参加评审的人员听起来就不会很懵,建立起来场景,大家的接受情况就会很高,评审效率也会很高

举例:PACS系统医院的登记员给患者在登记时调用HIS的计费接口,需求评审时候可以说在点击【登记】按钮时,调用计费接口。

这个说法看上去没有问题,但是如果通过场景化来表达,就会特别清晰。

  • 非预约登记:点击登记按钮时调用计费接口
  • 预约登记(非签到):点击登记按钮时调用计费接口
  • 预约登记,需要签到:点击签到按钮时调用计费接口

描述要准确

在需求评审时描述尽量用可以量化的词进行,尽量少用名词,或者描述不准备的词汇

举例:比如订单金额必须大于0才能提交,有的产品经理可能会描述成订单金额不为空、必须有订单金额才能提交。很明显,第一种的描述开发是特别清晰怎么去做的。

规则要定义好

现在技术发展迅速,基本没有实现不了的功能,我们在评审的时候一定要想好我们的业务规则,业务规则清晰,开发就能按照规则去开发。

举例:医生开立医嘱后,护士要执行,有的医院药房周六日休息,护士会提前领取(周五)将周日的药品,领取药品后就意味着给患者计费了,但是医生在周六突然停止医嘱了,周日的药不再给患者吃了,那么周日的药就要退掉,系统要做自动给护士创建一个退药的申请,那么,这个是评审的时候就需要设计到退药申请的规则问题。

那么,我们在设计产品时,这个规则一定要考虑清楚,就执行单计划时间(护士给患者服药的时间)晚于医嘱停止时间的才允许自动创建退药申请,不然没有这个规则,都退药的话,就把不该退的药也给退了。

评审时需要注意的地方

202303171101472.png

  1. 评审时切忌说模棱两可的话,会让大家对你失去信任。我们知道,程序员的世界很简单,要么对,要么错,如果我们说一些可能、也行、大概的话,会遭致评审人的反感,逐渐对产品经理失去信任,产品经理是要给参加评审的人一个主心骨的,如果自己都做不到,那么别人可想而知了。
  2. 产品经理在需求评审前和过程中,一定要自信,只有心里充满自信,才能在评审过程中有条理的回答别人的疑问,不要怕被质疑,产品经理注定是在不断的质疑中成长起来的。
  3. 评审过程中,遇到逻辑错误、遗漏的时候,也不要慌,毕竟人无完人,可以先回答说我下去确认下或者我再思考下,尽量不要直接给出方案,因为当场给出的方案,基本都是我们没有仔细思考的,容易掉坑里。
  4. 如果有需要调整方案或者补充的内容,产品经理会后要及时的完成,否则容易遗忘,丢掉关键信息。
  5. 评审前,产品经理可以找好的开发同事帮忙看看大的逻辑是否存在问题,技术实现是否可行?同时在评审前,将要评审的内容提前发出来,评审时候大家就会比较有针对性的提问,提高评审效率。
  6. 评审结束,要和相关角色讨论排期,如果不要排期,后面很可能会进度失控,不能如期上线,产品经理可能就要背锅了,其实产品经理某种程度上也在做项目经理的一部分事情。

结尾

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

感觉本文对自己挺有用的,特收藏以便后面继续学习