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