如何获得API的商业支持

随着越来越多的企业开始采用API-First的方法，许多组织甚至围绕API构建了整个产品线。然而，这并不意味着这种方法适用于每个组织。您可能已经能够判断这种方法是否适合您的组织。

尽管如此，在技术领域内部，仍有人误以为API只适合业余项目和开发者实验，而非真正的产品。鉴于这种观念，说服管理层接受API可能显得颇具挑战。

这种挑战部分源于一些开发人员在推销API时关注了错误的事情。解决方案在于使用商业语言来描述API的好处。您不需要MBA学位，只需对API的理念和讨论方式进行微调，就足以赢得领导层的支持。以下是几种有效的方法：

将 API 视为产品

Spotlight的CTO Jason Harmon在Nordic APIs的LiveCast中强调了API即产品的理念：

“API与其他产品并无二致。

您需要帮助传统业务管理层理解API程序的相关性。”

在推出新产品时，公司会问的基本问题同样适用于API：

当我们讨论API的用例时，我们关注的并非是编写代码本身。

“你无需在高管面前演示cURL命令——那不会带来预期的效果，”Jason指出。“这些属于运营和技术层面的操作，”他继续解释。“我们应该更多地思考这些操作背后的结果和它们带来的商业价值。”

换言之，我们需要明确谁将使用这项技术，以及它将如何与我们的商业目标相连接。

从战略层面来看，这要求我们将API视为一种颠覆性的工具，它能够解决行业内的僵局或争议。例如，从单一且效率低下的传统渠道转变为更高效的集成流程，可以帮助我们解决像修补漏洞和降低客户流失率这样的问题。

根据您公司的规模和业务范围，可能已经有内部的API使用案例可供参考。如果没有，您可以研究竞争对手或其他企业是如何利用API来改变商业世界的。

API究竟如何改变了我们的世界？正如Harmon所言：”API为消费者连接新的业务流程打开了大门……它们扮演着强大的角色。”

阅读这篇文章的您可能已经意识到，API的作用不仅限于修补漏洞和减少客户流失。它们还能够开拓全新的受众群体，并通过交叉销售和追加销售策略，向这些受众展示我们的其他产品。

正如Jason所指出的，人们通常对那些一开始便提出”我们需要彻底重塑整个业务”的会议持谨慎态度……尽管这可能是许多人内心的潜在想法。然而，越来越多的公司开始认识到，相比单一产品和品牌忠诚度，人们更关心的是如何实现业务的集成和自动化。

在这一点上，获得认可的关键在于不仅仅强调API的特性和功能，而是将其定位为解决商业问题的关键方案。正如Harmon所说：”我们需要从单纯的工具提供者转变为促进不同角色在我们平台上互动的市场构建者……API正是这些互动的连接点。”

Bill Doerrfeld曾提出一个深刻的见解：“我坚信，API不仅是一种商业工具，更是一种思维模式。”即使是对API充满热情的倡导者，如果不能成为组织内公认的布道者，他们的影响力也难以扩散。

当向高层管理者推介时，他们心中可能会涌现出一连串的问题，紧随“这将耗费多少成本？”之后的问题可能是“谁将主导这项工作？”实施以API为中心的策略需要跨部门的协作，涉及从技术开发到市场营销，再到客户支持的各个团队。

与这些团队进行深入交流至关重要。深入了解他们面临的挑战和需求。探索API如何帮助解决这些问题——无论是通过集成弥补功能上的缺失，还是将繁琐的手动流程自动化。通过这些对话，您将能够展示API的实际价值，从而在很大程度上赢得整个企业的支持和认可。

尽管您的公司员工可能对API的采用持开放态度，但他们心中难免会有疑虑。虽然我们之前提到，过早深入技术细节可能不是最佳策略，但在合适的时机，这些讨论是必要的。

比如，如果管理层担心流程的混乱或分散，您可以介绍OpenAPI规范的使用，它有助于统一和简化API的开发流程。如果他们对安全性有所顾虑，您可以解释如何通过OAuth或API网关等技术来确保用户数据的安全。

但管理层无疑最关心的是API产品的成本问题。即使您提供的数字只是一个粗略估计，讨论与API项目相关的成本也能给高管们留下深刻印象，并促进他们对项目的接受。

同时，讨论API带来的积极财务影响同样重要——例如，探索可能的免费增值模式和API货币化策略。但务必保持现实和务实的态度。我们不能期望在项目启动之初就立即实现货币化。相反，初期的重点应该放在如何将API有效地整合到业务流程中。

在Harmon的演讲中，这位专家强调了API作为产品的独特性：“API作为一种产品，其独特之处在于，它并不容易以客户为中心。”这种看法可能源于API长期被视为边缘项目和花哨工具的素材，而非成熟的产品。然而，这种观念已经过时。

Harmon警告说：“如果仅为了开发API而开发，而不深入思考其实现，这是一个坏主意。”如果API不被当作产品来对待，它们就会沦为普通的商品，一种技术产物。这可能导致设计出的API虽然技术上先进，但却未能真正满足最终用户的需求。

他进一步指出：“如果你不将API视为产品，你最终得到的是工程化的设计体验，而不是为最终用户而设计。”如果开发API时没有充分考虑公司内部其他人的意见，可能会开发出一些功能丰富但缺乏实际应用场景的API。没有对用户需求的深刻理解，就很难向潜在用户或内部受众传达API的价值，这可能导致项目的失败。

Harmon最后提出了一个严峻的警告：“如果你没有从商业角度考虑构建API的原因，那么从管理角度来看，它很容易被扼杀。”这表明，如果API的开发没有得到充分的商业理由和支持，即使技术上再先进，也可能因为缺乏战略意义而被管理层所忽视。

另一方面，如果公司对API的价值持有完全否定的态度，并且没有提供合理的解释，这可能是公司不愿意接受变革的早期迹象。在这种情况下，寻求一个更愿意接受创新和变革的工作环境，可能是一个值得考虑的选择。