浅析支付产品的设计“模式”

3 评论 7264 浏览 47 收藏 13 分钟

产品经理在接到需求之后,第一感觉往往是“赶紧找一个成熟产品扫两眼”,这虽然无可厚非,但对于我们的职业发展还是比较危险的。如何形成主动设计产品的设计“模式”呢?本文作者分享了他的看法,希望能给你带来一些启发。

今天收到一条问题,想看看某类产品的后台页面,当然了,每一个产品经理在接到需求以后,第一感觉就是“赶紧找一个成熟产品扫两眼”,无可厚非。只不过实际是实际,理想还是要有的,万一找不到参考可看呢?

想吃鱼,还得会钓鱼

别忘了自己的身份——我们是一名产品经理。

最后我们还是需要一个可以兜底的技能,自己动手搞起来!

那就是我们做为一名产品经理的最基本的素养——评估需求、分析业务、产品调研、需求分析、功能分析、方案设计……而很多时候,我们把产品设计中的产品调研完全放大成了“找个页面借鉴一下”。

但参考谁,谁的才是标准,其实,我们并没有答案,难道他的就是好的么?

高启强想吃鱼找老默,但是我们想吃鱼,还得学会钓鱼;可能有的人说了,我有钱,可以去菜市场买,那我们就真的成咸鱼了。

做产品经理也是一样,钓鱼能力,就是我们的基本专业素养和产品技能,如果没有这些基础能力,每次接到需求都想着找一个模板、看两个页面,职业发展还是非常危险的。

业务场景、需求、产品方案等都是无限多的,无法枚举;但是设计方法或者说产品方法论是有多的,是通用的。

那什么是方法论呢,简单的说,我把他理解成我们设计产品的“模式”以及在这个模式下的“工具箱”。

比如梅西踢球喜欢用左脚,从右边路盘带过人,到中路左脚抽射……我们的设计产品的模式“拿到一个需求,先分析业务场景和模式、再分析产品目标想干嘛、在该业务场景下这个目标如何通过产品实现”,而其中,如何分析业务场景呢?这时候就需要用到我们的工具包了,业务分析怎么做……

在长期工作训练、学习中,我们不断强化这个过程,慢慢的形成了我们自己的产品设计讨论,或者厚着脸皮说“我们自己的产品方法论体系以及产品哲学”,当然,抄,也是一种哲学!

回到开头的问题,如果我们想做一个资金管理系统以及配套的银企直联体系,我们该怎么办,当然啦,去找一个成熟的资金管理系统看一看,很快就能落地了,只不过,这个过程我们并没有真正成长,完全没有调动起来自己的“产品设计模式和工具包训练”。

假如,我们第一感觉不是去看一个成熟的产品,而是,习惯了先自己动手搞起来。

那我们第一个问题可能就是:我们是一家什么公司,什么样的业务模式,当前的业务情况如何,怎么就突然想做一个资金管理系统呢?这个诉求是在什么时候、什么情况下、由谁提出来的呢?计划用这个系统干嘛呢?

一系列的“?”浮现在脑子里,这就是一个成熟产品经理的职业习惯或者说职业病,如果你还没有,那可能说明,要不你还年轻,要不你习惯了“拿来主义”。

一切产品需求的产生都是有原因的、有目的。

而学会问问题,无论是问自己还是问别人,都是一个产品经理最核心的能力,通过一些列的问题,我们能够趋近我们要的答案。

那什么是资金管理系统呢?什么又是银企互联呢?

如果我们专业,那可以轻松解答这个问题,如果我们不懂,那也不妨碍我们去设计这个系统。

既然无法直面回答这个问题,我们可以绕到问题的另一面,需求者想用这个系统干嘛?——这就产生了“用户调研的需求”,如果能从用户口中了解他们想做这个系统的目的,那我们就有了答案。

即使我们无法定义什么是资金管理系统,但是我们可以帮助用户做一个“系统”能够解决他的所有诉求,比如他们想查询对公户的账户余额因为登录网银太麻烦、他们想通过自己的系统下载到全部的账单、他们想……

好了,我就给你们做一个银行账户余额查询功能,账单下载功能,但是我们公司有上百个账户啊,是不是我得做一个银行账户列表……那我怎么把我们公司的银行账户添加到系统里呢?……

解决一个旧的问题,就会迎来一个新的问题……那我们就继续问我们的用户、继续想怎么给他们解决办法…….最后得到了这样一个地图,我们的功能脑图就产生了。

想吃鱼,还得会钓鱼

(用户想干这些事VS我可以提供这些功能)

而我们最后,我们把这个用户需要的和我们设计出来的功能的组合起了一个名字——银行综合管理平台——其实我们发现,他干的就是所谓的资金管理系统做的事情。

一个系统总不是孤立的,这里我们想要的这些功能是不是需要上下游系统的联系,传递数据,操作联动;比如资金结算数据是不是要依赖外部系统,谁来发起对外的付款,需不需要审核;付款状态是不是要回传给上游系统……

想吃鱼,还得会钓鱼

其中还有很多细节需要分析,比如如果要变更银行账户信息怎么办呢?需要线上发起,线上审批么?怎么审批呢?我们公司用的钉钉,审批是不是可以接入钉钉呢?……我们的业务流程方案就产生了。

想吃鱼,还得会钓鱼

银企直联怎么接呢?一般银行的银企直联都有哪些功能,银行都提供哪些接口呢?账单怎么下载呢?需每天系统自动下载,还是用户需要那个银行就下载那个银行呢,手动点一下?哦,对了,需要出资金报表,得自动下载,不然有些数据分析不出来……我们的功能分析就产生了。

想吃鱼,还得会钓鱼

我们用的招商银行,去哪里找一下招商银行的银企直联接口文档研究研究?……很多问题,最后都可以转换成可落地的执行步骤。

就比如,账单如何下载呢?是不是要一个任务模模块每日凌晨2点去挨个下载每个维护的银行账户的上一日的账单,并且存储起来,在后台可以看到账单列表,可以点击操作下载到本地……

想吃鱼,还得会钓鱼

账单管理这个模块需要后台页面么?我想想……下载任务应该不需要人来维护,技术维护即可,那就不需要页面;任务执行结果是不是应该能看到,那就增加一个任务执行结果的日志展示,可以查询每天每个账户的账单下载情况,成功还是失败,那失败了是不是可以手动触发再次下载……我们的页面就产生了。

想吃鱼,还得会钓鱼

账单下载下来,是不是需要一个页面查看账单,并且可以手动下载到本地,如果推送到资金管理系统失败了,是不是可以手动触发推送……

想吃鱼,还得会钓鱼

如果已经下载成功了,再次触发下载账单,是要覆盖原来的账单么?如果已经推送到资金管理中心呢?再次下载以及再次推送可不可以……我们的产品功能逻辑就产生了。

想吃鱼,还得会钓鱼

最后经过一轮一轮的分析、拆解、结合业务诉求的研究,看了银企接口之后,我们也就大致可以分析出来银企互联系统需要哪些东西,能够提供什么功能,需不需要后台页面展示,配置化功能,数据查询功能,哪些操作功能——可能不完全,但足够好用。

对一个产品来说,能用是及格的,好用是最高的评价。

以上的设计模式,适用于所有产品的设计工作,只要静下心来,都能做出来,不要“怕”。

我觉得,产品是设计出来的,而设计产品是我们的核心职能;参考借鉴是没任何问题。

但,不要忘了,我们可以学会完全“自研”。

而,自研,离不开那些属于我们自己的“产品设计模式”和围绕模式打造的“工具包”。

我们成长和学习的目的是什么,就是收获我们的模式和工具包,并在工作中不断强化……

最后,回答另一个读者的问题:

想吃鱼,还得会钓鱼

做到我们上面说的那些……危机不在环境,而在自己,改变不了大环境,就改变自己,无限进化。

企业大概率不会裁掉一个“能给自己创造超额价值,且各方面都很强的员工”,就算自己被“误裁”,那也不愁去处。

专栏作家

陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!

题图来自 Unsplash,基于 CC0 协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 可以加你微信吗?

    来自广东 回复
  2. 你7个月没回那个读者的消息=、=

    来自北京 回复
    1. 哈哈,看得真仔细,有没有可能是他回复了我上面的内容

      来自北京 回复