To B产品经理如何设计接口类产品?
本文以被动请求接口为主,讨论如何进行对外系统接口的产品设计。一起来看看~
常见的To B产品有四类:
- 第一类为管理系统类产品,如CRM、ERP、BOSS平台等;
- 第二类为办公系统类产品,如OA;
- 第三类为商家端系统类产品,如给小B端用的商户系统;
- 第四类为接口服务类产品,如聚合支付接口、人脸识别接口。
从产品形态上来说,前三类To B产品都具有用户操作界面,其设计原则和C端产品的设计方法有很大的重合,可以借鉴C端产品的设计方法进行产品设计,例如尼尔森十大可用性原则、简约设计方法等UE、UI设计方法就同样适用于前三类产品的页面设计。但第四类接口服务型产品没有操作界面,产品形态是以API接口存在,所以设计的方式与C端产品就会有很大的不同。
一、产品经理需要关注哪些种类的系统接口
系统接口分为内部系统接口(公司内部系统与系统间的接口,例如数据中台和业务系统的接口)和对外系统接口(提供给第三方调用的接口,一般都是基于HTTP/SOAP的协议接口,例如微信开放平台提供给小程序开发者的接口),内部系统接口对于产品经理来说无需过多关注,例如服务器端都会面向APP提供调用接口,产品经理只需定义好APP的功能即可,具体APP和服务器的传输交互会由开发工程师来定义。
对外系统接口包含:主动推送接口(主动给第三方发送信息)、被动推动接口(被第三方推送信息)、主动请求接口(主动请求第三方获取信息)和被动请求接口(被第三方请求获取信息)。
其中普遍的主动请求接口产品经理只需要能看懂就可以,不需要花费太多的精力提此类接口的需求,例如:自己公司采购了第三方的人脸识别接口用于业务中的身份验证,产品经理只需要提出在某某业务环节需要调用人脸识别功能即可,无须过多关注如何调用人脸识别接口。因此主动请求接口本文不做讨论,本文以被动请求接口为主,讨论如何进行对外系统接口的产品设计。
二、如何设计接口类产品
系统接口类的产品设计需要定义如下内容:输入内容、输出内容、业务异常处理方式、计费逻辑、响应速度、并发量、易用性等。
1. 输入内容
即第三方发送给我们的业务请求参数。产品经需要关注业务请求参数,同时明确参数是否可空,无需定义公共请求参数。例如数字证书在线生成接口(一般由CA公司提供的服务,应用调用该接口请求CA公司生成个人用户数字证书或企业用户数字证书),名称、证件号码、证件类别等信息属于业务请求参数中不可空的参数,没有此部分数据无法完成证书的生成;电子邮件、手机号等属于业务请求参数中的可空的参数,缺省此部分参数也可完成业务;应用ID、加密因子、加密算法等参数属于公共请求参数,公共请求参数内容无需产品经理设计,无需体现在需求文档中。
2. 输出内容
即接收第三方的请求后,经由系统处理后的业务返回参数。产品经需要关注业务返回参数,同时明确参数是否可空,无需定义公共返回参数。例如数字证书在线生成接口,第三方调用该接口后,系统需要返回cer格式的数字证书给第三方,cer格式的数字证书就是业务返回参数。输出内容同样需要明确参数是否可空,同时还需要明确是同步返回还是异步返回。
3. 业务异常处理方式
异常部分产品经理只需定义业务异常的处理方式,即产品经理对业务规则的要求。例如为保障图片质量,要求第三方通过接口上传的图片需要大于100K,则需要产品经理明确指出在此要进行图片大小检查,若不符合规则即抛出异常。系统异常(如参数错误、参数缺失等)无需产品经理来定义。
4. 计费逻辑
即接口如何向第三方计费。
计费逻辑常包含两部分:
- 第一部分是哪些情况下需要计费,哪些情况可以不计费,例如简项比对接口(通过接口上传用户的姓名和身份证号码,系统根据公安系统人口库判断输入的信息是否一致,接口输出比对一致、比对不一致、库中无此号码等结果),比对一致、比对不一致可以设置成计费,库中无此号码则可以设置成不计费。如果产品做得比较成熟的话,计费与否可以从后台管理系统中通过返回结果码自由配置。
- 计费逻辑第二部分是需要明确计费方式,计费方式大致分为按次计费(调用一次接口收取一次费用)、阶梯计费(调用一次接口收取一次费用,但达到了一定使用量后单价有所下降)、按时间计费(包月或包年收费方式)。
5. 响应时间
即第三方从发出请求报文后,经历多久可以收到返回报文。通常接口的响应时间都是毫秒级的,但系统需要进行较大运算量的业务,响应时间可能会稍微长一些,例如OCR文字识别和音频识别接口,响应时间可能要达到几秒或几十秒,因为系统需要提取照片或音频中的文字内容。
6. 并发量
即系统支持同时请求接口的最大用户数量。通常并发量需求描述中会包含用户数量、响应时间、持续时长。例如聚合支付接口,请求高峰出现在中午12点到1点午餐时间,持续时长大概1个小时,对并发量的需求描述就可以按照500用户并发数,持续1小时,事务平均响应时间小于1秒来写。
7. 易用性
即接口对第三方来说容易读懂、容易使用,有基础开发背景知识的开发工程师就可以很方便的调用成功。通常接口类产品的易用性都是通过SDK(软件开发工具包,把接口封装成JAVA或PHP等语言的调用函数)和调用DEMO(示例代码)来实现,产品经理可以提出接口需要提供配套SDK(JAVA版本或PHP版本等)及调用DEMO的需求描述。
8. 其他
除了上述需求,还有一些不常用的业务需求产品经理可以关注,根据实际情况来判断是否需要写,例如系统每秒钟能够处理的事务数量(即TPS,系统吞吐量)需求;稳定性需求,即长时间运行一个比较大的并发量,观察系统是否稳定不宕机。
对外系统接口中产品经理还会关注主动推送接口(主动给第三方发送信息)和被动推送接口(被第三方推送信息),这两种接口的设计方法和上面所提的方法大体相同,但上面提到的都是非批量模式,这两种接口的需求需要体现推送是批量方式还是单次方式,例如给监管机构上报数据的接口就采用了主动推送、批量上报的模式,产品经理需要定义清楚上报内容,上报频次,上报异常处理方式。
本文由 @产品工具箱 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
应该需要考虑:
1、接口实现方式(api还是webservices)
2、接口由谁来提供。(调用方、被调用方)
3、接口调用场景(背景)
4、接口调用的频率和触发点
5、 如果接口涉及批量数据传输(同步):
5.1 如何处理数据重复的问题
5.2 如何处理部分成功的问题
6. 如果需要创建数据库表,需要明确表的创建位置
7. 接口对接数据映射关系
8. 接口性能参数
9. 接口是否需要实时调用
10.接口测试标准(如:i、调通、ii、成功返回预期数据、iii、通过压力测试)
哈哈
谢谢分享
客气了
说实在的 我觉得这类不算是产品经理的工作范畴
叫项目实施或者管理我觉得都比产品经理来的要准确
说实在的,产品经理这个职位就是被你这种技术小白搞臭的,根据手机壳切换屏保这种需求提出来笑掉大牙,活该被打。
兄弟淡定…
哈哈哈哈 我真是觉得你好笑
在互联网公司分工越来越精细的今天还需要pm来定义接口性能 把专业的事情交给专业的人来做 pm可以给信息输入应用场景的量级描述 你怎么不要求产品经理来设计系统架构呢
你如果这么专业那叫独立开发者
再说一遍 产品经理更应该在业务应用价值和用户需求考量以及市场商业价值评估着力 这些才是pm的价值 他说这个算是传统行业中的需求分析师或者项目管理 如果非要聚焦行业 只有少数云计算和b端接口sdk类公司的pm可能需要了解技术 但我不相信他们会来定义接口
另外 我是技术出身 985计算机专业毕业 搞臭职位这个帽子别瞎扣 说我不懂技术你可能踢到钢板上了
我并没说接口文档的所有东西要产品来出,只是一些页面字段,产品部定义研发怎么知道。你没做过b端吧。另外别以为985了不起,我也是计算机985。
你看看这层开始在说什么 说的是接口性能一类 这当然不是由pm来定义
至于字段定义 这个没什么讨论空间吧 肯定是pm 建议就事论事 不要总转移论点
不好意思 没有觉得985了不起 也没觉得计算机怎么样 只是乱扣帽子这种行为有点low罢了 戾气太重
2C不用这样
我之前2b,现在2c,要求更高,设计方面的,各个规范方面