如何快速閱讀一個API并且轉化為線上場景應用，這應該是產品經理尤其是B端產品經理必備的技能。本系列文章將從筆者親身的一些OTA旅游產品對接經歷入手，分享一些踩過的坑，背過的鍋。

在一個公司中免不了有很多業務需要對外合作，當業務規模成長到一定階段后就需要技術的介入：解放生產力，降低成本，提高效率。

此時，產品經理在了解業務需求、調研需求、解決需求的過程中就需要接觸到各個外部接口。

一、API的認知

1. 場景舉例

• 場景一：某平臺對商戶出了最新的考核標準，要求拒單率控制在3%以內，及時確認率控制在98%以上，我們還差得遠——來自運營的憂慮。
• 場景二：公司有一批很好的門票產品，在我們的自己的渠道銷售得非常好，現在公司想把這些產品放到幾個OTA上去售賣，并且資源可控可以滿足運營與要求。但是數量是1000條，假設上線到3個平臺，按照1個員工手動搬運產品（Ctrl+C然后Ctrl+V），6條/天/人，處理完3個平臺需要500個工作日，約2年。

上述兩個場景中，我們可以明顯得到的信息是人工生產力已經不能滿足當前公司業務的發展需求了。

那在這個時候，API就要開始大顯身手，產品經理需要從技術層面來解放生產力。

2. 什么是API？

Application Programming Interface，應用程序編程接口，即單方面約定一些預先定義的數組或字段，便于模塊外開發人員獲取信息并了解API想表達的細節。

API應用到上述場景中，即為了解決兩個主要的問題：

1. 快速上線產品到OTA平臺：通過API將完整的產品拆分為若干模塊，在符合平臺要求的場景下傳輸到平臺上完成上線，并且可以自動化的更新多個平臺的產品信息、價格、庫存等；
2. 快速獲取OTA平臺訂單信息：通過API的訂閱或主動查詢，以最快速度獲取到各個平臺的訂單詳情，通過標準解析后統一輸出到自有ERP中進行相關處理。

還是不懂？

再舉一個直白的例子：

小時候媽媽經常讓我去打醬油，每次都要去村口很遠的小賣部去付錢購買，再拿醬油回家；一貪玩把醬油摔壞了，回家騙媽媽說小賣部不賣醬油了，錢掉了，一頓胖揍（人工搬單、效率低下、責任不清）。

時代進步，現在有了微信，媽媽再也不用我打醬油了。

媽媽微信里面問詢：老板，醬油一瓶（API數據請求）。

老板回復：30元起送，一瓶不夠（API響應報錯）。

媽媽再次問詢：老板，10瓶醬油（API重試，數據請求）。

老板回復：好勒，10分鐘送到，30元，老規矩微信支付（API響應成功）。

媽媽：微信紅包30元（調用其他API接口請求）。

老板：已收款（API響應成功并確認）。

流程結束，效率提升，責任清晰，有聊天記錄（日志）可查。

二、業務側的理解

此時的流程與正常的需求處理是完全一致，需要全面的了解業務側的真實意圖，并針對API進行相關調研，最后進行需求的確認。

1. 業務想要的是什么？

我們需要對業務的兩個場景進行拆分，通過場景一分析，見圖1，可得業務方想得到為“拒單率3%以內”。

淘寶購物都知道供應商拒單無非三個方面：沒貨了，價格漲價了，產品拍錯了；即要降低拒單率，在這三個方面進行優化即可。

“及時確認率98%以上”：及時與確認是兩個維度，一個要求對時間掌控強，一個要求訂單要確認成功；即我們需要深入分析如何提高及時響應訂單，成功確認訂單（與上一個需求環環相扣）。

綜上所述，我們需要的API不僅要滿足產品更新的需求，也需要滿足訂單的需求。

圖1 場景一需求拆分

場景二的分析，業務方的需求比較簡單，即實現快速上線。但我們對需求進行拆分挖掘（見圖2），發現需求除了要求上線產品基本內容+價格庫存外，其實還有一個非常重要的隱藏需求，即下單相關屬性的需求（因為部分產品上線前就要預置下單信息，例如必填信息，是否限購等）。

綜上所述，本需求除了產品API，還應該去匹配API中其他必要字段，并可能需要有分平臺的管理系統來分別匹配各自平臺的不同字段需求。

圖2 場景二需求拆分

2. API怎么做需求調研？

很多人會問上面的需求是怎么分析得到的？API不就是完成數據解析，存儲就可以了嗎？

此言差矣，API數據接入其實只是API接入的一小部分，更多是數據接入后的處理兼容，以及如何讓數據發光發熱。

API的需求調研主要分為兩個方面來做：

首先，將業務分為已經存在的業務優化方向以及新增業務的功能新增方向。

• 已經存在的業務優化方向：例如已經接入了A平臺，現在要接B平臺，工作量一致，內容相似度較高，只需要將我們之前積累的對接經驗搬出來套用即可；
• 新增業務的功能新增方向：例如已經接入了產品更新功能，現在要接入訂單確認功能，完全不同的業務，需要我們重新分析業務需求，重新定義接口數據。

此時，我們再回來對之前的場景一、二進行深度挖掘與分析。

場景一中對于拒單率的要求，我們初步理解為其實是對庫存、售價、產品內容的要求，針對性的場景中需要滿足我們對庫存的分發實時把控，可以理解為某個平臺庫存為0并不等于總庫存為0，此時我們需要采用總分的結構來設計功能；針對價格的更新亦是同樣的道理，針對不同平臺的人群畫像，其采用的銷售策略是完全不一致的。

但是針對產品內容來說，則需要保持高度一致，因為所有的人出游產品是一致的那披露的內容也應該是一致的，必須要做到全平臺的一致，既范了流程，也節約了后續開發工作量，如圖3。

圖3 場景一需求進一步拆分

在場景二中，需求比較單一，但是如果我們只是單純完成業務方的表面需求上線產品，我們會在兩個階段發現問題：某些平臺上線產品，發現某些非產品信息的參數為空是不能上線的，例如每單起訂人數，是否分成人兒童，超過規定展示的SKU數量的取舍；或在第二個階段上線后，業務方發現很多產品需要二次匹配上述參數，此時會再次提出類似需求。

所以，我們在需求挖掘階段應該盡可能發現業務方的隱藏需求，并評估是否在本次范圍內一并滿足，如圖4。

圖4 場景二需求進一步拆分

3. 需求的進一步確認

在我們完成前一個階段的需求挖掘后，我們需要進行需求的確認，可以理解為需求拆分了之后進一步確認需求該怎么做，該在哪個模塊做，以及最后的收益與風險評估。

需求該怎么做？

按照上文的思路，還是進行拆分：

1）如果已有ERP，那就是數據接入。此時你的架構已經成型，或者內部規范已有，并不能做太多的變化，只需要按照已有經驗獲取字段、映射字段、處理字段即可。

2）如果沒有ERP，要從頭開始接入，在前期的設計中就需要考慮兩個方面：

1. 自身業務的通用性，即業務內部流轉并不受外部API的影響，例如我在X寶上賣衣服時可以通過這套系統訂貨，不在X寶上售賣時我正常的線下門店也可以利用此套系統進行訂貨和結算；
2. 對外的可拓展性，即業務可以接收多個平臺的數據，例如我即在X寶上售賣衣服，也在X東上買衣服，但都可以通過這套系統進行訂貨和結算。

結合這兩方面，我們傾向于用兩個平臺來處理，內部ERP處理自有訂單或內部關聯邏輯的處理；外部API平臺著重處理的交互處理、規范處理，可拓展性體現在無論哪個平臺的數據均需要處理后按標準數據輸出。

該在哪個模塊做？

電商的交互離不開三大模塊：產品、訂單、財務。

推送產品去售賣，獲取訂單數據去預訂，最后進行財務結算；我們只需要模仿人工處理時的流程，沿著流程進行梳理。

產品上線>平臺售賣>平臺下單>我司后臺預訂>反饋平臺預訂成功>平臺結算>我司財務結算>訂單核銷

上述流程的拆分，即設計到三個管理模塊：產品管理、訂單管理、財務管理。針對此系統，我比較推薦如下的整體設計，如圖5，后續我們會詳細分模塊來說明。

圖5 整體系統框架

4. 收益與風險評估

API的對接與其他需求評估一樣，也需要進行“技術+工作量+收益”的綜合評估來審核是否值得展開。

例如，API處理流程復雜，雖然上線后可以解決很大的問題，但是其研發費用為10W，人工1人/年/5W支撐，即我司開發成本需要兩年才能cover，這樣的項目并不是緊急且重要的。

所以，業務口中的“技術一下就搞定，為什么要人去做？”，我們需要給出合理的解釋，盡量是可量化的數據。為此，我們一般采用ROI的評估模式進行調研。

ROI=T時間段內利潤/研發投入成本，T=6個月/12月/18個月，三個時間節點來預估產出。

• 當ROI>1，且T=6/12/18時符合項目投入期望，如果T越大，ROI越高則后期回報越高；
• 當ROI<1,且T=6時表明項目短期內效益不佳，需要繼續查看12/18個月收益預期，綜合評估；
• 當ROI<1,且T=6/12/18時不宜投入。

風險評估也是必須可少的項目，除了上述的評估，此外接口的穩定性、可靠性，數據的安全性，項目整體的預計排期也是我們需要的。

API講求高效處理，如果排期較久可能并不利于解決業務面臨的問題。

后續筆者還將從API閱讀切入，加以實際案例分享來更生動地說明主旨。

感謝閱讀。

本文由 @寒松 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議