端产品如何做产品详细方案设计

　　本文作者详细的描述了，一个产品经理在做B端（后端）的详细的方案设计时的思考以及工作的流程，enjoy
　　一、前言
　　有一天被老板拉进了一个微信群，上游渠道的对接群，然后就说，和这个上游对接一下，把两边的系统打通。老板的需求就这么一句话，两边系统需要打通，而两个企业系统之间对接起来往往需要通过接口的形式，所以首先需要的看对方给出的接口文档。做B端的产品往往对外输出产品的时候也是以接口的形式对外输出。
　　二、系统流程设计
　　在和对方的接触过程中，发现对方是一个支付公司，老板的想法是在原有系统的支付渠道中加一条支付通道，加强系统的容灾能力。原本系统是只有单渠道在允许，一旦上游出现问题，那么我们系统就无法完成支付，造成系统的瘫痪。
　　1。原有流程整理
　　在进行新的方案流程设计之前，如果这个系统之前不是你经手的，或者是你很久之前做的，经过了几个版本的迭代，也不太记得具体的流程了。最好首选要做的是先梳理一下现有的系统中逻辑，只有清楚了现有系统中的逻辑才能实现以最小代价完成系统的改造，并且在上线之后不会有太大的后遗症出现。
　　那么先来看一下整理的现有的系统流程图。我采用的也是常用的泳道图，可以清晰的看到每个模块的处理情况。
　　给大家稍微的解释一下原来的整体流程：
　　这是自助零售系统的充值业务，整个流程需要经过优惠管理模块、订单管理模式、账户管理模块。具体流程主要以下几点：
　　用户在前端点击充值，后端接收请求后会根据系统配置判断改用户是否有充值优惠，如果有充值优惠则返回充值优惠套餐给用户选择，系统没有配置单的优惠套餐则选择系统默认套餐。
　　用户选择充值金额后，请求后端订单管理模块，会创建充值订单。根据用户的支付结果返回给前端，然后前端展示相应的页面。
　　如果用户充值成功，会通知账户管理模块，账户管理模块会根据充值数量，对应的用户上增加相关的数量。还会判断存在代理商分润情况，如果有分润则对应的代理商账户也会增加分润值。
　　2。问题思考
　　由于第一版系统设计的是单渠道模式，所以在创建订单时直接是往上游（即支付公司）上送交易数据，思考了以下几点问题：
　　如果需要新增一条渠道，需要如何进行新增，创建订单之前添加还是创建订单之后添加？
　　是否需要单独的将渠道管理模块独立管理？
　　用户使用的前端页面是否需要相应的修改，改动对于用户是否无感知？
　　3。新流程设计
　　带着以上几个问题，对系统的充值流程进行了改造，具体请看下图：
　　根据上图解释对上面的问题进行一一的解释：
　　1）如何新增渠道问题
　　采用了支付系统中常见的支付路由管理的办法，对渠道进行新增，这样对于系统而言，兼容性比较强，不需要每次新增渠道时，前端页面需要相应的配合改造，同时也解决了第三个问题，采用这个模式用户是无感的，整个流程仅仅只是新增了支付路由的形式。还有就是方便运营人员切换渠道，当上游不支持公司业务或与上游解约时，不需要上线，通过配置形式就可以完成渠道的切换。
　　此外制作路由最主要的目的是为公司节约成本，每次交易尽可能的走最低费率的渠道。
　　2）为什么路由模块是添加在创建订单之后呢
　　如果在创建订单前添加的话，首先用户在查询订单时候是查不到结果的，第二运营人员在相应的订单查询页面也是查不到相关数据，就算有单独创建失败订单查询页面（即单独查询系统创建失败的位置），也不是很方便的进行查询。
　　3）改动对于用户是否无感知
　　系统中新增了支付路由选择，渠道选择是在系统中完成的，所以用户是在体验上是完全无感知的。由于整体的流程图放置不下路由管理属性，所以将路由规则单独制作一张流程进行展示：
　　三、了解接口文档参数信息
　　在设计完业务流程之后需要对系统关键字段进行设计，关键字段的设计包含着两方面，第一是涉及到对接口的输出，可以给开发输出关键的字段给到对应的接口文档中。第二是在运用在运营页面上，所需要的字段内容。本文以支付宝接口为例，接口地址：https：docs。open。alipay。comapi1alipay。trade。pay。
　　先设计对外接口的输出部分，这里就以大家所熟知的支付宝的支付接口为例：这里例子是统一收单交易支付接口（其实就是常见的出示付款码）。先来看一下请求参数部分，分为公共请求参数和请求参数。
　　1。公共参数信息
　　公众参数部分作为产品的角度看，不需要太多的关注，都是固定值比较多。前期在上线之前之前需要准备好相关的参数给给开发即可，例如下图中的appid，这个需要去支付宝那边申请后会报备下来一个appid，可以说是代表企业身份的唯一标识。其他的秘钥这些参数由开发生成即可。
　　2。请求参数
　　我们的核心重点一般是关注在请求参数上，请求参数是一些变量值，有可能是在对外的接口文档中所需要，也有可能在运营页面中需要。例如：订单查询页面的字段就需要与接口请求参数保持一致，才能准确的查询出订单的详情的信息。
　　上图截取了请求参数的部分，其中必选参数则必须要往支付宝上送的参数值，可选参数则根据实际情况上送，如果是对外包装成产品的话，这部分参数需要在对外接口中是否需要商户端传输。例如订单标题，买家支付宝ID、支付宝授权码、订单金额等，如果仅是自身业务使用则在业务中需要获取到相关的参数值往支付宝接口中上送即可。
　　四、接口文档关键字段设计
　　1。新增接口关键字段说明
　　这里是以对外输出接口为主要设计，所以在写文档时，建议开发对外接口必填参数包含但不限于商户订单（这个是由商户上传的，可与支付宝的生成规则可不同，系统中订单生成规则尽量使用同一套，系统兼容性更强一些）、支付场景、支付宝授权码、订单标题、支付宝用户id、商户签约账号、订单金额，选填参数包括但不限于销售产品码、优惠金额、订单描述等。
　　根据以上分析，生成下列的关键字段信息描述如下（仅列举了部分），这些关键字段同样适用于订单查询页面。
　　2。存量接口关键字段说明
　　上图列举的关键字段其实是针对于全新的接口对接，如果是在现有的接口上进行的兼容的话，那么就需要先比对一下现有的字段是否能够满足所对接接口的字段要求，具体案例如下：
　　五、运营页面设计
　　对于B端（后端）来说，管理后台的页面虽然是比较注重的功能，但是对于使用体验上也得有一定的要求才行，运营人员使用起来需要方便快捷。
　　针对此次系统改造页面设计包括订单查询页面优化（因为系统已有订单查询页面，如无则需要新增）、支付路由配置页面新增。其中支付路由页面包括，常规支付路由配置页面，个性化支付路由配置页面，银行配置页面等。
　　本文以常规支付路由配置页面举例，改动对于用户是否无感知。
　　1。页面字段设计
　　根据支付路由的流程设计到字段，后台的操作页面与平时看到C端的页面有所不同，基本都是由表格构成，先将页面需要展示核心的关键字段进行设计，方便后续的原型制作时，不会空想，此外帮助开发刚加的了解业务内容，避免开发在设计数据库字段与实际使用不相符情况。
　　具体关键字段如下图所示，里面的字段是随机的列举，如有错误请见谅：
　　2。状态机图
　　状态流程说明：创建完后进入到待审核状态，审核通过直接启用，审核拒绝则变更为审核不通过，审核不通过可以重新提交，进行待审核，启用与禁用下可以相互转换。
　　3。页面设计
　　操作按钮包括查询、新增、下载、审核、修改、删除。
　　字段说明：成功率、费率在初始阶段仅作为参考作用，成功率每日进行更新统计，这两个字段后期可加入路由选择权重判断，其余的参考关键字段设计表。
　　六、总结
　　本文详细的描述了一个产品经理在做B端（后端）的详细的方案设计时的思考以及工作的流程。
　　总结归纳的步骤如下：
　　系统流程梳理：输出对应的业务流程图。
　　查阅接口文档：查看现有系统的字段是否可以复用。
　　接口关键字段设计：定义对外的接口文档关键字段。
　　运营功能页面设计：设计运营后台的操作功能。
　　最后感谢大家阅读完本文，如有写的不对的地方，请批评指正错误，欢迎大家一起来探讨。