三方对接心路历程
Table of contents
No headings in the article.
从业这几年,因业务的需要,对接过不少三方,有大公司也有小公司,其中感受颇多,这里回顾以及总结一下。
初入职场即与某大型X公司进行业务对接,其实很简单,我只需将公司内部数据提供一个接口给对方调用即可,然而没想到跟我对接的人疑似为对方公司的运营类人员,我按照对方要求完成接口开发,并顺利提供给对方使用,后来对方找到我们说是还需要接口提供其它字段云云,后因公司之间的一些博弈不了了之了,这件事给我的印象是: 对接首先要保证按需要完成,但如果能站在对方角度,提前发现,对接一些问题,想必也会减少不少麻烦。
后与大型跨国S公司进行业务对接,真颠覆了我对大公司的想象:文档给的是有,但是服务器接口不通,接口定义不完整,看起来像是基于某某语言的接口定义,微信、电话、邮件沟通,真是巨慢,骨子里透露着大公司的傲慢,我虽算不是特别的急性子,但也是相当之恼火,其实要做的事情也没多复杂,我只有一个开发与我进行完成时间段内的对接即可,或者提供一个完整、清晰的技术文档,然而这只是我一厢情愿的想法罢了。事情的收尾也很奇葩,因双方业务调整,暂停对接了,算是白忙活了。
在现在这家公司跟大型P金融公司对接金融系统,对方给的文档和技术资料都相对清晰,跟我进行技术对接的对方的一个外包人员,进行调试的时候还挺配合,但是当遇到突发问题的时候,就比较被动,首先要将问题产生的场景,数据报文以邮件形式给到外包人员,外包人员审阅发现无法解决,再将邮件转发给后台都是(核心系统开发),通常等待的时是都是以小时计算的。对方的技术文档是以doc文件给到,更新难免不及时,许多时候都需要电话沟通对照着文档确认一些技术细节及疑问。当然,毕竟是老版企业,对接后系统稳定性相当高。
后因公司业务发展,与代付公司进行业务对接,对方给到了技术文档及加密算法的java版demo,我仔细研究文档后发现有几处纰漏,多次沟通后改动了几个版本,也是那种电话沟通接照文档来的,后将java版demo转成golang过程中有一些小问题,也跟对方一一确认并解决,之后调度速度挺快,因为接口也不多,一周内就做完了,然后,公司因有其它更重要的业务,暂停了这个项目,后又不了了之了……(我可是用了自己的银行卡做了代付验证,还解绑不了,心在滴血)
与小贷P公司对接,其实也不算对接,是将离职同事写的java服务转成golang,然而文档并不够清晰,由于之前对接也存在着一些问题,文档资料比较混乱,也不清楚最新的版本,只能硬着头皮跟对方开发打电话讨论、修改达成一致,上线过程还算顺利,只是对方系统不够稳定,有几次比较大的宕机,对我方系统影响较大,业务上表的索引设计有问题,没有保证幂等,也是双方对文档的理解存在一些偏差。这次给我的教训是:1. 永远不要相信对接方的接口 2. 细节是魔鬼,一定要抓清楚问题 3. 对于理解上的偏差,尝试用example来解析或消除(说起来都是泪)
与小贷W公司对接,这个更奇怪,接口文档居然要我方来定,没办法,只好在石墨上建立共享文档,一个接口一个接口进行确认。在接口对接阶段,对方有三到5个开发同时与我对接,因为对方公司是按接口分任务的,果然人力充足,然后这只是灾难的开始。每个人对文档的理解竟然不一样,有的想要换另一种写法,有的想要字段写错了,有的字符串中混入了中文字符,加密算法在不同编程语言间的描述区别问题等等。所以,没办法,所有不按照文档来的,都会导致工期延后。这次给我的教训是:文档是个好东西,它是一个协议,这份协议是跟编程语言无关的,最好要有示例,如此,双方都能省心。
跟F公司对接,对方直接告诉我,我要对接的这套系统已经转了好几手,现在在他手里,很多地方也不是很清楚,文档是有的,技术看起来比较老旧,签名客户端只有windows版本(无奈,只能弄一台windows机器了),没有网络拓扑图,配置说明也比较老旧,对接过程磕磕绊绊,服务器与签名客户端是两拨人,回消息比较慢,好的时候以小时计,不好的时候以天计,最后终于完成对接,发现数据唯一性跟当初对接时描述还不一样…… 此处教训是:一定一定要跟想办法跟核心开发人员对接,一定一定想方设法拿到最准确文档,虽然我们是甲方,但在对接中,从来都感觉是乙方,由此,我养成了使用敬语的习惯,话说修养真的是好。
还有其它小的、印象不深的第三方对接,虽然每个公司都有各种各样的问题,但是作为从业人员,对接人员代表的是公司的形象,说话做事定当需要审慎的态度,无论甲方乙方,都需要更加严格的要求自己,有问题势必先要自查,以数据说话,毕竟,口碑就是这么建立起来的,信任也是这样累加的。
分享经历,以此共勉。