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

阶梯23级

需要评审，产品经理们再也相熟不外的任务，但关于许多产品新人来讲，不是一件简略的事。这是一场和本人的较量，毕竟是不是筹备充沛，是不是能将本人的计划禁受住其余人的灵魂拷问，归根结柢，仍是产品经理本人的事。详细要怎么做，但愿本篇文章能给各位带来帮忙。

大家好，本期咱们分享的是产品经理天天都会做的任务，很相熟，然而得多产品经理也很恐怖，那就是：需要评审。需要评审是产品经理的一场考试，其实我感觉更是产品经理的一场自我较量，是产品经理本人是不是筹备充沛，是不是能将本人的计划禁受住其余人的灵魂拷问，归根结柢，仍是产品经理本人的事。
一、故事引入
小李新入职了一家公司，领导支配小李先相熟业务，给他守旧了一个测试账号，小李就在测试环境上走流程、看功用，流程都走通了，对业务也有了一定的理解。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协定。
该文观念仅代表作者自己，人人都是产品经理平台仅提供信息存储空间办事。