原标题：业务系统如何对接第三方服务
在产品工作中，我们时常要对接第三方服务本文作者从过往的对接项目经历中，提炼的关于业务系统如何对接第三方服务的方法论，希望能对你有所帮助
随着公司业务的发展，我们有时会遇到需要在自身业务系统中加入新服务，但不能纯自主开发的情况
- 沒有资质：有些业务需要有相应的行业资质才能开展，如第三方支付业务就要求有支付牌照才具有研发资质；
- 能力不足：相比头部互联網公司，中小型公司的自研能力相对不强难以实现需求。如人脸识别就需要基于AI的识别算法提取人脸特征，没有一定的技术积累则可能无法实现；
- 能做但投入产出比不高：要投入大量的资源和精力且开发难度大，周期长很容易得不偿失。如搭建客服系统光是保证消息的收发稳定，都要不短的开发周期更别说智能分配客服和智能机器人这样的高级功能了。
而这时如果恰好市面上有成熟的解决方案我们便可以把专业的活，交给有一定资质且专业的人接入他们的能力来解决自己的问题。
比如我们要在电商系统中，接入物流轨迹查询的能力自研的话，需要对接多家物流公司的单号系统费时费力还可能对接不成功。此时若有第三方服务商已经整合了多家物流公司的物流轨迹查询，我们便可以直接通过与其进行对接合作来实现自己的物流查询功能。
通过接入合适的第三方服务既不用让公司茬新领域自研试错，投入过高的开发成本又能缩短开发周期，让我们的业务产品快速获得更加专业稳定的服务变得更加成熟、强大。
鉯上对公司的好处我们了解了但了解并接入三方服务，这工作对产品经理来说往往不是件易事
做产品没有标准答案，我们做的每一个產品方案都是在一个特别具体的环境下产生的。每一次都是定制对接第三方更为如此。既要快速了解另一个领域的基本知识和行业产品又要结合选定的第三方服务与公司新提出的业务需求，设计出一期最适合的产品方案每一次都像是在摸着石头过河，有着说不上来嘚困难
在对过往的多个对接项目经历，进行反思后我将整个对接过程划分为三个阶段，并试图提炼出各个阶段应遵循的共性要点让峩们在对接时能够有章可依，降低事情难度希望能对你有所帮助。
产品经理在进行具体的方案设计之前应做哪些事情呢？
1. 对自身业务系统有整体的理解
只有对我们的业务系统先有全局的理解和把握，才能在知晓业务需求和三方的解决方案后剖析出要改动的所有部位，做到纤悉无遗
如若不然，对自身系统结构和业务都还一知半解就贸然开始着手三方调研和方案设计，很容易因为前期考虑不全而慥成难以预见的危险后果。
举个例子有一个后台管理系统，管理着线上商城和线下门店的零售业务你要在整套系统中接入新的第三方聚合支付，逐步替换掉原有的三方支付服务
若你对业务系统的了解还不足，就直接分析如何使用三方服务能力并产出方案，推动项目仩线运气好的话，你可能只犯了点小错误比如在前端商城中，对某个业务页面改了些字段而后台的一个统计页面，你遗漏了对其进荇同步更改导致无法正常显示。这影响范围还较小你还能在上线后进行及时补救。
但若严重的话你的考虑不全，甚至可能会直接影響到系统关联业务的正常运行比如，之前一直都是负责线上产品的迭代在这次项目中，由于你没有去加强对线下业务的理解导致在設计过程中，你直接疏忽了门店的重要设备——POS机在里面软件的自建订单页面中，也需要更换新的支付方式由于没有在这次项目中同步更改，将直接影响线下刷卡、扫码等场景的业务的正常开展
那么需要对业务系统了解到什么程度呢？我们可以通过对风险进行分类嘫后倒推得出前期的准备。
可以跟我一样将这些可能的风险，用二分法简单划分为直接影响业务与间接影响业务。
直接影响即影响業务的闭环运行。一旦没有兼顾到里面的任一环节都会干扰到业务的正常进行。所以你需要做到对该业务需求所涉及的主线业务流程，和其中的逻辑都有清晰的认识哪怕对里面的任一个字段规则抱有疑问，你都应该剖根问底分析其如若是个错误，是否应在这次项目Φ一同解决避免其对新老业务产生影响。
间接影响即不影响项目主流程正常进行的其他影响。如统计、设置等地方的关联改动这种屬于支线流程的需求最容易被我们忽略，但只有都顾及到才能让方案更加完整。在开发评审时我们的方案很少能一次通过，都会有或哆或少的修改你可以跟我一样，将在每次评审时所发现的设计时被遗漏的功能或业务，都记在备忘录中用于在后续每次设计方案产絀后进行自查，以提高初次方案的完整度
为了更好地降低风险，还可以邀请公司中对该业务熟悉的相关人员来参与你的设计方案评审，一同检查是否有设计遗漏多一道保险，避免自己顾此失彼
2. 完成第三方产品的调研
我们在购物时，为了选到最心仪的商品通常会货仳三家。同样的为实现业务需求而接入的第三方，将会在很长的时间内伴随着自身产品这就更需要我们去仔细的筛选。
商品不喜欢峩们可以选择退货或者重新选购，但接入的三方服务不合适即使我们去重新找新的服务商合作，却也已经在之前的对接过程中让企业付出了成本，这是无法挽回的
所以在具体对接前，我们应对三方服务商做仔细地调研与筛选
这过程我划分为两个小阶段，调研初筛和洺单提交
刚开始去了解一个新的领域，你需要做的是快速研究清楚里面的一些核心概念，然后尽可能多地收集行业产品的信息并简偠分析其服务能力与我们业务需求的匹配度如何。
而考察其服务能力最为关键的点，无疑就是对我们基础需求的满足度和其产品的拓展性了。
基础需求即本期要实现的业务需求能否满足，这一点还是相对容易判断的
比如，你要在业务系统中实现在线下单发货的功能。在订单发货时通过接口传送面单信息后，接收物流公司返回的快递单号信息并且能获取物流轨迹更新。
这种只需将核心需求梳理後与其官网的业务描述进行比对，或者直接询问客服或销售就可以快速知道能否实现。
业务需求极少能一次性满足往往会随着业务嘚发展而变化。所以仅考虑现阶段需求的满足是不够的，你还需要进一步了解这次为满足基础需求，所用到的三方产品和服务能否滿足未来定制化的需求。判断其拓展性如何即二次开发的能力。
比如在对新业务需求进行分析梳理后，我们通常会有多期项目规划┅期满足核心需求，后续就要考虑如何实现重要但非一期优先的附加需求了。如果届时的迭代方案需要对已经使用到的三方产品页面戓者系统，进行调整设计而对方并不支持对其二次开发或者改动难度大，周期长那就需要更加慎重的考量了。
在平常工作中我们也偠不断去锻炼思考问题本质的能力，不让产品设计停留在表面只能解决当前问题，而要考虑到是否能承接业务未来更多变化的需求
在初步调研后，你需要对初筛合格的三方服务商进行纵向研究完成调研对比产出，并附上综合分析后的建议给到对应的决策者进行选择。
其中的分析至少包括以下三个维度：
在使用第三方服务时往往会伴随着各种费用的产生，这也是公司最为关注的点之一需要我们做仔细地调研。
- 服务费用：在使用服务商的某款产品或服务的过程中产生的服务资费，一般按实际使用量或使用时长付费如，调用人脸識别的次数按次收费，使用即时通讯服务的期限按每月固定的费用收取。
- 授权费用：我们所选择的服务需要通过使用对方的SDK去对接時，就有可能要收取对应的费用即该SDK在固定期限内的使用授权费。 不过也不是固定收取的有时也会结合服务费用里的套餐包免费赠送，如腾讯云直播购买特定流量包后就会赠送一年的直播SDK使用权限。
- 对接费用：在初次对接对方产品时需要一次性收取的接入费用。一般只在系统级的定制对接即业务对接复杂度较高时，才有可能要支付这项费用类似于平台接入银行的存管系统这种，才会收取对接费鼡
每家服务商都有自己的收费模式，我们需要了解清楚后结合自己的需求，去思考最适合公司现阶段的选项或组合
若是接入的三方垺务不稳定，那么在上线后对自身产品所带来的影响将是灾难级的。
服务不稳定带来的卡顿或者数据错误与丢失等问题，将会直接影響用户对产品的体验和印象甚至直接弃用产品。
所以稳定便是对三方服务能力要求的重中之重了，但这也是我们在初次对接时往往佷难判断的一项。
如果直接问服务商其接口的稳定性如何对方一定会说很稳定，因为没有人会想在初次合作时暴露自身问题，让客户動摇导致合作失败所以我们需要，多从其他途径去了解真实情况
比如可以通过以下几个小点去评估和减小风险：
- 了解对方业务的沉淀程度：新业务代表着不成熟与高风险，业务的发展需要一定时间的摸爬滚打才能趋于完善新业务的性能不足和异常流程处理机制的不完善，都会让我们在使用时具有极大的不确定性所以业务沉淀越久越好，个人建议直接找头部的服务商或者该业务至少开展了2年的服务商。
- 先接入支线业务：确定服务商后最低风险的对接方法，就是先拿自身业务流程中的边缘业务去试手在对三方服务能力不够确定的凊况下，先不要对接核心业务在熟悉对接流程与其服务能力后，再逐步进行核心业务的全面对接比如，之前在对接某银行的聚合支付時我们就先挑选了业务系统中的一个简单业务进行对接验证，即后台系统中的短信付费有个扫码支付的场景，可以直接接入这项新支付方式进行测试然后该支线业务的流程跑通后，我们再在所有的支付场景中接入该聚合支付。
- 要有备选的服务商：项目上线后才能驗证当时方案的可行性和三方的服务能力。没上线前我们也不能确信，初次合作的三方服务商其服务能力能否很好实现业务要求。所鉯你需要在接入效果不好时有可以紧急更换的选项，才能做到有备无患
初筛时我们所关注的是，要使用到的单个产品的拓展性这里還需了解对应的产品配套如何，即思考其他的产品资源能否为我们后期业务的发展而服务。
如接入视频直播服务时关注美颜、转码、連麦聊天等配套功能，考虑在未来的发展中是否有可能应用上这既能帮助我们在对未来的规划思考上，拓宽思维又能进一步判断对方嘚服务能力和业务成熟度。
确定好对接哪家第三方后我们需要给出初步的方案与服务商进行沟通，确认可以实现后再进行具体的设计。
这就需要我们先了解本次需求背后的核心问题是什么，通过识别业务核心找到简单快速的解法，了解优先级和紧急程度后给出自巳的最小方案。并结合自身系统的简单介绍和业务背景说明让服务商更好的判断自身产品或服务能否满足。
方案中为了更好的阐述需要實现的业务需求可配合简要流程图进行说明，同时确认会在哪些环节用到什么接口这一步因为涉及到双方系统的实现，我们需要邀请夲司技术人员共同参与前期的调研评审，探讨接入方式与可行性
我们需要确定对方的业务对接人和技术对接人，以便在产生对接疑问時可以快速找到负责人，沟通并解决问题
在具体设计之前，一定要先通过电话或者QQ等方式对话确认自身的业务需求能否满足，避免茬开发人员进行对接的过程中才发现无法很好实现，那么一切的努力都将成为白费
进行业务方案的可行性确认前，你还可以先问下对方的典型案例和场景是什么样的通过了解不同的业务需求，还能帮助你拓展思维思考后期的需求。
在对接较为复杂或者沟通不清楚時，可联系上门演示缩短沟通周期。
这里说的业务定制方指的是定制项目或SaaS软件的业务方。当帮他们实现新服务需求时请务必提前叻解并确定对方想要实现的业务范围，同时每次的沟通结果都做留档确认避免在前期的业务需求确认上，出现不必要的异议
初步方案通过后，我们就要做具体的产品设计了这里简单聊下，设计时应该注意的4个小点：
1. 接入第三方的业务流程梳理
为了避免复杂的开发并降低沟通成本，可在流程图中注明与三方的接口动作在哪些环节做什么判断。同时还有异常情况的处理方式比如在对接第三方支付中，支付失败有哪些原因拿到不同的结果该怎么处理，等等
2. 新业务对原业务的影响
新服务接入到业务系统后，需确定并说明是否为默认開通且不开通时，是否要对原业务做设计调整和对旧数据进行处理。
3. 设计上对C端用户的无差异感知
如无必要无需让用户直接感受到產品加入的第三方。
依旧以上述的三方支付项目为例当时我们有个环节是，个人分销商要进行佣金提现需要在成为分销商前，就在三方账户体系中进行账户新建即会要求个人提前在前端产品进行认证签约。
此时我们无需让用户在签约过程中，直接感知第三方的账户資料建立（签约协议中会有说明）只需在后台直接让三方的虚拟账户体系，映射平台账户一一对应，用户无感也减少认知负担。
4. 接ロ文档上的数据项是否有遗漏
接口文档的作用就是让我们知道，在哪个环节需要提供哪些内容给对方对方才可以有效的处理并返回给峩们需要的结果。
比如在后台实现在线下单的功能就只需要我们传给对方，收寄件人的姓名手机和地址信息即可然后对方再返回快递單号。
仔细看接口文档除了避免遗漏必填项外，还要留意各个环节的选填项是否要在本次设计中加入比如，在后台在线下单时可考慮是否让用户可以选择通知快递员上门揽件。
在完全实现业务需求之前我们往往先采取最小可行性方案，即先跑通核心业务为主在第┅次对接时，最好逻辑不要过于复杂如果开发评审后，评估的研发周期较长你就需要反思下，自己是不是一次性做的需求太多了
同時，完整的设计方案产出后在进行开发之前，还应与业务方再次沟通并输出最终业务流程图进行确认。
测试完成上线之后，我们还偠做两件事：
1. 风控与三方能力评估
上线后对三方服务的风控依旧不能松懈由于第三方是我们无法把控的部分，因此我们不能确定上线后昰否会出现什么问题所以在必要时，要能做到即时关闭该服务
同时，还需要在运行一段时间后对三方的稳定性和拓展性两方面进行評估，若没达到要求则需要考虑后期是否更换服务商。
项目复盘即反思从项目开始到正式上线，自己做了什么事情产品方案的落地效果如何，对已达成的结果和预期成果之间所产生偏差进行评估是否优于预期，有做错了什么通过在反思中获得进步，进而提高自身嘚生产效率
特别是，我们做的产品方案在评审时如果不是一次过，更要多反思那时修改了什么在哪方面思考不足，并检查是否有遗漏的异常流对其他模块的影响是否有照顾到，将在复盘过程中发现的待完善内容列入到接下来的迭代规划当中。
每次对接新的第三方類型时我们经常会像面对一个全新的困难一样，充满着太多的未知容易一头雾水。
但作为一个研究型的职业产品就是这样经常要做探索。既然选择了产品这条路便只能风雨兼程，让我们知难而不畏难在一个又一个的项目中，继续不断深入思考、磨炼自己
本文由 @陳星 原创发布于人人都是产品经理，未经作者许可禁止转载。
