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

8 评论 41112 浏览 312 收藏 14 分钟

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

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

一、故事引入

小李新入职了一家公司,领导安排小李先熟悉业务,给他开通了一个测试账号,小李就在测试环境上走流程、看功能,流程都走通了,对业务也有了一定的了解。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协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的非常好,干货满满

    来自广东 回复
  2. 受益匪浅,恍然大悟

    来自广东 回复
  3. 产品必修课

    来自江苏 回复
  4. 很多事都会交给后端开发做

    来自浙江 回复
    1. 哈哈,为什么呀

      来自北京 回复
    2. 给前后端拉架也是产品的必修课之一

      来自北京 回复
  5. 现实情况是,很少的产品经理能按照文章中说的这些注意事项来做事情的,能这么做的,都是会很受欢迎的

    来自江苏 回复
    1. 嗯确实是,需要不断修炼,多总结。

      来自北京 回复