浅析支付产品的设计“模式”
今天收到一条问题，想看看某类产品的后台页面，当然了，每一个产品经理在接到需求以后，第一感觉就是“赶紧找一个成熟产品扫两眼”，无可厚非。只不过实际是实际，理想还是要有的，万一找不到参考可看呢？
别忘了自己的身份——我们是一名产品经理。
最后我们还是需要一个可以兜底的技能，自己动手搞起来！
那就是我们做为一名产品经理的最基本的素养——评估需求、分析业务、产品调研、需求分析、功能分析、方案设计……而很多时候，我们把产品设计中的产品调研完全放大成了“找个页面借鉴一下”。
但参考谁，谁的才是标准，其实，我们并没有答案，难道他的就是好的么？
高启强想吃鱼找老默，但是我们想吃鱼，还得学会钓鱼；可能有的人说了，我有钱，可以去菜市场买，那我们就真的成咸鱼了。
做产品经理也是一样，钓鱼能力，就是我们的基本专业素养和产品技能，如果没有这些基础能力，每次接到需求都想着找一个模板、看两个页面，职业发展还是非常危险的。
业务场景、需求、产品方案等都是无限多的，无法枚举；但是设计方法或者说产品方法论是有多的，是通用的。
那什么是方法论呢，简单的说，我把他理解成我们设计产品的“模式”以及在这个模式下的“工具箱”。
比如梅西踢球喜欢用左脚，从右边路盘带过人，到中路左脚抽射……我们的设计产品的模式“拿到一个需求，先分析业务场景和模式、再分析产品目标想干嘛、在该业务场景下这个目标如何通过产品实现”，而其中，如何分析业务场景呢？这时候就需要用到我们的工具包了，业务分析怎么做……
在长期工作训练、学习中，我们不断强化这个过程，慢慢的形成了我们自己的产品设计讨论，或者厚着脸皮说“我们自己的产品方法论体系以及产品哲学”，当然，抄，也是一种哲学！
回到开头的问题，如果我们想做一个资金管理系统以及配套的银企直联体系，我们该怎么办，当然啦，去找一个成熟的资金管理系统看一看，很快就能落地了，只不过，这个过程我们并没有真正成长，完全没有调动起来自己的“产品设计模式和工具包训练”。
假如，我们第一感觉不是去看一个成熟的产品，而是，习惯了先自己动手搞起来。
那我们第一个问题可能就是：我们是一家什么公司，什么样的业务模式，当前的业务情况如何，怎么就突然想做一个资金管理系统呢？这个诉求是在什么时候、什么情况下、由谁提出来的呢？计划用这个系统干嘛呢？
一系列的“？”浮现在脑子里，这就是一个成熟产品经理的职业习惯或者说职业病，如果你还没有，那可能说明，要不你还年轻，要不你习惯了“拿来主义”。
一切产品需求的产生都是有原因的、有目的。
而学会问问题，无论是问自己还是问别人，都是一个产品经理最核心的能力，通过一些列的问题，我们能够趋近我们要的答案。
那什么是资金管理系统呢？什么又是银企互联呢？
如果我们专业，那可以轻松解答这个问题，如果我们不懂，那也不妨碍我们去设计这个系统。
既然无法直面回答这个问题，我们可以绕到问题的另一面，需求者想用这个系统干嘛？——这就产生了“用户调研的需求”，如果能从用户口中了解他们想做这个系统的目的，那我们就有了答案。
即使我们无法定义什么是资金管理系统，但是我们可以帮助用户做一个“系统”能够解决他的所有诉求，比如他们想查询对公户的账户余额因为登录网银太麻烦、他们想通过自己的系统下载到全部的账单、他们想……
好了，我就给你们做一个银行账户余额查询功能，账单下载功能，但是我们公司有上百个账户啊，是不是我得做一个银行账户列表……那我怎么把我们公司的银行账户添加到系统里呢？……
解决一个旧的问题，就会迎来一个新的问题……那我们就继续问我们的用户、继续想怎么给他们解决办法…….最后得到了这样一个地图，我们的功能脑图就产生了。
（用户想干这些事VS我可以提供这些功能）
而我们最后，我们把这个用户需要的和我们设计出来的功能的组合起了一个名字——银行综合管理平台——其实我们发现，他干的就是所谓的资金管理系统做的事情。
一个系统总不是孤立的，这里我们想要的这些功能是不是需要上下游系统的联系，传递数据，操作联动；比如资金结算数据是不是要依赖外部系统，谁来发起对外的付款，需不需要审核；付款状态是不是要回传给上游系统……
其中还有很多细节需要分析，比如如果要变更银行账户信息怎么办呢？需要线上发起，线上审批么？怎么审批呢？我们公司用的钉钉，审批是不是可以接入钉钉呢？……我们的业务流程方案就产生了。
银企直联怎么接呢？一般银行的银企直联都有哪些功能，银行都提供哪些接口呢？账单怎么下载呢？需每天系统自动下载，还是用户需要那个银行就下载那个银行呢，手动点一下？哦，对了，需要出资金报表，得自动下载，不然有些数据分析不出来……我们的功能分析就产生了。
我们用的招商银行，去哪里找一下招商银行的银企直联接口文档研究研究？……很多问题，最后都可以转换成可落地的执行步骤。
就比如，账单如何下载呢？是不是要一个任务模模块每日凌晨2点去挨个下载每个维护的银行账户的上一日的账单，并且存储起来，在后台可以看到账单列表，可以点击操作下载到本地……
账单管理这个模块需要后台页面么？我想想……下载任务应该不需要人来维护，技术维护即可，那就不需要页面；任务执行结果是不是应该能看到，那就增加一个任务执行结果的日志展示，可以查询每天每个账户的账单下载情况，成功还是失败，那失败了是不是可以手动触发再次下载……我们的页面就产生了。
账单下载下来，是不是需要一个页面查看账单，并且可以手动下载到本地，如果推送到资金管理系统失败了，是不是可以手动触发推送……
如果已经下载成功了，再次触发下载账单，是要覆盖原来的账单么？如果已经推送到资金管理中心呢？再次下载以及再次推送可不可以……我们的产品功能逻辑就产生了。
最后经过一轮一轮的分析、拆解、结合业务诉求的研究，看了银企接口之后，我们也就大致可以分析出来银企互联系统需要哪些东西，能够提供什么功能，需不需要后台页面展示，配置化功能，数据查询功能，哪些操作功能——可能不完全，但足够好用。
对一个产品来说，能用是及格的，好用是最高的评价。
以上的设计模式，适用于所有产品的设计工作，只要静下心来，都能做出来，不要“怕”。
我觉得，产品是设计出来的，而设计产品是我们的核心职能；参考借鉴是没任何问题。
但，不要忘了，我们可以学会完全“自研”。
而，自研，离不开那些属于我们自己的“产品设计模式”和围绕模式打造的“工具包”。
我们成长和学习的目的是什么，就是收获我们的模式和工具包，并在工作中不断强化……
最后，回答另一个读者的问题：
做到我们上面说的那些……危机不在环境，而在自己，改变不了大环境，就改变自己，无限进化。
企业大概率不会裁掉一个“能给自己创造超额价值，且各方面都很强的员工”，就算自己被“误裁”，那也不愁去处。
作者
陈天宇宙，微信公众号：陈天宇宙。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
