對(duì)于第三方平臺(tái)的產(chǎn)品經(jīng)理，熟悉官方API文檔，是非常有必要的一件事情。

最近在公司內(nèi)部負(fù)責(zé)兩個(gè)微信小程序項(xiàng)目，于是將許久沒(méi)有接觸的開(kāi)發(fā)文檔閱讀工作又撿了起來(lái)。

很多人也許要問(wèn)了，產(chǎn)品經(jīng)理一定要讀開(kāi)發(fā)文檔么？這個(gè)不是技術(shù)童鞋要做的事情么？

客觀地來(lái)說(shuō)，大多數(shù)時(shí)候你要是基于自己的平臺(tái)去開(kāi)發(fā)產(chǎn)品，那么是不需要在開(kāi)發(fā)文檔上花費(fèi)多少心思的；但作為一個(gè)第三方平臺(tái)的產(chǎn)品經(jīng)理（尤其如微信、支付寶等），閱讀平臺(tái)的API文檔，則是相當(dāng)有必要的，也可以說(shuō)是產(chǎn)品基本功吧。

那么，產(chǎn)品經(jīng)理究竟該如何來(lái)閱讀API文檔呢？

什么是API

API，全稱是Application Programming Interface，即應(yīng)用程序編程接口，我們?nèi)粘Ｖ辛?xí)慣簡(jiǎn)稱為“接口”。其實(shí)，接口這個(gè)詞大家應(yīng)該不會(huì)陌生，比如我們平時(shí)比較常用的“USB接口”，就是用來(lái)存儲(chǔ)和傳輸數(shù)據(jù)用的；那什么是API呢，API事實(shí)上是在內(nèi)部預(yù)先定義了函數(shù)，能夠使開(kāi)發(fā)人員無(wú)須明白API內(nèi)部實(shí)現(xiàn)的機(jī)制，就能夠?qū)崿F(xiàn)某一個(gè)功能。

比如說(shuō)你要實(shí)現(xiàn)一個(gè)手機(jī)注冊(cè)的功能，那么相應(yīng)地后臺(tái)工程師就需要提供一個(gè)手機(jī)注冊(cè)的接口，前端開(kāi)發(fā)人員在調(diào)用接口實(shí)現(xiàn)功能的時(shí)候，只需按照既定的規(guī)則進(jìn)行請(qǐng)求即可，不需要去理解該功能的實(shí)現(xiàn)邏輯。有了這么一個(gè)機(jī)制，就使得開(kāi)發(fā)人員間的協(xié)作變得非常簡(jiǎn)潔、高效。

所以，你可以簡(jiǎn)單地理解為“接口決定了功能”。

那API究竟是用來(lái)干嘛的呢？我的理解是，API其實(shí)是大自然的搬運(yùn)工。如何理解這個(gè)“搬運(yùn)工”的概念，其實(shí)就是指搬運(yùn)互聯(lián)網(wǎng)數(shù)據(jù)，因?yàn)锳PI的本質(zhì)就是根據(jù)調(diào)用者的輸入內(nèi)容來(lái)返回一些其他內(nèi)容，不就相當(dāng)于把數(shù)據(jù)搬來(lái)搬去么（這個(gè)搬運(yùn)工的比喻是不是很形象）。

API文檔的結(jié)構(gòu)

通常來(lái)說(shuō)，一份API文檔內(nèi)會(huì)包含多個(gè)API的信息，單個(gè)API的信息通常包括以下內(nèi)容：

• 接口描述：這個(gè)接口是用來(lái)干嘛的，以及相關(guān)的規(guī)則；
• 接口地址：以網(wǎng)址的形式展現(xiàn)，你通過(guò)發(fā)送請(qǐng)求給這個(gè)網(wǎng)址來(lái)對(duì)接口進(jìn)行交互操作；
• 請(qǐng)求方法：常用的有post和get兩種方式，一個(gè)是讀接口(常用get)一個(gè)是寫(xiě)接口（常用post）；
• 請(qǐng)求參數(shù)：請(qǐng)求該接口時(shí)，需要提供的參數(shù)，參數(shù)屬性包括名稱、類型、是否必填、描述等；
• 返回參數(shù)：接口正常響應(yīng)后，返回的內(nèi)容；
• 錯(cuò)誤代碼：接口請(qǐng)求失敗后，返回的錯(cuò)誤代碼。

小程序開(kāi)發(fā)文檔

閱讀API文檔的好處

這個(gè)恐怕是大多數(shù)產(chǎn)品童鞋的疑惑，就是產(chǎn)品經(jīng)理去閱讀開(kāi)發(fā)文檔，究竟收益在哪里？從我個(gè)人的經(jīng)驗(yàn)出發(fā)，也許會(huì)有這么幾點(diǎn)收益：

1、對(duì)技術(shù)理解更深刻，讓產(chǎn)品更有想象力

試想這么一個(gè)場(chǎng)景，如果你是小程序的PM，但是又不去閱讀開(kāi)發(fā)文檔，可能帶來(lái)的悲劇結(jié)果就是，微信開(kāi)放了許多小程序的最新能力，但是你卻不知道如何應(yīng)用到你自己的產(chǎn)品中去；或者，即使知道大概有那么一回事，卻不清楚具體可以做的操作細(xì)節(jié)有哪些，在自身產(chǎn)品中的應(yīng)用場(chǎng)景在哪里，而往往產(chǎn)品細(xì)節(jié)和場(chǎng)景又是那么地重要。拿我自己實(shí)操的一個(gè)案例來(lái)說(shuō)，就是因?yàn)楫?dāng)時(shí)沒(méi)有閱讀開(kāi)發(fā)文檔，所以誤以為不能獲取微信群的名稱，只能獲取到微信群的id，導(dǎo)致最后在產(chǎn)品設(shè)計(jì)的時(shí)候沒(méi)有給用戶更好的綁定群信息感知的體驗(yàn)。

說(shuō)的直白一點(diǎn)，沒(méi)有新技術(shù)就沒(méi)有新的想象力（別問(wèn)我想象力是什么）。

2、更好地預(yù)估開(kāi)發(fā)工作量

長(zhǎng)時(shí)間閱讀API文檔，可以對(duì)接口有更加深刻的認(rèn)識(shí)，那么在和開(kāi)發(fā)評(píng)估開(kāi)發(fā)工作量的過(guò)程中，也是有幫助的。因?yàn)楹芏鄷r(shí)候，產(chǎn)品和開(kāi)發(fā)對(duì)新舊的理解不同，所以會(huì)造成這樣一種現(xiàn)象：新的功能不一定需要新的API，相似的功能可能需要重新做一個(gè)新的API。如果產(chǎn)品經(jīng)理在熟悉了開(kāi)發(fā)文檔之后，就能大幅減少這種情況的發(fā)生，評(píng)估一個(gè)新的功能開(kāi)發(fā)工作量的時(shí)候，不會(huì)僅僅站在產(chǎn)品設(shè)計(jì)的角度（這兩個(gè)功能不是差不多么，所以基于之前的接口應(yīng)該很快就能上線吧），還會(huì)站在開(kāi)發(fā)的角度（噢，這里的確要兩個(gè)接口來(lái)實(shí)現(xiàn)），這樣也更有利于產(chǎn)品和開(kāi)發(fā)童鞋的和平共處。

3、鍛煉產(chǎn)品抽象能力

事實(shí)上，接口本身就是個(gè)非常抽象的事物，大概在很久很久以前，有一個(gè)人跟我說(shuō)過(guò)一句話，接口都是可以抽象起來(lái)進(jìn)行復(fù)用的，但是前端卻是千變?nèi)f化的。嗯，其實(shí)一個(gè)厲害的產(chǎn)品經(jīng)理，如果真的非常熟悉接口的話，他是可以做到像搭建樂(lè)高積木一樣，來(lái)通過(guò)現(xiàn)有的接口搭建產(chǎn)品的。聽(tīng)說(shuō)在騰訊內(nèi)部，騰訊會(huì)將大系統(tǒng)盡量拆分成功能單一的模塊，在架構(gòu)上盡量使用插件式的設(shè)計(jì)，高度解耦，并且會(huì)將業(yè)務(wù)邏輯服務(wù)化，比如將搖一搖、漂流瓶等都做成服務(wù)，供微信、QQ等開(kāi)發(fā)團(tuán)隊(duì)調(diào)用，這里調(diào)用的就是API。

總結(jié)

總的來(lái)說(shuō)，對(duì)于第三方平臺(tái)的產(chǎn)品經(jīng)理，熟悉官方API文檔，是非常有必要的一件事情。無(wú)論是從產(chǎn)品設(shè)計(jì)的角度，還是對(duì)于和開(kāi)發(fā)的溝通協(xié)調(diào)，以及產(chǎn)品經(jīng)理自身修養(yǎng)的提高等，都會(huì)有不少的幫助，可以讓你從更高的緯度去俯視整個(gè)產(chǎn)品。

也許，站的更高，真的能看的更遠(yuǎn)呢？

#專欄作家#

壹百度，微信公眾號(hào)：倒退集，人人都是產(chǎn)品經(jīng)理專欄作家。前在線教育企業(yè)服務(wù)領(lǐng)域產(chǎn)品經(jīng)理，創(chuàng)業(yè)公司Team Leader，曾主導(dǎo)多款重量級(jí)產(chǎn)品的產(chǎn)品策劃和設(shè)計(jì)工作；現(xiàn)人工智能領(lǐng)域高級(jí)PM。

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

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