最近在公司內部負責兩個微信小程序項目，于是將許久沒有接觸的開發文檔閱讀工作又撿了起來。
很多人也許要問了，產品經理一定要讀開發文檔么，這個不是技術童鞋要做的事情么？客觀地來說，大多數時候你要是基于自己的平臺去開發產品，那么是不需要在開發文檔上花費多少心思的；但作為一個第三方平臺的產品經理（尤其如微信、支付寶等），閱讀平臺的API文檔，則是相當有必要的，也可以說是產品基本功吧。
那么，產品經理究竟該如何來閱讀API文檔呢？
什么是API
API，全稱是Application Programming Interface，即應用程序編程接口，我們日常中習慣簡稱為“接口”。其實，接口這個詞大家應該不會陌生，比如我們平時比較常用的“USB接口”，就是用來存儲和傳輸數據用的；那什么是API呢，API事實上是在內部預先定義了函數，能夠使開發人員無須明白API內部實現的機制，就能夠實現某一個功能。
比如說你要實現一個手機注冊的功能，那么相應地后臺工程師就需要提供一個手機注冊的接口，前端開發人員在調用接口實現功能的時候，只需按照既定的規則進行請求即可，不需要去理解該功能的實現邏輯。有了這么一個機制，就使得開發人員間的協作變得非常簡潔、高效。
所以，你可以簡單地理解為“接口決定了功能”。
那API究竟是用來干嘛的呢？我的理解是，API其實是大自然的搬運工。如何理解這個“搬運工”的概念，其實就是指搬運互聯網數據，因為API的本質就是根據調用者的輸入內容來返回一些其他內容，不就相當于把數據搬來搬去么（這個搬運工的比喻是不是很形象）。
API文檔的結構
通常來說，一份API文檔內會包含多個API的信息，單個API的信息通常包括以下內容：
1、接口描述：這個接口是用來干嘛的，以及相關的規則
2、接口地址：以網址的形式展現，你通過發送請求給這個網址來對接口進行交互操作
3、請求方法：常用的有post和get兩種方式，一個是讀接口(常用get)一個是寫接口(常用post)
4、請求參數：請求該接口時，需要提供的參數，參數屬性包括名稱、類型、是否必填、描述等
5、返回參數：接口正常響應后，返回的內容
6、錯誤代碼：接口請求失敗后，返回的錯誤代碼
閱讀API文檔的好處
這個恐怕是大多數產品童鞋的疑惑，就是產品經理去閱讀開發文檔，究竟收益在哪里？從我個人的經驗出發，也許會有這么幾點收益：
1、對技術理解更深刻，讓產品更有想象力
試想這么一個場景，如果你是小程序的PM，但是又不去閱讀開發文檔，可能帶來的悲劇結果就是，微信開放了許多小程序的最新能力，但是你卻不知道如何應用到你自己的產品中去；或者，即使知道大概有那么一回事，卻不清楚具體可以做的操作細節有哪些，在自身產品中的應用場景在哪里，而往往產品細節和場景又是那么地重要。拿我自己實操的一個案例來說，就是因為當時沒有閱讀開發文檔，所以誤以為不能獲取微信群的名稱，只能獲取到微信群的id，導致最后在產品設計的時候沒有給用戶更好的綁定群信息感知的體驗。
說的直白一點，沒有新技術就沒有新的想象力（別問我想象力是什么）。
2、更好地預估開發工作量
長時間閱讀API文檔，可以對接口有更加深刻的認識，那么在和開發評估開發工作量的過程中，也是有幫助的。因為很多時候，產品和開發對新舊的理解不同，所以會造成這樣一種現象：新的功能不一定需要新的API，相似的功能可能需要重新做一個新的API。如果產品經理在熟悉了開發文檔之后，就能大幅減少這種情況的發生，評估一個新的功能開發工作量的時候，不會僅僅站在產品設計的角度（這兩個功能不是差不多么，所以基于之前的接口應該很快就能上線吧），還會站在開發的角度（噢，這里的確要兩個接口來實現），這樣也更有利于產品和開發童鞋的和平共處。
3、鍛煉產品抽象能力
事實上，接口本身就是個非常抽象的事物，大概在很久很久以前，有一個人跟我說過一句話，接口都是可以抽象起來進行復用的，但是前端卻是千變萬化的。嗯，其實一個厲害的產品經理，如果真的非常熟悉接口的話，他是可以做到像搭建樂高積木一樣，來通過現有的接口搭建產品的。聽說在騰訊內部，騰訊會將大系統盡量拆分成功能單一的模塊，在架構上盡量使用插件式的設計，高度解耦，并且會將業務邏輯服務化，比如將搖一搖、漂流瓶等都做成服務，供微信、QQ等開發團隊調用，這里調用的就是API。
總結
總的來說，對于第三方平臺的產品經理，熟悉官方API文檔，是非常有必要的一件事情。無論是從產品設計的角度，還是對于和開發的溝通協調，以及產品經理自身修養的提高等，都會有不少的幫助，可以讓你從更高的緯度去俯視整個產品。
也許，站的更高，真的能看的更遠呢。
