無論是C端還是B端，產(chǎn)品一般都不是孤立存在，而是整個業(yè)務流中的一環(huán)，所以也少不了和外部系統(tǒng)對接。那么，如何高效對接外圍系統(tǒng)呢？本文作者結合自身經(jīng)驗，總結了一些措施，希望能給你帶來幫助。

一、每個產(chǎn)品都不是孤立存在

無論是C端還是B端，某一產(chǎn)品一般都不是孤立存在，而是整個業(yè)務流中的一環(huán)。如果某產(chǎn)品屬于起始產(chǎn)品，產(chǎn)生數(shù)據(jù)后，也會連接下游產(chǎn)品，承接相應業(yè)務數(shù)據(jù)，完成整個業(yè)務流轉。比如獲客系統(tǒng)沉淀的客戶信息、來源渠道等，都會流轉到下游交易系統(tǒng)，即客戶購買商品產(chǎn)生交易單，交易系統(tǒng)的交易信息也會流轉到更下游的財務系統(tǒng)，負責單據(jù)的核算做賬等業(yè)務。

當然，理論上也沒有嚴格意義的起始產(chǎn)品，上述案例的獲客系統(tǒng)，其上游也會又獲客前的廣告系統(tǒng)、推廣運營活動系統(tǒng)，但某個公司的業(yè)務聚焦點是獲客后的交易，所以會以此公司主營業(yè)務范圍作為信息產(chǎn)品的邊界。

另外，每個產(chǎn)品的上游和下游系統(tǒng)也不僅僅只有一個，主要是因為業(yè)務不是單線流程，而是網(wǎng)狀結構，不同業(yè)務流交叉形成復雜的業(yè)務生態(tài)。例如上述案例中的獲客系統(tǒng)，除了下游會有交易系統(tǒng)以外，可能還會有專門的會員系統(tǒng)、積分系統(tǒng)等作為下游系統(tǒng)，主要是因為為滿足用戶需求，背后會有一系列產(chǎn)品為其服務。

既然大多數(shù)產(chǎn)品是業(yè)務流程中的某一環(huán)，那就少不了和外部系統(tǒng)對接，這里包括外部公司系統(tǒng)，如外部銀行、微信、支付寶支付渠道接口等，也包括內部公司其他系統(tǒng)。合作項目是否能成功上線、成功推廣，除了自己產(chǎn)品開發(fā)好，外圍系統(tǒng)是否能對接好也是非常重要。那么如何高效對接外圍系統(tǒng)呢？筆者通過實踐總結以下事半功倍的措施，希望有幫助。

二、防止出錯，提前預判

合作類項目跨部門協(xié)調溝通，需要有明確的目標、各自負責的范圍、互通數(shù)據(jù)的流程。但很多時候，以上流程是不清晰的，會導致項目進度受阻，或是項目上線后出現(xiàn)問題互相扯皮的情況，所以在項目開始前明確出來就非常重要。

整體流程包括：明確產(chǎn)品目標、梳理業(yè)務流程圖、明確各自產(chǎn)品負責的范圍及產(chǎn)品方案、督促雙方開發(fā)按進度完成上線、共同建立清晰的運維機制。根據(jù)實際工作經(jīng)驗，以下分為兩類合作項目介紹，以及容易踩坑點。

第一類：主動找其他部門配合

如果是產(chǎn)品經(jīng)理自己負責的產(chǎn)品需要其他部門配合，則更像大產(chǎn)品經(jīng)理，除了負責自己產(chǎn)品以外，更多的是站在整體角度，明確項目目標，帶著各方系統(tǒng)一起做。對個人的壓力會大一些，因為要對內對外協(xié)調很多資源，涉及具體要做什么事兒、需要誰來配合、如果對方不配合怎么辦、配合后雙方系統(tǒng)的產(chǎn)品范圍有重復交叉或是三不管地帶怎么辦、上線后用戶投訴互相甩鍋怎么辦等等問題。

筆者負責的項目中就有以上類似問題，經(jīng)過反思后，發(fā)現(xiàn)有些經(jīng)驗總結后，大腦就會對下次項目啟動風險預判提醒。

1）產(chǎn)品上線前

重點給外圍系統(tǒng)對接人闡述項目背景、明確項目目標，督促對方出具產(chǎn)品方案和上線時間。當然，對方是否配合取決于錢和開發(fā)資源排期，錢上面就是對方報價是否合理，內部好解決些報工時打卡即可（項目制管理的公司，會將每個開發(fā)人員打卡項目來衡量資源配比是否合理），外部則需找采購進行評估。

如果對方報價太高，則積極找相關利益方進行協(xié)調，比如換供應商、采購進行溝通調價等。如果對方報價合理，則進入方案確認，開發(fā)排期環(huán)節(jié)。此處需重點注意，盡量細化方案細節(jié)，比如正向流程、逆向流程，大概率場景、小概率場景，包括上線后容錯機制如何設定，產(chǎn)品設計、開發(fā)設計盡量面向未來等，這樣多考慮的目的就是避免上線后發(fā)現(xiàn)需要重新大改的風險。

2）產(chǎn)品上線后

建立雙方運維機制，上線不代表著結束，外圍系統(tǒng)人員必須配合一起試點推廣、全面推廣、日常運維等事宜。比如上線時需要準備什么配置項，遇到問題外圍系統(tǒng)人員需找產(chǎn)品、開發(fā)還是運維來解決？尤其是異常場景，比如外圍系統(tǒng)停機發(fā)版時，如何保證雙方系統(tǒng)數(shù)據(jù)準確等事宜。

比如，業(yè)務系統(tǒng)某付款單，需推送資金系統(tǒng)進行付款，但因資金系統(tǒng)停機，業(yè)務系統(tǒng)并未提前準備，則導致付款單推送失敗，用戶未在規(guī)定時間進行付款，造成客戶投訴。此類問題，有幾種解決方案，根據(jù)大家實際情況可自行選擇或延伸思考。

第一種需開發(fā)，如果單據(jù)量較大，并且系統(tǒng)自動識別報錯原因，衡量開發(fā)投入產(chǎn)出比較高，則可開發(fā)報錯提醒功能，如遇到付款單推送失敗報錯，則郵件提醒技術或產(chǎn)品人員。技術人員看到提醒郵件，則可手工再重推，也可再開發(fā)自動重推功能，針對失敗單據(jù)，如判斷是因為停機推送失敗則重推。

第二種人為要求，要求外圍系統(tǒng)每次停機前必須通知上下游系統(tǒng)進行準備，獲取到停機通知后，再通過郵件或工作群通知用戶避免停機期間操作系統(tǒng)數(shù)據(jù)。

第三種技術手工處理，針對單據(jù)量不大且不緊急情況，則技術人員獲取停機通知的第二天則手工處理，并且要求外圍系統(tǒng)避免業(yè)務單據(jù)量高峰期進行停機發(fā)版。

以上案例中只是拋磚引玉，目的是需要大家有意識的考慮多一些，完整流程跑一遍，無論是大概率的業(yè)務場景，還是小概率的停機場景，都保證和外圍系統(tǒng)對接完整，提前演練就避免生產(chǎn)環(huán)境大批量數(shù)據(jù)錯誤。

第二類：被動配合其他部門

筆者今年的兩個項目就是屬于此類，這類項目，其實坑更大。原因是服務的用戶不屬于自己產(chǎn)品范圍，對產(chǎn)品的目標、產(chǎn)品范圍邊界、產(chǎn)品方案、推廣上線等環(huán)節(jié)，都拿不準，因為服務的用戶是財務人員，而我并沒有專業(yè)的財務知識，則只能依賴財務系統(tǒng)人員。

相信很多業(yè)務型產(chǎn)品經(jīng)理應該理解這種痛，自己產(chǎn)品作為上游業(yè)務系統(tǒng)，需要為下游財務做賬系統(tǒng)提供業(yè)務數(shù)據(jù)，自己無法針對間接系統(tǒng)的財務用戶做調研。如果遇到能力強、好溝通的外圍系統(tǒng)對接人還好，自己還能趁此項目多學習多考慮，悲催的就是遇到不好溝通，但是喜歡甩鍋的人，這個也在職場上很常見，畢竟每個人都沒有幫助別人的義務。

對，我今年的兩個項目，其中一個就遇到了類似情況。

外圍系統(tǒng)找到我需要我做相應的功能改造，并按照他們要求出方案時，我還是比較懵的。因為我主業(yè)是負責好我的業(yè)務系統(tǒng)，服務好我的目標業(yè)務用戶，而非外圍的財務用戶。所以我就不斷問項目目標、項目具體背景、目前現(xiàn)狀、需要解決哪些問題、用戶需要什么時，這些基礎調研的問題，我都沒用從外圍系統(tǒng)對接人找到答案，即使上線了，也沒給我明確的回復。果不其然，上線后遭到財務用戶的投訴，究其原因有兩方面，一個是業(yè)務系統(tǒng)堆積幾年的歷史數(shù)據(jù)未處理，另一個是業(yè)務系統(tǒng)的細分場景并未被財務提出如何做賬，導致方案不完善，數(shù)據(jù)錯亂。

遇到這種問題，根本原因，還是人的原因。如果想不清楚就下手，肯定會有錯誤風險，開始上線沒問題，只是說明業(yè)務量不大，后續(xù)業(yè)務量上來，就會報錯。

今年經(jīng)歷了這次事故后，我反思職場中確實會有各種各樣的磕磕絆絆，如果只抱怨別人沒做好，就停滯不前，確實也對不起自己投入的時間。于是我化被動為主動，想辦法繞過外圍系統(tǒng)對接人，直接找到外圍系統(tǒng)使用的用戶、外圍系統(tǒng)所在業(yè)務的專家、相類似崗位的其他人員、此對接人的領導等等，側面或正面的反復了解業(yè)務背景、明確項目目標，主動和外圍系統(tǒng)用戶進行溝通確認方案范圍、方案細節(jié)，涉及歷史數(shù)據(jù)、主流程場景方案、逆向場景或小概率場景方案等，不斷迭代優(yōu)化，而不只是因為自己不熟悉外圍系統(tǒng)業(yè)務就不再向前。

所以，即使被動配合其他部門的項目，內心也要化被動為主動，積極促進項目進展。

三、避免麻木大意、建立運維響應機制

項目好不容易上線了，此時就皆大歡喜，不再盯著了嗎？萬萬不可，殊不知，項目挺過從0到1，卻因為1到N 時栽了大跟頭。

就像筆者遇到了一個項目，開發(fā)上線推廣迭代經(jīng)歷了一年，后面需求逐漸變少，開發(fā)維護投入逐漸減少，就不太在意此項目。誰知道，日常運維類項目突然出現(xiàn)了大批量數(shù)據(jù)問題，究其原因，此類合作方項目，因為上游變動，未衡量變動點對下游的影響，就自行變動，導致下游出錯。所以無論是合作方項目對接外圍系統(tǒng)，還是自有項目，都需以不變的運維機制對應變化的部分。

那么運維機制是什么呢？如何管理運維人員識別風險呢？

首先，需統(tǒng)一一個官方的項目群，尤其是合作方項目，會拉入上下游系統(tǒng)人員、對應業(yè)務人員入群，一有問題就拉小群，導致信息分散，運維人員也抱怨問題太多不集中，無法快速處理。還有的用戶除了拉群，還有郵件、報障系統(tǒng)等，問題分散多方，無法集中處理和分析。建立一個唯一的官方項目群，就是目的大家信息拉通，不在雞同鴨講。

其次，共享文檔非常重要，翻群消息大家都比較頭疼，尤其是多業(yè)務系統(tǒng)人員和不同公司的不同業(yè)務人員的大群，大家只關心自己的那一部分，如果看群消息很難找。所以統(tǒng)一官方群里的官方共享文檔就非常重要，統(tǒng)一的問題內容、登記時間、方案回復、截圖格式等，都讓人快速找到問題和解決方案，也有利于后續(xù)產(chǎn)品和運維進行問題分析，有助于產(chǎn)品優(yōu)化。

然后，定期的培訓也非常有必要，如有業(yè)務系統(tǒng)變更，運維人員需警惕，快速識別對上下游系統(tǒng)的影響，評估是否需要優(yōu)化各自系統(tǒng)等等，如優(yōu)化后，要及時培訓用戶，提升用戶使用系統(tǒng)的效率。

以上就是自己產(chǎn)品對接外圍系統(tǒng)的經(jīng)驗，供大家參考。