关于系统对接你需要关注的点都在这里Word文档下载推荐.docx

关于系统对接你需要关注的点都在这里Word文档下载推荐.docx

《关于系统对接你需要关注的点都在这里Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《关于系统对接你需要关注的点都在这里Word文档下载推荐.docx（8页珍藏版）》请在冰豆网上搜索。

切记，请不要相信对方提供的所谓开发文档，关键时刻还是要靠人对人的沟通。

如果你也准备做系统间的对接，那么我希望下面这些内容能够对你所有帮助。

一、了解对接目的是什么

有些是公司规划需求，有些是客户定制需求，无论哪种类型，我们都需要明确具体的需求是什么。

1.目前迫切的痛点

如果将需求按优先级来划分，那目前最迫切的痛点问题，自然是我们需要优先关心的。

你可能会说，做目前最迫切的痛点，这是句正确的废话，谁都知道。

为什么还要特别说明呢？

因为关于系统对接，为此所涉及到的功能和可能要动用的资源，实在是太多太多。

如果我们不提前规划好需求的优先级，最后的结果往往是什么都做不了。

以我们目前的情况来说，自己系统里的功能就将近10个，要对接的系统中的功能则更多。

在这样的情况下，你要对接哪些功能？

具体要怎么对接？

这些都是产品经理需要考虑的。

首先，我们需要和需求方明确当前阶段最紧急、最迫切的功能。

你可以这样考虑，为了保证业务能够走下去，我们至少需要做哪些工作；

尽量聚焦在核心业务流程上。

其次，在了解到需求方的要求之后，我们自己需要梳理一遍这流程中可能涉及到的关键和数据对接节点；

要确保不遗漏、不多余。

举个例子：

我们的客户要求首先将订单流程对接跑通，即用户能够下单，然后发货、库存这些信息能够做到同步。

针对上面的情况，如果你仅仅只做订单这一块，那肯定是不行的。

经过仔细的梳理，至少有下面这三大块内容需要考虑：

商品信息：

包括商品基本信息、库存信息；

订单信息：

包括下单流程、发货流程；

售后信息：

包括退款流程、退货流程；

有的放矢，抓大放小，一步一个脚印。

2.未来可能的需求

所谓的脚踏实地，心向远方，就是这样的状态。

我们不仅需要知道当下最重要的事情，还需要知道未来可能的方向。

可能你会问，我们将当下的事情做好、满足需求了，就已经不容易了，哪还有时间和精力去考虑其他。

话是这样说没错，但如果真的这样，那以后产品的升级，也许将难上加难。

了解需求方未来可能的潜在需求，无论是对自己产品的规划和功能的迭代，都有着重要的指导作用。

首先，通过对潜在需求的了解和分析，来判断未来的发展趋势和我们自己的规划是否相符。

如果相符，我们可以考虑怎样更好的进行融合；

如果不相符，我们可以考虑是调整自己的方向还是放弃未来的可能。

其次，通过对需求的深挖和抽象，对我们自己的产品规划有参考价值；

多种选择、多种方向，也许能为我们提供新的视野和方向。

以我们这次的对接来说，通过这次实践，对于我们自己以后的微服务有着很好的借鉴意义，也为我们以后的方向找到了一个可能的机会点。

未来的不可知，需要我们多思路、多角度思考问题。

二、明确对方能提供什么

俗话说，知己知彼才能百战百胜，放在我们这里，那就是知己知彼才能更好的对接融合。

在开始对接前，首先要做的，就是要了解对方能够提供什么。

1.自己先了解概况

想了解对方能提供什么，最直接也是最有效的方式就是自己去体验、去了解。

在这里，我们要感谢这个时代。

现在大部分的互联网产品，都会有官网介绍和产品体验，有些产品还可以进行试用甚至免费使用。

这就为我们了解第一手资料提供了很多便利，尽可能多的获取对方的资料。

当然，也是需要有重点的：

搞清楚对方主要提供哪些功能；

搞清楚对方是否能够提供标准的API接口；

搞清楚对方能否进行针对性开发等等。

如果对方有API接口和文档，那将能够大大的提升我们对接的效率。

毕竟能够提供标准接口的，大部分都是经过验证可行的。

如果我们的需求，超出了对方的标准范围，能够针对性的提供功能开发，具体费用如何，这些我们最好也要提前了解和准备，为后续的方案沟通做准备。

以上，是我们自己作为需求方，需要去了解的内容。

如果需求来源是我们的客户，那我们就可以通过与客户的沟通，深入了解对方系统的功能。

而且，在这种情况下，我们还可以进入客户的账号，亲自体验对方产品的操作流程和逻辑，梳理页面字段和内容，针对性整理汇总。

通过以上两种方式，先形成自己的初步印象。

2.有针对性的进行沟通

当我们自己首先了解到对方系统大致的内容后，我们就需要结合自己前期了解到的需求，有针对性的整理出可能存在的问题，切勿漫无目的的去了解。

当我们有了自己的初步判断后，紧接着就需要进行进一步的确认核实。

毕竟，我们所体验到的，未必就是正确的。

这时候，我们就可以直接联系对方，而且尽可能联系到相关部门，有时候400电话客服，并不能解决我们的对接需求，打过电话的人都懂。

联系到关键人之后，针对之前我们整理的问题，进行有效沟通，尽量避免谈一些大而空的内容，这是我个人的建议，毕竟大家的时间都很宝贵，直奔主题比较好。

也千万不要问XX能搜索到答案的问题，将时间留给最有用、最核心的关键点。

以我们自己为例，在明确了客户需要对接的需求后，我们初步整理出需要的商品、订单、售后三大模块；

然后针对这三大模块的对接问题，进行深入的沟通。

在此基础上，我们还了解到如果想进行这三方面的对接，第一步则是需要我们拿到客户的授权，而获得授权的方式和资料，也需要额外准备。

通过上面的例子你会发现，看似简单的对接流程，其实背后的相关操作逻辑有很多。

有时候，我们仅仅通过产品是无法感知的，必须在此基础上，进行针对性沟通。

查缺补漏，才能万无一失。

三、知道自己能对接什么

明确了对方能提供什么，接下来要做的就是知道自己能做什么、不能做什么；

为了完成有效对接，我们又需要额外准备些什么。

1.自己需要做哪些准备

通过前面两步，现在我们不仅了解到需求是什么，而且还了解到对方能提供什么，那么接下来要做的就是我们自己要准备些什么。

我们不仅要梳理出双方整体的框架流程，还需要明确两个系统之间的数据交互。

在什么时间节点，我们需要将信息推送给对方；

对方进行了什么操作，会将信息推送给我们，这是我们必须要搞清楚的。

数据传递过程中的API接口、消息推送机制，作为产品经理，我们需要提前做好预判，否则在后续开发过程中，会遇到各种问题。

与此同时，我们还需要知道，为了满足这些需求，我们自己的平台是否需要做相应的调整。

如果调整，会涉及哪些模块，会影响哪些功能，对现有功能是否造成影响，是做成公共模块还是定制模块。

如果不调整，能否快速的满足现有这些需求，能否顺利的完成对接。

以上这些，我们都需要事先定义好。

以我们为例，为了完成这次对接，需要在创建商品、创建订单、取消订单、申请售后等相关地方，都需要做开发判断。

涉及到的相关接口，都需要进行数据推送和消息反馈读取。

不打无准备之仗，将问题提前暴露。

2.整体到细节一个都不能少

我们不仅要从宏观层面了解整体流程，紧接着具体到每个功能，我们也需要尽可能的细分。

宏观层面：

帮助我们概括思路和梳理流程；

细节落地：

推进开发具体执行。

很多时候，我们看大流程、大思路都没有问题，可一旦深入到细节，才会发现步步是坑，寸步难行。

作为产品经理，我们不能让问题在开发阶段暴露，我们需要提前告知并梳理。

这样做，不仅是为了帮助我们自己理清思路，也是帮助整个对接过程更好的开展。

我们要做的，就是耐下心来，一个流程、一个页面、一个字段的梳理，最好是对照着API文档来看，尽量做到不遗漏。

以我们目前遇到的情况来举例，在做整体规划的时候，关于售后流程，只简单的提了一嘴，流程上也只是轻描淡写的画了。

可谁曾想，就是因为这个疏忽，导致了开发在评估时轻视了，造成实际开发周期延长了1天左右，因为这其中涉及到的点实在太多了。

简单的售后流程，双方的数据交互就有如此之多。

所以，在力所能及的范围内，尽量细化每一个关键节点和内容。

四、看到未来能产生什么

最后我还想说一下此次系统对接，对于我们自己产品的一些启发。

很长时间内，我们自己关于不同系统之间的数据交互，都是通过所谓的后端代码写死来实现的；

这样的好处是开发简单、快速上线。

可随着系统功能越来越多、数据量越来越大、流程越来越复杂，导致了现在改动任意一个小点，都极其繁琐。

要么是这里不支持，要么就是那里耦合太强，以至于现在想加新功能越来越难。

而且如果一个系统出问题，其他系统也都无法正常使用。

正当技术部门为此头疼的时候，通过此次对接，为我们自己提供了另一种思路。

不同系统之间，其实可以通过接口的方式进行调用，每个系统保持相对独立。

这样一来，即能够实现各自运行，又能够保证互联互通。

正所谓，山穷水尽疑无路，柳暗花明又一村。