当我们自己首先了解到对方系统大致的内容后，我们就需要结合自己前期了解到的需求，有针对性的整理出可能存在的问题，切勿漫无目的的去了解。
当我们有了自己的初步判断后，紧接着就需要进行进一步的确认核实。毕竟，我们所体验到的，未必就是正确的。
这时候，我们就可以直接联系对方，而且尽可能联系到相关部门，有时候400电话客服，并不能解决我们的对接需求，打过电话的人都懂。
联系到关键人之后，针对之前我们整理的问题，进行有效沟通，尽量避免谈一些大而空的内容，这是我个人的建议，毕竟大家的时间都很宝贵，直奔主题比较好。
也千万不要问百度能搜索到答案的问题，将时间留给最有用、最核心的关键点。
以我们自己为例，在明确了客户需要对接的需求后，我们初步整理出需要的商品、订单、售后三大模块。然后针对这三大模块的对接问题，进行深入的沟通。
在此基础上，我们还了解到如果想进行这三方面的对接，第一步则是需要我们拿到客户的授权，而获得授权的方式和资料，也需要额外准备。
通过上面的例子你会发现，看似简单的对接流程，其实背后的相关操作逻辑有很多。
有时候，我们仅仅通过产品是无法感知的，必须在此基础上，进行针对性沟通。查缺补漏，才能万无一失。
三.知道自己能对接什么
明确了对方能提供什么，接下来要做的就是知道自己能做什么、不能做什么。为了完成有效对接，我们又需要额外准备些什么。
01.自己需要做哪些准备
通过前面两步，现在我们不仅了解到需求是什么，而且还了解到对方能提供什么，那么接下来要做的就是我们自己要准备些什么。
我们不仅要梳理出双方整体的框架流程，还需要明确两个系统之间的数据交互。
在什么时间节点，我们需要将信息推送给对方；对方进行了什么操作，会将信息推送给我们，这是我们必须要搞清楚的。
数据传递过程中的API接口、消息推送机制，作为产品经理，我们需要提前做好预判，否则在后续开发过程中，会遇到各种问题。
与此同时，我们还需要知道，为了满足这些需求，我们自己的平台是否需要做相应的调整。
如果调整，会涉及哪些模块，会影响哪些功能，对现有功能是否造成影响，是做成公共模块还是定制模块。
如果不调整，能否快速的满足现有这些需求，能否顺利的完成对接。
以上这些，我们都需要事先定义好。
以我们为例，为了完成这次对接，需要在创建商品、创建订单、取消订单、申请售后等相关地方，都需要做开发判断。涉及到的相关接口，都需要进行数据推送和消息反馈读取。
下面的图片，就是我们在进行对接时所准备的交互流程。
不打无准备之仗，将问题提前暴露。
02.整体到细节一个都不能少
我们不仅要从宏观层面了解整体流程，紧接着具体到每个功能，我们也需要尽可能的细分。
宏观层面，帮助我们概括思路和梳理流程；细节落地，推进开发具体执行。
很多时候，我们看大流程、大思路都没有问题，可一旦深入到细节，才会发现步步是坑，寸步难行。
作为产品经理，我们不能让问题在开发阶段暴露，我们需要提前告知并梳理。
这样做，不仅是为了帮助我们自己理清思路，也是帮助整个对接过程更好的开展。
我们要做的，就是耐下心来，一个流程、一个页面、一个字段的梳理，最好是对照着API文档来看，尽量做到不遗漏。
以我们目前遇到的情况来举例，在做整体规划的时候，关于售后流程，只简单的提了一嘴，流程上也只是轻描淡写的画了。
可谁曾想，就是因为这个疏忽，导致了开发在评估时轻视了，造成实际开发周期延长了1天左右，因为这其中涉及到的点实在太多了。
大家看下面这张图就知道了，简单的售后流程，双方的数据交互就有如此之多。
所以，在力所能及的范围内，尽量细化每一个关键节点和内容。
四.看到未来能产生什么
最后我还想说一下此次系统对接，对于我们自己产品的一些启发。
很长时间内，我们自己关于不同系统之间的数据交互，都是通过所谓的后端代码写死来实现的。
这样的好处是开发简单、快速上线。可随着系统功能越来越多、数据量越来越大、流程越来越复杂，导致了现在改动任意一个小点，都极其繁琐。
要么是这里不支持，要么就是那里耦合太强，以至于现在想加新功能越来越难。而且如果一个系统出问题，其他系统也都无法正常使用。
正当技术部门为此头疼的时候，通过此次对接，为我们自己提供了另一种思路。
不同系统之间，其实可以通过接口的方式进行调用，每个系统保持相对独立。这样一来，即能够实现各自运行，又能够保证互联互通。
正所谓，山穷水尽疑无路，柳暗花明又一村。