在對(duì)接第三方的過程中，有時(shí)候明明是一個(gè)簡(jiǎn)單的業(yè)務(wù)，對(duì)接卻那么復(fù)雜。到底是什么原因造成了這樣的局面呢？本文將對(duì)此進(jìn)行探討，一起來看看吧。

前段時(shí)間在產(chǎn)品經(jīng)理的交流群里遇到一位小伙伴發(fā)表的疑惑：

剛好筆者之前也對(duì)接過另外一家第三方電子合同平臺(tái)，本文就以電子合同為例，探討一下：為什么第三方平臺(tái)對(duì)接越來越復(fù)雜？

筆者注：為了便于闡述觀點(diǎn)和確保內(nèi)容的易讀性，文中涉及的流程均做了一定程度的簡(jiǎn)化，不能作為對(duì)接第三方電子合同平臺(tái)的對(duì)接參考，請(qǐng)讀者注意分辨。

我之前在《新手產(chǎn)品經(jīng)理必學(xué)技術(shù)接口文檔知識(shí)》中講過，在設(shè)計(jì)開發(fā)產(chǎn)品的時(shí)候，產(chǎn)品需要用到某些功能，但這些功能的實(shí)現(xiàn)對(duì)于現(xiàn)有的團(tuán)隊(duì)而言，可能缺乏業(yè)務(wù)領(lǐng)域的優(yōu)勢(shì)，或缺乏技術(shù)領(lǐng)域的優(yōu)勢(shì)，亦或兩種領(lǐng)域的優(yōu)勢(shì)都明顯不足，因此往往需要通過對(duì)接第三方平臺(tái)來實(shí)現(xiàn)，像上文那位小伙伴提到的“電子合同”，因?yàn)樯婕皣?yán)格的備案和鑒權(quán)，在國(guó)內(nèi)，能夠做這個(gè)業(yè)務(wù)的公司屈指可數(shù)，因此多數(shù)公司的產(chǎn)品只能選擇對(duì)接有資質(zhì)的第三方平臺(tái)。

但在對(duì)接第三方平臺(tái)的過程中，暴露出的問題越來越明顯，就是明明只需要實(shí)現(xiàn)一個(gè)非常簡(jiǎn)單的業(yè)務(wù)，但是接口方提供的接口非常多，讓產(chǎn)品經(jīng)理覺得對(duì)接起來非常復(fù)雜，那么，到底是什么原因造成了這樣的局面呢？

要想解答這個(gè)問題，首先要從對(duì)接方的角度，看看最簡(jiǎn)單的對(duì)接流程應(yīng)該是怎么樣的，再來分析為什么接口提供方?jīng)]有辦法按照最簡(jiǎn)單的流程來做。

一、最簡(jiǎn)單的對(duì)接流程

從對(duì)接方的角度，以上流程雖然對(duì)接了4個(gè)接口，但實(shí)名認(rèn)證和簽署只需通過鏈接跳轉(zhuǎn)到對(duì)接平臺(tái)的頁(yè)面進(jìn)行操作，因此其核心對(duì)接步驟只需兩步：

1. 簽署人通過對(duì)接平臺(tái)進(jìn)行實(shí)名認(rèn)證后，業(yè)務(wù)平臺(tái)發(fā)送需要簽署的文件到對(duì)接平臺(tái)，簽署人到對(duì)接平臺(tái)提供的頁(yè)面進(jìn)行簽署；
2. 簽署完成后，業(yè)務(wù)平臺(tái)獲取已簽署的文件保存到自身服務(wù)器中。

那么為什么對(duì)接平臺(tái)不能提供這樣一個(gè)簡(jiǎn)單的流程給到對(duì)接方，而是每個(gè)環(huán)節(jié)都要弄出一大堆接口出來，主要是基于以下考慮。

二、為了場(chǎng)景的兼容性

以生成待簽署文件為例，有兩種場(chǎng)景，一種是業(yè)務(wù)平臺(tái)直接生成待簽署文件上傳到第三方平臺(tái)；另一種則是業(yè)務(wù)平臺(tái)上傳模板到對(duì)接平臺(tái)，然后往模板中填充內(nèi)容并生成待簽署文件，兩者的大致作業(yè)流程如下：

通過以上作業(yè)流程可以發(fā)現(xiàn)，無論是直接上傳待簽署文件，還是通過模板生成待簽署文件，最開始的時(shí)候都需要做一個(gè)上傳的動(dòng)作，兩者只是上傳的文件不同而已，因此，在設(shè)計(jì)接口的時(shí)候，獲取文件上傳地址和上傳文件這一步往往可以設(shè)計(jì)為2個(gè)接口，而非4個(gè)接口，系統(tǒng)只需根據(jù)上傳的場(chǎng)景在接口參數(shù)中標(biāo)記清楚當(dāng)前文件是屬于待簽署文件還是模板即可，比如用“file”表示待簽署文件，用“template”表示模板。

因此，把接口拆得更細(xì)，能夠兼容更多的場(chǎng)景，同時(shí)能夠提高部分接口的復(fù)用率，如果根據(jù)業(yè)務(wù)流程把一堆接口封裝成一個(gè)接口，那么上文提到的兩個(gè)場(chǎng)景中，將有部分接口內(nèi)容屬于是“重復(fù)造輪子”。

三、為了流程的靈活性

在電子合同簽署流程中，有一個(gè)環(huán)節(jié)叫做“簽署流程歸檔”，歸檔的概念是表示文件已經(jīng)簽署完成，不能再對(duì)該文件發(fā)起簽署，我們想象的歸檔流程和真正的歸檔流程分別是這樣的：

是不是感覺莫名其妙又多此一舉，明明一個(gè)接口能夠搞定的事情，偏偏還要多調(diào)用一個(gè)歸檔接口之后，電子合同平臺(tái)才進(jìn)行歸檔，但如果我告訴你以下兩種場(chǎng)景，你應(yīng)該就能夠理解這個(gè)設(shè)計(jì)的意圖了：

• 平臺(tái)需要對(duì)電子合同簽名進(jìn)行人工審核，審核通過才歸檔，審核不通過要求簽署人重簽；
• 需要多人簽署的文件，等到所有人都簽署完成之后才發(fā)現(xiàn)漏了一個(gè)簽署人，此時(shí)需要將該簽署人加上去，并讓該簽署人簽署。

因此，在平臺(tái)設(shè)計(jì)接口的時(shí)候，就已經(jīng)考慮到各種不同的場(chǎng)景，所以將一些重要環(huán)節(jié)的決策權(quán)交還給業(yè)務(wù)平臺(tái)去決定，從而使得流程更加靈活。

四、必不可少的異步通知

在簽署合同過程中，我們想象中簽署流程和真正的簽署流程分別是這樣的：

我們想象中的簽署流程是一蹴而就的，然而真實(shí)的場(chǎng)景中，從平臺(tái)發(fā)起簽署流程到簽署人進(jìn)行簽署，或多人簽署的場(chǎng)景等到最后一人完成簽署，都是需要等待一段時(shí)間的，這段時(shí)間可能很短，也可能很長(zhǎng)，但系統(tǒng)不可能一直在那里等著（loading），因此，就有了一個(gè)“異步通知”的概念，異步通知可以理解為某個(gè)流程的完成需要一定的時(shí)間，在這段時(shí)間內(nèi)，業(yè)務(wù)系統(tǒng)無需做任何處理，等到該流程完成后，對(duì)接平臺(tái)會(huì)通過另外一個(gè)接口來通知業(yè)務(wù)系統(tǒng)，業(yè)務(wù)系統(tǒng)再進(jìn)行后續(xù)處理，這個(gè)接口，就是異步通知接口。

以上文的簽署流程為例，假設(shè)一個(gè)多人簽署的流程，在全部簽署人簽署完成后進(jìn)行歸檔，其流程是這樣的：

五、不可忽視的商業(yè)性

除了上文提到的原因，拆分接口對(duì)于平臺(tái)的商業(yè)性而言，也有一定的優(yōu)勢(shì)，比如上文提到的簽署流程中，簽署人需要先通過平臺(tái)進(jìn)行實(shí)名認(rèn)證，拆分實(shí)名認(rèn)證接口，等同于將實(shí)名認(rèn)證的業(yè)務(wù)與電子合同簽署的業(yè)務(wù)進(jìn)行分割，如果有客戶只需要實(shí)名認(rèn)證的服務(wù)而不需要電子合同簽署業(yè)務(wù)，則可以將該業(yè)務(wù)獨(dú)立開來進(jìn)行收費(fèi)。

所以，現(xiàn)在你知道，為什么第三方平臺(tái)對(duì)接越來越復(fù)雜了吧？

以上便是本文的全部?jī)?nèi)容，感謝閱讀！

專欄作家

產(chǎn)品錦李，公眾號(hào)：產(chǎn)品錦李（ID：IMPM996），人人都是產(chǎn)品經(jīng)理專欄作家。不務(wù)正業(yè)的產(chǎn)品經(jīng)理和他的產(chǎn)品設(shè)計(jì)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。