支付产品经理应该具备怎样的产品能力？这篇文章里，作者从支付流分析能力、模式化设计能力、架构能力等维度进行了拆解和分析，一起来看看吧，或许会对你有所启发和帮助。

对于钻研整个支付来说，不简单也简单，说其不简单是因为有非常多的业务场景，也有非常多的支付组织，多维度组合出了非常复杂的支付设计，所以并不简单，滴滴的支付和美团的存在差异，同样京东的支付跟淘宝的也存在差异；说其简单也简单，因为复杂的背后总是有相似之处，通过归纳总结和抽象，精通其一便知其二，懂其二便知全部，因此，依托一个场景，去洞察其业务，研究其产品体系，并在此基础之上，形成一个完整的“知识网络”。

(相关资料图)

所收获的全局思维、架构能力、规划能力等，将有益于整个职业生涯，本文将从信息流和资金流分析能力、模式化设计能力、支付架构能力等3个方面构建一个支付产品经理应该具备的最基础的产品能力。

工作和日常交流过程中经常会涉及到信息流和资金流的分析，分析信息流主要是为了了解支付指令的传输途径或者交易流程，而分析资金流主要是了解支付中涉及到的货币种类和资金在不同主体之间的流动情况。

实际情况很多人并不能清晰的搞明白不同的支付活动中的信息流和资金流是怎么样的，或者根本上不知道如何去分析。接下来就聊一聊信息流和资金流的分析方法和通用模型，掌握了分析方法，就可以轻松的分析清楚任何一种支付活动的信息流和资金流。

什么是信息流和资金流？就如同一条小溪从高到低进行流动，“流”就是有规律的流动。

信息流就是信息的流动，这里的信息可以理解为支付指令所承载的信息，而流动就是支付指令在不同支付参与者或者支付系统之间的传递的过程，例如你在京东用微信支付了100元，那么支付信息流就从京东传递到了微信，如果你在微信支付时用了微信中的银行卡快捷支付，那么中间又涉及到了跨银行和微信支付之间的信息流动，断了直联之后清算机构参与了进来，这种情况下支付信息就从京东到了微信，从微信到了网联，从网联到了银行卡开户行。所以，不同的支付场景、支付工具、支付类型会形成不同的支付信息传递链路，也就形成了不同的支付信息流。

资金流就是资金的流动，我们知道支付的本质是货币的转移，无论是现金转移还是不同的电子货币在不同账户之间的转移。所以，资金流就是货币在支付活动中不同参与者之间的流动。

信息流和资金流不是孤立存在的，而是相互依存，资金的流动依赖信息流动，以信息流为依据；同样资金流动也是信息流动的必然结果，发生信息流动的目的就是推动资金的转移以完成最终的支付。

在分析信息流和资金流之前，我们要先明白哪些因素会影响信息流和资金流的模型，在什么场景下支付、用什么工具支付都会产生不同模型的信息流和资金流，通常情况有以下这些要素需要考虑。

支付场景：先明白要分析什么支付场景，是到线下超市买东西在pos机刷卡、是在电子商务平台上购买商品进行支付、是在支付应用内用银行卡往钱包里充值、是在银行柜台存取现金还是在银行APP上向另一张银行卡转账。搞明白了场景，才能搞明白这个场景里都会涉及哪些参与者、用到什么支付工具、发生怎样的信息交互和资金结算行为，这些资金是通过谁以什么样的清算模式进行划付的。

参与对象：理清楚要分析的支付场景中都会有哪些参与对象，他们都是什么角色，都会有什么样的行为和动作，例如个人、企业、支付机构、银行、清算机构还是央行等。例如我们在京东用微信支付进行付款，购买了一本书，那么这个支付活动中的参与者，或者这个支付场景下的参与者至少会涉及到：个人消费者、管理个人消费者货币以及商户收款结算的微信支付、撮合交易的电商平台京东、在平台上售卖图书的书店。更深一层又会涉及到进行跨行支付清算的清算机构以及人民银行和商业银行等。

分析清楚了参与对象，就明白了他们的角色是什么，个人是消费支付的哪一方，也就是出钱的哪一方，商家是卖东西提供商品的哪一方，微信是提供支付服务以及管理各类账户的哪一方，京东是提供交易场所的哪一方，网联是提供清算服务的哪一方，央行是提供最终机构间清算的哪一方，所以，大家都有各自的职能。

而信息的流动就是支付指令在这些参与者之间按照交易流程进行流动，从而让各自都可以发挥自己的职能，传递交易信息、用户信息、支付信息。

参与对象的账户：既然要分析资金流，那么就应该知道支付活动中所涉及到的资金有哪些。所谓资金无非就是现金、银行存款、支付账户存款等，在电子支付场景下它们以账户货币的形式存在，所以我们要分析清楚整个支付过程都会涉及到哪些种类的账户，以及这些货币在不同账户内的账务处理。还是以在京东购物去分析，这里会涉及到个人消费者的银行结算账户、京东在微信的商户收款账户、商家的银行结算账户、微信在人行的备付金账户等，不同参与对象的资产就存储在这些不同的账户当中，当发生支付信息流动时，货币也会在最终结算时在这些账户之间发生流动。

支付方式：支付离不开支付方式，就算在同一个支付场景下也会存在不同的支付方式，即使参与对象不变，但也会因为支付方式的不同而产生不同的信息流和资金流。例如在京东购物，可以用微信钱包支付、微信快捷支付、银行卡支付等支付方式。

支付类型：支付的信息流和资金流与支付类型也有关系，例如消费支付、转账、充值、提现、线下pos刷卡支付等。

清算模式：基于上述的一些影响因素，大致可以判断出来当前的支付活动会以什么样的清算模式完成最终的清算。我们将清算模式分成内部清算、跨机构清算两类。例如用微信零钱在线下饭馆扫码支付的最终清算就是内部清算，付款方的账户和收款方的账户都在微信内部，资金是在微信内部不同对象账户之间的流动。如果是用微信支付并选择银行卡支付，那么付款方的账户是在银行卡开户银行，收款方的账户是微信内的商户收款账户，商家结算提现时资金又会流转到商家的银行卡开户行，这里涉及到的账户种类就会更多一些，资金流会更长。

在上面的要素分析中，提到到了参与对象与参与账户两个要素，所以我们在分析信息流和资金流的时候就可以以对象为分析节点去分析，也可以以账户为分析节点去分析。

1）按对象分析信息流

每次支付活动中会有很多参与对象，例如去京东购物涉及到消费者、消费者银行卡开户银行、京东、京东商家、微信支付、网联、央行等参与对象，在分析信息流时就可以以这些对象为分析节点去分析，分析支付指令在他们之间的传递情况，从而得到了我们要的支付信息流结构图，如图1所示。

图1 按对象分析信息流

这里的信息是广义的信息，消费者的消费意愿和行为也认为是一种信息，上图涉及到的主要对象包括消费者、京东、微信支付，一般情况下我们站在京东的角度分析到支付机构层就够了，往往不需要再往上分析到人行备付金层的资金流动，除非我们站在支付机构的角度去分析。因此，分析到什么层级，什么颗粒度还要看具体的分析目的是什么，从而把信息流和资金流按照分析的目的分析清楚即可，而不是每次都一概而论的做全局分析。

2）按账户分析资金流

在分析资金流时依然可以按照对象的维度去分析，例如上述案例的资金流就是从消费者到微信，然后从微信到京东，这种方式并不去关注每个对象的的资金形式，当然消费者可以用消费者开户行替代，京东可以用京东结算账户开户行替代，如图2所示。

图2 按对象的资金流分析

其中更详细的资金存在形式是这样的，消费者的资金是“开户行的银行存款，也就是存储在银行的个人结算账户”，微信支付这边就是商户的支付账户，以及京东的银行企业结算账户，资金流就是在这些账户之间发生流动。如果再分析一层，就会到央行备付金账户，真正的资金流动实际上是发生在央行的备付金账户之间，所以一次支付会涉及到多层机构内相关的账户之间的账务处理，如图3所示。

图3 按账户角度进行资金流分析

3）通用分析模型

通过上面的分析，分析信息流和资金流的关键是支付指令在参与对象之间的传递，以及支付参与对象者的资金账户变化情况，因此可以将“参与对象”“资金账户”同时考虑，以此作为分析信息流和资金流的“模型”，如图4所示。

图4资金流和信息流分析的通用模型

图中包含了支付的参与对象和资金账户，信息在不同对象之间的传递路径，资金的流动路径。当对一个支付场景或者支付活动进行分析时，可以分以下几步：

第一步：分析出都有哪些参与对象，在图中标记出来，例如我们在京东购物用微信支付，支付方式选择银行卡，场景中涉及到的对象包括消费者、京东、京东商家、微信支付等。

第二步：涉及到哪些资金账户，这些资金账户都属于谁，例如第一步的案例中涉及到了消费者的开户行结算账户、微信支付的商户支付账户、商户的开户行结算账户等。

第三步：分析交易流程是怎么样的，在这个流程里这些参与者之间是如何进行信息交互的（支付指令传输），也就得到了我们要的信息流了。

第四步：将涉及的账户标记出来，看资金是从哪些账户流出，流入哪些账户的，就得到了我们的资金流了，也可以分析这些资金在账户所属的对象之间是如何流动的，也可以得到资金流。

总结：所有支付都是用户利用支付工具，通过信息化系统生成支付指令进行传递，最终实现了不同类型货币的转移，这就形成了我们要的信息流和资金流。其中支付工具就是银行卡、支票、网银支付等支付手段；信息化系统就是所谓的支付系统，而支付指令（纸质支付指令、电子支付指令）是支付信息的载体，支付指令的传递方式（邮寄，接口，文件，磁介质等）是信息流的形式。

所以，我们在分析信息流和资金流时，先逐一地分析清楚，其中的参与对象有哪些，使用的支付工具是什么，参与对象的账户种类有哪些，支付方式，支付类型，清算模式是什么，在那图5-4中标记出来就可以了。

案例：小宙在线下早点摊位用微信零钱扫码支付了10元早餐钱。

分析：案例中的参与对象是小宙、商家、微信支付、商家的银行开户行；支付方式是微信零钱支付；支付时的清算方式是“微信内部清算”，资金流在微信内部发生；商家提现的支付方式是“跨机构清算”，资金流在微信和商家开户银行之间发生，如图5所示。

图5 小宙买早餐的信息流和资金流

曾经收到过一个问题，关于如何设计资金管理系统和银企互联系统，有没有成熟的页面参考一下。当然了，每一个产品经理在接到需求以后，第一感觉就是“赶紧找一个成熟产品扫两眼”，这无可厚非。只不过实际是实际，理想还是要有的，万一找不到参考可看呢？我们还是需要一个可以兜底的技能，自己能够动手搞起来！并且将这个技能逐渐训练成一个固定的设计模式，这个模式可以应付所有的产品需求。

这个模式就是自己设计产品时稳定的设计习惯和方法的集合，简单的说就是：从拿到一个需求开始，会怎么做，直到产出产品方案。

一名产品经理的最基本的素养包括评估需求、分析业务、产品调研、需求分析、功能分析、方案设计……有些时候，一些产品人把产品设计中的产品调研完全放大成了“找个页面借鉴一下”。高启强想吃鱼找老默，但是我们想吃鱼，还得学会钓鱼；可能有的人说了，我有钱，可以去菜市场买，那就真的成咸鱼了。

做产品经理也是一样，所谓钓鱼能力，就是我们的基本专业素养和产品技能，如果没有这些基础能力，每次接到需求都想着找一个模板，看两个页面，这样下去职业发展还是非常危险的。业务场景、需求、产品方案等都是无限多的，无法枚举；但是设计方法或者说产品方法论是有限多的，是通用的。

什么是方法论呢，我把他理解成我们设计产品的“模式”以及在这个模式下的“工具箱”。比如梅西踢球喜欢用左脚，从右边路盘带过人，到中路左脚抽射。而我们设计产品的模式往往是“拿到一个需求，先分析业务场景和模式、再分析产品目标是什么，在该业务场景下这个目标如何通过产品实现”等，其中，如何分析业务场景呢？这时候就需要用到业务分析工具包了。

通过长期的工作训练和学习，我们不断强化这个过程，慢慢的形成了属于自己的产品设计模式，或者说“我们自己的产品方法论体系以及产品哲学”，当然，抄，也可以认为是一种哲学。

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

假如，我们第一感觉不是去看一个成熟的产品，而是，习惯了先自己动手搞起来，那一些列的问题就浮现出来：我们是一家什么公司，什么样的业务模式，当前的业务情况如何，怎么就突然想做一个资金管理系统呢?这个诉求是在什么时候、什么情况下、由谁提出来的呢?计划用这个系统干嘛呢？……

一系列的“？”浮现在脑子里，这就是一个成熟产品经理的职业习惯或者开始着手设计的开端，如果你还没有，那可能说明，你还没形成自己的产品设计模式。一切产品需求的产生都是有原因的、有目的，那什么是资金管理系统呢？什么又是银企互联呢？

如果我们在资金管理上足够专业，那可以轻松回答这个问题，如果我们并不懂什么是资金管理，那也不妨碍我们去设计这个系统。

如果无法直面回答这个问题，那就绕到问题的另一面：需求者想用这个系统干嘛？这就产生了“用户调研的需求”，如果能从用户口中了解他们想做这个系统的目的，那我们就有了答案。即使无法定义什么是资金管理系统，但是可以帮助用户做一个“系统”能够解决他的所有诉求，比如他们想查询对公户的账户余额因为登录网银太麻烦、他们想通过自己的系统下载到全部的账单、他们想……好了，我就给你们做一个银行账户余额查询功能，账单下载功能，但是我们公司有上百个账户啊，是不是我得做一个银行账户列表，那我怎么把我们公司的银行账户添加到系统里呢？

解决一个旧的问题，就会迎来一个新的问题，那我们就继续问我们的用户，继续想怎么给他们解决方案，最后得到了这样一个地图，我们的功能脑图就产生了，如图6所示。

图6 用户所想和产品实现

最后，把这个用户需要的和我们设计出来的功能的组合起了一个名字：银行综合管理平台，这时候我们发现，这就是资金管理系统。

一个系统不是孤立的，我们想要的这些功能是不是需要上下游系统的交互，传递数据，操作联动；比如资金结算数据是不是要依赖外部系统，谁来发起对外的付款，需不需要审核；付款状态是不是要回传给上游系统？如图7所示。

图7系统上下游的可能连接

其中还有很多细节需要分析，例如要变更银行账户信息怎么办呢？需要线上发起，线上审批么？怎么审批呢？如果公司用的办公软件是钉钉，那么审批是不是可以直接接入钉钉呢？这样的问答会产出业务流程方案，如图8所示。

图8系统上下游的更多连接关系

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

图9银企直联的功能分析

如果公司对公户开在招商银行，那么去哪里找一下招商银行的银企直联接口文档研究研究？最后，很多问题都可以转换成可落地的执行步骤。就比如，账单如何下载呢？是不是需要一个任务模块，每日凌晨2点去挨个下载银行账户的上一日账单呢？将账单存储起来，然后，在后台可以看到账单列表，并且可以点击操作下载到本地。更细化的功能分析就有了，如图10所示。

图10银企直联的账单管理功能分析

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

图11账单下载记录页面

账单下载下来，是不是需要一个页面查看账单，并且可以手动下载到本地，如果账单推送到资金管理系统失败了，是不是可以手动触发推送？这样就可以分析得到账单管理的页面设计，如图12所示。

图12账单管理页面

如果已经下载成功了，再次触发下载账单，是要覆盖原来的账单么？如果已经推送到资金管理中心呢？再次下载以及再次推送可不可以？这样分析，我们的产品功能逻辑就产生了。如图13所示。

图13账单管理的功能逻辑

经过一轮一轮的分析、拆解、结合业务诉求的研究，看了银企接口之后，我们也就大致可以分析出来银企互联系统需要哪些东西，能够做什么功能，需不需要后台页面展示，需不需要配置化功能，数据查询功能，以及需要哪些操作。这样设计出来的系统可能功能还不完整，但却足够好用，毕竟按照用户想要的，我们都一一实现了。对一个产品来说，能用是及格的，好用就是最高的评价。

因此，我们要刻意训练自己的产品设计模式，上述的设计模式，适用于所有产品的设计，只要静下心来，任何需求都能做出来。产品是设计出来的，而设计产品是一个产品经理的核心职能；参考借鉴没任何问题，但，也不要忘了，我们可以学会完全“自研”。而，自研，离不开那些属于我们自己的“产品设计模式”和围绕模式打造的“工具包”，成长和学习的目的是什么，就是沉淀我们的设计模式和工具包，并在工作中不断强化。

产品不是孤立存在的，而是具有行业背景、所在公司背景、以及设计团队等多因素共同作用，因此可以站在行业、企业、团队等全局视野上去把握产品设计也是一项重要的能力。我们就以家政为例，从宏观上去认识一个行业和企业的全业务体系，然后再从微观上去精通该环境下的产品体系，在此基础上搞懂支付的全链路，该分析模型把“家政”换成另一个行业依然可以。

家政一般指家政服务，包括月嫂、育儿嫂、保姆、保洁等业务，家政服务的服务人员需要上门服务，服务一般按照小时、天、月、年等为服务周期签订服务合同，以及支付相关的服务费用。其中：

家政行业的供需关系是这样的，核心主体是“劳动者”，劳动者是直接提供家政服务的服务人员，而提供家政服务（商品）的平台主要分小型家政公司、垂直的大型家政平台、综合平台中的家政业务模块等几类，消费者有个人消费者也有企业消费者，如图14所示。

图14 家政行业供需关系

一个典型的垂直家政平台，一般是通过互联网模式向消费者提供家政服务，主要会涉及到上述的月嫂、育儿嫂、保姆和保洁等品类。其业务模式也会涉及“自营业务、经纪业务、平台业务、SaaS业务、培训业务”等等，随着企业的发展，会围绕“家政”打造一个更大更完整的服务生态，如图15所示。

图15 垂直家政平台的业务架构

整个家政平台的全业务流可以分为“客户、商家、交易”三个维度去分析，这三个业务流组合成了一个完整的家政业务模型，其中客户流获得客户，商家流招募商户入驻，交易流实现双方交易的匹配和履约，整个业务流如图16所示。

图16 家政平台全业务流

客户流是消费端的流程，要从客户是怎么来到平台的，最终又是怎么成为消费用户的脉络去看，同样，这个思维也适合任何一个交易平台，如图17是客户从线索到下单的过程。

图17 客户流

商家流是供给端的流程，我们要从招募商家到上线服务去梳理。从招商线索、培训、签约、上线再到提供服务的全商家流如图18所示。

图18 商家流

交易流是整个平台最核心的流程，也是支付设计的核心环节，主要涉及到用户支付、匹配、上门服务履约、商家结算、售后服务等环节，如图19所示。

图19 交易流

过以上分析，我们基本就掌握了一家家政公司的全局业务流程，然后我们再去研究和思考这样一个问题“什么样的产品体系可以支撑这样的流程？”。

理清楚了行业和业务，接下来就是多维度规划一个企业的全局产品体系，对于家政平台来说，依托于前述的业务分析，我们可以设计出如图20所示的产品体系。

图20 全局产品体系

图中客户产品环节涉及到了客户的线索及转化，其中又包含线索体系、用户端产品体系、用户管理等模块；商家产品环节实现商家的线索及招商管理，包含线索体系及商家端产品体系、商家管理等模块；交易产品环节实现用户从下单到支付、从匹配到服务履约、从商家结算到售后服务等内部信息化系统体系，在交易产品线又包含了交易、支付、清结算、财务处理、财务等各产品组，因此，我们又可以去深挖每一个更细的产品环节，以形成对它的清晰认识。

实际工作中，又可能衍生出更多的产品环节来，比如“基础产品线、商业产品线、数据产品线、平台产品线、saas产品线、培训产品线”等，来适应变化的市场环境和公司战略的变化，产品是为业务服务的，为企业商业模式服务的，为战略服务的，只有懂业务，懂商业模式，懂战略，才能懂产品。

完成了对整个产品体系的分析和洞察以后，就可以思考整个产品体系的架构设计，思考全局的产品架构是怎么样系统性结合在一起的，无论是从产品功能视角、业务划分视角、还是其他视角，最核心的一条就是可以辅助我们看到产品的全局，如图21所示。

图21 全局产品架构图

其中，还可以对某个模块做细化架构，比如后台支撑体系，后台产品体系为内部员工提供运营赋能，所以更关注大家需要怎么干活、想怎么干活的后台能力的构建，其架构如图22所示。

图22 运营后台产品架构

又比如业务服务系统体系，业务服务层是系统服务处理集群，是平台全部能力的分组和集合，为各端和内部处理提供基础的服务端处理能力，其产品架构如图23所示。

图23 服务层产品架构

中台服务能力与该层在能力维度划分上具有相似性，在建设理念上存在差异，中台更多是通用能力的抽象，标准化的服务全部业务线。而某业务线的服务层更多是服务该业务线，具有明显的业务线特征。

最后在产品把握上还要下沉到产品细节上，可以细致入微到页面级别、到字段级别、到一个个的逻辑细节的级别，就比如每个系统的每一个页面，你都知道么？每一张表，你都知道么？虽然很难，但是并不是不可能。

当我们掌握了一个产品生态的全部要素时，才会形成一个化学反应：哦，原来如此，我们会明白原来任何一个决策、任何一次运行，都有迹可循。

至此，我们就建立了产品的全局视野，也是对自我产品能力的一次最好水准的升华。在任何一家企业都完成这样一次全局体系的研究和认知的沉淀，也不枉本次的工作经历，即使是螺丝钉，也要做一个有大脑的螺丝钉，一个遨游过星辰大海的螺丝钉。

产品需要依赖一个模式做出来，比如产研的流程，大家的合作模式等等一些列的规范问题，所以做产品需要关注规范，怎么提需求，怎么评审需求，怎么写文档，怎么评估上线效果等一些列实施落地能力，如图24是一个项目管理框架。

图24 项目管理方法

产品管理最核心的一环就是需求的管理，怎么收集需求，怎么评估需求，怎么安排需求版本，怎么与需求方协同，整个需求管理流程如图5-25所示。

图25 需求管理方法

一款产品或者一个需求的生命周期就像一条流水线一样，遵循一个既定的流程，从需求搜集到产品设计，再到研发测试，直至最终完成上线商用。对于产品经理来说这是一个再也熟悉不过的过程了，如图26是一个产研流程模型。

图26 产研流程模型

当我们在过往的工作经验里，都可以做到如上的全局、如上的深度、如上的颗粒度去复盘和总结每一段工作经历，将受益匪浅，将一次次迭代自己的“产品方法论”和“产品哲学”如果做不到这一点，一定会有缺憾。

那么在这样一个宏大的知识体系之上，能不能更近一步，抽象出一个非常通用的，摒弃一切行业属性和特点的支付通用架构出来，反过来以这个通用架构为基础又可以推演和适应各行、各业企业的支付建设架构。如此，我们将具备一个核心能力，一个掌握了支付产品设计的底层架构能力，如图27所示。

图27 通用支付体系架构图

专栏作家

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

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

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