和后台如何对接_业务系统如何对接第三方服务？
在產品工作中，我們時常要對接第三方服務。本文作者從過往的對接項目經歷中，提煉的關于業務系統，如何對接第三方服務的方法論，希望能對你有所幫助。
隨著公司業務的發展，我們有時會遇到，需要在自身業務系統中加入新服務，但不能純自主開發的情況。
比如會有以下三種：
而這時如果恰好市面上有成熟的解決方案，我們便可以把專業的活，交給有一定資質且專業的人，接入他們的能力來解決自己的問題。
比如，我們要在電商系統中，接入物流軌跡查詢的能力，自研的話，需要對接多家物流公司的單號系統，費時費力還可能對接不成功。此時若有第三方服務商，已經整合了多家物流公司的物流軌跡查詢，我們便可以直接通過與其進行對接合作，來實現自己的物流查詢功能。
通過接入合適的第三方服務，既不用讓公司在新領域自研試錯，投入過高的開發成本，又能縮短開發周期，讓我們的業務產品快速獲得更加專業穩定的服務，變得更加成熟、強大。
以上對公司的好處我們了解了，但了解并接入三方服務，這工作對產品經理來說往往不是件易事。
做產品沒有標準答案，我們做的每一個產品方案，都是在一個特別具體的環境下產生的。每一次都是定制，對接第三方更為如此。既要快速了解另一個領域的基本知識和行業產品，又要結合選定的第三方服務與公司新提出的業務需求，設計出一期最適合的產品方案，每一次都像是在摸著石頭過河，有著說不上來的困難。
在對過往的多個對接項目經歷，進行反思后，我將整個對接過程劃分為三個階段，并試圖提煉出各個階段應遵循的共性要點，讓我們在對接時能夠有章可依，降低事情難度，希望能對你有所幫助。
階段一：設計前
產品經理在進行具體的方案設計之前，應做哪些事情呢？
1. 對自身業務系統有整體的理解
只有對我們的業務系統，先有全局的理解和把握，才能在知曉業務需求和三方的解決方案后，剖析出要改動的所有部位，做到纖悉無遺。
如若不然，對自身系統結構和業務都還一知半解，就貿然開始著手三方調研和方案設計，很容易因為前期考慮不全，而造成難以預見的危險后果。
舉個例子，有一個后臺管理系統，管理著線上商城和線下門店的零售業務，你要在整套系統中接入新的第三方聚合支付，逐步替換掉原有的三方支付服務。
若你對業務系統的了解還不足，就直接分析如何使用三方服務能力，并產出方案，推動項目上線。運氣好的話，你可能只犯了點小錯誤。比如在前端商城中，對某個業務頁面改了些字段，而后臺的一個統計頁面，你遺漏了對其進行同步更改，導致無法正常顯示。這影響范圍還較小，你還能在上線后進行及時補救。
但若嚴重的話，你的考慮不全，甚至可能會直接影響到系統關聯業務的正常運行。比如，之前一直都是負責線上產品的迭代，在這次項目中，由于你沒有去加強對線下業務的理解，導致在設計過程中，你直接疏忽了門店的重要設備——POS機，在里面軟件的自建訂單頁面中，也需要更換新的支付方式。由于沒有在這次項目中同步更改，將直接影響線下刷卡、掃碼等場景的業務的正常開展。
那么需要對業務系統了解到什么程度呢？我們可以通過對風險進行分類，然后倒推得出前期的準備。
可以跟我一樣，將這些可能的風險，用二分法，簡單劃分為直接影響業務與間接影響業務。
直接影響，即影響業務的閉環運行。一旦沒有兼顧到里面的任一環節，都會干擾到業務的正常進行。所以你需要做到，對該業務需求所涉及的主線業務流程，和其中的邏輯都有清晰的認識，哪怕對里面的任一個字段規則抱有疑問，你都應該剖根問底。分析其如若是個錯誤，是否應在這次項目中一同解決，避免其對新老業務產生影響。
間接影響，即不影響項目主流程正常進行的其他影響。如統計、設置等地方的關聯改動，這種屬于支線流程的需求最容易被我們忽略，但只有都顧及到，才能讓方案更加完整。在開發評審時，我們的方案很少能一次通過，都會有或多或少的修改。你可以跟我一樣，將在每次評審時所發現的，設計時被遺漏的功能或業務，都記在備忘錄中，用于在后續每次設計方案產出后進行自查，以提高初次方案的完整度。
為了更好地降低風險，還可以邀請公司中對該業務熟悉的相關人員，來參與你的設計方案評審，一同檢查是否有設計遺漏，多一道保險，避免自己顧此失彼。
2. 完成第三方產品的調研
我們在購物時，為了選到最心儀的商品，通常會貨比三家。同樣的，為實現業務需求而接入的第三方，將會在很長的時間內伴隨著自身產品，這就更需要我們去仔細的篩選。
商品不喜歡，我們可以選擇退貨或者重新選購，但接入的三方服務不合適，即使我們去重新找新的服務商合作，卻也已經在之前的對接過程中，讓企業付出了成本，這是無法挽回的。
所以在具體對接前，我們應對三方服務商做仔細地調研與篩選。
這過程我劃分為兩個小階段，調研初篩和名單提交。
1)調研初篩
剛開始去了解一個新的領域，你需要做的是，快速研究清楚里面的一些核心概念，然后盡可能多地收集行業產品的信息，并簡要分析其服務能力與我們業務需求的匹配度如何。
而考察其服務能力，最為關鍵的點，無疑就是對我們基礎需求的滿足度，和其產品的拓展性了。
1.基礎需求
基礎需求，即本期要實現的業務需求能否滿足，這一點還是相對容易判斷的。
比如，你要在業務系統中，實現在線下單發貨的功能。在訂單發貨時，通過接口傳送面單信息后，接收物流公司返回的快遞單號信息，并且能獲取物流軌跡更新。
這種只需將核心需求梳理后，與其官網的業務描述進行比對，或者直接詢問客服或銷售，就可以快速知道能否實現。
2.產品拓展性
業務需求極少能一次性滿足，往往會隨著業務的發展而變化。所以僅考慮現階段需求的滿足，是不夠的，你還需要進一步了解。這次為滿足基礎需求，所用到的三方產品和服務，能否滿足未來定制化的需求。判斷其拓展性如何，即二次開發的能力。
比如，在對新業務需求進行分析梳理后，我們通常會有多期項目規劃。一期滿足核心需求，后續就要考慮，如何實現重要但非一期優先的附加需求了。如果屆時的迭代方案，需要對已經使用到的三方產品頁面或者系統，進行調整設計，而對方并不支持對其二次開發或者改動難度大，周期長，那就需要更加慎重的考量了。
在平常工作中，我們也要不斷去鍛煉思考問題本質的能力，不讓產品設計停留在表面，只能解決當前問題，而要考慮到是否能承接業務未來更多變化的需求。
2)名單提交
在初步調研后，你需要對初篩合格的三方服務商進行縱向研究，完成調研對比產出，并附上綜合分析后的建議，給到對應的決策者進行選擇。
其中的分析至少包括以下三個維度：
1.成本
在使用第三方服務時，往往會伴隨著各種費用的產生，這也是公司最為關注的點之一，需要我們做仔細地調研。
常見的費用類型有：
- 服務費用：在使用服務商的某款產品或服務的過程中，產生的服務資費，一般按實際使用量或使用時長付費。如，調用人臉識別的次數，按次收費，使用即時通訊服務的期限，按每月固定的費用收取。
- 授權費用：我們所選擇的服務，需要通過使用對方的SDK去對接時，就有可能要收取對應的費用，即該SDK在固定期限內的使用授權費。 不過也不是固定收取的，有時也會結合服務費用里的套餐包免費贈送，如騰訊云直播購買特定流量包后，就會贈送一年的直播SDK使用權限。
- 對接費用：在初次對接對方產品時，需要一次性收取的接入費用。一般只在系統級的定制對接，即業務對接復雜度較高時，才有可能要支付這項費用。類似于平臺接入銀行的存管系統這種，才會收取對接費用。
每家服務商都有自己的收費模式，我們需要了解清楚后，結合自己的需求，去思考最適合公司現階段的選項或組合。
2.風險
若是接入的三方服務不穩定，那么在上線后，對自身產品所帶來的影響將是災難級的。
服務不穩定帶來的卡頓，或者數據錯誤與丟失等問題，將會直接影響用戶對產品的體驗和印象，甚至直接棄用產品。
所以穩定，便是對三方服務能力要求的重中之重了，但這也是我們在初次對接時，往往很難判斷的一項。
如果直接問服務商其接口的穩定性如何，對方一定會說很穩定，因為沒有人會想在初次合作時，暴露自身問題，讓客戶動搖導致合作失敗。所以我們需要，多從其他途徑去了解真實情況。
比如可以通過以下幾個小點去評估和減小風險：
- 了解對方業務的沉淀程度：新業務代表著不成熟與高風險，業務的發展需要一定時間的摸爬滾打才能趨于完善。新業務的性能不足和異常流程處理機制的不完善，都會讓我們在使用時具有極大的不確定性。所以業務沉淀越久越好，個人建議直接找頭部的服務商，或者該業務至少開展了2年的服務商。
- 先接入支線業務：確定服務商后，最低風險的對接方法，就是先拿自身業務流程中的邊緣業務去試手。在對三方服務能力不夠確定的情況下，先不要對接核心業務。在熟悉對接流程與其服務能力后，再逐步進行核心業務的全面對接。比如，之前在對接某銀行的聚合支付時，我們就先挑選了業務系統中的一個簡單業務進行對接驗證，即后臺系統中的短信付費，有個掃碼支付的場景，可以直接接入這項新支付方式進行測試。然后該支線業務的流程跑通后，我們再在所有的支付場景中，接入該聚合支付。
- 要有備選的服務商：項目上線后，才能驗證當時方案的可行性和三方的服務能力。沒上線前，我們也不能確信，初次合作的三方服務商，其服務能力能否很好實現業務要求。所以你需要在接入效果不好時，有可以緊急更換的選項，才能做到有備無患。
3.產品配套
初篩時我們所關注的是，要使用到的單個產品的拓展性，這里還需了解對應的產品配套如何，即思考其他的產品資源，能否為我們后期業務的發展而服務。
如接入視頻直播服務時，關注美顏、轉碼、連麥聊天等配套功能，考慮在未來的發展中是否有可能應用上。這既能幫助我們在對未來的規劃思考上，拓寬思維，又能進一步判斷對方的服務能力和業務成熟度。
3. 初步方案
確定好對接哪家第三方后，我們需要給出初步的方案與服務商進行溝通，確認可以實現后，再進行具體的設計。
這就需要我們先了解，本次需求背后的核心問題是什么，通過識別業務核心，找到簡單快速的解法，了解優先級和緊急程度后，給出自己的最小方案。并結合自身系統的簡單介紹和業務背景說明，讓服務商更好的判斷自身產品或服務能否滿足。
方案中為了更好的闡述需要實現的業務需求，可配合簡要流程圖進行說明，同時確認會在哪些環節用到什么接口。這一步因為涉及到雙方系統的實現，我們需要邀請本司技術人員，共同參與前期的調研評審，探討接入方式與可行性。
1)注意事項
1.關于第三方服務商
我們需要確定對方的業務對接人和技術對接人，以便在產生對接疑問時，可以快速找到負責人，溝通并解決問題。
在具體設計之前，一定要先通過電話或者QQ等方式，對話確認自身的業務需求能否滿足，避免在開發人員進行對接的過程中，才發現無法很好實現，那么一切的努力都將成為白費。
進行業務方案的可行性確認前，你還可以先問下對方的典型案例和場景是什么樣的，通過了解不同的業務需求，還能幫助你拓展思維，思考后期的需求。
在對接較為復雜，或者溝通不清楚時，可聯系上門演示，縮短溝通周期。
2.關于業務定制方
這里說的業務定制方，指的是定制項目或SaaS軟件的業務方。當幫他們實現新服務需求時，請務必提前了解并確定對方想要實現的業務范圍，同時每次的溝通結果都做留檔確認，避免在前期的業務需求確認上，出現不必要的異議。
階段二：設計中
初步方案通過后，我們就要做具體的產品設計了，這里簡單聊下，設計時應該注意的4個小點：
1. 接入第三方的業務流程梳理
為了避免復雜的開發，并降低溝通成本，可在流程圖中注明與三方的接口動作，在哪些環節做什么判斷。同時還有異常情況的處理方式，比如在對接第三方支付中，支付失敗有哪些原因，拿到不同的結果該怎么處理，等等。
2. 新業務對原業務的影響
新服務接入到業務系統后，需確定并說明是否為默認開通，且不開通時，是否要對原業務做設計調整，和對舊數據進行處理。
3. 設計上對C端用戶的無差異感知
如無必要，無需讓用戶直接感受到產品加入的第三方。
依舊以上述的三方支付項目為例，當時我們有個環節是，個人分銷商要進行傭金提現，需要在成為分銷商前，就在三方賬戶體系中進行賬戶新建，即會要求個人提前在前端產品進行認證簽約。
此時，我們無需讓用戶在簽約過程中，直接感知第三方的賬戶資料建立(簽約協議中會有說明)，只需在后臺直接讓三方的虛擬賬戶體系，映射平臺賬戶，一一對應，用戶無感，也減少認知負擔。
4. 接口文檔上的數據項是否有遺漏
接口文檔的作用，就是讓我們知道，在哪個環節需要提供哪些內容給對方，對方才可以有效的處理并返回給我們需要的結果。
比如在后臺實現在線下單的功能，就只需要我們傳給對方，收寄件人的姓名手機和地址信息即可，然后對方再返回快遞單號。
仔細看接口文檔，除了避免遺漏必填項外，還要留意各個環節的選填項是否要在本次設計中加入。比如，在后臺在線下單時，可考慮是否讓用戶可以選擇通知快遞員上門攬件。
5. 注意事項
在完全實現業務需求之前，我們往往先采取最小可行性方案，即先跑通核心業務為主。在第一次對接時，最好邏輯不要過于復雜，如果開發評審后，評估的研發周期較長，你就需要反思下，自己是不是一次性做的需求太多了。
同時，完整的設計方案產出后，在進行開發之前，還應與業務方再次溝通，并輸出最終業務流程圖進行確認。
階段三：上線后
測試完成，上線之后，我們還要做兩件事：
1. 風控與三方能力評估
上線后對三方服務的風控依舊不能松懈，由于第三方是我們無法把控的部分，因此我們不能確定上線后是否會出現什么問題，所以在必要時，要能做到即時關閉該服務。
同時，還需要在運行一段時間后，對三方的穩定性和拓展性兩方面進行評估，若沒達到要求，則需要考慮后期是否更換服務商。
2. 項目復盤
項目復盤，即反思從項目開始到正式上線，自己做了什么事情，產品方案的落地效果如何，對已達成的結果和預期成果之間所產生偏差進行評估，是否優于預期，有做錯了什么。通過在反思中獲得進步，進而提高自身的生產效率。
特別是，我們做的產品方案，在評審時如果不是一次過，更要多反思那時修改了什么，在哪方面思考不足，并檢查是否有遺漏的異常流，對其他模塊的影響是否有照顧到，將在復盤過程中發現的待完善內容，列入到接下來的迭代規劃當中。
結語
每次對接新的第三方類型時，我們經常會像面對一個全新的困難一樣，充滿著太多的未知，容易一頭霧水。
但作為一個研究型的職業，產品就是這樣經常要做探索。既然選擇了產品這條路，便只能風雨兼程，讓我們知難而不畏難，在一個又一個的項目中，繼續不斷深入思考、磨煉自己。
本文由 @陳星 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
總結
以上是生活随笔為你收集整理的和后台如何对接_业务系统如何对接第三方服务？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自言自语
- 下一篇： 利用insert、update和dele