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

在一個(gè)公司中免不了有很多業(yè)務(wù)需要對(duì)外合作，當(dāng)業(yè)務(wù)規(guī)模成長(zhǎng)到一定階段后就需要技術(shù)的介入：解放生產(chǎn)力，降低成本，提高效率。

此時(shí)，產(chǎn)品經(jīng)理在了解業(yè)務(wù)需求、調(diào)研需求、解決需求的過(guò)程中就需要接觸到各個(gè)外部接口。

一、API的認(rèn)知

1. 場(chǎng)景舉例

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

上述兩個(gè)場(chǎng)景中，我們可以明顯得到的信息是人工生產(chǎn)力已經(jīng)不能滿足當(dāng)前公司業(yè)務(wù)的發(fā)展需求了。

那在這個(gè)時(shí)候，API就要開(kāi)始大顯身手，產(chǎn)品經(jīng)理需要從技術(shù)層面來(lái)解放生產(chǎn)力。

2. 什么是API？

Application Programming Interface，應(yīng)用程序編程接口，即單方面約定一些預(yù)先定義的數(shù)組或字段，便于模塊外開(kāi)發(fā)人員獲取信息并了解API想表達(dá)的細(xì)節(jié)。

API應(yīng)用到上述場(chǎng)景中，即為了解決兩個(gè)主要的問(wèn)題：

1. 快速上線產(chǎn)品到OTA平臺(tái)：通過(guò)API將完整的產(chǎn)品拆分為若干模塊，在符合平臺(tái)要求的場(chǎng)景下傳輸?shù)狡脚_(tái)上完成上線，并且可以自動(dòng)化的更新多個(gè)平臺(tái)的產(chǎn)品信息、價(jià)格、庫(kù)存等；
2. 快速獲取OTA平臺(tái)訂單信息：通過(guò)API的訂閱或主動(dòng)查詢，以最快速度獲取到各個(gè)平臺(tái)的訂單詳情，通過(guò)標(biāo)準(zhǔn)解析后統(tǒng)一輸出到自有ERP中進(jìn)行相關(guān)處理。

還是不懂？

再舉一個(gè)直白的例子：

小時(shí)候媽媽經(jīng)常讓我去打醬油，每次都要去村口很遠(yuǎn)的小賣(mài)部去付錢(qián)購(gòu)買(mǎi)，再拿醬油回家；一貪玩把醬油摔壞了，回家騙媽媽說(shuō)小賣(mài)部不賣(mài)醬油了，錢(qián)掉了，一頓胖揍（人工搬單、效率低下、責(zé)任不清）。

時(shí)代進(jìn)步，現(xiàn)在有了微信，媽媽再也不用我打醬油了。

媽媽微信里面問(wèn)詢：老板，醬油一瓶（API數(shù)據(jù)請(qǐng)求）。

老板回復(fù)：30元起送，一瓶不夠（API響應(yīng)報(bào)錯(cuò)）。

媽媽再次問(wèn)詢：老板，10瓶醬油（API重試，數(shù)據(jù)請(qǐng)求）。

老板回復(fù)：好勒，10分鐘送到，30元，老規(guī)矩微信支付（API響應(yīng)成功）。

媽媽?zhuān)何⑿偶t包30元（調(diào)用其他API接口請(qǐng)求）。

老板：已收款（API響應(yīng)成功并確認(rèn)）。

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

二、業(yè)務(wù)側(cè)的理解

此時(shí)的流程與正常的需求處理是完全一致，需要全面的了解業(yè)務(wù)側(cè)的真實(shí)意圖，并針對(duì)API進(jìn)行相關(guān)調(diào)研，最后進(jìn)行需求的確認(rèn)。

1. 業(yè)務(wù)想要的是什么？

我們需要對(duì)業(yè)務(wù)的兩個(gè)場(chǎng)景進(jìn)行拆分，通過(guò)場(chǎng)景一分析，見(jiàn)圖1，可得業(yè)務(wù)方想得到為“拒單率3%以內(nèi)”。

淘寶購(gòu)物都知道供應(yīng)商拒單無(wú)非三個(gè)方面：沒(méi)貨了，價(jià)格漲價(jià)了，產(chǎn)品拍錯(cuò)了；即要降低拒單率，在這三個(gè)方面進(jìn)行優(yōu)化即可。

“及時(shí)確認(rèn)率98%以上”：及時(shí)與確認(rèn)是兩個(gè)維度，一個(gè)要求對(duì)時(shí)間掌控強(qiáng)，一個(gè)要求訂單要確認(rèn)成功；即我們需要深入分析如何提高及時(shí)響應(yīng)訂單，成功確認(rèn)訂單（與上一個(gè)需求環(huán)環(huán)相扣）。

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

圖1 場(chǎng)景一需求拆分

場(chǎng)景二的分析，業(yè)務(wù)方的需求比較簡(jiǎn)單，即實(shí)現(xiàn)快速上線。但我們對(duì)需求進(jìn)行拆分挖掘（見(jiàn)圖2），發(fā)現(xiàn)需求除了要求上線產(chǎn)品基本內(nèi)容+價(jià)格庫(kù)存外，其實(shí)還有一個(gè)非常重要的隱藏需求，即下單相關(guān)屬性的需求（因?yàn)椴糠之a(chǎn)品上線前就要預(yù)置下單信息，例如必填信息，是否限購(gòu)等）。

綜上所述，本需求除了產(chǎn)品API，還應(yīng)該去匹配API中其他必要字段，并可能需要有分平臺(tái)的管理系統(tǒng)來(lái)分別匹配各自平臺(tái)的不同字段需求。

圖2 場(chǎng)景二需求拆分

2. API怎么做需求調(diào)研？

很多人會(huì)問(wèn)上面的需求是怎么分析得到的？API不就是完成數(shù)據(jù)解析，存儲(chǔ)就可以了嗎？

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

API的需求調(diào)研主要分為兩個(gè)方面來(lái)做：

首先，將業(yè)務(wù)分為已經(jīng)存在的業(yè)務(wù)優(yōu)化方向以及新增業(yè)務(wù)的功能新增方向。

• 已經(jīng)存在的業(yè)務(wù)優(yōu)化方向：例如已經(jīng)接入了A平臺(tái)，現(xiàn)在要接B平臺(tái)，工作量一致，內(nèi)容相似度較高，只需要將我們之前積累的對(duì)接經(jīng)驗(yàn)搬出來(lái)套用即可；
• 新增業(yè)務(wù)的功能新增方向：例如已經(jīng)接入了產(chǎn)品更新功能，現(xiàn)在要接入訂單確認(rèn)功能，完全不同的業(yè)務(wù)，需要我們重新分析業(yè)務(wù)需求，重新定義接口數(shù)據(jù)。

此時(shí)，我們?cè)倩貋?lái)對(duì)之前的場(chǎng)景一、二進(jìn)行深度挖掘與分析。

場(chǎng)景一中對(duì)于拒單率的要求，我們初步理解為其實(shí)是對(duì)庫(kù)存、售價(jià)、產(chǎn)品內(nèi)容的要求，針對(duì)性的場(chǎng)景中需要滿足我們對(duì)庫(kù)存的分發(fā)實(shí)時(shí)把控，可以理解為某個(gè)平臺(tái)庫(kù)存為0并不等于總庫(kù)存為0，此時(shí)我們需要采用總分的結(jié)構(gòu)來(lái)設(shè)計(jì)功能；針對(duì)價(jià)格的更新亦是同樣的道理，針對(duì)不同平臺(tái)的人群畫(huà)像，其采用的銷(xiāo)售策略是完全不一致的。

但是針對(duì)產(chǎn)品內(nèi)容來(lái)說(shuō)，則需要保持高度一致，因?yàn)樗械娜顺鲇萎a(chǎn)品是一致的那披露的內(nèi)容也應(yīng)該是一致的，必須要做到全平臺(tái)的一致，既范了流程，也節(jié)約了后續(xù)開(kāi)發(fā)工作量，如圖3。

圖3 場(chǎng)景一需求進(jìn)一步拆分

在場(chǎng)景二中，需求比較單一，但是如果我們只是單純完成業(yè)務(wù)方的表面需求上線產(chǎn)品，我們會(huì)在兩個(gè)階段發(fā)現(xiàn)問(wèn)題：某些平臺(tái)上線產(chǎn)品，發(fā)現(xiàn)某些非產(chǎn)品信息的參數(shù)為空是不能上線的，例如每單起訂人數(shù)，是否分成人兒童，超過(guò)規(guī)定展示的SKU數(shù)量的取舍；或在第二個(gè)階段上線后，業(yè)務(wù)方發(fā)現(xiàn)很多產(chǎn)品需要二次匹配上述參數(shù)，此時(shí)會(huì)再次提出類(lèi)似需求。

所以，我們?cè)谛枨笸诰螂A段應(yīng)該盡可能發(fā)現(xiàn)業(yè)務(wù)方的隱藏需求，并評(píng)估是否在本次范圍內(nèi)一并滿足，如圖4。

圖4 場(chǎng)景二需求進(jìn)一步拆分

3. 需求的進(jìn)一步確認(rèn)

在我們完成前一個(gè)階段的需求挖掘后，我們需要進(jìn)行需求的確認(rèn)，可以理解為需求拆分了之后進(jìn)一步確認(rèn)需求該怎么做，該在哪個(gè)模塊做，以及最后的收益與風(fēng)險(xiǎn)評(píng)估。

需求該怎么做？

按照上文的思路，還是進(jìn)行拆分：

1）如果已有ERP，那就是數(shù)據(jù)接入。此時(shí)你的架構(gòu)已經(jīng)成型，或者內(nèi)部規(guī)范已有，并不能做太多的變化，只需要按照已有經(jīng)驗(yàn)獲取字段、映射字段、處理字段即可。

2）如果沒(méi)有ERP，要從頭開(kāi)始接入，在前期的設(shè)計(jì)中就需要考慮兩個(gè)方面：

1. 自身業(yè)務(wù)的通用性，即業(yè)務(wù)內(nèi)部流轉(zhuǎn)并不受外部API的影響，例如我在X寶上賣(mài)衣服時(shí)可以通過(guò)這套系統(tǒng)訂貨，不在X寶上售賣(mài)時(shí)我正常的線下門(mén)店也可以利用此套系統(tǒng)進(jìn)行訂貨和結(jié)算；
2. 對(duì)外的可拓展性，即業(yè)務(wù)可以接收多個(gè)平臺(tái)的數(shù)據(jù)，例如我即在X寶上售賣(mài)衣服，也在X東上買(mǎi)衣服，但都可以通過(guò)這套系統(tǒng)進(jìn)行訂貨和結(jié)算。

結(jié)合這兩方面，我們傾向于用兩個(gè)平臺(tái)來(lái)處理，內(nèi)部ERP處理自有訂單或內(nèi)部關(guān)聯(lián)邏輯的處理；外部API平臺(tái)著重處理的交互處理、規(guī)范處理，可拓展性體現(xiàn)在無(wú)論哪個(gè)平臺(tái)的數(shù)據(jù)均需要處理后按標(biāo)準(zhǔn)數(shù)據(jù)輸出。

該在哪個(gè)模塊做？

電商的交互離不開(kāi)三大模塊：產(chǎn)品、訂單、財(cái)務(wù)。

推送產(chǎn)品去售賣(mài)，獲取訂單數(shù)據(jù)去預(yù)訂，最后進(jìn)行財(cái)務(wù)結(jié)算；我們只需要模仿人工處理時(shí)的流程，沿著流程進(jìn)行梳理。

產(chǎn)品上線>平臺(tái)售賣(mài)>平臺(tái)下單>我司后臺(tái)預(yù)訂>反饋平臺(tái)預(yù)訂成功>平臺(tái)結(jié)算>我司財(cái)務(wù)結(jié)算>訂單核銷(xiāo)

上述流程的拆分，即設(shè)計(jì)到三個(gè)管理模塊：產(chǎn)品管理、訂單管理、財(cái)務(wù)管理。針對(duì)此系統(tǒng)，我比較推薦如下的整體設(shè)計(jì)，如圖5，后續(xù)我們會(huì)詳細(xì)分模塊來(lái)說(shuō)明。

圖5 整體系統(tǒng)框架

4. 收益與風(fēng)險(xiǎn)評(píng)估

API的對(duì)接與其他需求評(píng)估一樣，也需要進(jìn)行“技術(shù)+工作量+收益”的綜合評(píng)估來(lái)審核是否值得展開(kāi)。

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

所以，業(yè)務(wù)口中的“技術(shù)一下就搞定，為什么要人去做？”，我們需要給出合理的解釋?zhuān)M量是可量化的數(shù)據(jù)。為此，我們一般采用ROI的評(píng)估模式進(jìn)行調(diào)研。

ROI=T時(shí)間段內(nèi)利潤(rùn)/研發(fā)投入成本，T=6個(gè)月/12月/18個(gè)月，三個(gè)時(shí)間節(jié)點(diǎn)來(lái)預(yù)估產(chǎn)出。

• 當(dāng)ROI>1，且T=6/12/18時(shí)符合項(xiàng)目投入期望，如果T越大，ROI越高則后期回報(bào)越高；
• 當(dāng)ROI<1,且T=6時(shí)表明項(xiàng)目短期內(nèi)效益不佳，需要繼續(xù)查看12/18個(gè)月收益預(yù)期，綜合評(píng)估；
• 當(dāng)ROI<1,且T=6/12/18時(shí)不宜投入。

風(fēng)險(xiǎn)評(píng)估也是必須可少的項(xiàng)目，除了上述的評(píng)估，此外接口的穩(wěn)定性、可靠性，數(shù)據(jù)的安全性，項(xiàng)目整體的預(yù)計(jì)排期也是我們需要的。

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

后續(xù)筆者還將從API閱讀切入，加以實(shí)際案例分享來(lái)更生動(dòng)地說(shuō)明主旨。

感謝閱讀。

本文由 @寒松 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自 Unsplash，基于 CC0 協(xié)議