無論是C端還是B端，產品一般都不是孤立存在，而是整個業務流中的一環，所以也少不了和外部系統對接。那麼，如何高效對接外圍系統呢？本文作者結合自身經驗，總結了一些措施，希望能給你帶來幫助。
一、每個產品都不是孤立存在
無論是C端還是B端，某一產品一般都不是孤立存在，而是整個業務流中的一環。如果某產品屬於起始產品，產生資料後，也會連線下游產品，承接相應業務資料，完成整個業務流轉。比如獲客系統沉澱的客戶資訊、來源渠道等，都會流轉到下游交易系統，即客戶購買商品產生交易單，交易系統的交易資訊也會流轉到更下游的財務系統，負責單據的核算做賬等業務。
當然，理論上也沒有嚴格意義的起始產品，上述案例的獲客系統，其上游也會又獲客前的廣告系統、推廣運營活動系統，但某個公司的業務聚焦點是獲客後的交易，所以會以此公司主營業務範圍作為資訊產品的邊界。
另外，每個產品的上游和下游系統也不僅僅只有一個，主要是因為業務不是單線流程，而是網狀結構，不同業務流交叉形成複雜的業務生態。例如上述案例中的獲客系統，除了下游會有交易系統以外，可能還會有專門的會員系統、積分系統等作為下游系統，主要是因為為滿足使用者需求，背後會有一系列產品為其服務。
既然大多數產品是業務流程中的某一環，那就少不了和外部系統對接，這裡包括外部公司系統，如外部銀行、微信、支付寶支付渠道介面等，也包括內部公司其他系統。合作專案是否能成功上線、成功推廣，除了自己產品開發好，外圍系統是否能對接好也是非常重要。那麼如何高效對接外圍系統呢？筆者透過實踐總結以下事半功倍的措施，希望有幫助。
二、防止出錯，提前預判
合作類專案跨部門協調溝通，需要有明確的目標、各自負責的範圍、互通資料的流程。但很多時候，以上流程是不清晰的，會導致專案進度受阻，或是專案上線後出現問題互相扯皮的情況，所以在專案開始前明確出來就非常重要。
整體流程包括：明確產品目標、梳理業務流程圖、明確各自產品負責的範圍及產品方案、督促雙方開發按進度完成上線、共同建立清晰的運維機制。根據實際工作經驗，以下分為兩類合作專案介紹，以及容易踩坑點。
第一類：主動找其他部門配合
如果是產品經理自己負責的產品需要其他部門配合，則更像大產品經理，除了負責自己產品以外，更多的是站在整體角度，明確專案目標，帶著各方系統一起做。對個人的壓力會大一些，因為要對內對外協調很多資源，涉及具體要做什麼事兒、需要誰來配合、如果對方不配合怎麼辦、配合後雙方系統的產品範圍有重複交叉或是三不管地帶怎麼辦、上線後用戶投訴互相甩鍋怎麼辦等等問題。
筆者負責的專案中就有以上類似問題，經過反思後，發現有些經驗總結後，大腦就會對下次專案啟動風險預判提醒。
1）產品上線前
重點給外圍系統對接人闡述專案背景、明確專案目標，督促對方出具產品方案和上線時間。當然，對方是否配合取決於錢和開發資源排期，錢上面就是對方報價是否合理，內部好解決些報工時打卡即可（專案制管理的公司，會將每個開發人員打卡專案來衡量資源配比是否合理），外部則需找採購進行評估。
如果對方報價太高，則積極找相關利益方進行協調，比如換供應商、採購進行溝通調價等。如果對方報價合理，則進入方案確認，開發排期環節。此處需重點注意，儘量細化方案細節，比如正向流程、逆向流程，大機率場景、小機率場景，包括上線後容錯機制如何設定，產品設計、開發設計儘量面向未來等，這樣多考慮的目的就是避免上線後發現需要重新大改的風險。
2）產品上線後
建立雙方運維機制，上線不代表著結束，外圍系統人員必須配合一起試點推廣、全面推廣、日常運維等事宜。比如上線時需要準備什麼配置項，遇到問題外圍系統人員需找產品、開發還是運維來解決？尤其是異常場景，比如外圍系統停機發版時，如何保證雙方系統資料準確等事宜。
比如，業務系統某付款單，需推送資金系統進行付款，但因資金系統停機，業務系統並未提前準備，則導致付款單推送失敗，使用者未在規定時間進行付款，造成客戶投訴。此類問題，有幾種解決方案，根據大家實際情況可自行選擇或延伸思考。
第一種需開發，如果單據量較大，並且系統自動識別報錯原因，衡量開發投入產出比較高，則可開發報錯提醒功能，如遇到付款單推送失敗報錯，則郵件提醒技術或產品人員。技術人員看到提醒郵件，則可手工再重推，也可再開發自動重推功能，針對失敗單據，如判斷是因為停機推送失敗則重推。
第二種人為要求，要求外圍系統每次停機前必須通知上下游系統進行準備，獲取到停機通知後，再透過郵件或工作群通知使用者避免停機期間作業系統資料。
第三種技術手工處理，針對單據量不大且不緊急情況，則技術人員獲取停機通知的第二天則手工處理，並且要求外圍系統避免業務單據量高峰期進行停機發版。
以上案例中只是拋磚引玉，目的是需要大家有意識的考慮多一些，完整流程跑一遍，無論是大機率的業務場景，還是小機率的停機場景，都保證和外圍系統對接完整，提前演練就避免生產環境大批次資料錯誤。
第二類：被動配合其他部門
筆者今年的兩個專案就是屬於此類，這類專案，其實坑更大。原因是服務的使用者不屬於自己產品範圍，對產品的目標、產品範圍邊界、產品方案、推廣上線等環節，都拿不準，因為服務的使用者是財務人員，而我並沒有專業的財務知識，則只能依賴財務系統人員。
相信很多業務型產品經理應該理解這種痛，自己產品作為上游業務系統，需要為下游財務做賬系統提供業務資料，自己無法針對間接系統的財務使用者做調研。如果遇到能力強、好溝通的外圍系統對接人還好，自己還能趁此專案多學習多考慮，悲催的就是遇到不好溝通，但是喜歡甩鍋的人，這個也在職場上很常見，畢竟每個人都沒有幫助別人的義務。
對，我今年的兩個專案，其中一個就遇到了類似情況。
外圍系統找到我需要我做相應的功能改造，並按照他們要求出方案時，我還是比較懵的。因為我主業是負責好我的業務系統，服務好我的目標業務使用者，而非外圍的財務使用者。所以我就不斷問專案目標、專案具體背景、目前現狀、需要解決哪些問題、使用者需要什麼時，這些基礎調研的問題，我都沒用從外圍系統對接人找到答案，即使上線了，也沒給我明確的回覆。果不其然，上線後遭到財務使用者的投訴，究其原因有兩方面，一個是業務系統堆積幾年的歷史資料未處理，另一個是業務系統的細分場景並未被財務提出如何做賬，導致方案不完善，資料錯亂。
遇到這種問題，根本原因，還是人的原因。如果想不清楚就下手，肯定會有錯誤風險，開始上線沒問題，只是說明業務量不大，後續業務量上來，就會報錯。
今年經歷了這次事故後，我反思職場中確實會有各種各樣的磕磕絆絆，如果只抱怨別人沒做好，就停滯不前，確實也對不起自己投入的時間。於是我化被動為主動，想辦法繞過外圍系統對接人，直接找到外圍系統使用的使用者、外圍系統所在業務的專家、相類似崗位的其他人員、此對接人的領導等等，側面或正面的反覆瞭解業務背景、明確專案目標，主動和外圍系統使用者進行溝通確認方案範圍、方案細節，涉及歷史資料、主流程場景方案、逆向場景或小機率場景方案等，不斷迭代最佳化，而不只是因為自己不熟悉外圍系統業務就不再向前。
所以，即使被動配合其他部門的專案，內心也要化被動為主動，積極促進專案進展。
三、避免麻木大意、建立運維響應機制
專案好不容易上線了，此時就皆大歡喜，不再盯著了嗎？萬萬不可，殊不知，專案挺過從0到1，卻因為1到N 時栽了大跟頭。
就像筆者遇到了一個專案，開發上線推廣迭代經歷了一年，後面需求逐漸變少，開發維護投入逐漸減少，就不太在意此專案。誰知道，日常運維類專案突然出現了大批次資料問題，究其原因，此類合作方專案，因為上游變動，未衡量變動點對下游的影響，就自行變動，導致下游出錯。所以無論是合作方專案對接外圍系統，還是自有專案，都需以不變的運維機制對應變化的部分。
那麼運維機制是什麼呢？如何管理運維人員識別風險呢？
首先，需統一一個官方的專案群，尤其是合作方專案，會拉入上下游系統人員、對應業務人員入群，一有問題就拉小群，導致資訊分散，運維人員也抱怨問題太多不集中，無法快速處理。還有的使用者除了拉群，還有郵件、報障系統等，問題分散多方，無法集中處理和分析。建立一個唯一的官方專案群，就是目的大家資訊拉通，不在雞同鴨講。
其次，共享文件非常重要，翻群訊息大家都比較頭疼，尤其是多業務系統人員和不同公司的不同業務人員的大群，大家只關心自己的那一部分，如果看群訊息很難找。所以統一官方群裡的官方共享文件就非常重要，統一的問題內容、登記時間、方案回覆、截圖格式等，都讓人快速找到問題和解決方案，也有利於後續產品和運維進行問題分析，有助於產品最佳化。
然後，定期的培訓也非常有必要，如有業務系統變更，運維人員需警惕，快速識別對上下游系統的影響，評估是否需要最佳化各自系統等等，如最佳化後，要及時培訓使用者，提升使用者使用系統的效率。
以上就是自己產品對接外圍系統的經驗，供大家參考。
本文由@元方 原創釋出於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。