編輯導語：產品經理在工作中經常會遇到系統對接的問題，系統對接並不是個簡單的事情，要涉及到技術方面的問題，處理不好可能會導致項目延遲；本文作者用自身經驗詳細分析了系統對接的流程和經驗。
做過B端業務的同學都知道，我們在工作中難免會遇到系統之間的對接問題。為此，我們不僅需要了解對方系統所能提供的內容，還需要知道雙方之間可以交互的節點。
對接的順暢，可以大大提升自己系統的擴展性；對接的不暢，步步是坑事倍功半。
最近自己剛好正在對接一個ERP系統，規模在國內算是比較大的那種。切記，請不要相信對方提供的所謂開發文檔，關鍵時刻還是要靠人對人的溝通。
如果你也準備做系統間的對接，那麼我希望下面這些內容能夠對你所有幫助。
一、瞭解對接目的是什麼有些是公司規劃需求，有些是客户定製需求，無論哪種類型，我們都需要明確具體的需求是什麼。
1. 目前迫切的痛點如果將需求按優先級來劃分，那目前最迫切的痛點問題，自然是我們需要優先關心的。
你可能會説，做目前最迫切的痛點，這是句正確的廢話，誰都知道。為什麼還要特別説明呢？
因為關於系統對接，為此所涉及到的功能和可能要動用的資源，實在是太多太多。
如果我們不提前規劃好需求的優先級，最後的結果往往是什麼都做不了。
以我們目前的情況來説，自己系統裏的功能就將近10個，要對接的系統中的功能則更多。
在這樣的情況下，你要對接哪些功能？具體要怎麼對接？這些都是產品經理需要考慮的。
- 首先，我們需要和需求方明確當前階段最緊急、最迫切的功能。你可以這樣考慮，為了保證業務能夠走下去，我們至少需要做哪些工作；儘量聚焦在核心業務流程上。
- 其次，在瞭解到需求方的要求之後，我們自己需要梳理一遍這流程中可能涉及到的關鍵和數據對接節點；要確保不遺漏、不多餘。
舉個例子：我們的客户要求首先將訂單流程對接跑通，即用户能夠下單，然後發貨、庫存這些信息能夠做到同步。
針對上面的情況，如果你僅僅只做訂單這一塊，那肯定是不行的。
經過仔細的梳理，至少有下面這三大塊內容需要考慮：
- 商品信息：包括商品基本信息、庫存信息；
- 訂單信息：包括下單流程、發貨流程；
- 售後信息：包括退款流程、退貨流程；
有的放矢，抓大放小，一步一個腳印。
2. 未來可能的需求所謂的腳踏實地，心向遠方，就是這樣的狀態。我們不僅需要知道當下最重要的事情，還需要知道未來可能的方向。
可能你會問，我們將當下的事情做好、滿足需求了，就已經不容易了，哪還有時間和精力去考慮其他。
話是這樣説沒錯，但如果真的這樣，那以後產品的升級，也許將難上加難。
瞭解需求方未來可能的潛在需求，無論是對自己產品的規劃和功能的迭代，都有着重要的指導作用。
首先，通過對潛在需求的瞭解和分析，來判斷未來的發展趨勢和我們自己的規劃是否相符。
如果相符，我們可以考慮怎樣更好的進行融合；如果不相符，我們可以考慮是調整自己的方向還是放棄未來的可能。
其次，通過對需求的深挖和抽象，對我們自己的產品規劃有參考價值；多種選擇、多種方向，也許能為我們提供新的視野和方向。
以我們這次的對接來説，通過這次實踐，對於我們自己以後的微服務有着很好的借鑑意義，也為我們以後的方向找到了一個可能的機會點。
未來的不可知，需要我們多思路、多角度思考問題。
二、明確對方能提供什麼俗話説，知己知彼才能百戰百勝，放在我們這裏，那就是知己知彼才能更好的對接融合。在開始對接前，首先要做的，就是要了解對方能夠提供什麼。
1. 自己先了解概況想了解對方能提供什麼，最直接也是最有效的方式就是自己去體驗、去了解。
在這裏，我們要感謝這個時代。現在大部分的互聯網產品，都會有官網介紹和產品體驗，有些產品還可以進行試用甚至免費使用。
這就為我們瞭解第一手資料提供了很多便利，儘可能多的獲取對方的資料。
當然，也是需要有重點的：
- 搞清楚對方主要提供哪些功能；
- 搞清楚對方是否能夠提供標準的API接口；
- 搞清楚對方能否進行針對性開發等等。
如果對方有API接口和文檔，那將能夠大大的提升我們對接的效率。畢竟能夠提供標準接口的，大部分都是經過驗證可行的。
如果我們的需求，超出了對方的標準範圍，能夠針對性的提供功能開發，具體費用如何，這些我們最好也要提前瞭解和準備，為後續的方案溝通做準備。
以上，是我們自己作為需求方，需要去了解的內容。
如果需求來源是我們的客户，那我們就可以通過與客户的溝通，深入瞭解對方系統的功能。
而且，在這種情況下，我們還可以進入客户的賬號，親自體驗對方產品的操作流程和邏輯，梳理頁面字段和內容，針對性整理彙總。
通過以上兩種方式，先形成自己的初步印象。
2. 有針對性的進行溝通當我們自己首先了解到對方系統大致的內容後，我們就需要結合自己前期瞭解到的需求，有針對性的整理出可能存在的問題，切勿漫無目的的去了解。
當我們有了自己的初步判斷後，緊接着就需要進行進一步的確認核實。畢竟，我們所體驗到的，未必就是正確的。
這時候，我們就可以直接聯繫對方，而且儘可能聯繫到相關部門，有時候400電話客服，並不能解決我們的對接需求，打過電話的人都懂。
聯繫到關鍵人之後，針對之前我們整理的問題，進行有效溝通，儘量避免談一些大而空的內容，這是我個人的建議，畢竟大家的時間都很寶貴，直奔主題比較好。
也千萬不要問百度能搜索到答案的問題，將時間留給最有用、最核心的關鍵點。
以我們自己為例，在明確了客户需要對接的需求後，我們初步整理出需要的商品、訂單、售後三大模塊；然後針對這三大模塊的對接問題，進行深入的溝通。
在此基礎上，我們還了解到如果想進行這三方面的對接，第一步則是需要我們拿到客户的授權，而獲得授權的方式和資料，也需要額外準備。
通過上面的例子你會發現，看似簡單的對接流程，其實背後的相關操作邏輯有很多。
有時候，我們僅僅通過產品是無法感知的，必須在此基礎上，進行針對性溝通。
查缺補漏，才能萬無一失。
三、知道自己能對接什麼明確了對方能提供什麼，接下來要做的就是知道自己能做什麼、不能做什麼；為了完成有效對接，我們又需要額外準備些什麼。
1. 自己需要做哪些準備通過前面兩步，現在我們不僅瞭解到需求是什麼，而且還了解到對方能提供什麼，那麼接下來要做的就是我們自己要準備些什麼。
我們不僅要梳理出雙方整體的框架流程，還需要明確兩個系統之間的數據交互。
在什麼時間節點，我們需要將信息推送給對方；對方進行了什麼操作，會將信息推送給我們，這是我們必須要搞清楚的。
數據傳遞過程中的API接口、消息推送機制，作為產品經理，我們需要提前做好預判，否則在後續開發過程中，會遇到各種問題。
與此同時，我們還需要知道，為了滿足這些需求，我們自己的平台是否需要做相應的調整。
如果調整，會涉及哪些模塊，會影響哪些功能，對現有功能是否造成影響，是做成公共模塊還是定製模塊。
如果不調整，能否快速的滿足現有這些需求，能否順利的完成對接。
以上這些，我們都需要事先定義好。
以我們為例，為了完成這次對接，需要在創建商品、創建訂單、取消訂單、申請售後等相關地方，都需要做開發判斷。涉及到的相關接口，都需要進行數據推送和消息反饋讀取。
不打無準備之仗，將問題提前暴露。
2. 整體到細節一個都不能少我們不僅要從宏觀層面瞭解整體流程，緊接着具體到每個功能，我們也需要儘可能的細分。
- 宏觀層面：幫助我們概括思路和梳理流程；
- 細節落地：推進開發具體執行。
很多時候，我們看大流程、大思路都沒有問題，可一旦深入到細節，才會發現步步是坑，寸步難行。
作為產品經理，我們不能讓問題在開發階段暴露，我們需要提前告知並梳理。
這樣做，不僅是為了幫助我們自己理清思路，也是幫助整個對接過程更好的開展。
我們要做的，就是耐下心來，一個流程、一個頁面、一個字段的梳理，最好是對照着API文檔來看，儘量做到不遺漏。
以我們目前遇到的情況來舉例，在做整體規劃的時候，關於售後流程，只簡單的提了一嘴，流程上也只是輕描淡寫的畫了。
可誰曾想，就是因為這個疏忽，導致了開發在評估時輕視了，造成實際開發週期延長了1天左右，因為這其中涉及到的點實在太多了。
簡單的售後流程，雙方的數據交互就有如此之多。
所以，在力所能及的範圍內，儘量細化每一個關鍵節點和內容。
四、看到未來能產生什麼最後我還想説一下此次系統對接，對於我們自己產品的一些啓發。
很長時間內，我們自己關於不同系統之間的數據交互，都是通過所謂的後端代碼寫死來實現的；這樣的好處是開發簡單、快速上線。
可隨着系統功能越來越多、數據量越來越大、流程越來越複雜，導致了現在改動任意一個小點，都極其繁瑣。
要麼是這裏不支持，要麼就是那裏耦合太強，以至於現在想加新功能越來越難。而且如果一個系統出問題，其他系統也都無法正常使用。
正當技術部門為此頭疼的時候，通過此次對接，為我們自己提供了另一種思路。
不同系統之間，其實可以通過接口的方式進行調用，每個系統保持相對獨立。
這樣一來，即能夠實現各自運行，又能夠保證互聯互通。
正所謂，山窮水盡疑無路，柳暗花明又一村。
作者：明天上線 微信公眾號：明天上線
本文由 @明天上線 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議