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