产品经理该如何把业务需求变成产品方案
编辑导读:产品经理日常工作中最常听到的词就是需求,而产品经理的核心工作也就是把需求变成可使用的产品。那当我们接到需求时,我们是如何把它转化成产品呢?本文将从七个方面进行分析,希望对你有帮助。
一、对“需求”这个词的理解
首先我们先了解一下,在产品开发过程中所沟通的“需求”到底指的是什么。我们先举几个我们工作中常常听到的需求:
- 老板:现在经营效率太低了,我们要上个系统,提高效率(目标需求);
- 财务:每笔费用报销都要走审批,加强对费用支出的管理(业务需求);
- 运营:日常经营数据需要支持导出功能,好进行加工分析(功能需求)。
我们可以将平常听到的需求都归为这三类,产品经理需要做的就是将目标需求和业务需要转化为产品方案,然后交付给开发团队。
接下来我们将以羽毛球馆订场地这个业务需求,来拆解一下整个过程,看它是一步步变成产品方案的。
二、定位业务问题
场馆运营部门提出一个需求,我们需要实现线上订场地。
业务需求的提出,肯定是为了解决某些业务问题。通过调研,现在纯线下订场的方式存在以下问题:
球友:
- 想运动,但不知道哪里有合适的场馆?
- 不知道场馆是如何收费的?
- 场馆有没有空闲的场地?
- 场馆的有哪些项目?有没有停车场、淋浴等设施?
场馆:
- 球友打电话过来,询问场地价格和空余等情况耗费时间;
- 新球友订场交定金麻烦,不交定金又可能爽约,造成场地未预定出去的损失;
- 人工登记场地预定情况,易产生失误,导致一场多订等情况,极大影响客户体验;
- 场地预定情况很难统计成分析数据,对运营决策无法提供帮助;
业务问题定位了,后面的设计就要围绕这些问题展开,设计完后要回过来看有没有解决这些问题,否则一切都是徒劳的。
三、梳理业务流程
流程是产品设计的关键,梳理流程能让你对整个过程更清晰。梳理过程前,先要明确下订场有几个场景,因为每个场景的流程可能不太一样。通过调研和分析得知,订场主要有以下几种场景:
- 线上订场—球友在微信或者APP上订场;
- 线下订场—球友直接到场馆前台临时订场;
- 电话订场—打电话给场馆前台,让前台预留场地;
- 长期球友固定订场—有些企业会固定在某个时段订场,比如周三的18:00~20:00,一次预订即可,定好有效期,不用每次临时预订;
- 包场—企业搞团建时会包下整个场馆;
这里就要思考一下,我们这次设计是否要满足这5个场景呢?我们回到定位业务问题这一步,问题都是在想要运动的球友在订场时存在的,而方式e在线下的处理暂时并没有多大问题,再深入一步调研可了解到,包场都是直接线下谈好价格,这个价格也是可浮动的,然后将钱线下转给场馆,放到线上反而不灵活,所以我们就先不考虑线上实现这个场景。
Tips:产品经理需要学会做减法,并不是把线下所有业务搬到线上来,开发出来后发现并没有什么用,又浪费这么多资源。
将待实现场景确定下来后,我们需梳理每个场景的业务流程,这样才能对整个过程清晰。因为我们这次只是讲方法,所以就只拿场景a来举例,继续下面的分析过程。
我们梳理出线上订场流程图后,这时我们需要分析一下,这些环节哪些需要做到线上?
入场前:订场、付款、锁场肯定是需要做到线上的,产品的目标就是为了解决订场效率低的问题;
前台接待:出示订场凭证、校验订场凭证、开灯、放行这些环节并没有太大的影响效率。出示订场凭证、校验订场凭证可通过报手机号的形式解决。开灯和放行涉及到智能灯控和智能闸机的对接,没有这些东西业务也能跑的通,也能正常营业,这期也先不考虑在线上实现;
入场后:到点提示也涉及到智能设备的对接,先可人工提示。
Tips:产品经理需要定义需求的优先级,先把影响业务正常运行的问题解决掉,再来迭代优化。
四、梳理业务规则
业务规则是运营部门为使业务正常运行而定义的,就算没有系统也是存在的。产品经理需要做的是把这些业务规则梳理出来,然后用产品的语言把它描述出来。还是以线上订场举例,场地什么时候可以订?订的时候有没有时间限制?价格会由哪些因素影响?可不可以退场?会员有没有什么特殊权限?这些规则听着是不是很乱,这就需要产品经理一条一条梳理清楚,梳理规则的同时还需要多问为什么要这样做呢,一来以后方便和开发等同事说清楚为什么这样设计,二来也能加深自己对业务的了解。
通过调研我们梳理出以下预订规则,但我们需注意以下两点:
- 这些规则都是比较容易通过调研得到的,还有一些隐性的规则,调研的时候很难得到,可能在产品上线一段时间后才能想到。例如订场后要在一定时间内支付,不支付就将场地变成空闲状态。产品上线后这种规则缺失一定会暴露出来的,但产品经理最好能提前考虑到这种规则,尽量避免损失。
- 这些规则仅仅为一个场馆的规则,为将产品的适用更多的场馆,也为防止以后场馆的业务规则变动,尽量做成可配置的。
以上只列举了线上订场的预订规则,还有退订规则、价格方案规则、会员权限等规则都需要一条一条梳理出来,这里就不一一列举出来了。
五、绘制原型
业务流程和业务规则都梳理出来后,就可以画原型了。这一步对产品经理来说,即简单又困难。简单是因为去想象具象的软件操作比思考抽样的业务逻辑更容易,难是因为画的原型最终要符合业务流程和业务规则,并且还要符合常规交互原则。
从业务流程分析,整个订场环节涉及到球友和场馆,那肯定要有球友订场端和场馆管理端。球友订场端刚开始也没必要做APP,做个H5放在微信公众号就可以了,还能引流到公众号。确定好用什么来实现后,我们要梳理一下线上订场有哪些页面,不要想到一个画一个,这样很容易漏页面。
Tips:刚开始设计原型时,尽量不要添加一些和主流程无关的页面,比如你觉得别人做了个VR查看场馆,你也要做一个,但是前期最重要的是把业务跑通,再来添加一些附加功能。
工具类产品原型设计多参考一下美团、淘宝等移动端产品,因为移动端产品发展到现在,已经培养了用户的操作认知,我们不用去发明轮子,让用户再重新去学习。
六、可用性测试
产品的原型出来了,可以给客户演示,让客户跑一遍整个流程,看先前提的业务问题有没有得到解决。如果有问题,再进行调整。其实让客户跑一遍流程也不能发现所有问题,只有在真正使用的时候才会暴露出问题来,但这一步也是不可少了。
七、撰写PRD
PRD全称为Product Requirement Document,中文名为“产品需求文档”。其核心目的是帮助开发、测试、运营、产品人员理解该需求的背景和具体要求,减少产品实现过程中诸多不必要的重复解答,从而提升整体项目推进效率。当业务规则、业务流程、原型图都出来后,我们需要把它交付给我们的开发团队去实现,交付的形式就是PRD。这里就不阐述PRD怎么写了。
八、总结
当接到业务需求时,变成产品的过程是:
- 定位业务问题;
- 梳理业务流程;
- 梳理业务规则;
- 绘制原型;
- 可用性测试;
- 撰写PRD。
以上只是个理想化的流程,产品经理并不是写完PRD扔给开发就没事了。包括后面的需求评审、跟进开发进度和问题、测试上线、迭代优化等,都需要产品经理主导。
写在最后:文中只讲了分析的方法,并没有把实际的过程细节描述出来。如果各位大佬有其他见解,也欢迎提出,产品路上我们一起成长。
本文由 @康力文 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自pexels,基于CC0协议
新产品的落地差不多经历了这些环节:
用户需求>-产品需求采集 >产品策划 >产品交互设计 >产品视觉设计 >产品页面重构 >产品研发 >产品测试 >产品发布 >需求收集 >迭代
—
那从用户需求到原型生成,是怎么抽象到具象的? 就像生活中 盖房子,拿到的原材料都钢筋 混凝土, 产出的高楼却各不同;
公司餐厅,厨师拿到的原材料是番茄和面,产出的却是番茄臊子面,为啥不是湖汤面。
就像你在设计工作中, 我觉得研究用户、组织、竞品、政策, 这些都是原材料, 经你输出出原型时,基本就具体化了,我看网称为具象就也这么说了。 张三拿到同样的原材料,输出了臊子面,李四却输出了糊汤面,这个过程发生了什么?
—
一段时间里我对这点很是困惑。
个人的一点浅见:原型可以看作是产品需求的具象化展示,所以这个问题在我看来就是用户需求如何转化为产品需求,而产品需求换一个角度来讲其实就是针对用户需求的解决方案。如果用户的目的只是为了填报肚子,那么提供臊子面还是糊汤面都是可以的,当然最好是再了解用户的口味喜好最终确定下来;如果用户就是专门为臊子面而来的,那就提供臊子面不要考虑糊汤面。至于用户需求转化为产品需求的过程就是产品设计,基于用户的业务场景、业务流程来设计产品的功能模块、功能入口、操作步骤、交互体验等,设计过程中要充分考虑到明面上或隐藏的业务规则以及各种异常情况。
可以向你请教一下
功能需求和业务需求的区分标准吗?
是需求大小的分别,比如是设计一个系统还是设计一个功能
还是需求解析到产品需求过程的区别,一开始是业务需求,在业务进行过程中产生的新需求,为功能需求
个人理解:需求这个词范围比较模糊,在不同场景每个人表达的意思都不太一样,我自己对业务需求和功能需求的区分,业务需求是个比较大的概念,提出后不能立马做,比如加个报表让老板知道每天的营业情况,需要产品经理去细化各个指标,形成功能需求,功能需求就比较具体了,比如加个导出功能、加个按时间筛选功能等等,简单粗暴的理解,业务需求是由若干个功能需求组成的。
1:客观梳理业务现状。
2:总结业务问题
3:输出产品解决方案
4:衡量收获
厉害厉害!
写得很好,思路清晰,对产品新人帮助很大的。
看必存
来自点嘀员工的赞许
哈哈,你是景林?
很赞
写的很棒,赞一个
谢谢,受益匪浅
写的挺好的