从稳定生产角度谈对业务的思考（得物开放平台）

开放平台（DOP）主要是将自己的资源或者服务通过API的形式开放给第三方合作伙伴或者客户进行对接，帮助他们快速构建自己定制化的业务系统，其核心在于对数据进行系统化的交互，常见的数据交互表现形式便是API。简单来讲，开放平台就是将得物现有的能力以接口的形式体现，实现系统数据交互。

那么开发者在面对数目众多的API时，如何接入、如何快速支撑他们的业务其实是开放平台技术运营需要进行思考的。 

什么是问题？

问题就是事物的矛盾，哪里有未解决的矛盾，哪里就有问题。

而思考是行为的种子，问题的出现则会激发我们思考的能力，有了思考才有解决问题的方法，才能找到独立思路的可能。

我们可以通过读书搜集知识，但必须通过思考将糠和麦子分开，从而带给我们新的认知，指引我们通向解决问题的大道。 

作为直面开发者的TS，我们这边收集了各个渠道的线上问题，通过数据分析，可以明晰哪些问题是开发者自身解决不了的，需要技术支持介入；这部分在之前的公众号文章中也有分享过，详细信息可参考浅谈TS如何提高自主处理占比。

这里简单展示一下：

此图为开放平台业务对接流程： 

从图中可以清晰看到在开发者进行对接流程中，需要经过多处审核点，不仅要完成相关的资质审核，还要完成业务的对接。

从用户注册到应用上线的整个流程，个个环节都可能带来相关问题咨询。

问题分析

开放平台接入属于技术+业务的对接，要求开发者不仅要有相关技术研发经验，又要对所接入业务有一定的理解；同时，接入过程中会存在多次审核，从入驻到应用上线的每个环节都有可能产生关联的问题，倘若开发者通过自身经验或者官网的对接FAQ文档等方式后仍无法准确定位和排查问题的话，那么问题就会流转到技术支持侧，从而增加了一定的问题咨询量。

业务思考

接入过程中的多次审核，是平台对开发者资质管控、提升整体开发者水平和平台能力使用合规等必要的手段，可见审核环节是开发者接入的重要一环。那怎么能避免审核驳回呢？

这边通过分析并与审核人员进行沟通，获取到了审核的几大要素：

• 开发者提交的数据是否合法；

• 是否可信；

• 开发者是否具备对应资质；

• 申请的权限是否符合其业务诉求等。

但这些要素并未在开放平台门户流程或文档中充分展示出来，对于开发者来说是一个黑盒。

对此我们采取了针对性的方案，目前关于应用审核规则以及权限说明等已被整理至开放平台首页优化和文档专项中。

此外，开发者在遇到自身无法解决的问题时，往往会通过搜索、阅读文档等方式排查和定位问题；这时就要求我们对开发者接入流程、排查步骤、业务讲解文档做到讲解清晰、逻辑完整，能快速解决问题。

但对于技术层面上的问题，比如自身bug或者开放平台相关报错时，开发者通常也无法实现完全自主处理，因此对于此类问题，开放平台对外提供了有助于开发者自排查的工具，比如沙箱和测试工具等。

总结

学而不思则罔，通过对开放平台业务的思考，我们可以发现问题产生的原因是接入流程较为复杂，而且审核节点较多，开发者很难仅仅通过搜索文档对问题进行排查和定位；因此在遇到bug类问题时，开发者便无法完成自主处理， 需要依赖于在线技术支持。 

在回答这个问题之前，我们可以先思考一个问题，开发者在面对问题时，能否通过现有的手段定位和解决问题（比如通过：文档讲解、问题搜索、排查工具、测试工具等）？

倘若不能解决时，开发者还可以做什么？ 

问题分析

理想状态下：

开发者完全可以通过现有的接入文档，开发者指南，常见问题FAQ等方式，来完成接入和上线，这几种解决方法应该类似于一个漏斗，而获取在线技术支持则是最后一步。 

那么从开发者的视角来看，我们可以使用哪些工具协助定位问题和解决这些疑难杂症呢？

目前开放平台已提供了以下“良药”：

• 开发者指南：通过此指南可以指引开发者一步一步完成注册、入驻、资料填写、提交审核、创建应用等，在API文档里也展示了API的出入参数等详细信息；

• API接入文档：提供API接口的详细url、出入参数、调用方式等信息；

• 业务场景文档：描述不同业务的适用场景以及该业务所需的API，表述了各个业务的接入流程；

• 常见问题FAQ：开发者会面临的常见问题收集，提供相关的排查思路和对应的解决方案等；

• 自排查工具：如测试工具，IP信息工具、沙箱环境等，可辅助开发者进行问题定位和排查。

既然我们已经提供了很多接入的文档或和问题排查工具等方式，但它是否可以真正满足开发者的诉求呢？

答案明显是否定的，那为什么现在没有达到这个理想状态呢？

业务思考

鉴于得物业务模式和普通电商的差异，很多经验无法精准套用，比如在出价、库存、对账、交易等方面，流程实为复杂；同时开发者会提出各种各样的业务诉求，总是希望我们平台能完成其需求；此外开发者遇到的各种技术问题，我们平台的现有的基础设施也很难对其痛点做到全面覆盖并最终解决问题。 

总结

我们从开发者定位和解决问题流程中可以看到，开发者强依赖于接入文档、业务讲解文档、排查工具等手段的现象表明：文档和工具是否易用以及是否可快速解决问题，对降低问题咨询频次有颇为重要的作用。

基于这个目标，我们针对性地对开放平台首页和文档类进行了专项治理，使其符合清晰、易用、提效的设计，从而进一步提升开发者的用户体验和开放平台的对外形象，使其脱胎换骨，内与外同时熠熠生辉。

以下简单分享一下部分开放平台首页文档专项内容：

• 首页布局改版

  首页展示内容/图片，确认整体布局和展示内容。

• 背景：

  目前官网首页展示信息量太少，对外展示形象不是特别专业。

• 建议：

  可增加平台优势介绍，业务场景等模块，提升开发者用户体验，如图所示

        首页最新公告模块

• 背景：

  信息展示不全，可获取的有效信息不足，开发者体验不友好；，如图所示：

• 建议：

  信息展示不全，可获取的有效信息不足，开发者体验不友好，如图所示：

        首页最新公告模块

• 背景：

  目前官网缺少首页底部快速导航模块， 如图所示：

• 建议：

  新增快速导航模块，可帮助开发者快速获取有效信息，提升接入效率，参考示例：

• 文档内容优化

• 增加视频讲解

• 增加应用介绍 

• 文档目录优化

• 背景：

  目前目录层级展示不规范，文章关联度不够，给开发者整体混乱、不统一的体验；

• 建议：重新规划目录展示名称和内容，统一整体布局。

• 增加全局搜索功能

• 背景：

  目前开放平台官网暂无全局搜索功能，开发者无法快速搜索和定位到解决方案，效率不高；

• 建议：

  增加全局搜索功能，搜索内容包含开发者文档，公告，api等，如图所示：

• 增加应用审核规范/审核规则

• 背景：

  目前开发者在不清楚审核规范的情况下，容易被驳回，造成入驻时效较高；

• 建议：

  增加应用审核规范/审核规则，提高整体接入时效。

提高效率应是我们永恒的追求。

在有限的时间和生命中做到高效率，就能获得很多有意义和有价值的事物，对别人和自己都是幸福和伟大的事情。 

问题分析

在开放平台应用上线和应用修改中存在着多级审核，而开发者总是迫切希望能迅速通过审核和上线；为了避免出现审核流程中应用无法使用的情况，毫无置疑审核时效越快越好。

而从审核人员（现开放平台审核人为产品）角度出发，审核时间是安排在每天固定的时间段，并在审核中需要对开发者提交的申请进行一一判定其是否符合开放平台授权使用策略，通常上审核时间是不定时的。 

业务思考

对系统准入而言，审核操作提高了开发者的门槛，并旨在降低问题出现的概率和保证系统安全。

在产品设计中，出于安全和管控的角度，开发者入驻、应用创建/修改、IP设置、权限包申请、应用上线等需要经过审核的操作貌似必不可少。

经数据分析后，可发现应用修改和权限申请的占比较高，而应用修改中IP白名单的设置又是其中最大占比的地方，在通过与审核人员沟通，与安全同事咨询确认后发现审核人员并不能精准判断其IP是否符合规则，因此目前的处理审核的策略是全部通过；从安全角度出发，由于修改应用IP白名单是需要使用其账号密码登陆开放平台门户控制台，所以在操作修改IP白名单时可判断其行为是可信任的，与此同时，我们也参考了其他开放平台的做法，应用IP白名单审核环节可以删除，这在后续的问题反馈中也验证了此方案的价值，上线后的审核咨询量降低了约为50%并实现了整体接入效率的提升。

那么从另一个角度来看，应如何持续降低审核时效和产品的时间投入呢？

我们可以在人工审核判断点：如法人实名认证、营业执照资质认证等，通过系统化自动认证方式实现判断：接入如百度实名功能等手段，完成自动化的初级校验，辅助产品审核决策，提高审核效率。 

总结

在安全允许策略下，降低审核节点，例如去除IP白名单审核环节，接入实名认证、营业资质自动认证，入驻流程部分自动化识别等方式可有力提升审核时效。

在线上对接问题中，即使开放平台官网已提供相关常见问题解答，或者FAQ文档，仍经常会有开发者提出重复问题的情况。

问题分析

即使可从现有的排查手段解决问题，但开发者仍将问题转到技术支持侧的原因究竟在何处呢？

这就需要我们思考，对外文档是否已涵盖充足的信息，是否存在逻辑不一致，文字/描述错误，内容是否易于理解等问题。

从以上几点入手，我们发现部分现存文档确存在图文老旧、几经改版部分字段描述缺失需要及时清理和删除和一些讲解说明与新版业务前后逻辑不一致等情况。 

业务思考

一个能解决开发者疑惑的文档应该是什么样的呢？

是否所有的文档都应符合这个要求，这就需要我们制定一个标准的文档发布流程，对公开的文档多角度审核，提高其质量。

 一个合格的文档在格式上应侧重以下几点：

• 一二级标题和正文格式是否规范

• 文章逻辑脉络是否清晰

• 信息量是否充足且直观

• 图表是否具有可读性

• 所表述业务是否能形成完整不遗漏的讲解

• 语意文字是否错误、存在歧义点等

总结

对外文档应制定标准，并经过多重审核，同时对于审核点：标题、逻辑、语意、关联文档等需重点关注。

在面对问题咨询时，有些看似简单易答，其问题的背后实际是开发者在寻找业务的解决方案；比如开发者在咨询资金对账问题时，提问的点往往是订单字段中有没有买家支付金额、为什么没有运费字段、是否有平台补贴金额等。

如果仅仅对这些问题进行回复，我们可以回复没有或是暂时不提供，但实际真正需要思考的是在这些问题背后开发者的提问点，如何对这些问题进行彻底的解惑，辅助开发者进行决策是值得我们深度探索的。

在询问订单资金类需求这个案例中，开发者实际是在对资金对账的业务进行询问，此时我们应引导开发者选择现且完善的资金对账类API，并辅助开发者完成业务建设，从根源解决问题。 

作为用户&产研&运营的沟通桥梁，技术支持在对接问题中不仅只是解答问题，还可以对问题进行归纳和复盘，并提炼为用户需求，跟进落地，推动业务发展。

在开放平台侧，技术支持通过与开发者的线上问题对接渠道，来获取和发掘开发者的需求和产品优化点，并分析其痛点并形成数据结果，在复盘会将需求反馈给产品，并与产研一同重新分析该需求，包括需求优先级、需求的根因和意义、技术开发的可行性、开发紧急优先级等多重因素，确认需求点，通过产品输出需求文档，技术进行功能开发，完成产品的迭代更新，这是目前普遍的互联网公司的一个工作流程。

同时，技术支持成为整个环节的发动机，围绕开发者的难点和痛点展开一系列解决方案，在新功能上线时，能够进一步深度运营，带动整个项目的发展，从而能够在整个项目里处于运筹帷幄之中。

下面举例介绍几个在开放平台对接中挖掘出的开发者需求。

需求背景

在开放平台门户和开放平台运营端后台，暂未有更换开发者资质和法人、管理员信息的流程；因此部分开发者在所属公司离职后，该公司面临需要更换信息的诉求，对此也只能通过邮件申请，研发手动操作来进行维护，其流程较长且不规范，容易出错或者遗漏。

此外目前开发者账户密码修改只能通过重置密码途径，暂无无快捷入口，无疑带来了部分咨询量。 

需求思考

当修改资质、管理员信息等核心数据时，应做到流程化、实现可追踪操作记录以及审核留档等步骤。

非正常流程修改数据则会带来系统安全风险，我们应通过门户控制台进行流程变更、申请、审核等操作，确保其变更的合规性。

另外增加修改密码的快捷方式，也会对开发者体验有较大提升。 

需求背景

在开放平台现有的门户首页样式中，存在以下问题：“最近公告”样式不清晰，标题被截取信息量较少，首页无业务介绍和操作指南，页脚无快捷导航等，整体在易用性和信息上仍有较大优化空间。

需求思考

技术支持应该作为产品发布后最先使用和反馈的人，在门户上应以快速获取信息，简单易用为出发点，切身体验，并提出相关建议。

首页门户中，公告栏可以通过增加其宽度，避免遮盖重要信息；此外首页部分区域应对业务支持范围和场景进行展示，同时增加页脚快速导航模块，提升用户使用体验。

目前此需求已反馈产品，并处于跟进中。 

技术支持在日常工作中主要负责对其业务域的对接问题解疑答惑，与此同时也会收到很多一线反馈问题的数据；基于这些数据，我们可以发现很多有价值的事情。

出于自身对业务的理解和思考，我们也能尝试去做到：对自己所负责的业务提出建议和反馈，并针对细节全方位分析，发扬工匠精神，并致力于从问题持续收集、总结、归纳、提炼需求中降低问题咨询和提升效率，做到极致，这也能对业务的发展和自身成长起到至关重要的作用。