最近在公司内部负责两个微信小程序项目，于是将许久没有接触的开发文档阅读工作又捡了起来。
很多人也许要问了，产品经理一定要读开发文档么？这个不是技术童鞋要做的事情么？
客观地来说，大多数时候你要是基于自己的平台去开发产品，那么是不需要在开发文档上花费多少心思的；但作为一个第三方平台的产品经理（尤其如微信、支付宝等），阅读平台的API文档，则是相当有必要的，也可以说是产品基本功吧。
那么，产品经理究竟该如何来阅读API文档呢？
什么是API
API，全称是Application Programming Interface，即应用程序编程接口，我们日常中习惯简称为“接口”。其实，接口这个词大家应该不会陌生，比如我们平时比较常用的“USB接口”，就是用来存储和传输数据用的；那什么是API呢，API事实上是在内部预先定义了函数，能够使开发人员无须明白API内部实现的机制，就能够实现某一个功能。
比如说你要实现一个手机注册的功能，那么相应地后台工程师就需要提供一个手机注册的接口，前端开发人员在调用接口实现功能的时候，只需按照既定的规则进行请求即可，不需要去理解该功能的实现逻辑。有了这么一个机制，就使得开发人员间的协作变得非常简洁、高效。
所以，你可以简单地理解为“接口决定了功能”。
那API究竟是用来干嘛的呢？我的理解是，API其实是大自然的搬运工。如何理解这个“搬运工”的概念，其实就是指搬运互联网数据，因为API的本质就是根据调用者的输入内容来返回一些其他内容，不就相当于把数据搬来搬去么（这个搬运工的比喻是不是很形象）。
API文档的结构
通常来说，一份API文档内会包含多个API的信息，单个API的信息通常包括以下内容：
- 接口描述：这个接口是用来干嘛的，以及相关的规则；
- 接口地址：以网址的形式展现，你通过发送请求给这个网址来对接口进行交互操作；
- 请求方法：常用的有post和get两种方式，一个是读接口(常用get)一个是写接口（常用post）；
- 请求参数：请求该接口时，需要提供的参数，参数属性包括名称、类型、是否必填、描述等；
- 返回参数：接口正常响应后，返回的内容；
- 错误代码：接口请求失败后，返回的错误代码。
阅读API文档的好处
这个恐怕是大多数产品童鞋的疑惑，就是产品经理去阅读开发文档，究竟收益在哪里？从我个人的经验出发，也许会有这么几点收益：
1、对技术理解更深刻，让产品更有想象力
试想这么一个场景，如果你是小程序的PM，但是又不去阅读开发文档，可能带来的悲剧结果就是，微信开放了许多小程序的最新能力，但是你却不知道如何应用到你自己的产品中去；或者，即使知道大概有那么一回事，却不清楚具体可以做的操作细节有哪些，在自身产品中的应用场景在哪里，而往往产品细节和场景又是那么地重要。拿我自己实操的一个案例来说，就是因为当时没有阅读开发文档，所以误以为不能获取微信群的名称，只能获取到微信群的id，导致最后在产品设计的时候没有给用户更好的绑定群信息感知的体验。
说的直白一点，没有新技术就没有新的想象力（别问我想象力是什么）。
2、更好地预估开发工作量
长时间阅读API文档，可以对接口有更加深刻的认识，那么在和开发评估开发工作量的过程中，也是有帮助的。因为很多时候，产品和开发对新旧的理解不同，所以会造成这样一种现象：新的功能不一定需要新的API，相似的功能可能需要重新做一个新的API。如果产品经理在熟悉了开发文档之后，就能大幅减少这种情况的发生，评估一个新的功能开发工作量的时候，不会仅仅站在产品设计的角度（这两个功能不是差不多么，所以基于之前的接口应该很快就能上线吧），还会站在开发的角度（噢，这里的确要两个接口来实现），这样也更有利于产品和开发童鞋的和平共处。
3、锻炼产品抽象能力
事实上，接口本身就是个非常抽象的事物，大概在很久很久以前，有一个人跟我说过一句话，接口都是可以抽象起来进行复用的，但是前端却是千变万化的。嗯，其实一个厉害的产品经理，如果真的非常熟悉接口的话，他是可以做到像搭建乐高积木一样，来通过现有的接口搭建产品的。听说在腾讯内部，腾讯会将大系统尽量拆分成功能单一的模块，在架构上尽量使用插件式的设计，高度解耦，并且会将业务逻辑服务化，比如将摇一摇、漂流瓶等都做成服务，供微信、QQ等开发团队调用，这里调用的就是API。
总结
总的来说，对于第三方平台的产品经理，熟悉官方API文档，是非常有必要的一件事情。无论是从产品设计的角度，还是对于和开发的沟通协调，以及产品经理自身修养的提高等，都会有不少的帮助，可以让你从更高的纬度去俯视整个产品。
也许，站的更高，真的能看的更远呢？
