科技猎OTA实战分解（1）：快速阅读API及场景应用
如何快速阅读一个API并且转化为线上场景应用，这应该是产品经理尤其是B端产品经理必备的技能。本系列文章将从笔者亲身的一些OTA旅游产品对接经历入手，分享一些踩过的坑，背过的锅。
在一个公司中免不了有很多业务需要对外合作，当业务规模成长到一定阶段后就需要技术的介入：解放生产力，降低成本，提高效率。
此时，产品经理在了解业务需求、调研需求、解决需求的过程中就需要接触到各个外部接口。
一、API的认知
1. 场景举例
- 场景一：某平台对商户出了最新的考核标准，要求拒单率控制在3%以内，及时确认率控制在98%以上，我们还差得远——来自运营的忧虑。
- 场景二：公司有一批很好的门票产品，在我们的自己的渠道销售得非常好，现在公司想把这些产品放到几个OTA上去售卖，并且资源可控可以满足运营与要求。但是数量是1000条，假设上线到3个平台，按照1个员工手动搬运产品（Ctrl+C然后Ctrl+V），6条/天/人，处理完3个平台需要500个工作日，约2年。
上述两个场景中，我们可以明显得到的信息是人工生产力已经不能满足当前公司业务的发展需求了。
那在这个时候，API就要开始大显身手，产品经理需要从技术层面来解放生产力。
2. 什么是API？
Application Programming Interface，应用程序编程接口，即单方面约定一些预先定义的数组或字段，便于模块外开发人员获取信息并了解API想表达的细节。
API应用到上述场景中，即为了解决两个主要的问题：
- 快速上线产品到OTA平台：通过API将完整的产品拆分为若干模块，在符合平台要求的场景下传输到平台上完成上线，并且可以自动化的更新多个平台的产品信息、价格、库存等；
- 快速获取OTA平台订单信息：通过API的订阅或主动查询，以最快速度获取到各个平台的订单详情，通过标准解析后统一输出到自有ERP中进行相关处理。
还是不懂？
再举一个直白的例子：
小时候妈妈经常让我去打酱油，每次都要去村口很远的小卖部去付钱购买，再拿酱油回家；一贪玩把酱油摔坏了，回家骗妈妈说小卖部不卖酱油了，钱掉了，一顿胖揍（人工搬单、效率低下、责任不清）。
时代进步，现在有了微信，妈妈再也不用我打酱油了。
妈妈微信里面问询：老板，酱油一瓶（API数据请求）。
老板回复：30元起送，一瓶不够（API响应报错）。
妈妈再次问询：老板，10瓶酱油（API重试，数据请求）。
老板回复：好勒，10分钟送到，30元，老规矩微信支付（API响应成功）。
妈妈：微信红包30元（调用其他API接口请求）。
老板：已收款（API响应成功并确认）。
流程结束，效率提升，责任清晰，有聊天记录（日志）可查。
二、业务侧的理解
此时的流程与正常的需求处理是完全一致，需要全面的了解业务侧的真实意图，并针对API进行相关调研，最后进行需求的确认。
1. 业务想要的是什么？
我们需要对业务的两个场景进行拆分，通过场景一分析，见图1，可得业务方想得到为“拒单率3%以内”。
淘宝购物都知道供应商拒单无非三个方面：没货了，价格涨价了，产品拍错了；即要降低拒单率，在这三个方面进行优化即可。
“及时确认率98%以上”：及时与确认是两个维度，一个要求对时间掌控强，一个要求订单要确认成功；即我们需要深入分析如何提高及时响应订单，成功确认订单（与上一个需求环环相扣）。
综上所述，我们需要的API不仅要满足产品更新的需求，也需要满足订单的需求。
图1 场景一需求拆分
场景二的分析，业务方的需求比较简单，即实现快速上线。但我们对需求进行拆分挖掘（见图2），发现需求除了要求上线产品基本内容+价格库存外，其实还有一个非常重要的隐藏需求，即下单相关属性的需求（因为部分产品上线前就要预置下单信息，例如必填信息，是否限购等）。
综上所述，本需求除了产品API，还应该去匹配API中其他必要字段，并可能需要有分平台的管理系统来分别匹配各自平台的不同字段需求。
图2 场景二需求拆分
2. API怎么做需求调研？
很多人会问上面的需求是怎么分析得到的？API不就是完成数据解析，存储就可以了吗？
此言差矣，API数据接入其实只是API接入的一小部分，更多是数据接入后的处理兼容，以及如何让数据发光发热。
API的需求调研主要分为两个方面来做：
首先，将业务分为已经存在的业务优化方向以及新增业务的功能新增方向。
- 已经存在的业务优化方向：例如已经接入了A平台，现在要接B平台，工作量一致，内容相似度较高，只需要将我们之前积累的对接经验搬出来套用即可；
- 新增业务的功能新增方向：例如已经接入了产品更新功能，现在要接入订单确认功能，完全不同的业务，需要我们重新分析业务需求，重新定义接口数据。
此时，我们再回来对之前的场景一、二进行深度挖掘与分析。
场景一中对于拒单率的要求，我们初步理解为其实是对库存、售价、产品内容的要求，针对性的场景中需要满足我们对库存的分发实时把控，可以理解为某个平台库存为0并不等于总库存为0，此时我们需要采用总分的结构来设计功能；针对价格的更新亦是同样的道理，针对不同平台的人群画像，其采用的销售策略是完全不一致的。
但是针对产品内容来说，则需要保持高度一致，因为所有的人出游产品是一致的那披露的内容也应该是一致的，必须要做到全平台的一致，既范了流程，也节约了后续开发工作量，如图3。
图3 场景一需求进一步拆分
在场景二中，需求比较单一，但是如果我们只是单纯完成业务方的表面需求上线产品，我们会在两个阶段发现问题：某些平台上线产品，发现某些非产品信息的参数为空是不能上线的，例如每单起订人数，是否分成人儿童，超过规定展示的SKU数量的取舍；或在第二个阶段上线后，业务方发现很多产品需要二次匹配上述参数，此时会再次提出类似需求。
所以，我们在需求挖掘阶段应该尽可能发现业务方的隐藏需求，并评估是否在本次范围内一并满足，如图4。
图4 场景二需求进一步拆分
3. 需求的进一步确认
在我们完成前一个阶段的需求挖掘后，我们需要进行需求的确认，可以理解为需求拆分了之后进一步确认需求该怎么做，该在哪个模块做，以及最后的收益与风险评估。
需求该怎么做？
按照上文的思路，还是进行拆分：
1）如果已有ERP，那就是数据接入。此时你的架构已经成型，或者内部规范已有，并不能做太多的变化，只需要按照已有经验获取字段、映射字段、处理字段即可。
2）如果没有ERP，要从头开始接入，在前期的设计中就需要考虑两个方面：
- 自身业务的通用性，即业务内部流转并不受外部API的影响，例如我在X宝上卖衣服时可以通过这套系统订货，不在X宝上售卖时我正常的线下门店也可以利用此套系统进行订货和结算；
- 对外的可拓展性，即业务可以接收多个平台的数据，例如我即在X宝上售卖衣服，也在X东上买衣服，但都可以通过这套系统进行订货和结算。
结合这两方面，我们倾向于用两个平台来处理，内部ERP处理自有订单或内部关联逻辑的处理；外部API平台着重处理的交互处理、规范处理，可拓展性体现在无论哪个平台的数据均需要处理后按标准数据输出。
该在哪个模块做？
电商的交互离不开三大模块：产品、订单、财务。
推送产品去售卖，获取订单数据去预订，最后进行财务结算；我们只需要模仿人工处理时的流程，沿着流程进行梳理。
产品上线>平台售卖>平台下单>我司后台预订>反馈平台预订成功>平台结算>我司财务结算>订单核销
上述流程的拆分，即设计到三个管理模块：产品管理、订单管理、财务管理。针对此系统，我比较推荐如下的整体设计，如图5，后续我们会详细分模块来说明。
图5 整体系统框架
4. 收益与风险评估
API的对接与其他需求评估一样，也需要进行“技术+工作量+收益”的综合评估来审核是否值得展开。
例如，API处理流程复杂，虽然上线后可以解决很大的问题，但是其研发费用为10W，人工1人/年/5W支撑，即我司开发成本需要两年才能cover，这样的项目并不是紧急且重要的。
所以，业务口中的“技术一下就搞定，为什么要人去做？”，我们需要给出合理的解释，尽量是可量化的数据。为此，我们一般采用ROI的评估模式进行调研。
ROI=T时间段内利润/研发投入成本，T=6个月/12月/18个月，三个时间节点来预估产出。
- 当ROI>1，且T=6/12/18时符合项目投入期望，如果T越大，ROI越高则后期回报越高；
- 当ROI<1,且T=6时表明项目短期内效益不佳，需要继续查看12/18个月收益预期，综合评估；
- 当ROI<1,且T=6/12/18时不宜投入。
风险评估也是必须可少的项目，除了上述的评估，此外接口的稳定性、可靠性，数据的安全性，项目整体的预计排期也是我们需要的。
API讲求高效处理，如果排期较久可能并不利于解决业务面临的问题。
后续笔者还将从API阅读切入，加以实际案例分享来更生动地说明主旨。
感谢阅读。
本文由 @寒松 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议